When something isn't working, building something new can feel like the obvious answer.
A new website. A new feature. A new product. A new platform. A new process.
Sometimes that's exactly what's needed.
But sometimes the problem isn't a lack of something. It's that something already there isn't working the way it should.
That's an important distinction. Because building the wrong thing doesn't solve the original problem. It just gives you a newer version of it.
The solution can become the problem
Imagine a business hearing the same customer complaint over and over. The natural reaction might be to add a feature that addresses it.
So the feature gets planned, designed, built, tested, and launched.
And the complaint doesn't really go away.
Maybe the feature was difficult to find. Maybe customers didn't understand it. Maybe the underlying process was the real problem. Maybe only a small part of the customer base actually needed it.
The business solved the problem it assumed existed. Not necessarily the problem customers were experiencing.
Start with the problem
Before deciding what to build, it helps to slow down and define the problem in plain language.
What is actually happening? Who is experiencing it? How often does it happen? Why does it matter? What happens if nothing changes?
Those questions can feel basic. They're also easy to skip.
A solution can sound exciting long before the problem has been properly understood.
That's where teams can get pulled toward building instead of solving.
Sometimes the answer is already there
A business might already have the tools it needs. The issue may be how those tools are being used.
Maybe customers aren't finding an important feature. Maybe the onboarding process is too complicated. Maybe information is spread across too many places. Maybe employees have created workarounds because the official process doesn't match how the work actually happens.
None of those problems automatically require a new product.
Sometimes the better answer is to simplify what already exists.
That might mean changing the experience, improving communication, removing unnecessary steps, or fixing a process that has grown complicated over time.
New isn't automatically better
There's a natural bias toward new things.
New feels like progress.
A new feature can be announced. A new platform can be launched. A new product can go on the roadmap.
But activity isn't the same thing as progress.
If the new thing doesn't improve the outcome that matters, it hasn't necessarily moved the business forward.
Sometimes the highest-value decision is to make something simpler rather than make something bigger.
Ask what outcome you're trying to change
One useful way to evaluate a potential solution is to work backward from the outcome.
What are we actually trying to improve?
More customers? Better retention? Faster onboarding? Fewer support requests? Higher conversion? Less internal effort? A better customer experience?
Once the outcome is clear, different solutions become easier to compare.
You might discover that a new product is the right answer.
You might discover that a small change to an existing experience would have a bigger impact.
Or you might realize that the problem isn't important enough to justify solving right now.
All three are useful conclusions.
Build when building makes sense
This isn't an argument against building new products.
New products can create enormous value. New technology can open opportunities that didn't exist before. And sometimes an existing system simply can't support what the business needs next.
The point is to earn the decision to build.
Understand the problem. Understand the people experiencing it. Understand the outcome you're trying to change. Then decide what kind of solution makes sense.
That solution may be a new product.
But it doesn't have to be.
The best solution isn't always the biggest one
Good problem-solving isn't about finding the most impressive solution.
It's about finding the solution that actually addresses the problem.
Sometimes that's a new product. Sometimes it's a new feature. Sometimes it's a process change. Sometimes it's better messaging. Sometimes it's removing something that never needed to be there in the first place.
The important part is knowing the difference.
Before asking, "What should we build?"
Ask:
"What are we actually trying to solve?"