One of the biggest mistakes I made early in my product career was getting excited about solutions too quickly.
Someone would suggest a new feature, and within minutes we’d be discussing designs, timelines, and implementation.
It felt productive.
We were moving fast.
But every now and then, after weeks of building, we’d launch the feature only to find that hardly anyone used it.
The problem wasn’t poor execution.
It was that we had never stopped to ask a simple question:
Is this actually a problem worth solving?
That question has become one of the most important parts of my product thinking.
A Great Solution Can’t Fix the Wrong Problem
As Product Managers, we’re naturally drawn to solutions.
We enjoy brainstorming ideas, prioritizing roadmaps, and shipping features.
But customers don’t wake up hoping someone builds another feature.
They wake up trying to accomplish something.
If your product doesn’t help them do that better, faster, or more confidently, the quality of your solution doesn’t matter very much.
I’ve learned that building the wrong thing well is still building the wrong thing.
Don’t Mistake Requests for Problems
One lesson I’ve learned is that customers often describe solutions instead of explaining their challenges.
A customer might say,
“Can you add a dashboard?”
Or,
“We need bulk editing.”
It’s tempting to write those requests directly into the backlog.
Instead, I try to understand what led them to ask for those features.
What are they trying to accomplish?
What’s frustrating about the current experience?
How are they solving this problem today?
Sometimes the requested feature really is the best answer.
Other times, it’s just one possible solution to a much larger problem.
Look for Patterns, Not Individual Requests
Not every complaint deserves a new feature.
If one customer asks for something, I make a note of it.
If five customers describe the same frustration in different ways, I start paying attention.
Patterns matter far more than individual requests.
I’ve found that the strongest product opportunities usually emerge when customer interviews, support tickets, usability studies, and product analytics all point toward the same underlying issue.
That’s a much stronger signal than any single piece of feedback.
Understand the Cost of the Problem
Another question I like asking is:
What happens if this problem isn’t solved?
Some problems create minor inconvenience.
Others stop customers from completing their work.
The difference matters.
A problem that costs customers time every single day is usually worth more attention than one they encounter once every few months.
Understanding the impact helps prioritize what deserves to be built first.
Validate Before You Invest
Validation doesn’t always require months of research.
Sometimes a handful of customer interviews is enough.
Sometimes usability testing reveals the issue.
Sometimes analytics show customers abandoning the same workflow repeatedly.
The goal isn’t to collect endless evidence.
It’s to build enough confidence that you’re solving a real problem before investing significant time and effort.
A week spent validating can save months of building the wrong thing.
Be Willing to Walk Away
This is probably the hardest part.
Occasionally, validation tells you something you don’t want to hear.
The problem isn’t widespread.
Customers don’t actually care.
Or they’re already solving it well enough without your product.
That can be disappointing, especially when you’ve become attached to the idea.
But I’ve come to see these moments as wins.
Finding out before development starts is far less expensive than discovering it after launch.
Sometimes the best product decision is deciding not to build at all.
Validation Doesn’t End After Launch
One thing experience has taught me is that validation isn’t a single checkpoint.
Launching a feature simply creates another opportunity to learn.
Are customers using it the way you expected?
Did it actually solve the original problem?
Has it improved the outcome you were targeting?
If the answer is no, the work isn’t finished.
Building a feature doesn’t validate the problem.
Customer behavior does.
Final Thought
Looking back, I don’t think the biggest risk in product management is building poor features.
It’s building features that solve problems nobody really has.
Ideas are easy to fall in love with.
Problems are harder.
They require curiosity, patience, and sometimes the humility to admit our assumptions were wrong.
The best Product Managers I’ve worked with don’t start by asking, “What should we build next?”
They start by asking, “What problem is important enough to solve?”
Because when you validate the problem first, you’re giving your product the best possible chance of creating real value.
Leave a Reply