Why Do Good Software Teams Build Bad Products?

One important question in software product development is: Why do capable software teams sometimes build weak or low-value products?

This problem can be seen in both consumer and enterprise products. Even with strong engineering teams, some products remain significantly behind successful global alternatives.

One important reason is moving too quickly from a requirement to a solution.

For example, imagine that the product manager of a super app tells the engineering team: “Users are having problems with money transfers. Let’s add a feature that allows them to make recurring transfers to another person.”

The engineering team may immediately start thinking about the solution: What should the architecture look like? What changes are needed in the database? Which APIs need to be developed? How should the UI be designed? And how should the feature be delivered?

But an important question may be overlooked:

What exactly is the users’ real problem?

“Recurring money transfers” may be only one possible solution—and it may not even address the root cause of the users’ difficulty.

Therefore, simply receiving a requirement does not mean that we fully understand the problem. Before moving toward solution design and implementation, we need to spend enough time discovering, investigating, and deeply understanding the problem.

Key takeaway:
Receiving a requirement does not mean that we know the exact problem yet. Understand the problem first, then move toward the solution.