The “lean” approach has become an established practice at startup companies as well as larger software companies. These organizations have learned that “lean development” quickly results in a product that their customers actually want. However, most successful software products today are not just products. They rapidly evolve into platforms on which customers build apps and solutions. Most of these software platforms though haven’t internalized that their customers also need to build apps and solutions using a lean methodology. Customers deserve better!
There are seven core tenets to the lean software methodology. The central tenet is rapid learning from user feedback. This should be the most vital part of the software development cycle. Beginning with a minimalist starting point (a Minimum Viable Product, or MVP) created and delivered quickly, the idea is to iterate rapidly, abandon failed ideas quickly, constantly update the product, and continuously collect and analyze user feedback (both explicit feedback as well as implicit feedback collected through product use). This innovative process leads to a product that users actually want because they have actively shaped its creation.
The lean approach stands in contrast to the traditional “waterfall” development model where a product starts with a detailed specification put together by an “expert” or via customer surveys. It is then implemented and tested thoroughly, and only then is it put in the hands of the actual users as a finished product. The chances of such a product actually being optimal are very low. This becomes an inefficient and expensive way of building software solutions. This is why many apps and IT solutions fail to gain traction.
From our work at AppSheet, I am particularly familiar with mobile app development platforms. Let us consider how a business goes about building a mobile app for its employees using a traditional app development platform. Typically, it needs a product requirements document, a design with screenshots and mockups, a price estimate, a schedule, allocation of in-house developers or an outsourced contract. Then comes the painful step of getting project and budget approval from management because there will be a significant upfront cost. The project then needs to be managed for months until there is a working version of the app. Then it goes into field tests with some initial employees, feedback has to be sent back to the developers who update the product, re-release, etc. Each iteration takes at least a month or two, and it is rare that the project is complete in less than six months. If you work in any IT organization, this sounds familiar!
To put it mildly, this is really inefficient and unproductive. In an idealized “lean” universe instead, the customer would go from a whiteboard sketch to a working app in a few days or less, get the app to initial employees immediately, capture feedback and iterate on it everyday, and converge on a functional and useful app within weeks. What’s more, most of the energy should have been spent reacting to real feedback from real users. Of course, the really important thing is that the apps created in this fashion are far more likely to be useful, rather than abandoned as app roadkill. Also in this ideal lean universe, there should be little need to budget or schedule at the start. It is only when the app shows signs of traction should it need any significant monetary or organizational commitment.
To summarize, the critical features of a lean software platform are near-immediate prototyping, constant user feedback, near-immediate updates, and incremental cost structure. To reflect that, I’d propose that for any particular domain, competing software platforms should be compared using a “lean benchmark” with exactly four measures:
• Time & cost to initial app creation
• Time & cost to initial MVP deployment
• Time & cost to get customer feedback
•Time & cost to improve and redeploy the MVP
The lower these four measures, the more value the platform generates for its customers. Bring on the lean, mean software platform machines.