Agile Product Discovery

I recently posted and twitted about my lean startup experiments.

The word startup in lean startup may be misleading because startup gives the idea of a new company creation. However, the concept on lean startup fits very well within established companies, no matter its size. I believe that instead of using the startup word, I’d rather name it as Agile Product Discovery, an iterative process of discovery of a problem and its best solution that can be turned into a product.

I’m reading now The Entrepreneur’s Guide to Customer Development: A cheat sheet to The Four Steps to the Epiphany:

The book’s cover is a cheat sheet by itself:

Here’s an excerpt of the book to give you motivation to read it all:

First, draw a map of your ecosystem.

  • The entities involved. Draw a box or a circle representing each entity in your ecosystem. Entities include users, customers, channel partners, technical partners, strategic partners, advertisers, your customers’ customers, etc. Include all entities that either provide value to you or receive value from your product. Value can be derived from money or the use of a product. Value can be direct (what a user receives from using a product) or indirect (money an advertiser gets from product user eventually).
  • Flow of currency. Draw lines or otherwise show your assumptions regarding the flow of currency. Who pays whom?
  • Product Distribution. Show your assumptions regarding how the product moves through channel(s) to reach end users.

Questions to consider:

  • Are you relying on third party technology that requires a formal partnership?
  • Are you relying on channel partners that will help you bring the product to end-users?
  • If you have a “free” business model and are looking to scale users, who will you eventually earn money from?
  • Are you partnering with a manufacturing firm?
  • Will you sell data or leads to third parties?
  • Does your product benefit your customers’ customers?

Second, define the value proposition for each player.
Each entity is only a member of the “ecosystem” if it will receive benefits by participating. For each member of the ecosystem, what benefit do they gain and what are they willing to trade in exchange? These value proposition statements will evolve into your core C-P-S (Customer-Problem-Solution) hypotheses that you test during Customer Discovery. For now, however, provide a concise description of the value you presume they will receive.


  • Users will be entertained
  • Advertisers get the attention of thousands of users
  • Buying influencer is happy to choose “green technology”
  • Customer’s customer gets highly qualified leads
  • Channel able to sell services on top of product
  • Customer will save money, mitigate risk, or increase market share

Third, posit a final MVP
As defined above, an MVP is “a product with the fewest number of features needed to achieve a specific objective, for which users are willing to ‘pay’ in some form of a scarce resource.” The reason the definition is somewhat obtuse is that we wish to differentiate between a “final” MVP and one or more intermediate MVPs. Final MVPs ostensibly test the business model. Intermediate MVPs test high risk components of the business model.

To develop assumptions regarding your final MVP, think of what you need to provide to each entity with whom you have a direct relationship in order to achieve the value you identified above. What are the basic features of the product each user requires to get the ecosystem functioning? What does each entity pay – whether money, attention, resources or some other currency? Describing what your final MVP looks like establishes an end point to the Customer Discovery process.

  • Currency = what the user/buyer “pays” for using the MVP
  • MVP Metric = what you are measuring to determine viability
  • Value Determinants = what the user/buyer requires (minimally) in order to spend their currency, such as features

Fourth, where’s the risk?
The goal for laying out a path for your Customer Development efforts is to prioritize and test your gating factors. If you validate key assumptions, you have proven critically important aspects of your business model. If you hit unexpected roadblocks and points of failure, then you have increased your odds of success by catching these issues early.

Think of critical near-term risks. Does your technology represent a significant risk? In other words, can you build what you believe the market needs? If your technology is difficult or costly to produce, what market-testable milestones can you build that would result in sufficient evidence to induce you to pivot or move forward? A proof of concept? A prototype? A demo?

If your risks are predominately marketing ones, what minimum set of features will result in paying customers? Or: What minimum set of features will result in a minimum of X number of users?

Time and money risks may affect intermediate MVP decisions. If your MVP will require $XM to build, but you only have $X/1000M, an intermediate MVP might be the answer to “what must I prove in order to acquire additional funding?”

Think of dependencies. If your final MVP requires that X happen, then can you build an intermediate MVP around X? What does X depend on? If possible, go to the root of the dependencies.

Fifth, create your Value Path
Your value path is the journey of Customer Discovery that takes you from where you are today to your proposed final MVP and includes both intermediate MVPs and core assumptions to be tested. From the risk table you created, map out the set of core assumptions you need to test for each identified gating factor. For each intermediate MVP, you will likely have a set of assumptions to test through direct customer interaction, in addition to a version of the product to build and test through usage.

1 thought on “Agile Product Discovery

Leave a Reply

Your email address will not be published. Required fields are marked *