The Lean Stack – Part 2

Last time, I outlined the thought process behind the Lean Stack and provided a 3000-foot overview of the toolset. In this post, I’m going to dive a little deeper into the process flow and end with a concrete case-study.

The Lean Stack MVP – A Different Approach

A number of you inquired if the new tools would be integrated into The answer is yes, eventually, but we are not starting there.

My earlier iterations (Lean Canvas layers, and Feature Kanban board) were all done in software. On the surface, a web app seemed to be the best choice because we already had a large pool of users and software should be fast and easy to change, right? Not quite. Looking back at those experiments – they took too long, cost too much, and created lots of needless waste – not counting hours dealing with UX issues, browser issues, and other defects.

You can almost always find unconventional ways to accelerate learning and reduce waste that doesn’t involve building the final solution you had in mind.

The very first Lean Canvas MVP was a blog post. The canvas was then refined over numerous workshops (through slides and paper exercises) before it was turned into software. While I considered applying the same approach here, running experiments is a more advanced and later stage step that didn’t naturally fit into my 1-day workshops.

So I invented a new learning product – The Running Lean Bootcamp. The idea behind the bootcamp was to go beyond the book and 1-day workshops which typically are characterized with high activation but low follow-through retention. In other words, people leave the workshop very excited but fail to put these principles to practice because real behavior change is hard.

The bootcamp aims to tackle this problem by getting people to run lean on their products for the period of the bootcamp – with accountability and personalized coaching built into the program. We get to share (and experiment) with our latest practices and the teams get to move their businesses forward – making it a win-win for both of us. The flow described below was refined through working with ~20 startup teams from the last bootcamp.

This time around I also decided to experiment with a physical MVP (using posters). This went against my grain because I am more of an abstract thinker. Even when I studied Electrical Engineering back in college, I was always the first one out of the simulation lab, but the last one out of the hardware lab. Despite my initial skepticism, using a physical MVP here was one of the best decisions we made.

Within a couple days, we had the posters designed, printed, and hung on a wall. Here’s a picture of what early versions looked like:

You’ll noticed there is no “Strategy and Risks” board in the top picture. That’s because there wasn’t one when we started. That board was the missing glue that was discovered accidentally as I was working with one the startups. The second picture has a hand-drawn version of that board which was eventually turned into a poster a few days later, and rolled out to all the teams.

With software, we’d have had to go back and code for a few more weeks to get this working. In the physical world, the surrounding wall and post-its provided us with a blank canvas that could be repurposed for anything we wanted. This is just one example of the many liberties the physical boards afforded us through out the process. Who says you can’t iterate quickly with a physical prototype?

Lets walk through the actual flow next.

The Lean Stack Flow

The Vision – Lean Canvas

The first step of the process is still capturing the essence of your vision as a single-page business model diagram using Lean Canvas.

I have already written a lot about Lean Canvas which I won’t repeat here again. But I will share a common pitfall I’ve seen one too many teams fall into – the analysis paralysis trap.

The goal of a Lean Startup is to inform our riskiest business model assumptions through empirical testing with customers – not rhetorical reasoning on a white board.

Yes, over time your canvas should be correctly segmented, focused and concise – and would probably even benefit from deep exploratory exercises like persona and customer flow creation. But achieving these goals on the first canvas is premature-optimization.

Instead, initially focus your efforts on quickly moving through the Lean Stack layers and use the built-in feedback loop to prioritize the areas that need further development. For example, the most rewarding time for a deep dive into personas might be when you get to the build stage of your first experiment – which will probably be a Problem Interview.

The Strategy – Strategy and Risks Board

With your vision documented, you then move on to the Strategy and Risks board. The goal here is to formulate an appropriate plan of attack – one that prioritizes learning about what’s riskest above everything else.

Risk prioritization in a startup can be non-obvious. The best starting point is identifying gaps in your thinking and talking through them with formal and/or informal advisors.

Another great tool is studying pre-existing analogs and antilogs. This is a conceptual framework introduced by Randy Komisar and John Mullins in their book: “Getting to Plan B”.

Analogs and antilogs essentially let you stand on the shoulders of others before you and see further by way of their lessons learned.

After studying a few analogs, some patterns might begin to emerge which helps in formulating your implementation plan. For example, after 37signals success with Basecamp, a number of companies applied their “build an audience through a blog, then follow with a web app” approach. Some succeeded, others didn’t.

While a strategy pattern cannot guarantee success, it can jumpstart your journey.

The Product – Validated Learning Board

With your strategy and risks documented, you are now ready to move on to experiments.

Not surprisingly, the workings of this board raised the most questions. I’ll just jump to the questions:

Question: How does one create a card for a product prior to conducting problem and solution interviews?

The product card is just a placeholder for the idea you plan to implement. All you need is a label to identify the idea or concept (which you can change later). It doesn’t pre-suppose a solution definition or commitment to build it. The only time one could potentially struggle to find a suitable name is if they were randomly fishing for ideas to go implement. But even there one could call this product: “Random idea fishing expedition”.

