The Lean Stack – Part 1

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 a lot of 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.

  1. The true product of an entrepreneur is NOT the solution, but a working business model.
  2. 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 out 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 to 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 own 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 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 process. But at Toyota they view their TPS reports differently.

“The right process will produce the right results.”
- Jeffrey Liker, The Toyota Way

In lean thinking, a process is not something passed down from the top and set in stone, but rather a living product that is 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 continuously improve it. 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 a number of attempts, we couldn’t get ourselves to adopt it into our daily routine.

We found ourselves struggling to constrain an experiment to a single section on the canvas. Many experiments, such as running a solution interview, potentially test a number of 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 a number of experiments which in turn was made up of a number of 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 many times before in Eric’s book 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 it’s 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 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 up front 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 Simonek’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 it can be weaved into a process that flows by building a visual control system at each stage of the pyramid. 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 was 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 as well as having conversations about risks with your team, stakeholders, advisors, customers, 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 simply 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 kind of product (not just software) by explicitly breaking out the flow into the 4 stages of the iteration meta-pattern:

  1. Understand Problem: Before you can define a solution, you need to understand the customer and problem.
  2. Define Solution: Instead of rushing to build out the solution, use a demo to define the solution first.
  3. Validate Qualitatively: Then validate the solution at small scale.
  4. Verify Quantitatively: Finally verify the solution scales.

But the big change here is that it models both product 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 a clearly defined exit criteria (such as number of interviews, learning goal, or a time box) which is 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 measure 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 has 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 it’s conceptually possible to create a third tier for tasks, it’s generally best to avoid nesting beyond 2 levels as the board becomes way 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.

  • JKLIC

    Great post, Ash. This may be a bit premature, but do you think you’ll try to incorporate your “Strategy and Risks Board” and “Validated Learning Board” into the LeanCanvas.com site? I’d love to incorporate these additional steps into testing my current Lean Canvas. Thanks a lot and I’m looking forward to your next post. Jarred 

  • http://www.ashmaurya.com/ Ash Maurya

    The short answer is (eventually) yes… but as software always takes time to build/test, in the next post I’ll provide some possible interim solutions.

  • http://www.facebook.com/profile.php?id=642582501 Simon Vandendriessche

    This is really interesting and practical, thank you for the post.

    In part 2, do you plan to present some detailed examples of use of your Lean Stack? I have to say I feel myself a little confused when trying to use all these boards in real life!

    Thanks again.

  • http://www.ashmaurya.com/ Ash Maurya

    Yes, I know it’s a lot to visualize and my next post will build upon a real world example from scratch.

  • http://www.facebook.com/profile.php?id=642582501 Simon Vandendriessche

    Great, thanks!

  • http://www.facebook.com/profile.php?id=642582501 Simon Vandendriessche

    Oh and BTW, when do you plan to publish your next post?

  • http://www.ashmaurya.com/ Ash Maurya

    Working on it right now… aiming to have it published late this week or early next week.

  • http://rallyroom.net/ Jeremy Blanchard

    You’re on fire, Ash! This is brilliant stuff. Definitely helps bring clarity to the processes you presented in the book. 

    In my own attempt to bring clarity to these workflow, I made a giant flow chart of the process described in the book on my whiteboard. I’ll be blogging about it soon. 

  • Pingback: Validating the Riskiest Parts of our Business Model

  • Pingback: The Lean Stack - Parte I. Oficial Ash Maurya Castellano »