Medium 9781449305178

Running Lean: Iterate from Plan A to a Plan That Works

Views: 1400
Ratings: (0)

We live in an age of unparalleled opportunity for innovation. We’re building more products than ever before, but most of them fail—not because we can’t complete what we set out to build, but because we waste time, money, and effort building the wrong product.

What we need is a systematic process for quickly vetting product ideas and raising our odds of success. That’s the promise of Running Lean.

In this inspiring book, Ash Maurya takes you through an exacting strategy for achieving a "product/market fit" for your fledgling venture, based on his own experience in building a wide array of products from high-tech to no-tech. Throughout, he builds on the ideas and concepts of several innovative methodologies, including the Lean Startup, Customer Development, and bootstrapping.

Running Lean is an ideal tool for business managers, CEOs, small business owners, developers and programmers, and anyone who’s interested in starting a business project.

  • Find a problem worth solving, then define a solution
  • Engage your customers throughout the development cycle
  • Continually test your product with smaller, faster iterations
  • Build a feature, measure customer response, and verify/refute the idea
  • Know when to "pivot" by changing your plan’s course
  • Maximize your efforts for speed, learning, and focus
  • Learn the ideal time to raise your "big round" of funding
Get on track with The Lean Series
Presented by Eric Ries—bestselling author of The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses—The Lean Series gives you solid footing in a proven methodology that will help your business succeed.

List price: $21.99

Your Price: $17.59

You Save: 20%


16 Slices

Format Buy Remix

1. Meta-Principles


The proper application of any methodology first requires a clear understanding and separation of principles from tactics.

Principles guide what you do. Tactics show you how.

The essence of Running Lean can be distilled into three steps:

Document your Plan A.

Identify the riskiest parts of your plan.

Systematically test your plan.

In this chapter, we’ll cover these meta-principles. The rest of the book will focus on the reduction of these meta-principles to practice.

All men dream: but not equally. Those that dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible.

T.E. Lawrence, “Lawrence of Arabia”

Everyone gets hit by ideas when they least expect them (in the shower, while driving, etc.). Most people ignore them. Entrepreneurs choose to act on them.


2. Running Lean Illustrated


A great way to understand the meta-principles covered in Chapter 1 is to see them applied to a real product.

I wanted to pick a simple example that would be readily understood. So, rather than picking a software or hardware product, I decided to outline the process I used to write this book.

Even if you haven’t written a book, you can probably appreciate the steps that go into writing a book, which, as you’ll see, isn’t unlike building a product.

Writing a book was never in my plans. I was too busy running my company. I started my blog in October 2009 because I had more questions about Lean Startups than answers.

Along the way, a few of my blog readers started suggesting that I turn my blog posts into a book. I knew writing a book (even from blog posts) would be a massive undertaking, so while I was flattered by the requests, I did nothing at first. After about a dozen such requests, I decided to explore further.


3. Create Your Lean Canvas


Capture your business model in a portable, one-page diagram.

The Lean Canvas is the perfect format for brainstorming possible business models, prioritizing where to start, and tracking ongoing learning.

The best way to illustrate the use of the canvas is through an example. I’ll describe the thought process that went into building my first product, CloudFire, using this methodology.

When you first start out, all you have is an inkling of a problem, a solution, and maybe a customer segment. Just as rushing to build a solution can lead to waste, so can prematurely picking a customer segment or business model. The danger here is that this “selection bias” is untested and may result in a suboptimal business model or local maxima.

In computer science, hill climbing is a mathematical optimization technique. It is an iterative algorithm that starts with an arbitrary solution to a problem, then attempts to find a better solution by incrementally changing a single element of the solution. If the change produces a better solution, an incremental change is made to the new solution, and the process is repeated until no further improvements can be found.


4. Prioritize Where to Start


Now that you have a list of possible models, the next step is to prioritize where to start. Otherwise, it’s easy to fall into the trap of making marginal progress, only to get stuck later.

Incorrect prioritization of risk is one of the top contributors of waste.

Before moving on, it helps to define what I mean by risk. We know that startups are highly uncertain, but uncertainty and risk aren’t the same thing. We can be uncertain about a lot of things that aren’t risky.

Douglas Hubbard makes a clear distinction between the two in his book, How to Measure Anything (Wiley):

Uncertainty: The lack of complete certainty, that is, the existence of more than one possibility.

Risk: A state of uncertainty where some of the possibilities involve a loss, catastrophe, or other undesirable outcome.

The good news is that the Lean Canvas automatically captures uncertainties that also are risks—the loss here can be quantified both in terms of opportunity costs and real costs. But not all these risks are equal.


5. Get Ready to Experiment


