Book

The Lean Startup

Eric Ries

This was very good. I borrowed it from my work library and read it in parallel to Facebook: The Inside Story. The ‘Lean Startup’ is a method for developing products and services under conditions of extreme uncertainty. Ries goes through the method using examples from several startups, including his own, IMVU (never heard of it). Interestingly, some of the businesses he gives as examples have subsequently tanked; I saw that as an example of the difficulty in setting up any business, rather than a failure of this method. I’ll bullet point all the ideas I liked lower down, but the main ones that stood out were the importance of getting early product feedback (vs. operating in stealth mode) and the value of small batch sizes.

Many startups are conceived and strategised at the whiteboard. Entrepreneurs like to draw diagrams and hypothesise about the market, but beyond a basic hypothesis, much of this effort is wasted speculation until you get the product (or idea of the product) to users and receive feedback. The more detail you get into, the more errors in your assumptions will make that plan useless.
Which of your efforts are value-creating and which are wasteful?
The lean startup aims to get people through the build-measure-learn feedback loop as quickly as possible. It doesn’t matter how fast you can build, it doesn’t matter how fast you can measure, what matters is minimising time through the whole loop.
The goal of an MVP is to begin the process of learning.
Early adopters queued up for the iphone despite the many features it lacked. Google could only answer a few questions at launch.
Dropbox believed that file synchronization is a problem most people didn’t know they had, but once they experienced the solution, they couldn’t live without it.
Focus on scaling something that is working rather than trying to invent something that might work in the future.
If we can solve the tough technical problems behind this AI product, will people use it? Will their use lead to the creation of a product that has real value?
It’s hard to get your product noticed, so don’t worry about others stealing it or getting your launch wrong. Most likely, no-one will download it, so get it out and start tweaking.
If a competitor can outexecute you, you’re doomed anyway. The reason you get going is so you can accelerate through the Build-Measure-Learn loop quicker than your competition.
If you are worried about brand damage from a low quality MVP, release under a different brand name.
No matter what comes of the MVP, you have to agree to not give up hope and iterate. Don’t give up at the first sign of trouble, or persevere until it crashes. Find the balance.
Talking to customers is valuable, but it is better to see how they are actually interacting with a product. Most of the time customers don’t know what they want in advance (think Ford and the faster horse). Find a balance between product vision and customer acceptance. Don’t capitulate to every customer demand (since they may not know exactly what they want) and don’t tell them what they want.
Cross-functional teams are essential. Most professionals’ idea of efficiency is to get lots of stuff done in their discipline each day (e.g. a coder wants an 8 hour coding day), but non cross-functional teams build up large bits of inventory that then has to be handed over. Much efficiency is lost in these handovers due to misunderstanding, change of requirements etc.
The goal of a startup is to find the right thing to build - the thing customers want and will pay for.
When it comes to VCs, having nothing allows people to imagine the dream. A business with small numbers invites small thinking.
Four part product owner questions: 1. Do consumers recognize that they have the problem you are trying to solve? 2. If there was a solution, would they but it? 3. Would they buy it from us? 4. Can we build a solution?
Having a value hypothesis is important. Do customers find value in this product?
Strategy helps find the right questions to ask.
What are the fundamental assumptions in your business plan? They need to be tested with experiments. Of these, which are high risk?
Analogs and antilogs. Using the ipod example: The assumption that people would listen to music in public with headphones was validated by the Sony Walkman, an analog. The assumption that users would pay to download music was challenged by Napster, an antilog. Therefore, the paying for downloaded music became a ‘leap of faith’ assumption.
Cohort analysis (e.g. Registration > Activation > Retention > Referral) and associated metrics are better than vanity metrics (revenue, total user numbers). A good guide (here)[https://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version]
Many features that make a product better in the eyes of engineers and designers have no impact on users, so test!
Kanban WIP limits
Metrics should be actionable, accessible and auditable. What is a website hit? Be tangible in your definitions. If there is room for argument regarding the numbers, then metric led experiments and techniques such as the five whys become subject to interpretation and low quality debate.
A customer segment pivot is hard because it ditches your early adopters in favour of users that will make you mainstream successful.
Who wins when sending 1000 letters: the team who divides into envelope writing, letter stuffing, envelope sealing; or one person doing all three stages alone? The second wins every time due to the wonder of small batch sizes. This is because of A) handover times, there is more stuff to handover each time. B) Defect management, if you find out that the letters don’t fit in the envelope, you’ve wasted effort and have to start again. In the second way, handover times are small and you discover defects much quicker.
Linking to small batch sizes and the idea of individual efficiency, individual performance is not as important as the overall performance of the system.
The benefits of finding and fixing problems faster outweigh the costs of stopping production to allow inspection.
In batch working, a designer get 30 drawings out, uninterrupted, and then hands them on to the engineers. Great, they can start on the next lot of drawings. But the engineers who have received them now have a raft of questions, interrupting the flow of work. If any drawings need to be redone, the engineers sit idle whilst the designer has to redo them. This has now stopped the designer from doing their second batch of work and the engineers from doing their first batch.
Small batching converts push methods to pull (i.e. based on need, therefore not wasteful)
New customers come from the actions of past customers
Is there an exchange of value between customers and the business? This can be monetary (Tupperware) or non-monetary (Facebook).
The five whys tends to get back to a human failure in the end. For example, if an engineer breaks something on their first commit, it the company’s fault for having such a brittle system. Five whys can be used to change the behaviour that led to such brittleness.
Introducing change is hard because organisations have muscle memory.
Why are new solutions hard to introduce? Often there is a fear of endangering the current business so proposed experiments are delayed, sabotaged and obfuscated. Actionable metrics can answer this, making it much harder for someone to sabotage.
A good innovation manager might be weak at operations. This creates a handover opportunity.