Part Three: Accelerate
In Chapter 9, we will see how Lean Startups take advantage of the counterintuitive power of small batches. We will see how Lean Startups take advantage of the counterintuitive power of small batches. Just as lean manufacturing has pursued a just-in-time approach to building products, reducing the need for in-process inventory, Lean Startups practice just-in-time scalability, conducting product experiments without making massive up-front investments in planning and design.Chapter 10 will explore the metrics startups should use to understand their growth as they add new customers and discover new markets. Sustainable growth follows one of three engines of growth: paid, viral, or sticky.
Chapter 11 shows how to build an adaptive organization by investing in the right amount of process to keep teams nimble as they grow. We will see how techniques from the tool kit of lean manufacturing, such as the Five Whys, help startup teams grow without becoming bureaucratic or dysfunctional.
In Chapter 12, we’ll come full circle. As startups grow into established companies, they face the same pressures that make it necessary for today’s enterprises to find new ways to invest in disruptive innovation. In fact, we’ll see that an advantage of a successful startup’s rapid growth is that the company can keep its entrepreneurial DNA even as it matures.
Chapter 9: Batch
The biggest advantage of working in small batches is that quality problems can be identified much sooner.
At IMVU, we attempted to design, develop, and ship our new features one at a time, taking advantage of the power of small batches. Here’s what it looked like. Instead of working in separate departments, engineers and designers would work together side by side on one feature at a time. Whenever that feature was ready to be tested with customers, they immediately would release a new version of the product, which would go live on our website for a relatively small number of people. The team would be able immediately to assess the impact of their work, evaluate its effect on customers, and decide what to do next. For tiny changes, the whole process might be repeated several times per day.
In fact, in the aggregate, IMVU makes about fifty changes to its product (on average) every single day. Just as with the Toyota Production System, the key to being able to operate this quickly is to check for defects immediately, thus preventing bigger problems later. For example, we had an extensive set of automated tests that assured that after every change our product still worked as designed.
For example, we had an extensive set of automated tests that assured that after every change our product still worked as designed. We called this our product’s immune system because those automatic protections went beyond checking that the product behaved as expected. We also continuously monitored the health of our business itself so that mistakes were found and removed automatically.
This class of problems is hard to detect solely with automation but is still catastrophic from a business point of view. At IMVU, our immune system is programmed to detect these business consequences and automatically invoke our equivalent of the andon cord.
When our immune system detects a problem, a number of things happen immediately:
- The defective change is removed immediately and automatically.
- Everyone on the relevant team is notified of the problem.
- The team is blocked from introducing any further changes, preventing the problem from being compounded by future mistakes …
- … until the root cause of the problem is found and fixed. (This root cause analysis is discussed in greater detail in Chapter 11.) At IMVU, we called this continuous deployment.
Continuous Deployment Beyond Software
- Hardware becoming software.
- Fast production changes. Historically, this has been used to offer the customer many choices of product, but in the future, this capability will allow the designers of products to get much faster feedback about new versions.
- 3D printing and rapid prototyping tools.
The essential lesson is not that everyone should be shipping fifty times per day but that by reducing batch size, we can get through the Build-Measure-Learn feedback loop more quickly than our competitors can. The ability to learn faster from customers is the essential competitive advantage that startups must possess.
From the point of view of individual efficiency, working in large batches makes sense. It also has other benefits: it promotes skill building, makes it easier to hold individual contributors accountable, and, most important, allows experts to work without interruption. At least that’s the theory. Unfortunately, reality seldom works out that way.
When I work with product managers and designers in companies that use large batches, I often discover that they have to redo their work five or six times for every release. One product manager I worked with was so inundated with interruptions that he took to coming into the office in the middle of the night so that he could work uninterrupted. When I suggested that he try switching the work process from large-batch to single-piece flow, he refused— because that would be inefficient! So strong is the instinct to work in large batches, that even when a large-batch system is malfunctioning, we have a tendency to blame ourselves.
Large batches tend to grow over time. Because moving the batch forward often results in additional work, rework, delays, and interruptions, everyone has an incentive to do work in ever-larger batches, trying to minimize this overhead. This is called the large-batch death spiral because, unlike in manufacturing, there are no physical limits on the maximum size of a batch. 6 It is possible for batch size to keep growing and growing. Eventually, one batch will become the highest-priority project, a “bet the company” new version of the product, because the company has taken such a long time since the last release. But now the managers are incentivized to increase batch size rather than ship the product. In light of how long the product has been in development, why not fix one more bug or add one more feature? Who really wants to be the manager who risked the success of this huge release by failing to address a potentially critical flaw?
The ideal goal is to achieve small batches all the way down to single-piece flow along the entire supply chain. Each step in the line pulls the parts it needs from the previous step. This is the famous Toyota just-in-time production method.
Startups struggle to see their work-in-progress inventory. When factories have excess WIP, it literally piles up on the factory floor. Because most startup work is intangible, it’s not nearly as visible. For example, all the work that goes into designing the minimum viable product is— until the moment that product is shipped— just WIP inventory. Incomplete designs, not-yet-validated assumptions, and most business plans are WIP. Almost every Lean Startup technique we’ve discussed so far works its magic in two ways: by converting push methods to pull and reducing batch size. Both have the net effect of reducing WIP.
Remember that although we write the feedback loop as Build-Measure-Learn because the activities happen in that order, our planning really works in the reverse order: we figure out what we need to learn and then work backwards to see what product will work as an experiment to get that learning. Thus, it is not the customer, but rather our hypothesis about the customer, that pulls work from product development and other functions. Any other work is waste.
Process is only the foundation upon which a great company culture can develop. But without this foundation, efforts to encourage learning, creativity, and innovation will fall flat— as many disillusioned directors of HR can attest. The Lean Startup works only if we are able to build an organization as adaptable and fast as the challenges it faces. This requires tackling the human challenges inherent in this new way of working; that is the subject of the remainder of Part Three.
Chapter 10 Grow
I use the word sustainable to exclude all one-time activities that generate a surge of customers but have no long-term impact, such as a single advertisement or a publicity stunt that might be used to jump-start growth but could not sustain that growth for the long term. Sustainable growth is characterized by one simple rule: New customers come from the actions of past customers. There are four primary ways past customers drive sustainable growth:
1. Word of mouth
2. As a side effect of product usage.
3. Through funded advertising.
4. Through repeat purchase or use.
These sources of sustainable growth power feedback loops that I have termed engines of growth.
The Sticky Engine of Growth
The rules that govern the sticky engine of growth are pretty simple: if the rate of new customer acquisition exceeds the churn rate, the product will grow. The speed of growth is determined by what I call the rate of compounding, which is simply the natural growth rate minus the churn rate. Like a bank account that earns compounding interest, having a high rate of compounding will lead to extremely rapid growth— without advertising, viral growth, or publicity stunts.
The way to find growth is to focus on existing customers for the product even more engaging to them. This goes against the standard intuition in that if a company lacks growth, it should invest more in sales and marketing. This counterintuitive result is hard to infer from standard vanity metrics.
The Viral Engine of Growth
This is distinct from the simple word-of-mouth growth discussed above. Instead, products that exhibit viral growth depend on person-to-person transmission as a necessary consequence of normal product use. Customers are not intentionally acting as evangelists; they are not necessarily trying to spread the word about the product. Growth happens automatically as a side effect of customers using the product. Viruses are not optional.
the Hotmail team could not afford an extensive marketing campaign. But everything changed when they made one small tweak to the product. They added to the bottom of every single e-mail the message “P.S. Get your free e-mail at Hotmail” along with a clickable link. Within weeks, that small product change produced massive results. Within six months, Bhatia and Smith had signed up more than 1 million new customers.
The same phenomenon is at work in Tupperware’s famous “house parties,” in which customers earn commissions by selling the product to their friends and neighbors. Every sales pitch is an opportunity not only to sell Tupperware products but also to persuade other customers to become Tupperware representatives.
Note that both of the above are evidence of the "Make Users Awesome" premise.
Like the other engines of growth, the viral engine is powered by a feedback loop that can be quantified. It is called the viral loop, and its speed is determined by a single mathematical term called the viral coefficient. The higher this coefficient is, the faster the product will spread. The viral coefficient measures how many new customers will use a product as a consequence of each new customer who signs up.
The Paid Engine of Growth
Imagine another pair of businesses. The first makes $ 1 on each customer it signs up; the second makes $ 100,000 from each customer it signs up. To predict which company will grow faster, you need to know only one additional thing: how much it costs to sign up a new customer.
Imagine that the first company uses Google AdWords to find new customers online and pays an average of 80 cents each time a new customer joins. The second company sells heavy goods to large companies. Each sale requires a significant time investment from a salesperson and on-site sales engineering to help install the product; these hard costs total up to $ 80,000 per new customer. Both companies will grow at the exact same rate. Each has the same proportion of revenue (20 percent) available to reinvest in new customer acquisition. If either company wants to increase its rate of growth, it can do so in one of two ways: increase the revenue from each customer or drive down the cost of acquiring a new customer.
Like the other engines, the paid engine of growth is powered by a feedback loop. Each customer pays a certain amount of money for the product over his or her “lifetime” as a customer. Once variable costs are deducted, this usually is called the customer lifetime value (LTV). This revenue can be invested in growth by buying advertising.
Chapter 11 Adapt
We need adaptive organizations who that automatically adjust its processes over time to match current conditions.
Focusing too much on speed is counterproductive. This is one of the most important discoveries of the lean manufacturing movement: you cannot trade quality for time. If you are causing (or missing) quality problems now, the resulting defects will slow you down later.
THE WISDOM OF THE FIVE WHYS
To accelerate, Lean Startups need a process that provides a natural feedback loop. When you’re going too fast, you cause more problems. Adaptive processes force you to slow down and invest in preventing the kinds of problems that are currently wasting time. As those preventive efforts pay off, you naturally speed up again.
Here’s how to use Five Whys analysis to build an adaptive organization: consistently make a proportional investment at each of the five levels of the hierarchy. In other words, the investment should be smaller when the symptom is minor and larger when the symptom is more painful. We don’t make large investments in prevention unless we’re coping with large problems.
The Five Whys ties the rate of progress to learning, not just execution. Startup teams should go through the Five Whys whenever they encounter any kind of failure, including technical faults, failures to achieve business results, or unexpected changes in customer behavior.
Key success factors:
- Executive support must be clear
- Everyone involved / impacted by the problem must be in the room
- Everyone must understand the process - appoint a "Master" who handles most of the sessions in an area. Person is senior enough to ensure the actions are taken but must have capacity to attend the meetings
- Start small - don't attack endemic problems first
- It must not become a blame game
Chapter 12 Innovate
Context here is about how to establish a start up unit in a traditional organization.
Startup teams require three structural attributes: scarce but secure resources, independent authority to develop their business, and a personal stake in the outcome.
Scarce but secure resources. Startup's need far less capital (people and resources) but must be able to keep what they have been given.
Independent development Authority. Must have everyone and everything needed to build and deploy products quickly i.e. cross functional, unencumbered from lengthy approval processes. Also, they measure productivity not by activity but by demonstrably moving the core metrics of value and growth.
A personal stake in the outcome. Think autonomy, mastery and purpose with confidence that if successful they can stay on if they wish, be recognized. Most importantly - there needs to be a single accountable team leader - like Toyota's "Shusha"
CREATING A PLATFORM FOR EXPERIMENTATION
Next, it is important to focus on establishing the ground rules under which autonomous startup teams operate: how to protect the parent organization, how to hold entrepreneurial managers accountable, and how to reintegrate an innovation back into the parent organization if it is successful.
The platform needs all of the characteristics of the Lean Start Up model. Also - as it operates it can place the existing business at risk by pulling customers away to the new product, channel cannibalization etc. If not managed these will cause managers to sabotage the effort. Also so much of this model flies in the face of standard practices that it is challenging to execute without also changing the company culture at least in the small.
They've seen a couple of common traps. Creating a sandbox that seems to match the model but lacks key components e.g. actionable metrics, ability to actually ship product etc. They've also seen "black box" organizations created while being successful in executing create a toxic environment once the successful new product needs to integrated back into the parent organization.
Here's the recommendation:
Create a sandbox for innovation that will contain the impact of the new innovation but not constrain the methods of the startup team. It works as follows:
- Any team can create a true split-test experiment that affects only the sandboxed parts of the product or service (for a multipart product) or only certain customer segments or territories (for a new product). However:
- One team must see the whole experiment through from end to end.
- No experiment can run longer than a specified amount of time (usually a few weeks for simple feature experiments, longer for more disruptive innovations).
- No experiment can affect more than a specified number of customers (usually expressed as a percentage of the company’s total mainstream customer base).
- Every experiment has to be evaluated on the basis of a single standard report of five to ten (no more) actionable metrics.
- Every team that works inside the sandbox and every product that is built must use the same metrics to evaluate success.
- Any team that creates an experiment must monitor the metrics and customer reactions (support calls, social media reaction, forum threads, etc.) while the experiment is in progress and abort it if something catastrophic happens.
Teams that work this way are more productive as long as productivity is measured by their ability to create customer value and not just stay busy.
True experiments are easy to classify as successes or failures because top-level metrics either move or they don’t. Either way, the team learns immediately whether its assumptions about how customers will behave are correct. By using the same metrics each time, the team builds literacy about those metrics across the company. Because the innovation team is reporting on its progress by using the system of innovation accounting described in Part Two, anyone who reads those reports is getting an implicit lesson in the power of actionable metrics. This effect is extremely powerful. Even if someone wants to sabotage the innovation team, he or she will have to learn all about actionable metrics and learning milestones to do it.
Eric then gets into the need for a large organization to use a practical portfolio based approach to its innovation and current product operations. He also discusses some of the paradoxical nature executing the model.
Some closing warnings:
Becoming the Status Quo (i.e. once the model is the norm)
I’ve found that every suggestion should be subjected to the same rigorous scientific inquiry that led to the creation of the Lean Startup in the first place. Can we use the theory to predict the results of the proposed change? Can we incubate the change in a small team and see what happens? Can we measure its impact? Whenever they could be implemented, these approaches have allowed me to increase my own learning and, more important, the productivity of the companies I have worked with.
Those who look to adopt the Lean Startup as a defined set of steps or tactics will not succeed. I had to learn this the hard way. In a startup situation, things constantly go wrong. When that happens, we face the age-old dilemma summarized by Deming: How do we know that the problem is due to a special cause versus a systemic cause? If we’re in the middle of adopting a new way of working, the temptation will always be to blame the new system for the problems that arise. Sometimes that tendency is correct, sometimes not. Learning to tell the difference requires theory. You have to be able to predict the outcome of the changes you make to tell if the problems that result are really problems.
For example, changing the definition of productivity for a team from functional excellence— excellence in marketing, sales, or product development— to validated learning will cause problems. As was indicated earlier, functional specialists are accustomed to measuring their efficiency by looking at the proportion of time they are busy doing their work. A programmer expects to be coding all day long, for example. That is why many traditional work environments frustrate these experts: the constant interruption of meetings, cross-functional handoffs, and explanations for endless numbers of bosses all act as a drag on efficiency. However, the individual efficiency of these specialists is not the goal in a Lean Startup. Instead, we want to force teams to work cross-functionally to achieve validated learning. Many of the techniques for doing this— actionable metrics, continuous deployment, and the overall Build-Measure-Learn feedback loop— necessarily cause teams to suboptimize for their individual functions. It does not matter how fast we can build. It does not matter how fast we can measure. What matters is how fast we can get through the entire loop.
Ultimately, the Lean Startup is a framework, not a blueprint of steps to follow. It is designed to be adapted to the conditions of each specific company. Rather than copy what others have done, techniques such as the Five Whys allow you to build something that is perfectly suited to your company. The best way to achieve mastery of and explore these ideas is to embed oneself in a community of practice.
As we’ve seen, too many innovation teams engage in success theater, selectively finding data that support their vision rather than exposing the elements of the vision to true experiments, or, even worse, staying in stealth mode to create a data-free zone for unlimited “experimentation” that is devoid of customer feedback or external accountability of any kind. Anytime a team attempts to demonstrate cause and effect by placing highlights on a graph of gross metrics, it is engaging in pseudoscience. How do we know that the proposed cause and effect is true? Anytime a team attempts to justify its failures by resorting to learning as an excuse, it is engaged in pseudoscience as well.
If learning has taken place in one iteration cycle, let us demonstrate it by turning it into validated learning in the next cycle. Only by building a model of customer behavior and then showing our ability to use our product or service to change it over time can we establish real facts about the validity of our vision.
And finally - a single vision statement:
What would an organization look like if all of its employees were armed with Lean Startup organizational superpowers?
For one thing, everyone would insist that assumptions be stated explicitly and tested rigorously not as a stalling tactic or a form of make-work but out of a genuine desire to discover the truth that underlies every project’s vision.
We would not waste time on endless arguments between the defenders of quality and the cowboys of reckless advance; instead, we would recognize that speed and quality are allies in the pursuit of the customer’s long-term benefit. We would race to test our vision but not to abandon it. We would look to eliminate waste not to build quality castles in the sky but in the service of agility and breakthrough business results. We would respond to failures and setbacks with honesty and learning, not with recriminations and blame. More than that, we would shun the impulse to slow down, increase batch size, and indulge in the curse of prevention. Instead, we would achieve speed by bypassing the excess work that does not lead to learning. We would dedicate ourselves to the creation of new institutions with a long-term mission to build sustainable value and change the world for the better. Most of all, we would stop wasting people’s time.
Ries, Eric (2011-09-13). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (pp. 283-284). The Crown Publishing Group. Kindle Edition.
No comments:
Post a Comment
Please no spam, advertisements, or unrelated personal discussions.