With your starting models and risks prioritized, now you need to get ready to run experiments.

Before you start running your first set of experiments, it’s important to assemble the right team.

In a Lean Startup, traditional department labels like “Engineering,” “QA,” “Marketing,” and so forth can get in the way and create needless friction. Eric Ries instead recommends organizing around two teams, the Problem team and the Solution team.

The Problem team is mostly involved with “outside-the-building” activities such as interviewing customers, running usability tests, and so on.

The Solution team is mostly involved with “inside-the-building” activities such as writing code, running tests, deploying releases, and so on.

I say “mostly” because these teams need to be highly cross-functional with overlapping members. Also, interacting with customers is everyone’s responsibility.


6. Get Ready to Interview Customers


The fastest way to learn is to talk to customers. Not releasing code, or collecting analytics, but talking to people. We’ll be using customer interviews as a learning tool[13] throughout the rest of book. This chapter lays some groundwork for conducting good interviews.

When asked to do the smallest thing to learn from customers, many founders’ first instinct is to conduct a bunch of surveys or focus groups. While running surveys and focus groups may seem more efficient than interviewing customers, starting there is usually a bad idea.

Here’s why:

It is hard, if not impossible, to script a survey that hits all the right questions to ask, because you don’t yet know what those questions are. During a customer interview, you can ask for clarification and explore areas outside your initial understanding.

Customer interviews are about exploring what you don’t know you don’t know.


7. The Problem Interview


Understand your customer’s worldview before formulating a solution.

The Problem interview is all about validating your hypotheses around the “problem-customer segment” pair. In the Problem interview, you are specifically looking to tackle the following risks:

How do customers rank the top three problems?

How do customers solve these problems today?

Is this a viable customer segment?

Your first objective is measuring how customers react to your top problems. Some ways of doing this are measuring customer reaction to a problem-centric teaser landing page,[16] blog post, or a Google/Facebook ad.

While these tactics can be helpful in quickly gauging problem resonance with customers, you still need to engage customers more actively to truly understand the problems they face—specifically if/how they solve them today. This might be done using informal observation techniques like those employed in the “Design Thinking” and “User Centric Design” methodologies, and/or using structured customer interviewing techniques.


8. The Solution Interview


Test the solution with a “demo” before building the actual product.

Armed with a prioritized problem list and an understanding of existing alternatives, you are now ready to formulate and test a solution.

You will start by double-checking your learning from the Problem interview, then look to test the following additional risks:

How do you identify early adopters?

What is the minimum feature set needed to launch?

Will customers pay for a solution?

What price will they bear?

The main objective here is to use a “demo” to help customers visualize your solution and validate that it will solve their problem.

Most customers are great at articulating problems but not at visualizing solutions.

I use the term demo loosely to mean anything that can reasonably stand in for the actual solution. The assumption here is that building the “full solution” is time-consuming and could lead to waste if you build the wrong solution or add unneeded features. You want to build just enough of the solution (or a proxy, like screenshots, a prototype, etc.) that you can put in front of customers for the purpose of measuring their reaction and further defining the requirements for your minimum viable product (MVP).


9. Get to Release 1.0


Reduce scope and shorten the cycle time between requirements and release so that you get to the learning parts faster.

Let’s start by taking a closer look at where learning (about customers) happens during a typical product development cycle (see Figure 9-1).

While some learning happens during the requirements-gathering stage, most learning happens after you release your product. Even though building a product is the purpose of a startup, very little learning happens during development and QA. Sure, you’re learning about other things then, just not about customers.

We obviously can’t eliminate development and QA, but we can shorten the cycle time from requirements to release so that you get to the learning parts faster.

The first step is to reduce the scope of your minimum viable product (MVP) to its essence so that you build the smallest thing possible.

A danger with iterating through mock-ups during the Solution interview is that it is quite easy to get carried away and end up with more than you need for your MVP. In order to reduce waste and speed up learning, you need to pare down your mock-ups so that all you have left is the essence of your product: your MVP.


10. Get Ready to Measure


You need not only the ability to visualize your customer lifecycle, but also the ability to measure it.

Even though the terrain before product/market fit is riddled with qualitative learning, you still need actionable metrics to be able to visualize and measure your customer lifecycle.

The objective before product/market fit is not as much about optimizing for conversion and all about quickly identifying and troubleshooting hot spots in your customer lifecycle.

Up until now, you have made a number of product decisions based on what customers have told you. It’s time to start measuring what they do.

An actionable metric is one that ties specific and repeatable actions to observed results.

The opposite of actionable metrics are vanity metrics (like web hits or the number of downloads), which only serve to document the current state of the product but offer no insight (by themselves) into how you got there or what to do next.


