Most products fail, not because we fail to build what we set out to build, but because we waste time, money, and effort building the wrong product.
I attribute the entrepreneur’s often unbridled and singular passion for the solution as the top contributor to this failure. Sometimes that solution is truly awesome for many people, but more often than not, it’s not.
So how do you overcome this?
For starters, I strongly advocate redefining the “true product” and “real job” of an entrepreneur.
- The true product of an entrepreneur is NOT the solution but a working business model.
- The real job of an entrepreneur is to systematically de-risk that business model over time.
This redefinition was my motivation for creating the derivative Lean Canvas format and codifying what I believe to be the universal meta-principles for Running Lean depicted below:
You start by drawing a line in the sand with your initial Lean Canvas, prioritizing risks, and systematically testing those risks through experiments. There is a built-in learning feedback loop from experiments back to risks back to the business model.
Putting it into practice
While this process works conceptually, I often field questions from other entrepreneurs, specifically on how to
1. correctly prioritize risks and define experiments
2. track those experiments so it scales over time (and with more people)
3. reflect the learning from experiments back on to the canvas.
More recently, I have also lived these challenges first-hand as I’ve grown my team and am attempting to build a learning organization where everyone runs experiments.
The root problem with this process is that each transition between stages requires a mental leap which is often hard to teach and/or share with another person.
Even though running experiments is a key activity in Lean Startups, correctly defining, running, and tracking them is hard.
For inspiration, I turned to Jeffrey Liker, who has written a number of books on the Toyota Production System. I’ll come out and admit upfront that I’m not big on the process and even have an inner aversion to it. Like many of you, I’ve worked at large companies and lived through many useless “TPS reports” and needless processes. But Toyota views its TPS reports differently.
“The right process will produce the right results.”
- Jeffrey Liker, The Toyota Way
In lean thinking, a process is not passed down from the top and set in stone but rather a living product owned by the people doing the work. They are charged with a singular directive — reducing waste (i.e., eliminating non-value-add work). You start by documenting your current process (with a value stream map) and then challenge everyone to improve it continuously. That I can get my head around.
After a few iterations and a lot of testing, we have developed a process that works for us and half a dozen other startups — something we’re calling a lean stack which I’ll explain in a bit. But first, it would help to explain how we got here.
Version 1: Risks and Experiments Layers to Lean Canvas
Our first approach was to utilize a layers model to the Lean Canvas. The idea was to keep the canvas structure intact but overlay different views for risks and experiments on it.
This is currently what’s built into the online Lean Canvas tool, but despite several attempts, we couldn’t get ourselves to adopt it into our daily routine.
We struggled to constrain an experiment to a single section on the canvas. Many experiments, such as running a solution interview, potentially test several business model assumptions/hypotheses at once.
The main issue, though, is that the canvas is a static view and doesn’t by itself help visualize the flow of work.
“Use visual controls so no problems are hidden.”
- Jeffrey Liker, The Toyota Way
Version 2: Feature-level Kanban board
That brought us to our second version, which was to create a minimum viable feature (MVF) level Kanban board which I documented in this post: “How we build features” and my book.
As a refresher:
MVF is derived from Minimal Marketable Feature (MMF).
MMF was first defined in the book “Software by Numbers”: as the smallest portion of work that provides value to customers. A MVP is made up of one or more MMFs.
A good test for a MMF is to ask yourself if you’d announce it to your customers in a blog post or newsletter. If it’s too tiny to mention, then it’s not a MMF.
The idea here was to use Lean Canvas to document the business model and risks and the Kanban board to document the actual work.
The choice of using an MVF for a coarse-grained unit of work was intentional. I wanted a macro view of the work that also captured customer learning versus having just a task board (which we keep separate).
While the Kanban board was great for tracking features, it was still a mental leap to go between the canvas and the board. Even though using the canvas to represent risks made sense, since everything on the Lean Canvas needs to be tested, the framing on the canvas is around assumptions. I found that simply marking a section on the canvas as a risk wasn’t sufficient, as one still needed to translate those sets of assumptions into risks and then prioritize them.
Mental leaps are bad because different people make different leaps which isn’t a bad thing on its own. You run into trouble when those undocumented mental leaps start driving work for others.
“Standardized tasks are the foundation of continuous improvement.”
- Jeffrey Liker, The Toyota Way
It also became quickly apparent that an MVF wasn’t a single experiment but made up of several experiments, which in turn was made up of several tasks. The board was too macro and, as a result, slow-moving.
A little more inspiration: The Vision-Strategy-Product Pyramid
We needed a process that flowed better end-to-end. The idea for that flow, and subsequent lean stack, came from listening to Eric Ries describe his Vision-Strategy-Product pyramid on a webinar we did together.
I had seen the pyramid in Eric’s book many times, but this time it had a different effect.
Here’s what I took away:
When entrepreneurs get hit by an idea, it all comes in as a single clear signal. Another way to restate the top reason products fail is that, as entrepreneurs, we often don’t take the time to deconstruct the idea into its vision, strategy, and product components. We instead race up the pyramid to the top — only to pre-maturely fall in love with the product.
A good way to explain the pyramid is by using a driving metaphor (like Eric does in his book):
Imagine you accepted a new job across town. The vision represents your destination or new place of work. The strategy represents all the possible means of getting there — you might bike, take a bus, drive, etc. You don’t know upfront what routes may be optimal, so you run experiments. A change in strategy is a pivot. The product is a repeatable roadmap for getting to work.
Another useful model for explaining the pyramid is using Simon Sinek’s Golden Circle. The vision is your why. The strategy is your how. And the product is your what.
Version 3: The Lean Stack
The pyramid is not only a good mental model but can be weaved into a process that flows by building a visual control system at each pyramid stage. That’s exactly what I did with the Lean Stack.
The Vision Layer — Lean Canvas
The lowest layer of the stack, your vision or why is still best captured by a Lean Canvas. It’s meant to document your current best guess at realizing a working business model.
The Strategy Layer — Strategy & Risks Board
The middle layer of the stack is the glue that connects the other two layers that were missing from my previous attempts. This layer helps to break down the big vision into an implementation plan (strategy) that is both informed through knowledge from studying existing analogs/antilogs and having conversations about risks with your team, stakeholders, advisors, customers, and even competitors.
The analogs/antilogs framework is a concept described by Randy Komisar and John Mullins in their book: “Getting to Plan B” which I’ll illustrate with examples in my next post.
Risks are captured on a Kanban board first in the backlog area, where they are prioritized and then used to drive other work (experiments) down the line.
The Product Layer — Validated Learning Board
The top layer of the stack is intended to capture the actual work that goes into building the product(s) that realize the vision.
I capture this work on a Validated Learning Board, which is similar to the Feature Kanban board but with a few additional tweaks. For one, it’s been generalized to support any product (not just software) by explicitly breaking out the flow into the four stages of the iteration meta-pattern:
- Understand Problem: Before you can define a solution, you need to understand the customer and problem.
- Define Solution: Instead of rushing to build out the solution, use a demo to define the solution first.
- Validate Qualitatively: Then validate the solution at a small scale.
- Verify Quantitatively: Finally, verify the solution scales.
But the big change here is that it models both products and experiments on the same board using a two-tiered board implemented using horizontal swimlanes. If you want to learn more about Kanban boards, I highly recommend David Anderson’s classic book: “Kanban” as a great primer.
The top tier captures the state of the product. A “product” on the board can represent a minimum viable product (MVP), minimum marketable feature (MVP), or a related sub-product. At any given time, a product can only be in one of the four stages. Each stage has clearly defined exit criteria (such as a number of interviews, learning goal, or a time box) which are captured on the product card.
For each product, you can run any number of experiments which are placed in a horizontal swimlane for the product. Each experiment has a clearly defined falsifiable hypothesis and optional time box constraint. An experiment goes through a Build/Measure/Learn cycle represented by similarly named columns on the board.
The build column represents the definition and setup stage of the experiment, which often involves things like coding, landing page design, mockups, interview script creation, etc.
The moment the experiment is shown to at least one customer, the card moves into the measurement stage.
Once sufficient data has been collected or the time box exceeded, the card is moved into the learning stage, where it is either marked validated or invalidated based on the criteria described in the falsifiable hypothesis.
That learning is then internalized to determine whether the stage exit criteria have been met. If it has, the product card moves to the next stage. Otherwise, more experiments are run.
What about tracking all the tasks within experiments?
While creating a third tier for tasks is conceptually possible, it’s generally best to avoid nesting beyond two levels as the board becomes too busy. Also, the measure of progress in a Lean Startup is learning, not building, which is another reason to keep the build details off this board.
We track our tasks on a separate task board (also Kanban) that is linked to experiments, but for now, I’m considering that board off-topic and out-of-scope.
The Lean Stack in Action
This was a lot of information to cover in a single post. Next week, I’ll cover how to wire these boards together and illustrate it in action using an example from one of my products.