There’s a lot of buzz about Lean Startups in the software community in general and amongst mobile developers in particular. How lean a startup can be is strongly influenced by the tools and processes available on their chosen platform. Which platforms enable the leanest product development processes? How and why does lean framework matter?
For those not already familiar with the terminology, “lean” in this context does not simply mean “low cost” and “startup” is not necessarily a small new company. Being “Lean” is more about the minimisation of waste (particularly wasted effort) and the concept has evolved from methods Toyota pioneered in manufacturing many decades ago. Eric Ries, combined lean management philosophy and agile software development processes with Steve Blank’s customer development, creating the Lean Startup movement, to enable a more scientific approach to the creation of new products and services. The greatest uncertainty in many new ventures is not how to build the product but what to build and who for. If the assumptions that the success of a project depends upon are explicitly stated then experiments can be designed to test them efficiently. The goal is to invest just enough effort to test the assumptions first, rather than build something complete and polished that nobody wants.
The core process is to build a Minimum Viable Product (MVP) then get it into the hands of real customers, measure their response then learn from that to make new assumptions and build another iteration. Build, Measure, Learn, Iterate. The goal is to have very fast feedback loops and evolve the product towards something there’s a clear market for as quickly as possible. The faster assumptions and hypotheses can be tested, the sooner that goal can be reached.
Clearly software built and delivered in the shortest possible time with rapidly changing requirements by design needs a very robust and flexible development methodology. This methodology was developed around software delivered via the web and supported via certain technology and processes: agile software development, continuous deployment, split testing and analytics. It is being applied in varying degrees to other businesses where these don’t all apply. Mobile apps, being relatively similar to websites in many ways, should be able to adopt similar processes, however, small variations in tooling and policy can make a big difference.
Clearly mobile websites are similar enough to desktop websites that the same tools and processes can be applied. There are some still some subtle issues with tooling, such as the need to automate tests on actual devices to have enough confidence in releases for continuous deployment or restrictions on the split testing methodology that can be applied if your site has a responsive design or otherwise targets multiple screen resolutions. In general though, a mobile website allows a faithful implementation of lean startup techniques, easy experimentation and rapid iteration to product/market fit.
Unfortunately many developers are still finding it difficult to monetize web applications. Some try to solve this by creating a native app wrapper for their web apps and selling them through an app store. The store introduces friction to the deployment process, although as long as the wrapper is very thin or simply adds generic access to platform APIs that rarely needs to change then the addition of the wrapper makes little difference to a developer’s ability to develop their product following lean startup principles. However, there may be marketing impacts to launching an MVP on an app store which has a somewhat permanent record of the product’s history – particularly the reviews. Andrew Chen has a great post on ways mobile startups can iterate faster, although the solutions all have drawbacks that can be quite serious if you’re not VC funded and going for massive scale with a free app:
Once you move to a native application framework the issues around MVPs on app stores still apply and all of your tools for lean development change too. Whilst there are many variations on agile software development, the versions that support continuous deployment and major changes of product direction (known as pivots) require some test automation. The tools to support this are less mature and more painful to work with for native apps. Most native mobile frameworks are similarly poorly served in this regard – it’s always possible but harder than it should be. Android is possibly slightly ahead of iOS, which is then ahead of Windows Phone. Since continuous deployment is almost impossible anyway (you can deploy to beta-testers via Testflight or HockeyApp automatically but not to app stores) and users don’t really want to download a complete update to your app several times a day to keep using it, many developers are skipping the automated testing entirely.
Although continuous deployment isn’t practical, on Android you can release a new app version to the store as often as you want within reason. Other platforms have variable length waiting times for review before the app is published, with iOS typically having the longest (which you can get a decent measure of here) – it’s typically about a week but can get significantly longer around new product or OS version releases. That places a fairly hard limit on your cycle time for new product iterations if you’re using pure native code. Longer cycles mean slower learning and a longer and more expensive route to product/market fit.
Fortunately mobile apps are very well served with analytics – there are multiple very capable solutions in the market with broad platform support. As such it’s very easy to measure the results of experiments and learn about the volume and types of use a product iteration is achieving. Sadly, being able to measure what’s happening in your apps rapidly and accurately is not so useful for lean product development if you can’t react very quickly. For this reason several lean startup advocates recommend leading with Android to iterate and experiment faster, even if their main revenue generation is expected to come from iOS. This seems like sensible advice although there’s a risk that the results of experiments don’t transfer between the different platform demographics.