Defining the Problem – Distinguish Between Real and Fake Issues

gpt-4-turbo has translated this article into English.

Over the 15 years of working in software development and system architecture,
the most common scenario I’ve encountered is this:

“I was solving a problem, but that problem didn’t need to be solved in the first place.”

Within organizations, problems are created to generate work,
and resources and time are spent ‘solving’ these problems.
However, the customers are not interested in these problems.

Misdefining the Problem Leads to Unnecessary Work

Misdefining a problem results in:

• Waste of unnecessary resources
• Developing features irrelevant to customers
• Meaningless achievements and repeated failures

As a result, we end up doing “work for the sake of work” rather than actually solving problems.

In practice, we often see cases like these:

• Mistaking internal inefficiencies for problems, while overlooking the inconveniences felt by customers
• Defining technological obsolescence as a problem, and forgetting about the customer issues that the technology addressed
• Viewing approval processes as a problem and automating them, yet the customer experience remains poor

When a problem is misdefined,
the solution might be precise but the outcome is meaningless.

Requirement Analysis Must Start with Understanding the Customer

Requirement analysis is not just about asking “What should we create?”
The real start is:

“Why are customers feeling discomfort, what are they expecting, and where do these expectations come from?”
Understanding this is crucial.

If requirement analysis isn’t customer-centric,
we define “problems that seem like problems” and
solve “things that customers don’t consider important,” committing errors.

Problem Recognition Comes Before Technology – An Architect’s Perspective on Defining Problems

A good architect structures problems before designing solutions.
Recognizing problems is not just pointing out errors but
defining the tasks that need to be solved.

Defining a problem means answering these questions:

• What is the root cause of this phenomenon?
• In which layer of the system does this problem occur?
• How does this problem impact customer value?
• What changes occur when this problem is solved?

Four Criteria to Distinguish Real Problems from False Ones

1. Does the risk really exist?

It’s essential to distinguish between mere inconveniences and substantial losses (revenue, customer churn, reputation damage, etc.).

2. Is it a core issue or a side effect?

Solving the phenomenon alone may lead to the same problem repeating in another form.

3. Is it important from the customer’s perspective?

The problem should impact the customer’s experience and goals, not just internal efficiency.

4. Is it a high priority?

Not all problems can be solved. Decisions should be based on resource allocation and cost-effectiveness.

Defining the Problem is More Important Than Solving It

Many people view problems solely as something to be solved.
But what’s truly important is,

“Is it a problem worth solving?”
First defining this is crucial.

A well-defined problem is half-solved.
Conversely, a poorly defined problem can never win the customer’s heart, no matter how excellent the technology.

Conclusion – Customers Cannot Be Overlooked When Defining Problems

We often define problems from the perspective of the organization.
However, if customers are absent from problem definition,
that problem likely becomes a ‘false problem’ meaningful only within the organization.

Problems always reside within the customer,
requirement analysis must start with understanding the customer, and
problem definition should be expressed in the customer’s language.

Defining the problem well is harder and more important than
solving the problem.