I might be a little late to the party but I’ve just recently finished reading The Lean Startup by Eric Ries. These days, it’s nothing much out of the ordinary, but only as a result of its own success. It has, without a doubt, been one of the most influential books in the last decade and its impact has been so ubiquitous, it’s become easy to take for granted. The concepts from this book are now in wide use not only in startups, but in many large companies as well.
But even as far as I’ve been exposed to the world of startups (and all the buzzwords that get tossed around within it), reading the book myself has still managed to surface a lot of fresh perspectives for me. And the best part is, a lot of it is not too far off from observations I’ve made in my actual work, making it easy to immediately turn some of the concepts into action. That said, I can only imagine how paradigm-shifting this was when it first came out.
So without further ado, let me get into five takeaways I’ve made from The Lean Startup (and, for some of them, how I’ve managed to incorporate them into my own work).
1. Building in small batches.
As we get caught up in agile practices and scrums and whatnot, it’s easy to forget what sprints are all about at the heart of it. It’s about building in small batches and it’s why agile is so different from the traditional waterfall model of project management.
I’m personally not much of a “visionary” – I value execution a lot more than I value the vision. It’s not that I don’t appreciate those who have the power to see what the future should be like; I’m just a lot better at getting us from the now to where the vision lied. That said, I’m rarely ever too certain about what a year or so down the line will look like, but I see it happen all the time. It’s the temptation to get to this vision quickly that drives us to plan in large batches.
As the Lean Startup tells us, it’s always better to have an inch of doubt about what we’re building and to try and validate that doubt by building in smaller batches – whether you’re adding value in increments or failing to do so at very little cost.
2. Five Why’s as a tool for improvement, rather than bureaucracy.
As someone who’s worked in a Japanese company for most of my career, the Five Why’s is ingrained in me. But to be honest, it was something I truly detested and found utterly useless for the most part. It was another form to be filled in to “clear your name”. A tool for bureaucracy, simply put.
Lean Startup has convinced me to give it another try. I realize that the way it’s executed in a lot of companies is what gives five why’s (at least to me) a bad rep. It’s often dealt as an “interrogation” when I think in essence it should be a “coaching opportunity”. Facilitating the thought process instead of demanding for answers will lead to better results.
Recently, I’ve found it to be a tool not for bureaucracy, but for accountability. The key is to keep it safe for those involved. Remember that you’re trying to uncover a systemic issue, not finding where to pin the blame.
3. The right metrics.
In this data-driven world, it’s tempting to come up with numbers just to support your case. Lean Startup talks about this tendency to head into politics by brandishing numbers instead of taking the time to find those that actually matter. The key difference is finding out what’s actually driving the results, and not just the results themselves.
For example, sales is a good metric to understand performance, but actionable metrics are necessary to be able to make meaningful decisions. What’s driving sales? Is it your paid advertising? Finding numbers to back up your hypotheses that paid advertising is important then becomes crucial so you can either spend more on it or less.
Admittedly, this part of my takeaways is the hardest to pull off because defining metrics is one thing and establishing the infrastructure to keep track of them is another. However, in the interest of learning, it’s vital that we spend a little bit of time putting up what’s necessary to understand how we’re doing.
4. The importance of identifying assumptions.
If there’s anything to take away from this book, it’s that a lot of the work we do is based on assumptions. We might be convinced of it to varying degrees, but taking a step back and seeing what biases may have come into play is going to really help.
Personally, I like to keep two columns of “assumptions” – user assumptions and engineering assumptions. User assumptions are the things we assume about our user – that they want certain features, that they are going to find it easy or hard to use what we build, that they need certain tools to solve their problem. Engineering assumptions, on the other hand, are what we assume about the future of the technology – that it will be outdated in a year’s time, that it will need to be extended to other use cases in the next 6 months, or that it will need to support a certain number of transactions once it’s live.
Both types of assumptions are important to identify, because we unknowingly make them all the time. If we don’t approach our work with an attitude of curiosity and skepticism, it’s easy to get pulled into work that doesn’t create any value at all.
5. The value of innovation.
Innovation accounting is a key phrase that I’ll always take with me from this book. Basically, it means measuring learning, as a substitute for financial measurements which typically comes much later. While it seems dangerously close to brandishing numbers to support a case, it can become your most important tool to keep yourself and others accountable for continuing to run small, validating experiments.
One thing that was striking to me was that this seemed a bit contrary to the traditional lean principle of minimizing the turnaround time between concept to cash. Though thinking about it further, it does make sense in the context of knowledge work, which is invariably unpredictable. And it makes even more sense if you take “cash” to mean anything of “value”.
In the work I do with Synacy, I’ve since tried to emphasize that “value”, while most directly measurable in terms of money (revenue made, expenses reduced), can come in many different forms. In addition to revenue and savings, I believe value can come from learning (i.e. validated assumptions, actionable data) and mission (how much is contributed to your company’s mission). One helps you make exponential progress on your future work, the other gives your work meaning.
Overall, regardless of whether you work for a small startup or in a big enterprise, I believe you can benefit from the insights found in this book. As I’ve personally experienced, it’s easy to relate to what we do on a day-to-day basis, regardless of industry or scale, and a lot of the ideas can be put into action almost immediately.
Get the book here, if you’re interested in reading more!
Dexter is an engineering manager at Synacy, a co-founder of ATeam Business Software Solutions, and founder of TechManagement.Life. He loves to share his experiences and thoughts on managing software teams and running businesses.