“Hey, I had a great idea for a feature…”
That’s how many product conversations begin and it’s also how many great products die before they’re even born.
If you’ve been in product management long enough, you’ve seen it: a flashy prototype that solves nothing. A perfectly executed feature that no one uses. A product roadmap that’s more wishlist than warpath.
The root cause? Falling in love with the solution before deeply understanding the problem.
The Trap of the Clever Feature
It’s easy to get enamored with clever ideas. Engineers love building cool stuff. Stakeholders love seeing visible progress. PMs love pitching shiny things in reviews. But there’s a cost to this premature affection: misalignment with actual user needs.
Imagine building a rocket to deliver pizzas. Technically thrilling. Practically useless.
Great product managers resist this trap. Instead, they fall in love with the problem they become obsessed with the customer pain, the job to be done, the struggle behind the scenes.
What Falling in Love with the Problem Looks Like
- You talk to real users often especially when it’s uncomfortable.
Not just happy users. Not just vocal users. You dig into the quiet churn, the dropped funnels, the workarounds in spreadsheets. - You ask “Why?” five times, even if it makes people squirm.
A user says they want a dashboard. Why? “To track things.” Why? “Because I have to report to my boss.” Why? “Because we’re measured weekly.” Ah now you’re getting somewhere. - You’re okay killing your darlings.
That feature you ideated in the shower? You’ll drop it in a second if user research shows it doesn’t solve anything real. - You measure success in outcomes, not outputs.
Launching a feature is a milestone. Solving a pain is the mission.
Real-World Example: Slack’s “Channels”
Slack didn’t start with “Let’s build a messaging app with public and private channels.”
They started with: “Email is broken for teams. It’s slow, siloed, and hard to search.”
The problem was clear. The pain was real. Channels were simply the most elegant way to address that pain.
Compare that with countless “chat features” bolted onto project management tools. Clever additions rarely used. Because they weren’t born from pain. They were born from FOMO.
How to Practice Problem-First Thinking
- Spend 30% of your time on discovery.
Talk to users, dig through support tickets, analyze drop-offs. Look for friction. - Write problem statements, not feature briefs.
Before you spec a solution, write a one-pager on the user problem, backed by data and quotes. - Challenge every idea with: “What user problem does this solve?”
Make it a ritual. In meetings. On Jira tickets. In roadmap reviews. - Track user problems like features.
Maintain a “Problem Backlog.” Prioritize it. Groom it. Make it as real as your feature backlog.
Falling in Love with the Problem Builds Product Intuition
When you live in the user’s world, your product intuition sharpens. You start to sense what will resonate before testing. You see around corners. You build with clarity, not guesswork.
More importantly, you earn user trust. Because you’re not just shipping features you’re solving real struggles.
In Summary:
Clever features are fun. But solved problems are unforgettable.
Great PMs don’t start with “Wouldn’t it be cool if…?”
They start with: “What’s really broken here?”
So fall in love not with your own idea, but with your user’s pain. That’s where the magic begins.



Leave a comment