A Cautionary Tale: The Poorly Defined Problem Statement

Once, an engineer named Sam was tasked with improving the efficiency of a factory's assembly line. Under tight deadlines, Sam hastily put together a problem statement: "The assembly line needs to be faster."

Without clearly defining the current inefficiencies, the desired improvements, or specific criteria for success, the team embarked on the project. They invested heavily in new machinery and software, believing these upgrades would solve the undefined problem.

However, the vague problem statement led to misaligned efforts. The new machinery caused unexpected downtimes, and the software was incompatible with existing systems. Instead of improving efficiency, the changes disrupted the assembly line, leading to increased costs and production delays.

Sounds familiar? I'm sure it puts a smile on many people’s faces. This situation happens all the time.

Here is another interesting fact. The story above is 100% written by AI (ChatGPT). Why is this important, you ask? Well, for two reasons:

1. It is hard proof that this situation is so common that even AI can come up with this lively story.
2. I personally had firsthand experience with people who have no idea what the purpose of the problem statement is, and yet, the machine trained by humans does.

Food for thought...

What is a problem statement and why is it so important?

We discussed this in detail in one of our recent articles, and everyone is encouraged to read it. I’d like to reiterate the definition and the importance of having a proper problem statement.

Definition

A problem statement is a clear and concise description of an issue that needs to be addressed. It identifies the gap between the current state and the desired state, providing a foundation for research and problem-solving efforts. It typically includes the problem’s background, its impact, and the criteria for a successful solution.

Importance of Problem Statement

• It focuses the team's efforts
• It guides research and development
• It clarifies objectives for all stakeholders
• It improves communication between the team and stakeholders
• Most importantly, it facilitates problem-solving

The goal of this article, however, is not to repeat what we've already said, but to highlight that a properly defined problem statement is a rare occurrence nowadays. Engineers often don't invest enough effort in problem statements and sometimes skip them altogether. Let's try to understand why this happens. Understanding the reasons is a step closer to solving the issue.

Why Many Skip Over the Step of Problem Statement?

Many individuals and teams skip over the step of defining a problem statement or invest very little in it for several reasons:

Lack of Understanding

I think there are two parts to it, both contributing to preventing people from investing in this simple concept.

First is the lack of understanding of the importance of a well-defined problem statement and how it can guide and streamline the project. We already explained that above and in the blog article, so I won’t repeat myself.

On the other hand, if people don’t understand the systems or the problem space well enough, it becomes extremely difficult, if not impossible, to define a problem statement. Surprisingly, many engineers we’ve been working with do not understand the system well enough, even though they have worked on it for years.

Now we have an interesting situation. The engineers don’t have enough information to define the right problem statement, yet their management demands it. They must produce something to satisfy the manager but are never given enough time or support to do it properly.

The worst part is that their managers are in the same situation. They typically know even less and have no chance to correct the engineers. So, even if this step is not skipped, it will be done just for the sake of a “checkmark.”

Time Constraints

Time constraints directly contribute to the lack of knowledge. Everyone is pressured to deliver solutions quickly and sees defining the problem as a waste of time.

While it may feel true, this approach is very short-sighted. More often than not, it leads to addressing symptoms instead of solving the actual problem. The issue is managerial. Managers expect quick results, and they get them, in a way. A short-sighted manager will accept symptom-level mitigation as a solution. I rarely see this process continue to its proper conclusion where the root cause is addressed and the problem is solved. People get busy with other "important" things, and the mitigated issue takes a back seat until something blows up again. And it will, because every "patch" like that always creates more problems down the line.

Overconfidence

In almost every team, especially the large ones, there's always someone who thinks they know everything. If I had my way, these would be the first people out the door. This is a discussion for another article, but these people inject overconfidence into the team. While they don’t know everything—no one does—they create the illusion of progress. This includes the problem statement as well. The "smart" ones either push to avoid having a problem statement because they think they don't need it, or they create one that doesn't serve its purpose.

The reason for this is a lack of understanding and a lack of willingness to learn and gather enough information to make a real difference. Again, I blame the management who rewards this behavior. Many prefer quick short-term results instead of investing in a long-term vision that allows further development.

Assumptions

Teams might assume that everyone understands the problem without needing to document it. Wrong! The document itself is not the point. The process of creating the document, in this case, a problem statement, forces the team to invest time in understanding the issue.

Another aspect that contributes to the effect of assumptions is seniority and human psychology. If a senior engineer makes strong assumptions, junior team members will likely accept them, even if they don't necessarily agree.

Guess what? This is a managerial problem too. The right culture isn't set to overcome this issue. It's about training people and providing them with the right tools for the job. One good example is from Jeff Bezos. He mentioned that in his meetings, they let the more junior contributors talk first. Great! It's one way to solve this problem.

Focus on Solution

There is often a tendency to jump straight to brainstorming solutions without spending enough time defining and understanding the problem. People are eager to find quick fixes and show immediate progress. This approach is often driven by pressure to deliver results and a desire to appear proactive. Additionally, the excitement of generating new ideas can overshadow the step of thoroughly analyzing the problem. Why? The only reason I can think of is unhealthy competition and poorly set expectations within an organization. You guessed it, a managerial issue.

Last Thoughts

Skipping the problem statement can lead to misaligned efforts, wasted resources, and solutions that do not effectively address the core issue. Ultimately, the end client pays the price.

We have invested time and effort to help our users define a proper problem statement. We would love to hear your feedback and thoughts about it.