First, we need the problem, not the solution.

Anyone working in product development knows the challenge that discussions in meetings with stakeholders quickly slide towards solutions. This is understandable because people want to solve problems quickly. However, jumping to a solution too early is dangerous because we often don't understand clearly enough what problem we actually want to solve.

The topic isn't new. In Requirements Engineering and Systems Engineering, it has long been part of the basic understanding. Nevertheless, it is still surprisingly rarely truly anchored in practice. Especially outside the narrower Systems Engineering bubble, the understanding of the problem is often viewed as a brief obligatory part (or skipped) before something „concrete“ finally happens. Yet, it is precisely at this point that it is often decided whether a development project will run clearly and economically later on, or if unnecessary complexity and friction will arise.

The problem with the solution

The drive to find a solution is an expression of action orientation. It becomes difficult when the discussion of solutions supplants the understanding of the problem. Then, the actual concern is no longer openly investigated, but a direction is implicitly already given.

This is often evident in the language used. Statements like „we need a compressor,“ „we have to expand the interface,“ or „we should introduce an additional review step“ initially sound plausible and professional. In reality, however, they usually describe not problems, but already suspected solutions. This narrows the solution space early on, before it's even clarified what the cause of the problem is. Or worse, symptoms are treated while the actual problem remains unsolved.

In practice, this often leads to the first available solution being chosen rather than the best one. However, an early, poorly understood solution can lead to high costs in the long run. It can unnecessarily complicate architecture, make teams more coordination-intensive, or mask existing weaknesses with new artifacts.

Solution-oriented thinking leads to the first available solution, not the best one.

This is particularly problematic in complex development environments. When multiple disciplines collaborate, when suppliers are involved, or when a product has both physical and digital components, poor decisions become expensive early on. An imprecise problem definition doesn't stay local then. It travels through specifications, models, interfaces, and processes, solidifying with each further concretization.

A timeless example from Joel Spolsky

That this problem is not new is shown by an older, but still worth reading, text by Joel Spolsky from 2000: Painless Functional Specifications – Part 1: Why Bother? Joel vividly describes why teams without a clear functional description often jump directly into implementation, unnecessarily committing to a specific technical solution too early. His point is less about „more documentation“ and more about „better problem clarification.“ Only when it's clearly described what a system should achieve from a user's perspective does the opportunity arise to meaningful weigh different solutions.

This is more important today than ever. In many organizations, the reflex to jump straight to solutions has only grown stronger. Agile ways of working, rapid iteration, and high pressure lead to the temptation to skip problem analysis. However, if analysis means truly understanding the problem, then it is a means of risk reduction.

A classic misunderstanding is that early problem analysis is perceived as „slow,“ while early solutions are considered „fast.“ In reality, it's often the exact opposite. As long as we are still in the realm of thought and language, changes are cheap. As soon as an idea is concretely implemented, the cost of changes increases significantly.

Systems Thinking as an Antidote

This is where systems thinking comes into play. Systems thinking is not a specialized technique for methodology enthusiasts, but a very practical mindset. It helps to first consider a situation as a whole before discussing individual actions. That is precisely where its value lies.

A good systemic perspective doesn't immediately ask which solution should be implemented. It first asks which actors are affected, what interactions exist, where system boundaries lie, and which causes and effects can be distinguished from one another. This sounds abstract, but in practice, it's often precisely the difference between superficial symptom management and robust problem-solving.

A recent post on IO+ puts it well: "Systematic Thinkers" are those who can structure complexity, make interdependencies visible, and avoid prematurely reducing technical challenges to isolated measures. Precisely this ability is becoming increasingly important in development organizations because products, teams, and dependencies are constantly becoming more complex.

In this sense, systems thinking is also not the opposite of pragmatism. Rather, it is a prerequisite for meaningful pragmatism. Those who do not clearly distinguish between the problem space and the solution space may act quickly, but not necessarily effectively.

Needs and requirements are not the same

In requirements engineering, there is a well-established terminology for this distinction. The INCOSE Guide for Writing Requirements distinguishes between Needs and Requirements. This distinction is by no means just academic.

A Need describes the need or concern from a stakeholder's perspective. The focus is outward: on usage, operation, value contribution, or environmental constraints. A Requirement It is directed against it, focusing more on the system and describing what this system should achieve or comply with. This brings you closer to the solution. INCOSE explicitly formulates this relationship: Requirements are derived from Needs and other sources.

