The Problem Solving Framework

Define your problem before jumping into immediate solutions

Effective problem-solving isn't about jumping quickly into solutions; it's about solving the right problems in the right way.

Personally, I don’t like never-ending discussions, finding another blocker, or asking for one more requirement in your ticket. I prefer to move fast with limited information and some degree of uncertainty. I strongly believe in an iterative approach, where relevant data and good decisions emerge during the journey.

Yet, such an iterative approach only makes sense if we work on problems worth solving with the most optimal solutions to them.

Here, you can find a PDF cheat sheet that sums up this article.

How to Solve Problems?

For inspiration on building a problem-solving framework, I recommend the short, humorous, yet insightful book "Are Your Lights On" by Don Gause and Gerald Weinberg. This book emphasizes the importance of carefully defining the problem before rushing into solutions. It challenges readers to think critically, question assumptions, and consider multiple perspectives.

---

In organizations where the engineering team is viewed as a "feature factory", the discovery process can be perceived as wasteful. As long as software engineers don't produce something tangible (like pull requests or features), their work is undervalued. The trap here is the assumption that Product Managers, senior management, or the CEO have all the answers.

Side note: I have covered the true role of software engineers in empowered organizations in a few of my past articles:

• Building a Team of Missionaries, Not Mercenaries

• Focusing on Solutions, Not Problems

In such environments, engineering teams come up with solutions too quickly. This isn’t surprising in the end, as they are inventors and creators with strong technical skills, often the only ones in the company who can build things. They are frequently assessed by what they produce, not by what they think through.

But here's the trap: in order to solve a problem, it must first be defined. If engineers jump immediately into the solution, it doesn't mean the problem is undefined. It means it's defined with some (hidden) assumptions, biases, and personal interests.

There is also another challenge with software engineers. If not jumping into solutions too quickly, they also tend to overthink their problems indefinitely, multiplying missing requirements, finding edge cases, and overall getting stuck in a quest for perfection.

What's the Problem?

In the complex world we live in, the initial solution is rarely the optimal one. Complex problems may have multiple definitions, none of which is ultimately the right one. A problem may have multiple stakeholders, each with their own solution, and these stakeholders may have different power to articulate their preferences (the loudest one in the room, the most senior on the org chart, or those who prefer to remain silent).

The book describes problems from a few different angles, For example:

A PROBLEM IS A DIFFERENCE BETWEEN
THINGS AS DESIRED
AND THINGS AS PERCEIVED.

—"Are Your Lights On"

This means that to solve a problem, you can either focus on achieving the desired state or change your perception of the problem. You can check the book for more ideas or continue reading for a systematic framework I came up with based on the lecture and my personal experiences.

---

The Problem-Solving Framework

Here’s a framework that will help both groups:

• For teams that tend to jump into instant solutions, this framework provides perspective and support in problem framing.

• For teams that overthink their problems, it helps narrow the focus to "just enough" information to start iterations.

Inspired by "Are Your Lights On", here is an 8-step framework to help find optimal solutions for problems faced by software engineering (or, more generally, product engineering) teams.

The 8 Steps of Problem Solving

1. Recognizing the problem (What’s a problem?)

2. Defining the problem (What are the facts behind the problem?)

3. Exploring the problem's depths (What are root causes of the problem?)

4. Identifying stakeholders (Who have the problem?)

5. Assessing the willingness to solve (Is it worth solving the problem? Is it aligned with broader goals and strategy?)

6. Developing solution strategies (What are options for solving problems? Which are the optimal ones?)

7. Implementing the solution

8. Monitoring and reviewing (Are success metrics defined and achieved through the solution?)

The 8 Steps of Problem Solving - Explained

The entire article and PDF/Notion/doc templates are available only for paid subscribers. You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!