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?

Why Lean?

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.

How Does it Work for Mobile Developers?

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.

Mobile Web

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.

Deploying Hybrid ‘Wrapper’ Apps

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:

1. Create a very simple but polished MVP – the “polish” automatically makes it not minimum though, if you’ve got some important things about the product wrong then you just wasted a lot of time polishing.
2. Test the market with a beta program before launch – this is almost always a good idea although for iOS the size of your beta audience is heavily limited by Apple’s test device limits (e.g. 100 per developer account) and you can’t easily charge your beta testers, which means you’re missing out on the important test of whether early adopters are prepared to pay for your app/service.
3. Test the market by releasing an MVP and early iterations under different names on separate developer accounts – this is genius, although has some ethical and/or logistical issues around what to do about paying customers for the versions you abandon.

Building Native Apps in the Lean Framework

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.

Measuring Native Apps

The ability to experiment with variations in a product via split testing (A/B, multivariate and similar techniques) is also a major pain point for native app developers. Pure native in-app split testing solutions now exist (e.g. Switchboard) but are hampered by the app update cycle in terms of how frequently you can perform different experiments. For iOS, Apple does not allow downloading of code aside from JavaScript for the built-in UIWebView component, so developers have been incorporating web content into their native apps where they need to run lots of split tests. Twitter recently acquired the company behind a leading solution of this type, Clutch.io, and open sourced the framework. It combines a native A/B testing framework (for iOS & Android) with hybrid web/native app framework (the latter for iOS only thus far) for maximum flexibility. On this measure, iOS appears to be ahead of Android with other native platforms so far not well supported. In theory, Google’s more relaxed policy on code downloading should enable more advanced split testing frameworks for Android with automatic replacement of native features. However, so far the convenience of the Android update process appears to be sufficient for developers to avoid adding such complexity to their  apps.

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.

Conclusion

With all factors considered together, the app store review time seems to be the most significant element in determining how well you can implement lean startup principles in a native mobile app development. Unless Apple improves this, iOS will lag the other native platforms and Android will continue to lead as long as they have no review process; even so, users don’t tend to update apps frequently or enable automatic updates. When the primary revenue model for iOS was paid downloads this wasn’t critical. As we move towards more in-app purchase based models the ability to split test to improve conversions will become critical. Will more developers start with a web/native hybrid app for more rapid iteration while they get the product right and replace with native components later (a strategy that Facebook appear to have followed by accident?). This would certainly make sense for the parts of an application directly related to conversion from free to paid users from a process perspective – how much sense it makes technically and in terms of user experience is another question. An MVP is supposed to target early adopters who are more forgiving of a product’s flaws or incompleteness because it serves some job they really want done. Does that forgiveness extend to accepting a non-native user experience? Perhaps that’s another hypothesis worth testing.