The Lean Startup by Eric Ries
Somewhere in 2020, for mysterious reasons, I thought it would be a good idea to read 50 books in 2021. Now, 28 books in, I find that I appreciate aspects of these books that I have shunned, that I never expected. I feel enriched by the educational value of some of the books I've read, as well as inspired by the different perspectives they give me.
This realisation of mine, has only made it feel very apt that I take the time to turn a spotlight on the few gems that I have found along the way, in the way of a short book review or perhaps even recommendation.
I'm starting it all of with 'The Lean Startup' by Eric Ries. A book I've read in May this year.
In my current position as an 'Information Technology Architect' I am mostly in charge of developing products and processes for new markets and clients. We are a small team, completely isolated from the rest of the company, focussing solely on innovation and adding more value to our offering towards the customers. Especially early on, our team felt very much like a startup. A group of people finding their new roles and responsibilities. Working on things that hadn't ever been done within the company, with technologies we weren't very familiar with.
An external advisor within the team is very good at structuring the goals of our team into clusters that we call products and markets, as well as finding early adapters for these markets that we would like to enter. I picked up this book, hoping to find some framework or reference on how to develop (both in commercial and technical sense) these new products, with the customer always in mind, in a lean but mostly agile way. Now for something actually about the book;
Vision
The first part, Vision, dives into a more Lean way of thinking. It dives into the benefits of thinking in small batches, small iterations. The benefit of these small incremental steps, are something I now see in practise. Due to the nature of our short, feature driven sprints we can accommodate specific requests from (potential) customers and 'pivot' (change direction/strategy) on a sprint basis. It also allows you to gain feedback on features that might not be exactly as you envision (but functional nonetheless) to gain insight in what customers actually want, and want to use. These lessons on where you are actually adding value to your customers and how they want to consume your product (and where your own assumptions and development fail) are quantified as lessons learned.
The biggest success of this iteration driven, feedback intensive process is that you do not lose vision, but rather appreciate batch driven development as part of it. As a result 'Lessons learned' should always be quantified in a KPI. In the end they are what make you and your product better. It creates a mechanism that allows people to avoid building products that have no market. By extension it embraces the concept of pivoting away from something with lessons learned, rather than doubling down refusing to take these lessons to heart. You hypothesise, build, measure/test and learn.
From personal experience there is one obvious pitfall to this strategy. Because it leans so heavily on small iterative changes based on feedback, you are dependant on people and preferably early adaptors to give you this feedback. It is important that the feedback of these early adaptors doesn't become the basis of your strategy, leading to a customer specific end product. Always keep the end product and it's market in mind, and rather let the feedback and lessons learned steer you towards the areas where you really add value.
Steering
Part two is about steering, or rather; Knowing when to change your course. I found this especially interesting as it is something I personally struggle with. Knowing when the product you are building no longer has an audience, or when you are slowly drifting into territory that has a competition you're not comfortable taking on. It's important to know when to 'pivot'. Take a step, reevaluate your current course and where it leads you. Have a look at your strategy and either pivot into another direction, or persevere.
The critical part is that this time between development and feedback/ lessons learned is as short as possible. Time spent on something that isn't viable, is after all time wasted. Test the assumptions you have when you start out. Are people indeed tired of doing 'x' manually? Do they really want to pay for that product that you're building? How big is that audience exactly? What is the market for it? Is there really no solution these people already refuse to adopt?
These assumptions are driving your strategy and need to be tested. With as much feedback as possible. In the iPod business, one of those leaps of faith was that people would pay for music.
Some of the examples given to test these assumptions are 'Genchi Gembutsu' or 'Go and see for yourself', External customer data and finally customer archetypes. Humanise the type of person your product is aimed for.
The best way to test your assumptions however, is building a Minimal Viable Product and bringing it under the attention of early adapters of your market. Not only does the Minimal Viable Product test your technical and design assumptions, it tests your fundamental business hypothesis. A Minimal Viable Product is most succesful when you don't spend time developing any feature, process or design that does not contribute directly to learning about the assumptions that are driving your vision and strategy. Instead search out to validate the assumptions you've made about where you add value to your customer.
The best way to reinforce this way of learning about what your company or product is about is simply making the lessons learned (as mentioned in Vision) a KPI of the company. Eric Ries calls this 'Innovation Accounting' e.g. are you producing validated learnings. Define learning milestones. Define which assumptions you aim to test. 'Tune the engine' so that the economic market of your product expands.
Accelerate
There are four primary ways past customers drive sustainable growth:
Word of mouth. Embedded in most products is a natural level of growth that is caused by satisfied customer’s enthusiasm for the products.
As a side effect of products usage. Fashion or status, such as luxury goods products, drive awareness of themselves whenever they are used.
Through funded advertising. As long as the cost of acquiring a new customer (marginal cost) is less than he revenue that customers generates (marginal revenue), the excess (marginal profit) can be used to acquire more customers. The more marginal profit, the faster the growth.
Through repeat purchase or use. Like subscriptions or voluntary repurchases.
Eric Ries dives into different 'engines of growth' that you can employ to grow the company and its revenue.
The first is the sticky engine of growth. In short; More customers come in, than drop off. This engine keeps a close look on churn rates and incoming new users. The tuning happens mostly in reducing the cost of finding new customers, or lowering the churn-rate by retaining customers longer.
Secondly, the viral engine of growth. This growth-model depends mostly on mouth-to-mouth advertising. Not in a preachy or evangelistic way, but rather just simply by using the solutions that you are providing. Think of applications like Facebook and Whatsapp. With these application there is a sort of feedback-loop, the more people use the application, the more people are exposed to the solution, increasing the audience and thus the potential of the engine of growth.
Thirdly the paid engine of growth. This growth-model is based on a positive ratio between the cost of acquiring new customers, and the lifetime value (total amount of money paid) when someone becomes a customer. Assume an add costs 100€, and gets 10 new customers to your product. The cost per acquisition (CPA) of a customer is 10€ in this case. If the LTV (Lifetime Value) of a customer is greater than that 10€, it means the product and company is growing. The margin between CPA and LTV determines the speed at which this engine of growth works.
