Shipping a product is a big benchmark, but initial release is just the beginning. Expecting an app to perform well, drive downloads, and have sustained usage without working to improve the product is a mistake that is all-too-common.
The “publish and pray” approach has two major issues: it assumes that at launch, your product will be absolutely perfect and fully-finished, which means time to delivery is slower; and it ignores the vast benefits that can be gained from collecting feedback and rolling out new product versions based on actual market and user data.
Lean Agile eschews this and encourages delivering quickly and delivering often. This approach is paramount for both unproven concepts and mature products, but the reasoning for each scenario is very different.
For smaller user bases or concepts that are unproven on the market, your minimum viable product will be a smaller release and should be launched quickly. Since there is a degree of uncertainty with new concepts, it’s harder to determine what users find valuable; that’s why getting to market quickly with an MVP is important so you can get user feedback, collect data, and prove or disprove the assumptions you’ve made. This is the logic behind “fail fast to fail cheap.” If you take too long to ramp up with an unproven concept, you are spending time and resources to release a product that is based on many assumptions and may need to pivot – any failures are much more costly.
Releasing often allows you to learn from your users to improve the experience; make features better; fill in gaps present in earlier versions, and ultimately make the product better. If your app has a video player and that is what people use most frequently, for example, you know that focusing on making that feature the strongest is a good course of action, prior to rolling out a number of new features.
Once you grow enough through validating (or disproving) the assumptions you’ve made, and your app becomes mature, delivering quickly and often will help you engage, retain, and delight the user base you’ve established.
Mature brands already have a large customer base. They may not yet have mobile products, but consumers expect a certain level of quality from any product or service a mature brand provides. In this scenario, the first version of the product that goes to market needs to meet a certain expectation – not necessarily more features, but a high quality, functional product that adds value.
Users won’t provide the same level of leniency to mature brands as they do to unproven concepts. Since there is a higher expectation associated with whatever the brand releases, they need to please users from initial launch. Therefore, what’s considered a minimum viable product is different for these kinds of companies.
While it’s still necessary to launch MVPs quickly, version 1 of the product needs to be more fleshed out. Updating often allows you to roll out more features and enhance the user experience, adding more value for the customer and encouraging engagement and retention. It’s less about validating assumptions to prove the concept and more about adding additional value to your users regularly with every release.
Spotify’s Decoupled Release Model
Spotify has implemented this by creating an environment where releasing is routine and easy to do. Since the product is so complex, they’ve changed their architecture to allow decoupled releases so they can push new features easily without affecting the overall architecture. Facebook takes a similar approach, following a “ship early and ship often” philosophy. They use a lightweight process that allows them to iterate rapidly to get new features out quickly.
Adopting a deliver quickly, deliver often approach helps you consistently and predictably improve your product, add value to users, and ensure long-term product success. Implementing a process and culture that allows you to do this is of integral importance. If you focus only on initial launch, your product will remain stagnant and lose relevancy in a competitive app economy that never stops evolving.