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?

Guest blogger, Toby Morris, is back with his take on the importance of Minimally Viable Product (MVP) in Agile.  Toby, known around these parts as “The Amazing Toby”, is a software developer at Valpak.  Enjoy!

When it comes to agile learning, development and growth, one concept rises to a level of importance few, if any other, concepts rise. With this one concept, if you grasp it, you will grasp the very heart of agile. If you can’t, you will struggle to reach the level of efficiency you should be able to reach.  Minimum Viable Product (MVP) is the soul, wit and zest of agile.

To me, agile is about maximizing the value and speed of delivery of the products my customers need and want. It’s about cutting waste and inefficiencies out of the development process. MVP is the deliverable with the absolute least number of features that will satisfy your customer’s needs. Period. Anything more or less isn’t good enough. Not enough features and the product may not be useable. Too many features and you’ve wasted resources and delayed getting the product to the people who need it most.

Minimum Viable Product is a concept that wraps up many agile principles, and it’s a tool for slicing through extraneous features. When looking at any user story, a first thought should be “how much of this is needed for a working product?”. Use the MVP blade to cut away at fluff and “wants” to get to the heart of the product. Try defining the product in a catalog blurb. If a feature isn’t in that blurb, then it’s probably not needed. Every feature that isn’t a core feature of a product is a wasted time in not only development, but also support.

Use the MVP blade to cut those extraneous features out of the current user story and add them to the backlog. If they are valuable, they will make it back into the sprint plan and into the product. If they never make it into a sprint plan, then they weren’t valuable. You just saved yourself, your company and your customer the time and resources that feature would have cost.

We’ve had customers at our company that ask for every possible feature during the early stages of a product’s development. They share a belief that if they don’t get everything in the first round, we’ll put features they want on the backlog, only to never find the time to get back to them. And that’s true. And that’s how it should be. If a feature belongs in the product, MVP will force you to include it. If it doesn’t belong in the product, MVP will relegate it to the backlog, where it will die a slow, cold death.

The Minimum Viable Product concept applies to anything you create. Anything you do. It’s the Zen of software development, and every other creative process. Whether you’re applying it to an entire application, a single feature of an application, or even a component of a feature, if you let it guide you, you will be surprised at how efficient you become.