Learn how to raise your odds of success

 

The Lean Stack – Part 1

Written by Ash Maurya

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.

  • http://www.leanlearnin.com/ Brent Weber

    Ash,  Thanks for posting this.  I wanted to be there last night but had something come up.  

    I have actually been thinking a lot about this stage and came up with a Lean Experiment Tracker that fits pretty neatly along with your Validated Learning Board.  Would love your feedback.

    http://leanlearnin.com/?p=1

  • http://twitter.com/Trollaroid Trollaroid

    These are some great thought tools. I’d like to see a project management tool like Asana that had features to help this process of cyclic iteration rather than just helping to move forward with predefined tasks.

  • Emile Silvis

    Awesome. I’d love to see this all rolled into an online tool (a la http://www.leancanvas.com).

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

    In time :-)

    Will address this next week.

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

    Yes, I am big on 1 page reports much like Toyota’s A3 reports. 
    Next time, I’ll talk about what goes into them. We have different ones for Product and Experiment. The experiment one has a lot of overlap with yours.

  • http://twitter.com/agilesensei Claudio Perrone

    Thanks for you post Ash. I must admit I have been studying it carefully but I still need some clarification. 
    I guess I should wait for your next post to see what actually goes into the board. I’m a bit confused with the MVP/MMF/MVF relationship. I’m not sure about what an MVF really is, since the article does not define it (“related to MMF” how? are you using them interchangeably? and I suspect there is some typo, so I’m not too sure what goes where (e.g. “viable product (MVP), minimum marketable feature (MVP), or a related sub-product.”)

    So, let me see what I understood so far. 
    We start with assumptions, expressed in the canvas as (falsifiable) hypothesis.
    We use a risk board to explicitly prioritize the validation of those hypothesis.
    We eventually use antilogues/analogues to reduce effort and support our decision of where the uncertainty/risk really is.

    I assume you transfer the canvas propositions in that board, is it correct? Is this what you mean by “translating” hypothesis into risks? Is there any other risk that may emerge outside the canvas?

    Priority will probably certainly change over time, often based on product type, but also based on development stage (problem/solution fit, product/market fit, growth). Is there a point in time when that board loses its utility?

    So, what goes in the Validated Learning Board? I am a bit puzzled with that board. 
    There is no question that we need to track the experiments, and we need a link between experiments and the hypotheses that those experiments test. But I’m a bit puzzled by the Product in the top tier, especially since you state that the “true product is a working business model”. 
    In a problem interview we may have no MVP/MMF/MVF yet, so what goes into the “understand problem” stage? Isn’t the MMF “just” one of the byproducts of the experiments that we need to design?

    Or are you perhaps just considering the scenario of a customer/proxy “asking for a feature”, so is it a board containing some “feature request”? 

    Do you actually validate the produc/featuret? Or do you validate your assumption of the impact that the feature(s) has on reaching your goal?

    Sorry, lots of questions!

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

    This is great and yes I’ll take a stab at addressing all these in the next post and tightening up definitions. 

    Just a quick note on the validated learning board, I am using the term “product” rather loosely  but lets take the ideation stage. By the time you get to the VLB, you have an inkling of problem, solution, and customer segment. So even though I advocate not fully defining (definitely not building) your solution until you’ve understood the problem, you can still use a product name placeholder to identify the experiments under it. 

    Hopefully, this will get clearer with the concrete  example…

  • http://twitter.com/agilesensei Claudio Perrone

    Ok, I get it. The solution as defined in the canvas would be sufficient as “product”.
    Looking forward to hear more!

  • BillSeitz

    For that Golden Circle image, I’d consider (a) changing the colors of the layers of the pyramid to match the corresponding bits, and/or (b) moving the labels of the circle layers from the bottom-half to the top-half so that they correspond to the pyramid layers.

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

    Thanks – I like those… will incorporate.

  • http://twitter.com/jerrydon Jerry Don

    Thank you Ash. It will be helpful if you can add an example case study on the Lean Stack.

  • Pingback: Jnaapti – One Year On… | Gautham Pai «buzypi.in»

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

    Working on it right now for the next post.

  • http://rallyroom.net/ Jeremy Blanchard

    After reading Running Lean, I was very interested in how to visualize the process. Similar to the value Ash’s tools provide, I made a flowchart to see what the Running Lean methodology looks like all in one place. Here it is:

    http://blog.blanchardjeremy.com/post/25854027305/running-lean-flowchart

    Enjoy!

  • http://www.galoor.com/ Clint Lenard

    Great post! I saw part 2 in an email and realized I have had this sitting next to approximately 30 other tabs, yet I hadn’t gotten around to reading it. Looking forward to the next one. Just tweeted this, too, BTW.

  • Shea Lutton

    Ash,
    I witnessed firsthand the trouble startups are having running experiments to validate their business concepts, so I built an experiment platform to help them. I am working on adding template experiments to make it super simple for entrepreneurs to select experimental designs that meet their needs. Check it out: https://www.perilabs.com/site/page?view=entrepreneurs
    Shea Lutton
    Peri Labs, Inc. 

  • Pingback: Da difícil facilidade « startupolitanos

  • Pingback: O Lean Stack em Português – Parte 1 | Bizstart Blog

  • Pingback: Tim Harford And The Lean Startup | BELVIDO

  • Pingback: Bookmarks for juni 14th through juni 19th - robertsahlin.com

  • Pingback: Jour 2: Coachs et Lean Startup | NEST

  • Pingback: Jnaapti – One Year On… | jnaapti

  • Pingback: | Sébastien Sacard

  • Pingback: Quel Canvas choisir pour la définition de modèle économique ? | Sébastien Sacard

  • Pingback: Der Lean Stack (Teil 1) - //SEIBERT/MEDIA Weblog

  • http://www.facebook.com/roman.sterly Roman Sterly

    It is Simon Sinek, not Simonek :-)

  • Pingback: Der Lean Stack (Teil 2) - //SEIBERT/MEDIA Weblog

  • Pingback: Essential Reading | Startup Weekend Saratoga

  • http://twitter.com/AllanCaeg Allan Caeg

    What about org Mission & Vision? Should they be somewhere in the stack?

  • Pingback: Lean Stack 2.0 – The Art of the Scientist and The Customer Factory

  • Pingback: Introducing the Lean Stack | We Love Lean – Lean startups, design, happiness and everything in between

  • Pingback: How to Identify (and Mitigate) the Riskiest Parts of Your Product Strategy (The Lean Product Chronicles) | Street Smart Product Manager

  • Pingback: Product 101: best of the internets on product management, MVPs/MDPs, pricing, product/market fit, and more! | The Startup Textbook

  • Pingback: Pivot, Don’t Jump | KeyIdeas

  • http://www.leanventures.se Andy Cars

    Thank you Ash for yet another great post.