In practice though, by the time you get to this stage you’ve already got a pretty decent inkling of problem, customer, and even possible solution. Instead of describing how to name your product, I should be expending more words trying to talk you out of pre-maturely naming your product – not spending precious cycles running domain name searches and designing logos for your “product”.

Question: What is a Minimum Viable Feature (MVF)? What is the relation to MVP? How does one know which one to use?

The product card is intended to capture “a unit of product” that is delivered to customers. The first “unit of product” you release to customers is your Minimum Viable Product (MVP).

In my last post, I was assuming a continuous deployment process, like the one we use, where after the MVP, we would deliver subsequent “units of product” as individual feature pushes. Given that not everyone deploys in that fashion, a more general label might have been to call it a Minimum Viable Release (MVR) where the MVP is Release 1.0 and a release can in turn be a single feature (MVP) or a collection of features.

In addition to MVP and it’s follow-on MVRs, the product card can also be used to represent multiple related products on the same board. At Spark59, we use a single Lean Stack to capture the many “tools, content, coaching” products we build.

Question: Can you explain the lifecycle of a product through the 4 stages on the board?

What I found after building a few products the lean way is that the process for going from idea to MVP is/should be the same as going from MVP to Release 2.0, 3.0, etc. Otherwise, it’s very easy to stop listening to customers and be led astray. That process is what I codified into the iteration meta-pattern shown on the board.

At ideation, that process would involve

  1. Finding a problem worth solving by understanding the problem (and customers).
  2. Defining a possible solution or MVP.
  3. Testing that MVP at small scale.
  4. Then scaling out

Subsequent releases follow similar stages

  1. Finding follow-on problems worth solving that justify the release.
  2. Defining possible solutions or features that make up the release.
  3. Testing the release at small scale using a partial rollout.
  4. Then verifying value through a full rollout of release.

Question: Where do you capture product and experiment details?
The Kanban card is intended to visualize and communicate the flow of work. The face of the card is too small to hold all the details that go along with a product or experiment. So we only place the most critical pieces of information on each card.

  • For a product, that would be an identifier (name) and exit criteria for the specific stage.
  • For an experiment, that would be an identifier (usually a short action based name like “Run problem interviews”) and a list of one or more falsifiable hypotheses.
  • For a risk or issue, that would be an identifier typically posed as a question such as “Can we charge $100/mo for this product?”.

If this were an online tool, opening a card would reveal more details. We implement this today using a separate one-page A3 report. A3 reports (named after the international paper size on which it fits) are extensively used at Toyota for various problem solving initiatives which parallel a lot of similar challenges in a startup. In my attempts to grok A3 reports, I uncovered another parallel between the 4 stages of the iteration meta-pattern above and the 4 stages of the Deming cycle: Plan, Do, Check, Act (PDCA). But that’s a whole other can of worms best left for a future post.

The Lean Stack in Action

Time to jump into the concrete case-study.

Now it’s Your Turn

In lean thinking, a process is not something passed down (…) and set in stone, but rather a living product that is owned by the people doing the work.

Like Lean Canvas, Lean Stack is licensed as creative commons.
You can download (or purchase) the Lean Stack MVP posters here:

Where it goes from here is up to you!


Become a Practice Trumps Theory member. It’s free.

