I read Lean Startup by Eric Ries twice, and it is a book I would recommend to study multiple times. The book is full of many recommendations on executing risky plans, validating new technologies, or learning what your customers really want. Working harder is insufficient. What if our current problems are caused by trying too hard - at the wrong things?
Here are my eight most favorite quotes from the book
Unfortunately, “learning” is the oldest excuse in the book for a failure of execution. It’s what managers fall back on when they fail to achieve the results we promised. […] we are wildly creative when it comes to demonstrating what we have learned. We can all tell a good story when our job, career, or reputation depends on it.
VM comment Bull’s eye. I admit with shame that I’ve done quite a few storytelling sessions on my “learnings”.
Validated learning is the process of demonstrating empirically that a team has discovered valuable truths […].
VM comment If someone asked me to describe how I measure my learning, most probably I would say it’s a count of “read pages” or “remembered terms”. It’s a crappy way to measure anything, and it has nothing to do with validated learning, which is a topic for a separate blog post.
[…] teams have followed the “Let’s just ship a product and see what happens” plan. Unfortunately, if the plan is to see what happens, a team is guaranteed to succeed - at seeing what happens - but won’t necessarily gain validated learning.
VM comment Been there, done that. I love motivational videos, but the phrase that gets repeated over and over again there is “Dare to begin” or “It gets easier over time”. Apparently, in the Lean Startup context, this is asking for problems.
The question is not “Can this product be built?” In the modern economy, almost any product that can be imagined can be built. The more pertinent questions are “Should this product be built?” and “Can we build a sustainable business around it”.
VM comment This is particularly the case for developers. We want to start coding so fast, that we might not investigate idea’s viability beforehand.
[…] if we’re building something that nobody wants, it doesn’t matter if we’re doing it on time and on budget.
VM comment It’s the biggest challenge to determine whether the development efforts are leading to real progress - just a piece of compiling code or a solution to client’s problems.
[…] activities happen in Build-Measure-Learn order, our planning works in the reverse order: we figure out what we need to learn, […] figure out what we need to measure, and then figure out what product we need to build to run an experiment.
VM comment Once you specify what you want to validate/learn, it’s much easier to achieve a tangible goal.
Individual efficiency of specialists is not the goal in a Lean Startup. Instead, we want to force teams to work cross-functionally to achieve validated learning. […] It does not matter how fast we can build. It does not matter how fast we can measure. What matters is how fast we can get through the entire Build-Measure-Learn loop.
VM comment This requires extraordinary team work skills. My blog post: Cross-functional team, or how to not kill each other.
The decision to pivot is emotionally charged for any startup […]. One way to mitigate this challenge is to schedule the meeting in advance […] a regular “pivot or persevere” meeting.
VM comment Changing an idea once you made some progress sounds painful. Eric suggests to schedule a regular meeting to question development progress and the idea itself.