"M" Stands for Minimum

I've recently lead a product build for an app, now available on the iPad store, my organization is using to support the distribution and consumption of a relatively new service offering.  This was an MVP build.   If you are familiar with agile development or other user-centric iterative processes, you will know that "MVP" stands for "Minimal Viable Product."  

The "MVP"...

What an MVP IS:

In terms of a product build within an organization, the objective of an MVP build is to create working functionality with the LEAST AMOUNT OF EFFORT, aimed to accomplish some business value so that it can be put in front of users to capture FEEDBACK so that assumptions can be validated/disproved and courses can be corrected if need be.  Key here is the fact that effort should be MINIMAL.  We want to get a working product in front of users as soon as possible so that we can ensure we are focusing effort in the correct places, addressing erroneous assumptions before a critical amount of effort is wasted and to also uncover additional product opportunities.  An MVP is lean and hyper-focused and is really the first significant release in (hopefully) a series of increments.

What an MVP IS NOT:

Given the objectives of the MVP, we know we're not going to have a product which looks, feels, and functions like a seasoned tool.  Depending on the type of feedback the team is looking to capture, visual design may be basic, unpolished, even unappealing and the functionality may leave something to be desired (Which can be a very good thing if your feedback supports this notion!).  

Some Challenges and Notes for Success

As a Product Owner, I am the gatekeeper of the success of the product.  Part of how we define "success" for an MVP build it is that the product truly adheres to the definition of "MVP" and that all stakeholders (and anyone who will any interest at all in the product) are aligned and that expectations for the product are properly communicated and understood.  

Setting Expectations:  Before an MVP build is initiated, it's paramount to set expectations with "investors" and stakeholders on what it means to be an MVP and what our objectives are during an MVP build.  I was lucky in the sense that my immediate team and project sponsors are well-versed in iterative product development- Educating wasn't an issue, but expectation setting and reminding is always important.

Maintaining that "MVP-Mentality": As a PO, one of the more challenging aspects during a product build is ensuring that the team remains focused on an "MVP-mentality."  It's very easy for a team, when deep in the minutia and technical aspects of development, to stray from a key point of our mantra which is focused on how effort is directed.  As Product Owner, I continuously ask: "Is this the least amount of effort we can spend to realize the targeted business value?"  To do this, I must own a keen sense of the business value we are achieving and have the ability to "take a step back" and focus on the greater objectives...which are not at the level of a backlog item.  A mental process I perform quite a few times each day.

Argh, but the FEEDBACK!: After an MVP release, I've noted another challenge:  We've just spent an intense period of time releasing a product, which is highly visible and public.  The work we've put in has consumed our lives for the duration - It only makes sense that we would be passionate about the product.  ...And now it's time for feedback.  I think it's natural to be protective of the product and design decisions the team as made - Refer back to to impetus behind many of these decisions:  We've built and MVP and it is accomplishing core objectives, feedback being one of them.  Do NOT take comments and feedback as personal - view them as opportunities which are extremely valuable to take forward as the product matures.