The Product Death Cycle: why "what features do you want?" is killing your product

"Just tell me what features you want."

It sounds like the responsible thing to say. Customer-centric. Humble. You're not assuming you know best — you're listening. And it's one of the single most reliable ways to slowly kill a product.

I still see product teams do it constantly. They sit across from a customer and ask, point blank, "What do you want?" And in doing so they trigger what David Bland named the Product Death Cycle.

How the cycle plays out

It's a loop, and it feels productive the whole way around — which is exactly why it's so dangerous:

Every lap feels like progress. You're shipping. You're "responding to feedback." The backlog is full of real customer requests, so how could you be doing anything wrong? And yet adoption stays flat, the product gets more bloated and less focused, and somewhere around lap four it dawns on you that you've been very busy building things nobody actually uses.

Why building from feature requests fails

The cycle breaks down for three connected reasons:

• You moved too fast. A request goes straight onto the roadmap with no exploration and no validation. You skipped from "a customer said this" to "we're building it" without ever asking whether it solves a real, widespread problem.
• You bet big on light evidence. One person's opinion in one conversation gets treated as fact. Anecdote becomes strategy. Ship enough features on that basis and your roadmap is just a pile of loudest-voice requests.
• Customers don't know the best solution. And it's genuinely not their job to. They don't know what's technically feasible, what's valuable to build, or what else is possible. They know their world and their frustrations. The solution is your job.

This is the core mistake: confusing the customer's expertise in their problem with expertise in your solution. They're the world's leading authority on the first. They know almost nothing useful about the second.

The reframe: stop asking "what do you want?"

The fix is almost embarrassingly small. Change the question.

Instead of "What features do you want?", ask "What are you trying to achieve?" — and then dig into the story behind it. What were you doing when this came up? What did you try? What happened? Where did it hurt?

That shift moves the conversation from solutions (their weak spot) to problems and goals (their expertise). You walk away with the raw material you actually need — a real understanding of needs and desires — instead of a feature you're now obligated to build and nobody asked to be held accountable for.

How to break the cycle

Bland's escape route is three steps, and you can start running it this week:

1. Discover opportunities

Focus on finding the right problem to solve for your target users. Use story-based interviewing — get them recounting actual past experiences, not predicting what they'd hypothetically use. Past behavior is evidence. Future intentions are wishful thinking.

2. Validate solution assumptions

Before you write a line of production code, test your idea cheaply. A prototype, a fake-door test, a quick experiment. Build a culture where every solution is a hypothesis to validate, not a request to fulfill. This is the step the Death Cycle skips entirely — and the one that saves you the most wasted engineering.

3. Measure outcomes, not outputs

This is where most teams still go wrong, even after they fix their interviews. They count features shipped (output) instead of whether anything got better (outcome). Twelve features is an output. Users who'd be genuinely upset to lose your product is an outcome. Only one of those tells you the cycle is broken.

The metric that proves you've escaped

Here's the catch with "measure outcomes": which outcome? Adoption of a single feature is too narrow — you can get people to click a thing and still be drifting nowhere. You need a measure of whether the whole product is becoming more of a must-have.

That's exactly what a PMF score gives you. Ask your engaged users how they'd feel if they could no longer use your product, and track the percentage who say "very disappointed." It's the cleanest outcome metric there is, because it can't be gamed by shipping more stuff. If you're stuck in the Death Cycle — busily building requested features that don't deepen anyone's attachment — that number sits flat no matter how full your changelog gets. When you break out and start solving real problems, it climbs.

So the score does double duty: it's both your escape hatch and your alarm. A flat PMF score under a busy release schedule is the unmistakable signature of the Product Death Cycle. A rising one is proof you've stopped taking orders and started doing discovery.

Putting it to work this week

1. Audit your last five shipped features. How many came from a real validated problem, and how many from "a customer asked"? Be honest.
2. Change the question. In your next interview, ban "what do you want?" Ask "what are you trying to achieve?" and chase the story.
3. Validate before you build. Put a prototype or fake door in front of users before committing engineering time.
4. Watch the outcome, not the output. Run the Sean Ellis survey and track your PMF score. If it's flat while you're shipping hard, you're still in the cycle.

Building features people request feels safe. It's the riskiest thing you can do. Stop shipping blindly, find out what's actually worth building first — and let the score, not the changelog, tell you whether it's working.