‘Minimum viable products’ for fun & profit
I recently started a role heading up a new online health venture. Prior to my joining, the team had worked hard developing a high-quality web app, but it needed tightening up if we were going to get it in front of customers sooner and in a way that was manageable for a small team.
Over the past 6 or 7 years I’ve worked on a lot of new online services, and the ‘lean-start-up’ school of thought has been my preferred approach — quick iterations of a digital service, testing with users, gathering data and improving the service quickly and intelligently. In particular the ‘miniminum vialble product’ (or MVP) concept has served me well.
The basic idea of an ‘MVP’ is to create a service with the bare minimum of features you need to make it workable and testable with real users. One challenge with the MVP approach is that developers or designers can sometimes dominate the process, using techncial or design constraints to define the MVP. But for commercial services you need to make sure your MVP allows you to test your business model, not just your tech or user interface. After all this is a key consideration to determine the ‘viability’ of your services.
Business owners/managers, may find it difficult to let go of visions of a fully loaded product, especially if operating in a competitive industry. But reducing the range of features for an MVP increases speed of contact with customers. This allows you to adjust and course-correct before you spend money on a big marketing and sales push with a more refined product. Feedback from an MVP can also work wonders for settling internal debates about future development that get mired in subjective opinions, rather than the realities of your market.
Back to our app —working with the team we were able to formulate a plan for a slimmed-down version of our app, focused on the core commercial offering and the bare minimum of features needed to support this. Keeping this MVP rooted in commercial objectives helped gain buy-in with stakeholders, as well as providing clarity for the design and development teams.
Ultimately for us it has been a case of ‘taking one or two steps back to quickly take much quicker steps forward’. But now we can keep our development focused on our core services and add to and enhance them gradually as we move forward.
