Your best idea has a 1-in-3 chance of working. Here's how the best teams find the other two.

Here's an uncomfortable number. Companies that A/B test their ideas have learned that, in the best case, roughly one in three ideas produces a measurable improvement. In the common case, it's closer to one in ten.

Read that again. Even great teams, with great instincts, are wrong about most of what they build.

So what do most teams do with that fact? They ignore it. They sit in a room, brainstorm a list of features, rank them by gut feel, drop them on a roadmap, and start building. Then they act surprised when the metrics don't move.

There's a better way to work. It's not faster brainstorming or a smarter prioritization framework. It's a shift in what you treat as the starting point — from solutions you're excited about to problems you can prove are real.

The trap: optimizing for the wrong thing

When you don't have a clear way to connect work to value, you default to the thing that's easy to measure: how much you ship. Velocity goes up. Story points get burned down. Everyone looks busy.

But shipping more isn't the goal. Mitigating risk is. Every feature you build carries four kinds of risk:

• Value risk — will customers actually want this?
• Usability risk — can they figure out how to use it?
• Feasibility risk — can you build it with what you have?
• Viability risk — does it work for the business?

The team racing to hit a delivery date optimizes for feasibility and ignores the other three. So they ship things that work perfectly — and that nobody wants. That's the most expensive kind of "done."

The mechanism: the Opportunity Solution Tree

Teresa Torres gave this a name and a shape: the Opportunity Solution Tree. It's a simple map that forces every solution to earn its place. You build it top-down, in four moves.

1. Start with one outcome — not a feature list

At the top of the tree sits a single product outcome: a change in customer behavior you're trying to drive. Not "increase revenue" (that's a business outcome you don't fully control) — something closer to the product, like "more users complete their first project in week one."

One outcome. If you have five, you have none. The whole point is focus.

2. Map the opportunities — the real customer problems

Below the outcome, you map opportunities: the needs, pain points, and desires that, if you addressed them, would move that outcome. You don't invent these. You find them — in customer interviews, support tickets, behavioral data, and the things people actually say when you stop pitching and start listening.

Group them. Prune them. Decide which ones are worth exploring and which are noise.

3. Ideate solutions — many, for one opportunity

Only now do you let yourself brainstorm. And here's the discipline: you generate several solutions for a single opportunity, not one solution for each. The first idea is rarely the best one. Breadth before depth.

4. Surface the riskiest assumptions — and test those first

Every solution rests on a stack of assumptions. Underneath "users will love an AI summary" might be "users actually read these documents," "they trust an AI to be accurate," and "this is a problem they'd change their workflow for." Find the assumption that, if false, sinks the whole thing. Then design the cheapest possible test for it.

A test can be a five-customer interview. A fake door. A prototype. A landing page. The format doesn't matter. What matters is that you spend days learning something, instead of a quarter building on sand.

Why this beats "build it and see"

"Build it and see" is a test too. It's just the slowest, most expensive test ever invented. You learn the same thing — whether the idea works — except it costs you a full release cycle, the team's morale, and the opportunity you could have pursued instead.

The tree doesn't make you slower. It makes you fast in the direction that matters. You still build constantly — you just build the surviving ideas, the ones that already cleared a cheap test before a single engineer touched them.

How to start this week

1. Pick one outcome your team is supposed to move this quarter. Write it as a behavior change, not a revenue number.
2. List every opportunity you think sits under it. Then mark which ones you've actually heard from customers, and which you assumed.
3. Book five customer conversations to fill the gaps. (More on how to run those here.)
4. For your top solution, write down the one assumption that would kill it. Design a test you could run in under a week.

That's it. No new tooling. No reorg. Just a different first question: not "what should we build?" but "what do we need to be true for this to work — and how do we find out cheaply?"

Get that question into your team's bloodstream and the 1-in-3 odds stop being a threat. They become your edge. While everyone else is shipping on faith, you're shipping on evidence.