One question has stayed with me throughout my journey as a Product Manager.
“If we didn’t build this feature, what customer problem would remain unsolved?”
It sounds simple, but it’s surprisingly difficult to answer.
Early in my career, I spent a lot of time discussing features. Roadmaps were filled with requests from customers, ideas from stakeholders, and responses to competitor launches. Every sprint ended with something new being released.
We were busy.
We were shipping.
But when I looked at customer outcomes a few months later, many of those features had made very little difference.
That’s when I realized something important.
Building features and solving customer problems are not the same thing.
Customers Rarely Ask for What They Actually Need
One of the biggest lessons I’ve learned from customer interviews is that people often describe solutions instead of problems.
A customer might say:
“Can you add bulk editing?”
“We need another dashboard.”
“Can you integrate with this platform?”
It’s tempting to write those requests directly into the backlog.
But over time, I started asking one more question.
“What are you trying to accomplish?”
That simple question often changed the entire conversation.
Sometimes the customer didn’t actually need bulk editing.
They wanted to reduce repetitive work.
The dashboard wasn’t the goal.
They simply needed quicker access to information.
The requested feature was only one possible solution.
Features Are Outputs. Problems Lead to Outcomes.
As Product Managers, we naturally measure outputs.
Features released.
Stories completed.
Roadmap milestones achieved.
Those metrics are easy to track.
Customer outcomes are harder.
Did hiring become faster?
Did support tickets decrease?
Did customers save time?
Did adoption improve?
Those questions require more effort, but they reveal whether the product is actually creating value.
A feature is only successful if it improves an outcome customers care about.
The Cost of Building the Wrong Thing
Every feature comes with hidden costs.
Engineering effort.
Testing.
Documentation.
Support.
Future maintenance.
The question isn’t whether you can build another feature.
It’s whether that feature deserves to exist.
I’ve worked on features that were technically impressive but rarely used after launch.
I’ve also seen small improvements, like simplifying a workflow or removing unnecessary steps, create far greater customer impact.
Complexity grows with every release.
Value doesn’t.
Listen Beyond the Request
One habit that has improved my product decisions is spending more time understanding customer workflows than customer requests.
Instead of asking:
“What feature do you want?”
I ask:
- What task are you trying to complete?
- Where do you lose the most time?
- What’s the most frustrating part of your day?
- How are you solving this today?
Those conversations usually uncover problems that customers never thought to mention.
And that’s where meaningful product opportunities begin.
Don’t Confuse Customer Requests With Customer Priorities
One mistake I’ve made is assuming that the loudest requests represented the biggest opportunities.
They didn’t.
Sometimes a feature was requested by only a few customers but solved a significant business problem.
Other times, dozens of customers requested something that ultimately had little impact on their success.
Context matters.
Understanding the importance of a problem is often more valuable than counting how many people requested a solution.
Great Products Remove Problems, Not Just Add Features
Some of the best product improvements I’ve worked on never appeared in release announcements.
We simplified workflows.
Reduced unnecessary clicks.
Improved performance.
Made confusing processes easier to understand.
Customers rarely celebrated these changes publicly.
But they noticed.
Support requests declined.
Task completion improved.
Customer satisfaction increased.
Sometimes the most valuable feature is removing friction that customers shouldn’t have experienced in the first place.
Start Every Roadmap With One Question
Whenever I’m reviewing new ideas now, I try to ask one simple question before discussing implementation.
“What customer problem becomes easier because of this?”
If the answer is vague, the feature probably needs more thought.
If the answer is obvious, measurable, and meaningful, it’s usually worth exploring.
That question has helped me avoid building features simply because they sounded interesting.
Final Thought
It’s easy to become proud of the features we build.
After all, they represent months of planning, design, and development.
But customers don’t judge products by the number of capabilities they offer.
They judge them by whether those capabilities make their lives better.
As Product Managers, our responsibility isn’t to fill roadmaps with features.
It’s to solve problems that genuinely matter.
Because at the end of the day, customers won’t remember how many features you launched this year.
They’ll remember whether your product helped them accomplish something they couldn’t do before.
Leave a Reply