Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Q&A with Ash Maurya on Scaling Lean

Q&A with Ash Maurya on Scaling Lean


Key Takeaways

  • You can communicate an early stage idea to key stakeholders using innovation versus financial metrics
  • Next to validated learning you also need measurable business results to build a successful product
  • Measuring traction, the rate at which a business model captures monetizable value from its customers, is essential for growing your business
  • To launch a new feature or kick off a new marketing campaign you should craft experiments for breakthrough learning
  • "Failure" should be removed from your vocabulary

In the book Scaling Lean, Ash Maurya explores how entrepreneurs can collaborate with stakeholders to establish a business model for a new product or service using Lean Startup principles. It builds on top of his first book Running Lean, showing how to use experiments, measure business progress, and scale your startup.

InfoQ readers can download a sample of Scaling Lean.

InfoQ interviewed Ash Maurya about what to measure when your startup is growing, how you can you find out if the business model that you have for your startup is worth pursuing, how to design and run good experiments, and the differences between lean sprints and agile/Scrum sprints. InfoQ also asked him for advice for entrepreneurs who want to scale their startup.

InfoQ: Why did you write this book?

Ash Maurya: Most new products fail simply because entrepreneurs fail to build what customers want. The challenge is that you can't simply ask customers what they want, you have to extract it from them.

My first book, Running Lean, tackled this problem. It described how to "get outside the building" and engage customers - to first deeply understand their problems before building solutions. 

However, once these entrepreneurs got back "inside the building", they faced a different challenge: how to communicate their findings in the language of their stakeholders. While learning and qualitative validation is key for testing the riskiest assumptions, it doesn't easily extrapolate to financial metrics like profit and ROI. So these entrepreneurs end up spinning different progress stories - one for their core team built on learning and build velocity metrics, and the other for their stakeholders built on "any metric" that communicates growth. 

This leads to a dichotomy of progress stories that isn't healthy. Bridging this dichotomy was the goal of Scaling Lean.

InfoQ: For whom is this book intended?

Maurya: Startups are conversations. While Running Lean was aimed at the "entrepreneur to customer" conversation, Scaling Lean is aimed at the "entrepreneur to stakeholder" conversation. This book is for entrepreneurs and their stakeholders.

An entrepreneur is anyone charged with bringing a bold new idea to life under conditions of extreme uncertainty. This could be a startup founder, a corporate innovator, or a product manager.

A stakeholder is someone who holds the innovation accountable. This could be a mentor, investor, domain expert, or a leader in the organization.

InfoQ: Lean startup tells to use validated learning as the measure of progress when we're starting something new. What should we to measure when we want to grow?

Maurya: Validated learning is critical for testing key assumptions and invaluable for keeping our unbridled passion for our products in check. But when this pursuit of learning is carried out at the expense of demonstrable business results, which is often the case, the analogy of "a startup as an experiment" breaks down. We need to realize that the goals of scientists and entrepreneurs are not the same.

The pursuit of raw knowledge is a scientific pursuit. In that realm, learning is truly the measure of progress. But entrepreneurship is goal driven. Empirical learning is part, but not all, of the final goal: to build a repeatable and scalable business model before running out of resources. While empirical learning is a key part of that process, unless you can quickly turn that learning into measurable business results (aka traction), you are just accumulating trivia.

InfoQ: How can we measure traction, and how can we analyze data?

Maurya: Coming from a business modeling mindset, I define traction as the output of a working business model. Specifically, traction is the rate at which a business model captures monetizable value from its customers.

It's important to make the distinction between monetizable value and revenue. Monetizable value is a key measurable customer activity that serves as a leading indicator for future revenue. If customers do enough of the first, the second takes care of itself.

InfoQ: How can you find out if the business model that you have for your startup is worth pursuing?

Maurya: We have traditionally reached for the mythical Excel spreadsheet where we pound away on the keyboard for hours with a goal of being able to tell a big story just within the realm of believability. The problem with this approach is that all these numbers distract us from our most critical assumptions. It's not the output, but the inputs to the spreadsheet that matter. There are only a handful of key metrics that drive any business.

In Scaling Lean, I share a five minute back-of-the-envelope calculation that uses Fermi estimates to ballpark the potential of any business model. The goal isn't precision, but estimation. The goal isn't building the model top-down, but bottoms-up.

Instead of juggling hundreds of numbers, using just three-five inputs such as your pricing model, projected customer lifetime, acquisition rate, and minimum success criteria, you can quickly ballpark your business model’s output. If you can't make this model work on paper, you're going to be hard pressed to make it work in the real world.

For an example, check out Chapter 2 in the excerpt.

InfoQ: What suggestions do you have for measuring and getting insight into the progress that a startup is making?

Maurya: Like taking a journey into uncertain terrain, we need to start with a rough ballpark destination. This is where the goal, or specifically your minimum success criteria, comes into play. Your minimum success criteria is the smallest outcome (typically a yearly revenue number) that would deem your project a success X years from now where X <= 3 years.

Your next step is turning your minimum success criteria into a "number of customers" which is a lot more tangible than revenue. So assuming your minimum success criteria is to reach $10M/year revenue in three years and your customers pay you $200/mo, you would need 4,1667 active customers by year 3.

Most businesses don't grow linearly, but non-linearly. Fast growing businesses tend to follow a 10X/year growth rule which is a good rule of thumb to start with that you can further refine later.