11. The MVP Interview


Before selling your minimum viable product (MVP) to strangers through your distribution channel (e.g., marketing website), sell it face to face to friendly early adopters. Learn from them. Then refine your design, positioning, and pricing for launch.

With your MVP, marketing website, and conversion dashboard ready, you are all set to pay your prospects another visit. Your objective is to sign them up to use your service and, in the process, test out your messaging, pricing, and activation flow.

If you can’t convert a warm prospect in a 20-minute face-to-face interview, it will be much harder to convert a visitor in less than eight seconds on your landing page.

During the MVP interview, you are specifically looking to answer the following questions:

Does your landing page get noticed?

Do customers make it all the way through your activation flow?

What are the usability hot spots?


12. Validate Customer Lifecycle


Now that you have some early customers signed up, work closely with them to ensure that they make it through your conversion funnel completely.

The fastest way to learn from customers is to talk to them.

Much like I favor interviewing customers over conducting surveys, I prefer getting feedback from customers in person or over the phone than through other means like email, forums, or discussion boards.

Here’s why:

A toll-free number sends a signal to your customers that you care and that you went the extra mile to make it easy for them to call you.

Contrary to popular belief, you won’t be bombarded with phone calls. A lot of my calls are typically from prospects with questions about the service, not about support issues. It is fairly easy to set calling hours during the day and reroute the calls if and when you run into a scaling problem (which is a great problem to have).


13. Don’t Be a Feature Pusher


In a great market, a market with lots of real potential customers, the market pulls the product out of the startup.

Marc Andreessen,The Pmarca Guide to Startups”

Earlier, I advocated implementing a Continuous Deployment system. While Continuous Deployment helps you streamline your product development process for speed, you have to be wary of simply cranking out more features faster.

When you launch your product, lots of things can and will go wrong. Sure enough, feature requests will also start pouring in. The common tendency is to build more, but that is seldom the answer.

Here’s why:

You have taken great effort to keep your minimum value proposition (MVP) as small and focused as possible. Don’t dilute your UVP with unnecessary distractions.

Simple products are simple to understand.


14. Measure Product/Market Fit


The first step is to define a metric to measure product/market fit. Once you have that, you can systematically iterate toward achieving it.

Even though Marc Andreessen did not coin the term product/market fit,[22] his blog post on the topic remains one of the most popular descriptions of what product/market fit feels like:

Product/Market fit means being in a good market with a product that can satisfy that market.

You can always feel when product/market fit isn’t happening. The customers aren’t quite getting value out of the product, word of mouth isn’t spreading, usage isn’t growing that fast, press reviews are kind of “blah,” the sales cycle takes too long, and lots of deals never close.

And you can always feel product/market fit when it’s happening. The customers are buying the product just as fast as you can make it—or usage is growing just as fast as you can add more servers. Money from customers is piling up in your company checking account. You’re hiring sales and customer support staff as fast as you can. Reporters are calling because they’ve heard about your hot new thing and they want to talk to you about it.


15. Conclusion


Congratulations! We’re done.

I believe that the life of any startup can be divided into two parts: before product/market fit (call this “BPMF”) and after product/market fit (“APMF”).

Marc Andreessen, “The Pmarca Guide to Startups”

Getting to product/market fit is the first significant milestone of a startup. At this stage, some level of success is almost guaranteed and your focus can now shift from learning to scaling (see Figure 15-1).

Along with continually tuning and resetting your engine of growth to meet customer adoption challenges as you attempt to “cross the chasm” between early adopters and mainstream customers,[25] you will inevitably also be faced with new challenges as you grow your company.

Every process works well until you add people.

The key is to build a continuous learning culture of experimenters versus specialists, where it’s everyone’s job to be accountable toward creating and capturing customer value.


A. Bonus Material


I’ve bootstrapped my company for the past seven years and learned a lot about bootstrapping from Bijoy Goswami, founder of Bootstrap Austin. Bijoy doesn’t limit the definition of bootstrapping to the more commonly held one about building a company without external funding, but rather views bootstrapping as a philosophy summarized as “Right action, right time.”

This mantra applies just as well to Lean Startups as it does to bootstrapped startups:

At every stage of the startup, there are a set of actions that are “right” for the startup, in that they maximize return on time, money, and effort. A lean/bootstrapped entrepreneur ignores all else.

While bootstrapping and Lean Startup techniques are not just limited to funding, funding is one of the first problems entrepreneurs tackle, which can lead to waste.

There are several reasons why premature funding can lead to waste:



Print Book

Format name
File size
0 Bytes
Not Allowed
Not Allowed
Read aloud
Format name
Read aloud
In metadata
In metadata
File size
In metadata