If you spend any time amongst people in the London tech startup scene, it won’t be long before you pick up on the influence that Eric Reis’ 2008 book The Lean Startup has had on many people in fledgling businesses.
The book describes a methodology for running a new (tech) venture that draws on both the lean manufacturing movement pioneered by the Japanese car industry in the 1980s, but also from agile software development methodologies.
Overall, Lean Startup argues that if you want to build a business you need to change your product or service to reflect what your customers need, rather than building the “perfect product” and releasing it to market.
There are a few core concepts at the heart of Lean Startup:
Minimum Viable Product (MVP) encourages releasing a new product or service as early as possible, rather than waiting for the whole to be developed. This feels quite similar to time boxing and working releases in agile methods.
Continuous deployment encourages all software written to be released into production immediately.
Split testing (also know as A/B testing) is an experimental method of testing multiple versions of an application to see which is most preferred by users. It’s been a very common technique in commercial web development for many years.
Actionable metrics are measures that allow for meaningful business decisions to be made, as opposed to vanity metrics which tend to just paint a rosy picture of a business’s position.
Pivot, which is when a business changes it’s fundamental business proposition on realising that it’s original hypothesis isn’t necessarily a great idea. Nokia, for example, started as a rubber products business, moved into producing cables as part of that product set, then into electronic components and from there into mobile phones and networking equipment.
Lean Startup came about in the world of the Web, and there are (it seems to me) a few challenges that need to be thought about when it comes to building a business that is focused on apps rather than a browser:
You need to think a bit harder about what you want to measure
The world of Web applications, and Web analytics is such that there is a lot of data about people’s use of your application generated at the server side which can be analysed using off-the-shelf tools (Google Analytics, for example). Those analytical tools provide so much information that you will probably have data that can provide actionable metrics.
If you are delivering an App, that changes: you can find out information automatically about the demographics of people downloading your app, and maybe some very limited usage data (time of use, for example), but that will be about it. Help is at hand though from services like Flurry.com which enable you to build flags to report on specific sorts of activity within your app.
A/B testing becomes more challenging
Within a browser environment you can deliver different versions of the same service to different people at the same time – having two entirely different versions of your site being tested concurrently is perfectly possible without the end user being much aware of their experimental subject status. Building that kind of testing model into an app becomes more challenging unless you have a level of complexity built into your app (or potentially can find a way to deliver two different versions of basically the same thing to your customer base).
Alternatives might include testing versions in a lab, but that can be costly or runs the risk of strange results from using small samples of experimental users and the impact of lab testing in the first place (this, in fact, is kind of what led to the New Coke debacle in the 1980s).
Continuous deployment versus app store submission processes
The idea of releasing multiple versions of code in quick succession works well in the Web world – code is released to a server, and can be rolled back quickly as well. In an app environment where there are submission processes and quality control on behalf of the app store owners, it’s slightly more challenging: if it takes a day (or a week, or whatever) to deliver an update to an app, then releasing every hour into the live environment is just impractical. Larger releases on a weekly or longer basis potentially bridge the divide (a week or even a month is a short time in comparison to application release schedules of old…)
There’s a lot of sensible advice in Ries’ book, but some of the concepts might need a bit of flex in a world where Apps become an increasingly important facet of a tech startup’s business.