15:00
Juan MC Larrosa
The Lean Startup in a Nutshell II: Build
In this part of the Lean Startup in a Nutshell series, we discuss how to accelerate the first stage of the build-measure-learn feedback loop where we build code from ideas. Each technique is designed to help us build faster and eliminate waste.
Minimum viable product
In product development, the Minimum Viable Product or MVP is a strategy used for fast and quantitative market testing of a product or product feature, popularized by Eric Ries for web applications. — Wikipedia
Or, as defined by Eric Ries himself,
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. — Eric Ries, StartupLessonsLearned.com
The MVP caters to early-adopter customers:
The minimum viable product is that product which has just those features and no more, that allows you to ship a product that early adopters see and—at least some of whom—resonate with, give you money for, and start to give you feedback on. —Eric Ries, Venture Hacks interview
The MVP falls in between the maximum-feature approach—building a complete product implementing the entire vision of the startup founders—and the "release early, release often" mantra—shipping code immediately, listening to customers, implementing what customers want, repeating the process.
The MVP presupposes a clear long-term vision of a product or service which solves a core problem. It represents the smallest effort of building a product that delivers the promise of that vision to early adopters—the people who have the same visioning power as the entrepreneurs, who will be the most forgiving, and who will fill in—in their minds—the features which aren't yet there.
An MVP can be a crappy first web application, a clickable screen design, a paper prototype, or just a text, video, or graphic describing the problem and the solution embodied in the vision for the product.
Agile development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.— The Agile Manifesto
Talking in depth about agile development would require a blog post of its own—or probably even an entire book. Let me thus assume that you are familiar with the basic aspects of the agile methodology (XP, Scrum, TDD) and talk instead about how agile development relates to customer development.
All agile development methodologies, be it XP or Scrum or Kanban, at some point need to answer the question, "What is the most important work we should do right now?". Usually, the answer to this question takes the form of a backlog, a collection of stories to be worked on in the next iteration.
In a Lean Startup, the backlog is fed as part of the company-wide feedback loop, by the new hypotheses derived from actual customer feedback.
Continuous deployment
Remember, a Lean Startup optimizes the total time through the company-wide feedback loop. Imperative to that aim is not to "get stuck" in the build phase for longer periods of time than necessary. Whenever you're working on a current release, make it as minimal as possible. Your aim is to learn as quickly as possible whether the work you are doing makes sense.
Continuous deployment is the natural extension (and completion) ofcontinuous integration:
For those of you with some background in lean manufacturing, you may notice that integration risk sounds a lot like work-in-progress inventory. I think they are the same thing. Whenever you have code that is un-deployed or un-integrated, it's helpful to think of it as a huge stack of not-yet-installed parts in a widget factory. The more code, the bigger the pile. Continuous integration is a technique for reducing those piles of code.
What continuous deployment adds to that is to actually deliver the code to the customer to get the company-wide feedback loop running again. It means to overcome the anxiety of occasionally releasing a broken or malfunctioning product and to embrace the power of being fast and flexible enough to fix problems as they occur.
Of course, some development environments—such as the iTunes App Store—restrict the developer's ability to do continuous deployment. In that particular case, try to gain back the freedom of continuous deployment by having an alternate version of the product—a web-based client—running at a faster pace of iteration, or by relocating part of the product's magic from the client side to the server side.
Open-source components
There are two kinds of philosophies: the closed-source world of Microsoft Windows and proprietary systems, and the open-source world of harnessing the world's knowledge and giving back accordingly. I tend to resonate much more with the second philosophy, and it is at the very heart of the Lean Startup.
Leverage open-source technology to its full extent not only to keep costs down, but to increase the speed and versatility of product development early on. Open source operates using the model of commons-based peer production which is proven to be incredibly effective at creating and nourishing extensive collaborative communities and cooperative ecosystems.
If I were to include one specific tool here, it would be GitHub.
The cloud
Cloud technologies—such as cloud computing, cloud storage, SaaS offeringsand IaaS offerings—enable young tech companies to start with zero overhead and practically zero cost while being able to scale considerably onceproduct/market fit is achieved.
Today, there is almost no point in setting up your own data centers upfront, before having validated that you are actually building something people want. My newest startup uses open-source technology (e.g. Ruby on Rails) and cloud IaaS (e.g. Heroku) exclusively in order to achieve a high speed of iteration at low cost.
I believe that the advent of powerful scalable cloud infrastructures with pay-as-you-go models basically supersedes—and renders less important—Eric Ries's concept of just-in-time scalability. If you are interested in the story of just-in-time scalability, enter Eric Ries.
Cluster immune system
The concepts of agile development and continuous deployment may seem quite radical to project managers of older schools, having practiced thewaterfall-style approach to product development. When you think of a product juggernaught such as the Microsoft Windows operating system, for instance, how could you possibly even dare to think about deploying this piece of software continuously?
What if someone breaks an important feature during a deploy? What if someone interrupts the e-commerce flow of an online store system? What if someone hides the "Payout" button in an online payment system, turning the entire business into a hobby (borrowing from Eric Ries)?
These concerns are all valid—unless there are proper defenses in place to guard against such potential dangers. Test-driven development and strict continuous integration rules are among the first lines of defense. The cluster immune system is later-stage, more sophisticated, line of defense.
A cluster immune system is designed to track bad deployments—changes having unintended consequences—to the production environment in real time. It continuously measures the business's core metrics and automatically rejects and reverts changes affecting these metrics in a negative way.
A good cluster immune system would understand that a recent code change made the average order volume drop to about 50% of the original value. It would then revert the change, returning the system to the previous working state. It would also interrupt the deployment pipeline so that further changes would become impossible. It would send an e-mail to the author of the change as well as the whole development team to inform them about the problem. It would only allow deployment to resume once a human got to the root cause of the problem and understood and fixed it.
Building a cluster immune system isn't easy. It doesn't happen in a single day. Cluster immune systems should be built iteratively as well, starting simple and becoming more complex over time. Their development should be driven by the needs of the development team and the particular technology stack used by the team.
Conclusion
Building products in a Lean Startup requires technology and methodologies which enable the development team to iterate as rapidly as possible while remaining as flexible as possible at the same time. The speed of iteration is to be counter-balanced by defensive methods designed to remove anxiety from the team. Making mistakes is vital in a Lean Startup. Design the development environment so that mistakes can never have disastrous consequences.
.png)
