Thoughts on The Lean Startup (Eric Ries)

I just finished reading the Eric Ries book, The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. I recall skimming this in Waterstones a few years back; I was surprised to find it was published as recently as 2011. Since then, it’s become a classic and many of its concepts, especially the Minimum Viable Product, have become ubiquitous in business life.

What’s this book all about?

Enterprises focus on developing new products efficiently, but what use is it to efficiently developing a product no-one needs? Today’s challenge is to build the right thing. Given the uncertainty, the unknowability, of the market, the only way to build the right thing is to test your ideas in the marketplace as early as possible. Push out a first offering and measure its uptake. Refine and repeat. Through a series of structured experiments, learn what customers value, and what will drive growth of your business.

Ries talks about a couple of leap-of-faith assumptions. These are the riskiest elements of a startup’s plan, therefore it’s a priority to test these hypotheses.

The first leap-of-faith assumption; the value hypothesis

A startup will only succeed if it offers something of value to its customers. This is equally true of for-profit businesses or not-for-profit social or governmental offerings. My current hobby project (definitely not planned as a for-profit startup) is a web site for travellers. The value hypothesis is:  “Travellers will find it useful and fun to track all of the UNESCO World Heritage Sites they have visited or plan to visit, hence they will be motivated to sign up and to return to the site.”

Ries would recommend building a very basic form of the the offering, in this case a web site. This is the Minimum Viable Product (MVP). The MVP will be primitive, it might even be buggy. But it provides a vehicle to test the value hypothesis. Early adopters are willing to endure rough edges if there is value in the offering. The imperative to learn quickly must trump the desire for perfection at this stage of an embryonic startup. Even small numbers of visitors can deliver insight into to customer experience; Ries described the early days of his company IMVU, which paid Google Adwords $5 a day to bring 100 customers to the site. Each week, the company would chart the behaviour of recent visitors, in terms of sign-up, login, usage, and conversion to a premium paid offering. Each week, new features would be introduced, and the team would monitor impact on the key metrics. This gave clear visibility of features which customers valued and should be retained, as opposed to features of no value, which were discarded as a waste of effort.

The second leap-of-faith assumption; the engine of growth

How does a startup grow? In one of three ways, says Ries: sticky, viral or paid. The engine of growth dictates which growth metric the entrepreneur should study most closely.

Sticky growth occurs when customers, once recruited, tend to stay with the product for a long period. This might be because of barriers to entry (such as market-leading technology), network effects (a special-interest community) or high obstacles to change (enterprise software). If your business depends on sticky growth, the key growth metric is attrition or churn rate. Even if you are attracting new customers at a high rate, growth will be meagre if existing customers are defecting.

Viral growth occurs when existing customers attract new customers through recommendation or word-of-mouth. The key growth metric is the viral coefficient, which is the number of additional customers who will use the product as a result of each new customer recruited. Businesses that seek viral growth must focus on this more than any other factor, because small changes will have dramatic effects on growth rate. A coefficient of 0.9 will lead to stagnation or failure, whereas a coefficient of 1.1 will lead to spectacular growth. As a result, such companies often do not charge customers directly, lest this impede viral spread, but instead rely on indirect revenue such as advertising.

Paid growth occurs when a business has strong visibility of the value it will extract from a customer over the lifetime of their relationship, and can therefore invest in marketing to attract customers. It matters not whether the Cost Per Acquisition (CPA) is $8 to acquire Lifetime Value (LTV) of $10, or CPA of $8,000 to acquire LTV of $10,000; both have a marginal profit of 20%, which is available to reinvest in further growth.

A fundamental assumption of this book I’m not sure about

There is an assumption that the startup must aspire to rapid and massive growth. Ries talks about:

The land of the living dead … when a company has achieved a modicum of success – just enough to stay alive – but is not living up to the expectations of founders and investors. Such companies are a terrible drain of human energy.