By applying the 10X rule, you can now chart out a rough roadmap with the following milestones:

  • Year 1: 42 customers
  • Year 2: 416 customers
  • Year 3: 4,167 customers

Even though these numbers are a quick back-of-the-envelope calculation, a rough estimate is always better than no estimate. It gives you a starting goal which you revise as more data comes in.

Using experiments and metrics as your compass and dashboard, you steer and course correct until you reach your intended destination.

InfoQ: Which ideas can you give for designing and running good experiments?

Maurya: Whenever you launch a new feature or kick off a new marketing campaign, you are running an experiment. Unfortunately, most experiments don't lead to breakthrough insights because we are easily fooled by our own cognitive biases like post-rationalizing results to match our perceptions.

To avoid this, I outline the following "7 Habits for Running Highly Effective Experiments" in a chapter with the same title:

  1. Declare your expected outcomes up front
  2. Make declaring outcomes a team sport
  3. Emphasize estimation, not precision
  4. Measure actions rather than words
  5. Turn your assumptions into falsifiable hypotheses
  6. Time box your experiments
  7. Always use a control group

InfoQ: How can you learn from experiments that failed?

Maurya: Can you find the common theme across these discoveries: penicillin, microwave, X-ray, gunpowder, plastics, and vulcanized rubber?

Yes, they were all accidental discoveries. But because they were accidental, it's easy to dismiss them as lucky breaks. However, there was more than luck at play. All these discoveries started as failed experiments.

In each of these cases, the inventors were seeking a specific outcome, and instead got a different outcome. But instead of throwing away their "failed" experiments, they did something very different from most people: they asked why.

Innovation experiments are no different. Achieving breakthrough, then, is less about luck and more about a rigorous search. The reason the hockey-stick trajectory has a long at portion in the beginning is not because the founders are lazy and not working hard, but because before you can find a business model that works, you have to go through lots of things that don't.

Breakthrough insights are often hidden within failed experiments.

Most entrepreneurs, however, run away from failure. At the first sign of failure, they rush to course correct without taking the requisite time to dig deeper and get to the root cause of the failure. In the Lean Startup methodology, the term "pivot" is often used to justify this kind of course correction.

But this, of course, is a misuse of the term:

A pivot not grounded in learning is simply a disguised "see what sticks" strategy.

The key to breakthrough isn't running away from failure but, like the inventors mentioned above, digging in your heels and asking why. The "fail fast" meme is commonly used to reinforce this sentiment. But I've found that the taboo of failure runs so deep (everywhere except maybe in Silicon Valley), that "failing fast" is not enough to get people to accept failure as a prerequisite to achieving breakthrough. You need to completely remove the word "failure" from your vocabulary.

There is no such thing as a failed experiment, only experiments with unexpected outcomes.


InfoQ: What are the differences between lean sprints and agile/Scrum sprints?

Maurya: A lean sprint is a time-boxed iteration for sourcing, ranking, and testing big ideas using small, fast, additive experiments.

While lean sprints are heavily influenced by agile and scrum practices, there are some key differences.

1. The goals are different. While the goal of a Scrum sprint is demonstrating "build velocity", the goal of a lean sprint is demonstrating "traction velocity". It is not enough to build a great product or feature during an iteration, or just to demonstrate learning. You have to build, measure, learn, and demonstrate how your product or feature affects one or more of the key levers for traction.

2. The participants are different. Scrum and agile are typically developer-only practices. Lean sprints, on the other hand, require the complete team, including your internal and external stakeholders.

3. Time boxing does not dictate build or release cadence. I am still an advocate for using kanban (or just-in-time) techniques for continuous delivery. Time boxes in a lean sprint are used only to force a decision and do not drive the release cycle. You can still choose to practice continuous delivery or a more traditional schedule-based release cycle as you see fit.

InfoQ: Any final advice that you can give to entrepreneurs who want to scale their startup?

Maurya: Establishing repeatability is a prerequisite to scaling. Too many entrepreneurs fall into the trap of premature scaling where they try to go fast on everything. When you go fast on everything, you only end up getting lost faster.

The key is continuously identifying the key constraint or bottleneck holding back your business model and only focusing on breaking the constraint. The way to identify your key constraints is through metrics. Once a constraint is broken, you need to search for the right next constraint to work on. Then, rinse and repeat.

Some of you will recognize this as the "Theory of Constraints" from Eliyahu Goldratt’s book: "The Goal". His framework was a key influence in my book, where I adapted his focusing steps for systems thinking to the business modeling process.

About the Book Author

Ash Maurya is the creator of the one-page busi­ness modeling tool Lean Canvas and the author of Running Lean. He regularly hosts sold-out workshops around the world, serves as a mentor to several accel­erators, including TechStars, Accelerace, and Slingshot, and guest lectures at several universities, including MIT, Harvard, and the University of Texas, Austin. He serves on the advisory board of a number of startups, consults for new and established companies, and con­tributes to leading business publications and websites. He lives in Austin, Texas.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • How to integrate the running and scaling lean approach to scale multisided business model?

    by Kavin Natarajan,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    I am Business management student. I have a startup plan. I have read running lean and scaling lean book as suggested by my professor. I just want to know In what ways i can integrate the both approaches( running glean and scaling lean) to scale to the business model?What would be my first step to the scale business model ?My business archetypes is Multisided .

  • Re: How to integrate the running and scaling lean approach to scale multisi

    by Kavin Natarajan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    can someone help me with the reply?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p