At some point in every PM's life, someone walks into a meeting and says: "We need a dashboard." Or "Users want a dark mode." Or "Can we add an export button?" And the PM's job — the real job, not the ticket-writing, sprint-grooming, roadmap-presenting job — is to resist the instinct to nod and ask instead: "Why?"
The Feature Factory Problem
The feature factory is a well-documented anti-pattern: a team that measures itself by output (features shipped) rather than outcome (value delivered). You can recognize a feature factory by its roadmap — a long, satisfying list of items that never seems to move the metrics anyone actually cares about.
I've worked in organizations that operated this way. The backlog was enormous and well-groomed. The sprint velocity was impressive. And yet, quarter after quarter, user retention was flat. The team was busy building the wrong things, faster and faster.
"Building the wrong thing efficiently is not a competitive advantage. It's just expensive failure with great documentation."
Intent Over Request
Here's the reframe that changed how I approach feature requests: users don't want features. They want outcomes. The feature is just the solution they happened to think of.
When a user says "I want an export button," they actually want to use your data in their existing workflow without friction. When they say "I want a dashboard," they want visibility into something that currently feels opaque or unpredictable. The feature is downstream of the need — and if you build features without understanding needs, you'll often build the right answer to the wrong question.
At Accenture, I worked on a travel industry benchmarking tool. The initial request from the client was "we need a report." What they actually needed was a way to have a credible conversation with their clients about competitive positioning. The report was one possible output. What we ultimately built — an interactive, filterable dashboard — wasn't what they asked for, but it was exactly what they needed. Getting there required five conversations that started with "why."
The Five Whys in Practice
The Five Whys technique, borrowed from lean manufacturing, is deceptively powerful in product discovery. It works like this:
- Feature request: "We need a dark mode."
- Why? "Users are complaining about eye strain."
- Why? "They're using the product late at night."
- Why? "Our main use case turns out to be post-dinner task management."
- Why does that matter? "Because our current onboarding assumes morning usage and the entire UX cadence is wrong for our actual users."
Dark mode is now the least interesting part of the problem. You've discovered a fundamental mismatch between your assumed use case and your actual use case. That's a product strategy finding, not a design ticket.
How to Ask "Why" Without Being Annoying
There's an art to this. If you mechanically ask "why" five times in a row, you'll sound like a toddler or an interrogator. The goal isn't to challenge the request — it's to understand the problem deeply enough to solve it well. Some language that helps:
- "Help me understand the use case — who's asking for this and when do they need it?"
- "What does success look like once this is shipped? How would we know it's working?"
- "Is there a workaround people are using today? What's painful about it?"
- "If we couldn't build this, what's the next best option?"
These questions don't say "your request is wrong." They say "I want to solve your real problem, not just your stated one." Most stakeholders — when they understand that distinction — appreciate the rigor.
Data as the Second "Why"
Asking "why" verbally is powerful. Asking "why" with data is decisive. Before I commit to building anything, I want to see the signal — usage data, support tickets, user research, churn analysis, NPS comments. Not because I distrust the person making the request, but because data reveals patterns that no individual can see from their vantage point.
As someone trained in analytics, this is where I feel most at home. The question "why this feature" becomes richer when you can point to cohort data that shows a 40% drop-off at a specific step, or support volume that clusters around a specific frustration. The why stops being a hypothesis and starts being a fact.
The Culture Question
None of this works if the culture treats "why" as a challenge to authority rather than a tool for alignment. The best product organizations I've seen — and the ones I aspire to work in — treat rigorous questioning as a sign of respect, not resistance. The question "why this feature" isn't skepticism. It's care.
Care that the team's time is spent on what matters. Care that users get what they actually need. Care that the product gets better, not just bigger.
Ask the why. Every time. It's the most important thing a PM does.