Managing Startups: Best Blog Posts

Chapter 4. The Lean Stack MVP—A Different Approach

Ash Maurya

In a previous post, I outlined the thought process behind the Lean Stack and provided a 3,000-foot overview of the toolset. A number of you inquired if the new tools would be integrated into LeanCanvas.com. The answer is yes, eventually.

My earlier iterations (Lean Canvas layers and the 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.

Note

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

The very first Lean Canvas minimum viable product (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 one-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 one-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 into 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 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.

Note

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

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 preexisting analogs and antilogs. This is a conceptual framework introduced by Randy Komisar and John Mullins in their book, Getting to Plan B.

Note

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 that help in formulating your implementation plan. For example, after 37signals’s 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.

Note

While a strategy pattern cannot guarantee success, it can jump-start 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 presuppose a solution definition or commitment to build it. The only time one could potentially struggle to find a suitable name is if one 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 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—i.e., 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 (“The Lean Stack—Part 1”), 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 the 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 the lifecycle of a product through the four stages on the board?

What I found after building a few products the lean way was 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 they fit) are extensively used at Toyota for various problem-solving initiatives that 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

If you’d like to see a concrete case study, check out the video on my blog.

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.

Where it goes from here is up to you!