Velocity isn't the point. The 4 product risks that sink launches.
Plenty of products fail with flawless execution - on time, on budget, beautifully built, and dead on arrival. Not because Agile is broken, but because the team efficiently built the wrong thing. Here are the four risks to kill before you write code.
Some products fail despite flawless execution. On time. On budget. Clean code, polished UI, smooth launch. And then almost nobody uses it.
That's the part obsessing over velocity never tells you: shipping fast only means you reach the wrong destination sooner.
Lean and Agile aren't the problem here. Building the wrong things efficiently is. Marty Cagan's advice to strong product teams is to tackle the big risks early, before anyone builds anything. Speed is a multiplier. Point it at the wrong thing and it multiplies the waste.
So before something goes on the backlog, it's worth asking which risks it still carries. There are four.
The four product risks
Cagan calls them the four big risks. In plain words:
1. Value - do they actually want it? Will customers choose it, use it, and in a lot of cases pay for it? This is the risk teams most love to assume away, because a few loud requests feel like proof. They aren't.
2. Usability - can they figure out how to use it? The value can be real and the thing can still fail because people can't work out how to get to it. Great idea, buried behind a confusing flow, equals no value delivered.
3. Feasibility - can we actually build it? With our engineers, our tech, our data, and the time we have. Not "is it possible in theory" but "can this team ship it in a reasonable window."
4. Viability - does it work for the business? A feature can be wanted, usable, and buildable, and still sink you: wrong economics, legal exposure, no way to sell or support it, margins that don't hold. It has to work for the customer and for you.
Most teams stress-test feasibility endlessly (can we build it?) and wave through value (should we?). That's backwards. Feasibility rarely kills products. Value does.
Where the four risks come from
This framework isn't new, and that's the point.
IDEO's design thinking looks for the overlap of what's desirable for people, viable for the organization, and feasible with technology. David Bland and Alex Osterwalder turned those three lenses into a testing practice in Testing Business Ideas.
Map Cagan's four onto those three and you get the same lenses, with desirability split in two: value and usability. The split matters most in B2B, where the person who buys and the person who uses are usually different people. The buyer can love the value while the users can't get through the flow.
Who owns which risk
Cagan also gives each risk an owner. The product manager is responsible for value and viability, the product designer for usability, and the lead engineer for feasibility.
Owning a risk doesn't mean working on it alone. The same article asks for solutions worked out collaboratively, with engineering, design and product side by side. That's the product trio: three people accountable together, each watching the risk they know best, so none of the four gets waved through.
How to actually use it
A risk framework you only recite in a slide is decoration. Here's how it becomes a habit.
Map the assumptions. Write down what has to be true for the idea to work, across all four risks. You'll usually surface a dozen buried "we're assuming that..." statements nobody had said out loud.
Rank by risk, start with the scariest. Order the assumptions by how much damage a wrong one does and how little evidence you have. The top of that list is almost always value.
Test cheap, before you build. Run the smallest experiment that could prove an assumption wrong: a fake-door test, five interviews, a landing page, a concierge run-through. This is what a real culture of experimentation is for, and it's the same discipline behind building on evidence, not a hunch.
The payoff is unglamorous and enormous: fewer failed launches, less wasted engineering time, and a backlog full of things you've already got some reason to believe in.
Because the goal was never to ship faster. It was to stop building features nobody needed, and mapping these four risks before you write code is the cheapest way to do exactly that. It's the backbone of how we run the Product Discovery Workshop.
