The Lean Startup
“The Lean Startup” by Eric Ries
My Notes
Part 1: VISION
- START, DEFINE, LEARN, EXPERIMENT
- the boring stuff matters the most, got to have the right processes
- minimizing the build –> measure –> learn/feedback loop is absolutely key; it can help to identify market fit, save time by not building products without users, etc. (seems like design sprints will compliment this well)
- entrepreneurship and management don’t have to be vehemently opposed; startups need to think critically about how they work (a la some management), focusing on building what matters, instead of what winds up in the trash can
- “building what matters” will be accomplished by evaluation, science, data, FEEDBACK!
- entrepreneurs can exist in the traditional sense, but also within an organization — anyone who is trying to bring a team/product/solution together to solve a problem with lots of uncertainty
- management is responsible for cultivating entrepreneurship and risk taking within a company (this includes the tech that allows everyone to quickly innovate); it is possible to have a startup within a company; it doesn’t take huge budgets, additional hiring, etc
- rapid iteration is also key, reduce the feedback loop, and reduce the barrier to entry to testing new ideas and quickly getting feedback; anyone in the company should be able to do this; are we a company that just makes small incremental changes well… or are we company that is good at taking big swings? creating new ideas and innovating?
- when an experiment/test/product fails you may be tempted to say “at least we learned something”, but that isn’t good enough. if you have learning, it should be “validated learning” — learning that drives you closer to providing value
- which processes are value-creating and which are wasteful? “lean thinking” defines providing value to the customer, anything else is waste — they don’t care how you built it or how brilliant you think an idea is…. do they use it? would they use it? would they pay for it? you need to get to the core of these questions ASAP
- learn as much as you can about your customer/value while minimizing the effort required to do it (DESIGN SPRINTS FTW!!!)
- constantly run experiments to understand your customers; why are these using your product? what frustrates them? where can you align your product vision with the REAL feedback that you are getting?
- in today’s world almost any product CAN be built. the greater question is SHOULD it be built? can you build a sustainable business around this set of products and services?
- ^ startups should be viewed as grand experiments trying to answer the above question
- use experimentation to test the value and behavioral assumptions you have for a customer; its good to know exactly what your assumptions are! (similar to sprint questions… “will users be able to find what they are looking for the first time without additional help?”)
- questions that codec uses
- do consumers recognize that they have the problem you are trying to solve?
- if there was a solution, would they buy it?
- would they buy it from us?
- can we build a solution for that problem?
- SUCCESS is not delivering a feature, SUCCESS is learning how to solve the customer’s problem
PART 2: STEER
- LEAP, TEST, MEASURE, PIVOT (OR PERSEVERE)
- validate your value and growth hypotheses: does this provide value to customers? and will it grow? through your measurements/experiments/etc
- test your assumptions!!
- don’t be a company that is practicing “success theater” (the appearance of growth to seem successful)
- “go and see for yourself!” (the Toyota way) and “get out of the building”
- Know your customer personas
- How to MVP live sale in a week? Use existing beta and add a “faked chat”
- For MVP any additional work that does not get to the core of what you want to learn about the products value is waste
- Possible MVPs other than keynote/invision prototype: concierge (just 1 customer exp working and the scale up), video demo, smoke n mirrors
- Cohort analysis is really valuable, better than gross measurements
- Target metrics are really good, instead of making a bunch of changes and then just hoping it effects some number like revenue, target metrics with things like a/b tests and cohorts
- Avoid vanity metrics like gross metrics of revenue or total customers… it doesn’t tell the full story like a metric related to cohorts quarter to quarter growth, retention of new customers, etc
- All features should be tested and validated as part of their development, if they prove to not be useful and provide value, then they should be removed
- Metrics should be actionable, accessible (as easy to understand as possible) and audible
- Validate what the data is saying with users
- Productivity is not about story points, it’s about aligning our efforts to deliver more value
- When your companies growth engine starts to slow down, then it’s probably time for a pivot
- Types of pivots:
- Zoom-in: one aspect of the existing product becomes the focus
- Zoom out: whole existing feature becomes part of larger product
- Customer segment pivot
- Customer need pivot
- Platform pivot
- Business architecture (ex: from b2b to b2c, high volume lower touch sales to low volume higher touch sales) pivot
- Channel (of business) pivot
PART 3: ACCELERATE
- BATCH, GROW, ADAPT, INNOVATE, EPILOGUE
- small batches and the ability to quickly adapt and change is better than large batches where change is expensive and issues can not be found until much later
- Use CI/CD to move quickly and get validated learning as fast as possible
- Learn as fast as you can, if you can learn without investing tons of resources, then do it
- As soon you formulate a hypothesis about a design or change in product etc, test it! Otherwise it piles up like overstocked inventory or work in progress
- Sustainable growth are when new customers come from existing customers, this is what you want
- Focus on improving your engine of growth which will help eliminate the noise of all the things you “could do”
- Types of engines
- Sticky - you need customers to keep coming back, a good metric here is churn (for people that used the app 30 days ago, how many are still using it? How many are still buying from it?), you want repeat customers. For apps, I think this is us, look into calculating retention, churn,
- Viral - this might be us too. There is a viral coefficient that can be used to track the likelihood that adding a user will in turn add another user. “How many friends will each customer bring with them”. Our product could certainly be more viral by giving folks an incentive or somehow broadcasting their use of our apps for others to see (without violating privacy).
- Paid - is the cost of acquiring a new customer less than the amount of income the customer will generate? If so this engine is running well. If not you must drive down the cost to acquire new customers or increase the ability for existing customers to generate more revenue. This seems more like the model our sales marketing team does; however I’m not sure we are doing any paid ads right now, are we?
- You can have organizations with multiple engines if growth, but be careful since it is hard to try and do these simultaneously
- Engines of growth eventually run out, make sure to have an organization that allows startsup within the organization to create new engines
- One boarding new employees with a mentor/mentee can be beneficial
- Make sure you have rails and infrastructure in place so you can continue to move fast
- Use the “5 why’s” (not the 5 blames!) exercise to get to the root of the problem; fix the issue at each level, if possible
- It’s often that you don’t need to build out an entire system to go ahead and test and validate certain assumptions or ideas
- When doing 5 whys, make sure everyone is there (idea isn’t to target someone, get to objective truths)
- Have all new engineers make a push to production environment on their first day or week, if something breaks then shame on us and let’s fix it so it is less hard to break
- MVP of 5 why’s is when encountering a problem, you ask how can ensure this never happens again?
- Bring NPS back?
- Innovation teams within the company should work in a sandbox that doesn’t effect a huge percentage of existing customers and they should be tracking data to measure the success of their work and it should be time boxed (sort of like the team putting together live on the app)
- Entrepreneurs on the team should have freedom of staying with products or moving to next thing
- More of our issues are caused not by working too hard, but by working too hard on the wrong problems
- No more pseudo science. Figure out the assumptions, drive towards real results/metrics