I've been aware of the lean startup approach for a while, but never really dug into it until I actually moved from software consultancy to a startup. With the benefit of hindsight, I should have gotten smart about it a lot earlier.
As it happens, many of the lean startup techniques can be valuable in non-startup contexts as well. For example, when you or one your customers is thinking of launching a new product or a new major product feature, there are a variety of techniques in the lean startup methodology that will help you validate the idea, minimize risk, and find the optimal product-market fit.
If I had to summarize the value of the lean startup approach in one sentence, that would be something like: "Lean startup helps you find a scalable business model in the presence of great uncertainty and with scarce resources." That's the situation most startups are in by definition, but it also isn't too far from what established companies are facing when they're trying to do something new.
Now that I'm starting to figure out this whole lean startup thing, I'd like to share a few things I wish I'd known a few years earlier, while I was doing software development in established companies.
Read The Literature
There's a growing literature on the topic of lean startups. One might think these books aren't that useful for people who aren't in startups, but I believe that's wrong. This is a goldmine for anyone dealing with the business of software in any shape or form.
There are two books I especially recommend:
The Lean Startup
The Lean Startup by Eric Ries is the introductory book, and the book that started it all. It explains where the lean startup philosophy comes from and why it works.
The main thing I personally took out of this book was an understanding of the lean startup techniques, and a motivation to apply them.
Running Lean by Ash Maurya is a perfect companion to the Ries book. It takes the philosophy and gives a fully laid out plan for applying it in practice. This is exactly the kind of advice you need when you're new to something, and this book delivers. I find myself returning to it time and time again.
Running Lean is one of the books on O'Reilly's Lean Series. The other titles in that series look fascinating too, but I haven't gotten around to them yet.
Use The Lean Canvas
Of all the tools in the lean startup toolbox, the Lean Canvas is possibly the easiest to get started with, and the one with quickest return in terms of value. It is a visualization tool whose purpose is to visualize the different aspects of the product or business idea you have, to approach it from different angles, and to get a picture of whether it's feasible or not.
Startups use these kinds of things all the time, but I think this is really something that should be used much more in other contexts too. It's a very quick tool to apply - it only takes fifteen minutes to draft a canvas. In that short amount of time, it's quite incredible how much you can clarify your thoughts, as well as communicate them to others.
The sections of The Lean Canvas are:
- The Problem - what problem(s) does your idea solve? For an idea to be successful, there must be some problem in the world that it fixes. Also, think about existing alternatives people are currently using to solve that problem. The alternatives might be other products or workarounds, for example. Thinking of alternatives helps you evaluate the usefulness of your solution.
- The Customer Segments - who exactly is it that has the problems you described? Is it a specific group of people? If there are multiple different groups of people, mention all of them. Also identify early adopters - the people or companies you'll be able to talk to and get traction with even before your solution is finished.
- The Unique Value Proposition - what is the big idea, with which you solve these problems for these people? Think of what would read at the top of the product's website: Who needs your solution, how does their world change when they use it, and when does that happen?
- The Solution - how, in practical terms, do you implement your Unique Value Proposition so that the problems are solved? Here we're talking specific features and qualities of the solution.
- The Channels through which you reach those early adopters. Do you know them already? Do they know you? If not, how can you get your message across to them? This is all about marketing and communication.
- The Revenue Streams and The Cost Structure. In other words, the financials. How do you get revenue from the solution? How much will it cost to implement it? What kind of revenue will you need to break even?
- The Key Metrics with which you track whether your solution is working. This is crucial so that you'll know when you need to change something. A very useful tool for defining these is Dave McClure's Pirate Metrics model.
- The Unique Advantage you have. What is it that you posess that isn't easily copied or bought by someone else? Do you have some insider information or an existing community you can leverage? This is often the hardest part to define, but it can make the difference between a succesful endeavour and a failed one.
One thing that has been particularly striking for me is the realization that as a programmer, most of my ideas have originated from the Solution box: I've come across some technology or implementation idea and everything has followed from that. The thing is, that isn't really what makes something fly. You need to look at all the other boxes too. Most importantly, what problem is that solution solving and for whom? I've always been kind of aware of this issue but have lacked the tools to deal with it. Now I have them.
The Lean Canvas is based on prior work by Alex Osterwalder and co, with their business model canvas concept. If you're interested in finding out more about these canvases, I recommend you look at the Running Lean book and Maurya's Lean Canvas webapp, as well as Osterwalder's Business Model Generation book. There's also a recent InfoQ interview with Osterwalder, in which these topics are discussed.
Get Out of The Building
Crafting a Lean Canvas is one thing, but what you need to do next is even more important: You need to look at your canvas, identify which part of it carries the biggest risk or uncertainty, figure out how to validate that part in the real world, and get out of the building to actually test it.
Startups are usually working with scarce resources, which drives them towards techniques like this: When you don't have much budget or time and you're facing enormous uncertainty, you have to do all you can to reduce that uncertainty with the minimum amount of effort. This is possibly the most important problem the lean startup approach aims to solve.
In established companies, budgets and schedules are usually much larger, and I think that's actually hurting them in the sense that they aren't forced to face the real world soon enough. I've often seen a company work on developing a product for months or years on end, without any proper customer feedback loops in place. Finally, at the end of the project, there's *The Launch*, and that is when you start to actually learn whether the product was something the market wanted or not. If it was, that's great, but if it wasn't, an enormous amount of work and money has gone to waste. That didn't have to happen.
Agile development methodologies have been enormously successful in helping organizations keep development on track by means of continuous feedback. It is just as important to insert similar feedback loops to measure whether the track itself is heading in the right direction. This is what The Lean Startup does, and any company that isn't educated on it is that much worse off.
by: Tero Parviainen