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 interactive software systems is a fantastic opportunity not 
There is a school of thought which suggests that smaller teams are considerably more effective, per person, than larger ones. The theory goes that the overhead required to organise and manage a smaller team is proportionately lower than that of a larger team. As team numbers increase, in fact, this overhead appears to increase exponentially.
