With the Major League Baseball All-star game coming up I’ve been thinking about MVPs.  But probably not the way you’re thinking of.  Instead of wondering who the most valuable player will be for the American and National leagues, I’m thinking about minimum viable products.

In the software development world, the concept of a minimum viable product has been around for years.  You can find links on Wikipedia and through Google to get more information, but the basic idea is to use fast and quantitative market testing to determine what feature or feature set constitutes ‘enough’ for users to want to pay for a product.  Eric Ries talked about this concept in his book The Lean Startup.  Yuval Yeret wrote a cool blog post about MVPs and the lean/agile requirements dinosaur you might also find interesting (who doesn’t like to see pictures of dinosaurs?): http://bit.ly/Uxyfwj.  And Anthony Panozzo provides a concise definition of a minimum viable product in his blog post Signs You Aren’t Really Building a Minimum Viable Product, “A Minimum Viable Product has just those features that allow the product to be deployed, and no more.” (Here’s a link: http://bit.ly/RZz6Yj).  I found so many cool links and posts about this topic that if I put them all here this blog post would be even longer than mine usually are.  If you really want to find these you can check my recent tweets.

The key goal of an MVP in Agile development is to answer the core design, technical, and business questions you need to understand before investing in the development and marketing of a more complete product.  Is there a real market for this product?  Does the proposed product solve a pervasive and painful market problem?  Is it intuitive enough to use that people will embrace it as a solution, or is it too clunky to be adopted by the market?  Does it solve enough of the problem to be seen as an acceptable solution or will the market view it as incomplete and inadequate?

Following the Agile principle of simplicity (which I recently wrote a series of blog posts about), the goal is to build only what the market will value as a product rather than building all of the imaginable features. Developing an MVP helps answer the key questions early before significant time is spent building something not yet validated by the market.  A great ‘Tools For Agile Blog’ post had the following picture about identifying the minimum viable product: (Check this out for more: http://bit.ly/18QweEg)

A product has to have enough features and benefits to be viable, but not so many that the product becomes cumbersome to use.  Products with too many features also take longer to build, running the risk that by the time the feature-rich product gets to market it may not actually be what people want to buy (and here’s a strong argument against building such products: http://toolsforagile.com/blog/archives/260).  Of course, in order to be viable a product also needs a defined market of eager buyers but that’s a different topic for another day.

Defining the minimum viable product involves figuring out which feature set solves the identified market problem.  If we plan to build a product to solve a three-step problem we need to know the following things:

A)     Does the market agree that this is a three-step problem or do they see it as having four steps (in which case our solution is inadequate) or two steps (in which case we built more than they needed)?

B)      Does the market agree that we’ve identified the right three steps, or do they segment the problem in a different way (that is, we built steps 2-4 from their perspective instead of steps 1-3)?

C)      Does the market actually want the solution we’ve built or is a different part of the process where the real pain is?

It may seem obvious, but we cannot answer these questions on our own; we have to get into the market and talk to real and potential users of the product we want to develop.  It can be very tempting for those of us with deep industry knowledge to create what we think of as a great product and then to start building it before we have gotten the market input we need to define the MVP.  The Agile development process works best when we get frequent market feedback at each step of the way – from the initial definition of the market problem through each phase of iterative software building – so that we are validating our approach and ensuring that we are creating a product people will pay for.

I wrestle with these issues a lot, and talk about them frequently with the product managers leading the projects on which I serve as product owner.  My role ‘on the bridge’ is more internally focused – making sure we build our products right – while I count on the product managers to ensure that we are building the right products.  We regularly ask if we have identified the minimum viable product and if we have understood how the market looks at the problems we are trying to solve.  The most valuable players on our development teams keep us focused on developing the MVP we need to answer the central design, technical, and business questions the market needs solutions for.  As the many links above make clear, there are a lot of smart people thinking about this and we are trying to learn from them as we struggle through the process ourselves.  Figuring out the minimum viable product is crucial to avoid under- or over-developing.  It’s vital for us to figure this out, but in truth it’s not that simple.