Velocity isn't the point. The 4 product risks that sink launches.

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. As Marty Cagan puts it, "We need to make sure that the things we add to the Product Backlog are actually worth building." 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

1. Desirability - 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 desirable, 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.

This framework isn't new, and that's the point - it's stood up for two decades. It started as IDEO's Desirability-Viability-Feasibility model in the early 2000s, and got sharpened for product teams by David Bland in Testing Business Ideas. The only tweak worth making is for B2B: split desirability into user value and usability, because in B2B the person who buys and the person who uses are usually different people. That split is why you'll hear it called the "4 product risks."

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 desirability.

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.