# The bravest sentence in Discovery: "We're not building that."

> The more stories you close in Discovery, the better. Discovery isn't a pre-coding formality — it's the filter that determines what actually gets built.

**Veröffentlicht:** 2026-05-18  
**Autor:** Torsten  
**Tags:** discovery, productmanagement, pareto

---

I still remember backlogs that had grown into endless collections of every possible idea — overflowing and impossible to navigate.

Hundreds of stories. Neatly described, prioritized, with acceptance criteria. All of them waiting to be built someday. And most of them? Never needed.

This isn't an exception. It's the rule.

## Discovery is widely misunderstood

Many teams use Discovery to prepare stories — clarify requirements, align on designs, estimate effort. That's important. But it doesn't go far enough.

For me, Discovery is primarily one thing: **the phase where I find out what I should _not_ build.**

That sounds counterintuitive. Why put in so much effort just to end up in the trash?

Because there is nothing less efficient than doing the wrong thing efficiently.

Discovering, refining, developing, testing, and deploying a story — only to realize nobody needed that feature — costs many times more than the courage to say no early.

## Pareto applies to the backlog too

20% of stories create 80% of real value. The other 80%? Well-intentioned. Possibly even sensible-sounding. But measured against what users actually need and what truly moves the product forward, they're dead weight.

Discovery's job is to find exactly those 20% — and consistently close the rest.

Not eventually. Early.

The earlier a story is closed, the more energy is saved: no design, no refinement, no development, no testing. Every step in the process makes a retreat more expensive. This is the real Pareto funnel: not what goes in, but what makes it out.

## What this means in practice

In Discovery, I don't just ask _how_ something should be built. I first ask _whether_ it should be built at all.

- What real user problem does this story solve?
- Do we have data or feedback that supports this?
- What happens if we _don't_ build it?

If these questions don't produce convincing answers, the Discovery was a success — even if the story gets closed afterward. Especially then.

Closing a story isn't a failure. It's a deliberate decision that frees up energy for what actually matters.

## But it takes courage — and authority

This is where the real bottleneck lies. Not the method. Not the framework.

It takes a Product Owner with the authority to make a decision — and the courage to actually make it. Even when someone filed that story months ago. Even when stakeholders are disappointed. Even when there's pressure to build everything eventually.

A team that builds everything that lands in the backlog isn't a product team. It's a feature factory.

## Discovery is the filter, not the preparation

Discovery isn't a pre-coding formality. Discovery is the filter that determines what makes it into development at all.

And the more stories that get closed in Discovery — with good reason, based on real insights — the higher the chance that what does get built actually matters.

The bravest and most valuable skill in product development isn't shipping fast.

It's knowing when to stop.