Prior to reading this, I would have confidently espoused my ambition to become a shoestring entrepreneur, building a web application or two that would appeal to a loyal, niche audience with no intention whatsoever of attracting venture funding, still less becoming the next Facebook. A digital corner shop if you will. But in Ries’s world, every corner shop should be dreaming of becoming the next Walmart. Caroline says it’s just because he’s American. I’m feeling a bit confused about this now; do I lack ambition? Is a small scale project doomed?

Things I really liked in this book

The book has a really strong focus on developing actionable metrics; Ries also calls this innovation accounting. I love to see simple measurements that illuminate exactly how a process is working. Unfortunately it’s a rare thing, and even the best-intentioned seem to create scattershot collections of what can I measure? that only serve to confuse. Ries further points out the danger of vanity metrics, which are less innocent. A management team determined to demonstrate success to investors can easily show flattering measures such as overall growth in number of customers, while ignoring or suppressing figures that may indicate growth is slowing, or attrition increasing, or new product features have not been valued by customers. They only delude themselves, and are likely discarding the vital information that could turn around their plight.

Specifically, I learned some techniques that I wish I’d known sooner and may be able to use in future. I’d heard all about A/B testing, but there were good examples of companies who build this into a rapid innovation pipeline such that no feature is complete until the A/B test results are in, and the decision is made whether to persist with it, or back it out as a failed experiment. I learned about cohort analysis, which would have been immensely valuable when I was trying to provide a clear representation of the marketing pipeline at Brighter Business, a complex situation with customers arriving online, sometimes obtaining quotes online, but generally converting via the call centre.

In regard to validated learning, the key phrase is Pivot or Persevere. Armed with the metrics that should provide crystal clear insight into how your product is performing, the entrepreneur has to decide whether optimising the current strategy will eventually deliver success, or whether a more radical change is needed. Pivot means changing course, while keeping one foot on the ground, for instance changing to a different engine of growth strategy, narrowing or expanding the product scope, or seeking a different customer group. I think for Ries, the difference between success and failure for a startup is the speed of reaching these decision points and the clinical accuracy of making the pivot or persevere decision.

Towards the end of the book, Ries introduces a discussion of small batch thinking, which absolutely appealed to me, and brings things back to the starting point of this blog; the inevitable failure of traditional Enterprise Architecture. The scenario is a father and daughters stuffing newsletters in envelopes. Father asks the children: what is the quickest way to address, stamp and stuff 100 newsletters in 100 envelopes? The daughters confidently say: first fold 100 newsletters, then stuff 100 newsletters into 100 envelopes, then address 100 envelopes, then attach 100 stamps. Father challenges them, and takes the opposite approach, fully processing one newsletter at a time, known in manufacturing as single-piece flow. Counter-intuitively, Father wins the race, and not just because he is an adult.

The advantages of single-piece flow have been consistently demonstrated. Part of the advantage arises because of tasks we tend to forget: in this case stacking and tidying the growing pile of 100 folded newsletters. But more significantly, the large batch approach is prone to unexpected rework. What if the folded newsletter doesn’t fit the envelope as we expected? We may have to go back and repeat work.

Enterprise IT, and specifically traditional Enterprise Architecture, takes upon itself the challenge of working out in advance all of the steps required to reach the target state. Then it tends to demand large quantities of cash to execute the plan. Lo and behold, things don’t go according to plan. The project’s stakeholders develop antagonism towards the project, and demand more frequent reviews. Productivity takes a dive as everyone spends their time talking about the problem rather than contributing to the solution.

How much better it would be if we tackled our transformation in small batches, with carefully chosen metrics, and rapid, iterative persevere or pivot decisions.

Three Things a City In Charge of its Destiny Ought to Know About Software

http://radar.oreilly.com/2015/01/four-short-links-9-january-2015.html

Photo City of Light (c) Carl Milner.

This quote gets to the heart of some of the mistaken group-think in enterprise IT.

The so-called economies of scale claimed for big IT solutions turn out to be largely illusory. Their business cases begin with wrong-headed, goods-dominant accounting copied from the world of manufacturing, where buying stuff in bulk really can be cheaper. Wishful thinking by people remote from the frontline carries these projects forward unchallenged. But by the time complex shared services have been tailored to the needs of the people and teams who use them, they can actually increase costs substantially.