Historically, the software industry has been plagued by spectacular failures: massive enterprise developments which fail to meet even the most basic requirements; applications whose feature sets are over-complex and confusing; web portals promising the earth but delivering very little – the list goes on and on. Countless budgets have been swallowed in the pursuit of the ‘next big thing’, the ‘killer app’ which will change everything.
It’s a tough industry at the best of times, but sometimes we make it tougher by simply aiming to do too much. We put our heads together around our funky meeting tables and let rip, resulting in huge, complex lists of possible features and requirements.
The sad truth is, though, that we’re not always that great at getting the basics right. In fact, scrub that, we don’t even know what the basics are. Why? Because in our rush to please, we forgot to really work with our users to identify what they really need. We thought we knew best, and acted accordingly.
Wrong.
In the world of the micro ISV, there’s a strong trend toward keeping things simple and offering limited feature sets which work and serve the majority of users, rather than extended ones which aim to please everyone. We call this ‘minimal viable product’ (MVP) and in essence it’s all about getting to market quickly at a minimal cost and maximum return on that cost. It’s typically geared toward getting the first version of a product out there to effectively ‘test’ a marketplace. And it works. Rather than commit huge budgets toward building every little feature, a company can save time and money and concentrate on fine-tuning a product and its positioning within a specific market.
So, how does this fit into the software prototyping ecosystem?
That’s an easy one. MVP is as viable an approach to test the acceptance and suitabililty of a prototyped solution design within an organisation as it is to a commercial product out in the big bad world. The same rules apply; designers can focus their efforts on creating smaller, simpler prototypes to stimulate discussion with end users. ‘Edge-case’ functionality is conveniently out of scope, and everyone turns their attention to the core, minimum feature set. When this happens, we spend much more time really working out how those core features should work. We quickly identify those features that users need the most. Need, not want.
In conventional MVP, there is an emphasis on measuring what users do when they use a system. The real power of MVP is collecting and interpreting this data and feeding it back into the refinement of the system’s design. Sound familiar? Of course – it’s simply an ‘in-the-field’ version of what we use software prototypes for: gathering contextual information about what works and what doesn’t before committing to particular aspects of a design.
MVP is, in a way, both a compliment and an alternative to conventional software prototyping – both have their uses and there’s a strong argument to think of MVP as simply ‘live prototyping’. Either approach can deliver real benefits by saving time and avoiding unnecessary design of flawed or non-viable features.
Designing good software is far from straightforward. It’s all too easy to simply jump in and hope for the best. Software prototyping is one technique which can help 
Having mentioned that software prototyping is an iterative process, it follows that version control is important to consider.
One tactic which is worth covering is to understand your audience and how they will perceive your prototype. A technical audience will doubtless look at your prototype in an entirely different way to a business audience, which in turn will probably look for different things than would an audience of end-users. The key is to tailor your approach to demonstrating your prototype so that:
