Product Marty Cagan

The Biggest Risk

One of the things I like about a Lean Canvas is it helps to quickly highlight the key assumptions and major risks facing a startup or a significant new product in an existing business.  This is a good thing.   The idea is to tackle the biggest risks first.  That’s the theory at least.

However, the reason for this note is that in practice, I keep running into entrepreneurs and product leaders that are focused on secondary risks rather than the primary risks.

Partly I think this is due to the fact that risk is subjective and hard to quantify.  So depending on your perspective, you may think some risk is secondary when I think it is primary.

Mostly, however, I think the major reason is that it’s human nature for people to focus more on those areas they feel they can control and are knowledgable about.

So let’s say your startup founder is someone that comes from a business background, probably trained as an MBA.  He or she is probably acutely aware of the risks associated with coming up with a good business model.  They’re often very focused on unique value proposition, pricing, channels and/or costs.

But I will often have to sit these people down and explain that while these are real risks, they are largely academic at this stage.  And then I try to point them at what, in my experience, is the biggest reason that startups and new product fail.

You are probably thinking that I’m speaking of market risk – that the new product is focused on solving a problem that customers just don’t care enough about.

This is a very real risk, and one that’s responsible for it’s share of failed efforts, but I argue this is not usually the most significant risk.

I need a couple caveats here:

First, I have to say that the vast majority of the teams I meet are not actually solving new problems.  They are working on long-standing problems with long proven markets.  What’s different about the startup or product is their approach to solving the problem (their solution).  Most often, and increasingly, because they are leveraging newly available technology to solve the problem in an innovative way.

Second, if the market is indeed new, then today the techniques we have for validating demand have never been better.  If you don’t use these techniques, you proceed at your own peril.  This is an especially egregious mistake because the techniques are not expensive in terms of money and time, so there’s just no excuse not to do this.

So I argue the major risk facing most efforts is solution risk.  Discovering a solution that is compelling to customers.  A solution that your customers will choose to buy and use.

However, if you’ve created a canvas before, you know that there’s precious little in there about the solution.  The official rationale for that is that it’s far too easy to fall in love with your particular approach and lock yourself in prematurely.  In fairness, this is a very real issue with teams.  I see this behavior constantly.  It was the motivation for the two-week rule.

But a consequence of this meager representation of the solution in a canvas is that it plays to the tendency of many to focus on those risks they feel more comfortable with, and leave the solution as an exercise for the developers.

Rather than delegating or deferring figuring out the solution, we need to embrace product discovery as the most important core competency of a product team.

Look, if you can discover a solution that your customers love, then you can tackle the risks of monetization and scale.  However, without that solution, the rest of your work is very likely going to be wasted.

So whether your constrained resource is cash or management’s patience, you need to make sure you primarily use your time to discover a valuable, usable and feasible solution.  Get that risk resolved first, and then you can focus on the other risks.


In response to a few follow-up questions after I posted this article, I wanted to clarify that when I said above that you should first get the product right, and then focus on monetization and scale, I was not suggesting that “figuring out your product” was in any way independent of validating value.  This is absolutely part of product discovery.  For example, the main way we validate value for a for-fee product is by making sure that prospective customers will pay real money for this (see  Specifically, during product discovery we need to get good answers to these four critical questions:

  1. Will customers buy it?
  2. Can customers use it?
  3. Can we build it?
  4. Can our stakeholders support it?

Note that the stakeholder question includes: can we sell it and can we afford it?

The point is that you don’t need to be spending your time doing pricing optimization testing, and sales tools, and marketing programs, and working to cut costs until and unless you have discovered a viable product.