The Lean Startup: Difference between revisions
Content deleted Content added
No edit summary |
No edit summary |
||
Line 56:
=== III – Accelerate ===
📦 '''9 – Batch.''' James Womack and Daniel Jones tell a simple story: a parent and two daughters, ages six and nine, sit at a table to stuff newsletters into envelopes—address, stamp, fold, insert, seal—and debate whether to do all of one step first or finish each envelope one by one. Running the process reveals what lean manufacturers learned decades ago after World War II: large batches hide mistakes until late, while small batches surface problems early and finish steady streams of completed work. The contrast scales beyond paper and stamps; Toyota’s production lines institutionalized rapid detection with the andon cord so anyone could stop the line when defects appeared. Product development often lags behind: at the iPhone 4 release, Apple touted more than 1,500 changes, yet those changes reached customers in a single, giant batch. IMVU flipped that pattern by building one feature at a time with engineers and designers working side by side, releasing immediately to a small slice of users, and reading behavior within hours. The feedback loop shortened from weeks to minutes, so adjustments happened while context was still fresh and risk was still small. Continuous deployment proved feasible even in regulated settings: Wealthfront pushed more than a dozen releases per day in an SEC-regulated environment. The point is not speed for its own sake but faster discovery of what fails, so teams spend less time polishing the wrong thing. Small batches reduce work-in-process, make defects visible where they occur, and keep learning continuous instead of episodic. In this frame, “faster” means fewer surprises and less rework because evidence arrives earlier. Treating development as flow—rather than a series of big launches—aligns effort with real customer feedback and cuts preventable waste. ''The biggest advantage of working in small batches is that quality problems can be identified much sooner.''
🌱 '''10 – Grow.''' Two very different companies—a consumer collectibles business and a B2B software vendor—show the same problem: early revenue, investor interest, and active customers, yet flat growth curves when asked to scale. Sustainable growth, the book insists, follows one rule—new customers come from the actions of past customers—and those actions concentrate into three engines: sticky, viral, and paid. The sticky engine is all about retention: make the product valuable enough that cohorts continue to use and pay, and improvements that raise retention speed the loop disproportionately. The viral engine depends on use itself spreading the product; Hotmail’s 1996 tweak—“P.S. Get your free e-mail at Hotmail”—attached to every outgoing message brought a million sign-ups in six months, two million five weeks later, and a $400 million acquisition at roughly twelve million users eighteen months after launch. Viral growth is quantified by the viral coefficient; when each active customer reliably brings in more than one additional user, the loop accelerates without paid spend. The paid engine is arithmetic: lifetime value must exceed cost per acquisition, and the margin between LTV and CPA determines how fast paid campaigns can expand without subsidy. Vanity totals distract here; actionable, people-based cohort metrics show whether tuning truly moves the chosen engine. Chasing every idea creates noise; focusing on the few inputs that drive the loop produces compounding effects. Once one engine works, switching engines—or mixing them—becomes a strategic choice rather than a guess. Pick the loop, instrument it carefully, and tune only the levers that change its speed. ''Therefore, I strongly recommend that startups focus on one engine at a time.''
🦎 '''11 – Adapt.''' A real incident at IMVU begins with customer complaints after a new release: a feature fails because a server misbehaves, which traces to an obscure subsystem used incorrectly, which traces to a developer who didn’t know the right procedure, which traces to the absence of training, which traces to a manager who considered training a luxury. Walking the Five Whys turns a technical outage into a human systems problem, and the fix follows a proportional rule: if the fault is minor, invest an hour now on the first step of an eight-week plan and escalate only if the issue recurs. Over time, that cadence of small corrective investments accumulates into robust process without freezing the team in bureaucracy. The same proportional approach led IMVU to build a training program strong enough that new engineers were productive on day one, with mentors assigned, a living curriculum, and shared accountability between mentor and mentee. Orientation itself became an experiment, revised as evidence mounted, so the program grew more effective and less burdensome with each cohort. The lesson generalizes: treat defects and outages as opportunities to improve the system that produced them, not as moments for blame. Pull the andon cord early, bring the right people to the table, and make fixes small, quick, and durable. As quality rises, speed can rise with it because teams stop tripping over the same hidden faults. Organizations that evolve in this way maintain agility even as headcount climbs and product complexity grows. A culture that links problems to learning—rather than to punishment—keeps improving on its own. ''I call this building an adaptive organization, one that automatically adjusts its process and performance to current conditions.''
💡 '''12 – Innovate.''' In a large-company product meeting, senior managers argued over a pricing experiment they had run: custom reports filled the room, the data warehouse team fielded questions, and yet no one could agree what the numbers meant or which customers had actually seen the test. That muddle frames the need for internal startup teams with the right setup—scarce but secure resources, independent authority to build and change, and a personal stake in the outcome—so experiments yield unambiguous learning instead of politics. Toyota’s shusa model makes the ownership concrete: a chief engineer holds final authority over every aspect of a new vehicle, embodying end-to-end responsibility rather than functional turf. To keep innovation “in the open” without blindsiding colleagues, the chapter proposes an innovation sandbox: true split-tests limited to specific segments or territories, owned by one team from end to end, bounded in time, exposure, and a standard report of five to ten actionable metrics. Because every team inside the sandbox uses the same metrics and monitors customer reactions in real time, good ideas survive scrutiny and bad ones die quickly. The approach turns black-box breakthroughs—like IBM’s PC story—into a repeatable practice that a parent organization can sustain and reintegrate. Intuit’s SnapTax shows how a small “island of freedom” can run rapid tests within a big company while still reporting transparently. Portfolio thinking follows: protect the core, seed disruptive bets, and measure each one with innovation accounting until it is either folded back in or retired. The effect is cultural as much as technical, replacing status contests with evidence and giving would-be founders a path to build inside. Teams learn to trade heroics for cadence: short cycles, clear gates, and visible outcomes. In this frame, autonomy is not an indulgence but a control system that keeps risk small and learning fast. When that platform exists, people who thrive on creating the new don’t have to leave to do their best work. ''In fact, entrepreneurship should be considered a viable career path for innovators inside large organizations.''
♻️ '''13 – Epilogue: Waste Not.''' The year marks a century since Frederick Winslow Taylor’s 1911 treatise on scientific management, which popularized management by exception, standardized tasks, and the task-plus-bonus system that helped power twentieth-century prosperity. Those techniques, and later lean manufacturing, proved that work can be studied and improved, yet they also carried prejudices and rigidities that treated people as automatons. The epilogue argues that modern waste comes less from how we assemble things and more from building the wrong things at industrial scale—failed launches, large-batch death spirals, and “success theater” that dresses up opinion as fact. The remedy is not more exhortation or slower, bigger plans but a research-driven practice for innovation: form hypotheses, run experiments, and hold teams accountable to validated learning. Taylor’s spirit of systematic inquiry becomes a call for startup testing labs, shorter cycle times, and public-private collaborations that compare methods with objective outcomes. It even imagines a Long-Term Stock Exchange where firms report on innovation accounting alongside profits, align executive pay to long-horizon results, and reduce incentives for vanity metrics. The vision extends to organizational “superpowers”: anyone, even a junior employee, can surface testable assumptions, design a learning plan, and avoid pseudoscience by proving cause-and-effect with cohort behavior over time. Rather than choosing between speed and quality, teams get both by bypassing work that does not lead to learning and by shrinking batch size when uncertainty is high. The payoff is humane as well as productive—less blame, more candor, and fewer meetings in which evidence is ambiguous by design. Seen this way, efficiency is not the finish line; it is a property of systems that measure truth early. A century after Taylor, the greatest untapped resource is not muscle or machines but attention and imagination. ''Most of all, we would stop wasting people’s time.''
🤝 '''14 – Join the Movement.''' The closing chapter maps a practical route from reading to practice as the Lean Startup movement spreads beyond Silicon Valley to local ecosystems worldwide. An official site at theleanstartup.com hosts case studies, talks, and links to the Startup Lessons Learned blog so practitioners can learn directly from applied examples. Meetups make the work local: as of this writing there are over a hundred groups, with large communities in San Francisco, Boston, New York, and Chicago, and simple tools exist to find or start one. A community-maintained Lean Startup Wiki catalogs events and resources for teams that don’t use Meetup.com. The Lean Startup Circle—founded by Rich Collins—runs an active mailing list with thousands of entrepreneurs trading tactics, metrics tips, and field reports every day. Reading lists point newcomers to customer development classics and contemporary blogs, turning scattered insights into a shared vocabulary for experiments. The emphasis stays on doing: form a small team, run a test in your local context, and share results so others can build on what works. As participation grows, the method evolves through documented practice rather than slogans. That open, peer-to-peer cadence mirrors the process it advocates: short loops, clear metrics, and concrete next steps. The destination is not a club but a habit of learning in public. ''Reading is good, action is better.''
== Background & reception ==
| |||