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 will dive a little deeper into the process flow and end with a concrete case study.

The Lean Stack MVP — A Different Approach

Several of you inquired if the new tools would be integrated into LeanCanvas.com. 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 became 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 by 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 few days, we had the posters designed, printed, and hung on a wall. Here’s a picture of what early versions looked like:

You’ll notice 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 of 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 throughout the process. Who says you can’t iterate quickly with a physical prototype?

Let's 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 riskiest 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, several 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 jump to the questions:

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

The product card is just a placeholder for the idea you plan to implement. You only need a label to identify the idea or concept (which you can change later). It doesn’t presuppose a solution definition or commitment to building 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: a “Random idea fishing expedition.”

In practice, though, by the time you get to this stage, you’ve already got a pretty decent inkling of the 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 prematurely 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 assumed 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 its 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 a product's lifecycle through the four 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 a 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 a 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 four stages of the iteration meta-pattern above and the four 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.

Sign up for a free Lean Stack account or contact us for downloadable Lean Stack posters here: Lean Stack.

Where it goes from here is up to you!