Get exclusive updates, worksheets, and resources delivered to your inbox.

  • Artsmc88

    I found trello to be a great service to do this

  • Ven88

    Agreed. Huge fan of trello. And (incredibly) it’s still free! 

  • Ash Maurya

    We used trello heavily on our earlier Kanban boards until we needed the concept of horizontal swim lanes. Swim lanes help you keep the product/feature card and experiments together. 

    We made do with leankitkanban for a little while and eventually switched to kanbantool for our task board. 

  • Chris

    Ash, at the end of the video, you talk about expanding your vision to cover multiple products and business models. Do you try to fit all of this onto the same lean canvas?

    We’re in a similar situation, exploring spinning off several related products, which all have different business models. Would you recommend using one Lean Stack for this?

  • Ash Maurya

    Yes we put everything on one. In our case, while we have different products, they all feed into each other and align with the original vision. That said, it’s still a great signaling mechanism and quickly brought to attention that we were taking on too much.. allowing us to prioritize and (if you are familiar with WIP from Kanban), put some limits on how many things we test at given time.

  • Patucao

    Thanks Ash for sharing your process! My startup in Brazil started applying it immediately.

    A complementary link for those, like us, who don’t know “Analogs / Antilogs” approach:

    Randy Komisar himself speaking about it in the stanford e-corner. 

  • Pingback: O Lean Stack em Português – Parte 2 | Bizstart Blog()

  • Dominic Matheron

    Hi Ash, brilliant demo of your lean stack!

    I read the Lean Startup with a lot of attention earlier this year and embraced its ideas but, like many, had a hard time defining a workflow for it.

    I then read your book, which greatly helped make it clearer.

    Really glad to see that you turned this into a company building tools to help your peers. Keep up the good work, this is all really precious help!

    PS: I am a first time entrepreneur trying to follow the lean startup and customer development for a few months now, unbelievable how much less waste and more learning we make!

  • Jeremy Blanchard

    Thanks for sharing this. Sometimes Ash references things without examples and I have a hard time groking them. This helped nail down the analog/antilog questions I had.

  • Jeremy Blanchard

    Great stuff, Ash!

    What sizes do you print the posters at?

  • Jeremy Blanchard

    Can you explain how the swim lanes relate to product/feature card and experiments?

  • Ash Maurya

    We print them huge – 54′ by 24′.

  • Ash Maurya

    Swimlanes are the horizontal grouping of a product and corresponding experiments. They keep related things together. With tools without swimlanes, it would be hard to keep experiments assigned to a particular product together assuming you have other products/features in the same stage on the board.

  • Bigwhitej

    Hi Ash, great blog. I am a new entrepreneur, starting a new online business. I am still at the idea stage and about to take it to the MVP stage and your blog and book have been great assets to keeping me in-line to reach my vision. However I am curious as to what avenues you use to hold “problem interviews.” Are these in forums,  face to face discussion or through social media?

  • Jeremy Blanchard

    Ash, you don’t talk much at all about the “Implementation Plan” aspect of the Strategy and Risks board. Can you speak to what specific kinds of things you put in there? It seems like why/how/what circle is part of it. Anything else? More importantly, how does it “flow” to/from the other parts of the stack?

  • Hashim Warren

    “Risk prioritization in a startup can be non-obvious. The best starting point is identifying gaps in your thinking and talking through them with formal and/or informal advisors.”

    I like this advice. It allows me to ask advisors “what are the riskiest parts of my idea?” rather than “do you like my idea?”

  • Hashim Warren

    first time I heard about Trello! Thanks for introducing me. What an incredible tool.

  • Hashim Warren

    Ash, have you considered the 4 actions framework (as detailed in the Blue Ocean Strategy) for your strategy board? The authors advise looking across alternative industries to discover analogs/antilogs.

    Then, using the learnings from you decide on 4 actions for your own business model:
    1. reduce
    2. eliminate
    3. increase
    4. introduce

    This helps you avoid two traps – benchmarking against existing competitors and reinventing the wheel.

    You’ll still have a guess, but at least it will be a guess that’s worthwhile to test.

    I like the 4 actions framework because it asks you what you will do with those analogs and antilogs.

  • Ash Maurya

    Exactly – in my book I outline a business model interview process to find visionary advisors that parallels customer interviews to find visionary customers.

  • Ash Maurya

    For problem interviews, in order of effectiveness towards maximizing learning:
    1. Face-to-face interviews
    2. Video skype interviews
    3. Phone/voice interviews

    In addition to interviews, you can also a learn a lot just through “fly-on-the-wall” observation wherever customers can be watched – online forums, events, malls, etc.

  • Abhi Sachdev

    I love the idea of Lean Stack. We have been using the (paid plan) and have found it really useful to communicate internally within the company as well as keep us focused. However, the way I understood lean canvas is that it is a business plan for the MVP or for a release of the product in the near future (say over the next 1-3 months) but not quite the vision document.

    The vision (IMHO) is always a more general statement and where you want the product/business plan to evolve into (based on current assumptions).

    For example, the vision could be to “address unmet needs of the individual investors who want to buy real-estate rental properties and provide services to manage those investment rental properties”. The MVP could be to simply address the problem of 1) providing analytics and predictions on buying fore-closed properties 2) providing phone consultation with experts. It need not address other benefits such as, marketplaces, referrals, group buying, etc.

    I would generally use the leancanvas to capture the problem statements around the MVP or for individual MVRs. So a bit confused about what your recommendations are about capturing the Vision and the Strategy?

    An example, like above, would be very instructive.


    P.S. The need for a concise vision document is to appeal to stakeholders within the company and outside.

  • Pingback: Focus your MVP right « Five Whys()

  • Pingback: Managing Startups: Best Posts of 2012 |()

  • Pingback: Managing Startups: Best Posts of 2012 (guest post)()

  • Pingback: Startup Strategies – Best of 2012 – Digital Cowboys()

  • Pingback: Managing Startups: Best Posts of 2012 | andrewbruce01()

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

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

  • Pingback: Tendencias de decoración para startups | Nichos de mercado en Internet()

  • Pingback: Tendencias de decoración para startups | La Factoría De Negocios()

  • 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!()

  • luis

    Trying to sign-up for the newsletter but it says: There was an error with the AJAX request: Internal Server Error

  • Pingback: Product-Camp 2014 – Hypothesen Kanban | Anton Skornyakov, Agile Trainer & Innovationsberater()