In follow up to his post in April on Minimally Viable Product (MVP), our special guest blogger, Toby Morris, is back with “The Base Model Theory”.  Oh, and a big congratulations to The Amazing Toby for his recent promotion to Software Developer II at Valpak.

There seems to be some confusion as to what constitutes a Minimum Viable Product. The MVP is the least amount of features that meet your customer’s needs for the product under development. That doesn’t mean it’s the least possible work you can get away with. It doesn’t mean you are allowed to skimp on quality. An MVP should have every bit as high quality as any product you’d put your name on. Those bare minimum features are still produced with your normal level of quality and craftsmanship.

Here’s a different way of looking at it.

When you go to buy a car, what would you expect if you bought the lowest price car? What would the Minimum Viable Product be? Would it be an engine on a wood frame, with maybe, if you’re lucky, four wheels? Would it have an engine? Of course it would have an engine. It would have everything you’d expect to find in a modern car. A steering wheel, seats, a radio and air conditioning would all be included. Leather, heated seats and satellite radio probably wouldn’t be included. Those are luxury features. Those would be found on upgraded models. Not on the base model. And that’s what a Minimum Viable Product is. A base model.

What goes into a base model? Well, that depends on your audience. You wouldn’t find leather seats in a base model Ford. The audience doesn’t expect it. A BMW probably should have leather seats. And heated mirrors. The BMW audience would consider those features necessary, not luxuries, or “nice-to-haves”. Knowing your audience is invaluable in knowing what your MVP would be.

Here’s a software example. Let’s say you want to build a notepad app. You want it to be the best notepad app, eventually, but right now, being agile, you want to build the minimum viable notepad app you can build. You don’t want to waste time adding features that your future users won’t use. That increases the amount of time you must spend developing the app before you can ship. And delaying shipping for unneeded features costs you money. Both in the time and resources spent developing this waste, and the loss of revenue from missed sales.

So let’s decide the minimum feature set. You’d need a functioning app that launches, shows your user a place to enter data, and a way to enter data. That’s the bare minimum to consider this a notepad. But is that the base model? Can you save files? Or load existing files for editing? If not, this isn’t a base model. You’ve not only left out non-essential features, you’ve also left out features your audience would consider essential.

To reach the base model standard, you add basic file operations. Once you get that running, you think to yourself that it might be nice if the users of your app could click a button and have the text they’ve entered be set to music automatically. Sure, that would be awesome, but it’s not a base model feature. That’s most definitely an option.

The next time you’re designing a product, and trying to cut out unneeded features without taking away too much, think about the base model. Would the feature in question be in the base model? Would your audience expect it?