The Product Death Cycle: why "what do you want?" kills your product

"What do you want?" feels like the responsible question to ask. It's not. It's how you end up trapped in what David Bland calls the Product Death Cycle, and once you've seen the loop, you'll recognize it everywhere.

Here's how it runs, on a schedule that never seems to break:

1. You launch a product, or a feature.
2. Barely anyone uses it.
3. You ask your customers what's missing.
4. You build exactly what they asked for.
5. You ship it. Almost nobody uses that either.
6. Go to step 3.

Sound familiar? Most teams don't notice they're in it. Each lap around the loop feels like progress: a feature shipped, a customer request closed, a box checked on the roadmap. The team stays busy. The backlog stays full. And usage stays flat.

It's not the customer's job to hand you the solution

Customers are the world's experts on their own problems. They are not experts on your product, your data, or the trade-offs behind ten different ways to solve the same need. So when you ask "what do you want," you're not doing research. You're outsourcing the one job you were actually hired to do.

As a product team, you're responsible for turning a deep understanding of the problem, the needs, the desires behind it, into the right solution. That's the job. Handing it back to the customer and building whatever they say doesn't make you customer-centric. It just moves the risk from "did we understand the problem" to "did we build what one loud customer happened to ask for."

Why it feels like progress (but isn't)

Two things are usually going on at once:

You built too quickly. There was no exploration of the actual opportunity, and no validation of the solution before it got built. A request came in, and it went almost straight to the backlog.

You placed a big bet on light evidence. A handful of vocal customers become "the market." Anecdotes and opinions get treated as facts, because they're the only signal in the room.

The way out

Escaping the cycle isn't about ignoring customers. It's about changing what you do with what they tell you.

Discover product opportunities. Instead of collecting feature requests, dig into the problem underneath them. Focus on finding the right problem to solve for your target customers, not the first solution someone happened to suggest.

Validate solution assumptions. Before you build, test the assumption cheaply. This is what a real culture of experimentation is for: small tests that tell you whether an idea holds up before it costs you a sprint.

Measure outcomes. Define what "working" actually means before you ship, then track it. If you can't say what number should move, you won't know whether you escaped the cycle or just ran another lap of it.

So don't just ship features. Discover what to build, before you code it.

If your roadmap reads like a transcript of your last ten sales calls, that's usually the tell. It's exactly the pattern our Product Discovery Workshop is built to interrupt, before the backlog fills up with requests nobody's validated.