This is an important point because this intermediate step is often skipped in many projects. Then requirements are formulated, even though the underlying need is still unclear. The result is often very concrete sentences that, while technically unambiguous, only incompletely represent the actual problem.

A simple example makes the difference clear. The statement „The system should provide PDF export“ is a typical requirement formulation. It is concrete, but already heavily solution-oriented. However, a completely different need could be behind it, such as: „Users must be able to pass on results outside the system in a comprehensible and audit-proof manner.“ Only from such a description can it be reasonably deduced whether PDF export is indeed the right answer or whether another form of provision would be more sensible.

This clean separation is so valuable because it keeps the solution space open initially. It doesn't prevent you from arriving at concrete requirements. It merely ensures that these requirements are better justified and more stable.

Black Box vs. Glass Box

A very useful mental model from systems engineering in this context is the Distinction between Black Box and Glass Box. It also helps to clearly separate the problem and solution.

The black-box view initially considers a system from the outside. The focus is not on the internal components or the technical implementation, but rather on the interactions with the environment. What are the inputs? What are the outputs? Are actors or neighboring systems relevant? What information, energy, materials, or signals cross the system boundary?

This perspective is so valuable because it deliberately omits the solution at first. The question is not: „How does the system build that?“ Instead, it's: „What must the system achieve in its context?“ This is precisely a precise form of problem description.

Only then is the step into the "glass box" worthwhile. This deals with the internal structure, meaning decomposition, components, responsibilities, interfaces within the system, and ultimately architecture and implementation. This step is necessary, but it is methodologically stronger when it builds upon a clean black-box description.

Unfortunately, the opposite often happens in many development projects. Teams discuss components, modules, software parts, electronics, or mechanics early on, even though it's not sufficiently clear what system effect is actually stably required in the context. Then they want to talk very precisely about the internal structure while the external task is still unclear. This often creates architectural work with a weak foundation.

A practical introduction: The context diagram

The question, of course, is how to apply this way of thinking in everyday life. A very practical answer to that is: with the System context begin.

Especially when stakeholders have little experience with requirements engineering or systems engineering, a context diagram is often the most accessible entry point. It doesn't immediately force clearly formulated requirements, but rather a shared view of the system and its environment first.

A context diagram helps to focus the conversation on relationships and interactions. Who interacts with the system? What information or services are exchanged? Where is the system boundary? What external dependencies or constraints are relevant? Such questions almost automatically bring us closer to the actual problem.

that's in Workshops particularly helpful. Because open questions about „requirements“ immediately elicit solution-oriented answers from many stakeholders. On the other hand, a shared look at a system diagram often leads to more precise observations. Then statements like these emerge: „This information actually comes from the supplier,“ „this is where the misunderstanding arises,“ „the problem lies before this step,“ or „we've been talking about the wrong system the whole time.“ Such insights are significantly more valuable for subsequent solution development than hasty functional requests or solution technologies.

When stakeholders drift into solutions

Naturally, even with a good start, you can't prevent stakeholders from constantly thinking in terms of solutions. That's normal and not fundamentally wrong. The only important thing is that you can methodically translate these contributions back into the problem space.

A very simple moderation technique often helps with this. When someone formulates a solution, you don't have to shut it down immediately. Instead, it's worth translating it back into a question about the system's effect or the interface. For example, if someone says, „Then we just need an additional dashboard,“ the interesting follow-up question isn't what that dashboard should look like, but rather what information problem it's actually meant to address. Who needs what information, when, in what form, and for what purpose?

This type of follow-up question is astonishingly effective. It takes the contribution seriously without prematurely pushing the group towards implementation. At the same time, it strengthens the team's ability to distinguish between observation, need, and solution. And this, ultimately, is one of the most important competencies in good systems work.

Conclusion

The idea that we should understand the problem before discussing solutions is not a new realization. What's new, at most, is how consistently this simple insight is lost again in many organizations. Under time pressure and implementation pressure, problem analysis often seems like a luxury. In reality, it is a means to avoid unnecessary complexity and costly mistakes.

Requirements engineering and systems engineering have long offered suitable conceptual tools for this. The distinction between needs and requirements, working with black boxes and glass boxes, or starting with context diagrams are not theoretical textbook concepts. They are practical aids for having better conversations and developing better systems.