MVP, MVaP or MVC? WT… the case for Maximum Value Creation as a Product Management framework

Frameworks are a handy thing in Product Management, they act as a mental short cut reminding you what’s important, how to operate and how to interact as you go about your (very busy) job. However, they can often be used and abused to achieve other ends than they were created for — There are scores of examples of organisations that are Wagile, or think they are on to a good thing with Spotify’s Scaling Agile approach to organising people and teams by simply renaming their existing organisational structure.

Organisations can take a good framework and apply it in such a way that it conflicts with the values and principles that underlie it, in the process forgoing it’s benefits for other ends (I’ll let you decide whether that’s been done consciously or not!). Here I introduce a new framework (well really just rebranding what we already know, but that could be a powerful thing for the under-pressure Product Manager) that hopefully is more resistant to such abuse.

The MVP

A case in point of an abused framework is the MVP. Oh, the MVP. How often have experienced Product Managers with a packed roadmap and limited resource been advised to implement the MVP. Firstly though, let’s be clear about what it is: As previously discussed the term Minimum Viable Product historically comes from the lean start-up movement, probably in reaction to the slow and wasteful practices associated with waterfall development. As opposed to defining all requirements upfront, putting everything into development, then QA, then releasing (then scrambling to fix all the bugs and working up ‘phase 2’ because customers have moved on since all those requirements were written), the Minimum Viable Product approach gave organisations a framework and license to be quick and dirty, by putting together the bare essentials to get a product in-front of customers.

This could take many forms — It could be the most basic web page (or even a phone number) with services being hand cranked in the background. Tesco’s grocery home shopping service started this way for example: Customers were given a CD with the product catalogue and could submit their order that was then printed out and fulfilled by their local store (a world away from the robotic warehouses the likes of Ocado now have!). Whatever the implementation, the approach and desired outcome are the same: Put together the minimum service with the goal to validate with customer feedback as quickly as possible that you have something that meets a customer need.

If you find you are meeting that need, great, build up your product, normally by automating processes and scaling so you can start to make some money. Not meeting the need? That’s fine, pivot to where the need is if you can (and if not, you’ve wasted the minimum effort). Either way by the magic of malleable software and continuous development, you can iterate to build a successful product whilst minimising the risk. So, what’s the problem?

Lost Outcome

Just like the other frameworks mentioned above, the goal of the MVP is often lost or replaced with another. An MVP should be a stopgap approach that drives rapid learning and validates whether the product meets the anticipated need. The desired result is validation of the customer need, and then very rapid iteration to better meet that need and become profitable (or pivot). However, this is often lost in the excitement of being able to achieve seemingly more in less time. The learning outcome is replaced by other goals, often to complete as much of a roadmap as soon as possible and move on to the next thing quickly. Such feature led approaches are rife in organisations where success is measured in terms of the number of features shipped, and the MVP is a great vehicle for the feature shippers, you’ll get lots out of the door (whether that delivers value though is another question!).

Lost Iterations

Similarly, the subsequent iterations needed to grow an MVP into something sustainable and profitable are often lost. This is particularly true again of the feature shippers, in a rush to get down the roadmap as soon as possible (and keep everyone happy) a successful MVP isn’t iterated and either dies a death or becomes a burden. The MVP should be a stopgap approach that allows quick learning about customer need and won’t be sustainable (by very definition of being an MVP).

Lost Context

Finally, whilst a few lucky people get to blaze a trail by exploring new markets and new customer needs, most work in more firmly established areas with existing customer relationships that need to be treated with care. You know your customers. Revenue streams already exist. Customers can normally easily switch to competitors. They already have certain expectations of you. You stand for something.

If you already know your customers who are using your established product, why take the risk with their precious loyalty? There are other ways that involve less risk. UXR is an even quicker and cheaper way to start validating your idea — or even go gorilla and just ask people in the street. Alternatively, if you really need the in the wild validation you could only include those customers that are tolerant of new and potentially ropy things by running a Beta trial that customers sign-up to. Or if you’re investigating exposing existing customers to new services, brand them differently (Tesco did this with Tesco.com back in the day for example) or pitch it as a trial. Google had a host of services they’ve trialled and since shut down (like Google+) but they haven’t suffered much from the fallout, because like all great consumer brands they’re careful with their core offer and keep new services separate until they’ve proved themselves.

MVP Alternatives: MVaP (and other similar terms)

Don’t get me wrong, I’ve a fan of the MVP. But used for the right outcome, iterated and in the right context. It’s just like all useful frameworks, it has its place and can be used and abused. What alternative is there for developing everything as an MVP then? An interesting alternative is the MVaP which has gained some traction. The ethos of the Minimum Valuable Product (and other similar terms) is in essence a focus on the minimum work needed to deliver the value that you want. This is a much more flexible framework as unlike the MVP (focused on a learning outcome), the value delivered by an MVaP could be anything that is important to the organisation and map to any of its outcome metrics.

The MVaP helps to move the conversation to value, which is great, cos that’s what Product Managers are in the business of delivering. Definitely a step forward. However, why stick to focusing on minimum value? Because we still want to get stuff out the door quickly. That first word is a marker in the sand though, what if we have a few options that are more or less the same effort, one of which should deliver more value, why wouldn’t we focus on that? Why not challenge ourselves to aim higher?

Introducing the MVC — Maximum Value Creation

If we go back to basics (101 Product Management) when you put a backlog or roadmap together, all else being equal you put the higher value stuff at the top. And being a good Product Manager, you don’t just put that together every year or quarter, you’re constantly scanning your market to see if opportunities have changed and your priorities need to shift. Wouldn’t it be great if we had a simple way of talking about that with our stakeholders without rolling out all the Agile development life cycle diagrams? Wouldn’t it be powerful if we could use a common simple language to talk about all the great stuff Product Managers do to ensure stakeholders get the best bang for buck over time?

Well you could call it you’re in the business of maximising value creation. Your core role is to ensure that with the limited time and resource you have you maximise value creation (MVC). You’re continually making cost / benefit trade-offs on the roadmap, so you can deliver as much value as possible as quickly as possible.

By flipping the minimum value concept on its head and by following MVC you still deliver fast, as you’re constantly aware of the next thing and the diminishing returns of what you’re currently doing (you know that as you’re also regularly validating the value you’re creating, via UXR or other approaches) and you can switch development when it makes sense to start adding more value elsewhere. You’re aiming high but also efficiently delivering as your aim is to maximise. You have a longer-term view (and can avoid short term decisions introducing debt) as you’re looking to maximise value creation continuously and over time, not just in the here and now or project by project. You’re building a team, skill and capabilities to achieve maximum value creation over time and pursuing your vision which in itself is an expression of how you’re going to maximise value creation longer term. You select the right approaches to pursuing MVC, including using an MVP where there’s potentially high value to be had but you need to rapidly learn whether you can meet a customer need first.

So next time someone says you just need to implement the MVP, tell them you’re in the business of maximising value creation (you follow MVC) and you’ll determine the best way of delivering as much value as quickly as possible.