Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

MVP Is a Marketing Exercise, Not a Technology Exercise

DZone's Guide to

MVP Is a Marketing Exercise, Not a Technology Exercise

Odds are that even as a developer you've heard the acronym MVP bandied about. Read on for some commentary on how this term is causing confusion in the industry and what can be done about it.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

MVP is a marketing exercise, not a technology exercise.

Image title

… Minimally Viable Product

Possibly the most fashionable and misused term in the digital industry right now. The term seems to be used by one-side-or-other to criticise the other.

I recently heard another Agile Coach say: “If you just add a few more features you’ll have an MVP” – I wanted to scream “Wrong, wrong, wrong!” But I bit my tongue (who says I’m can’t do diplomacy?).

MVP often seems to be the modern way of saying “The system must do.” MVP has become the M in Moscow rules.

Part of the problem is that the term means different things to different people. Originally coined to describe an experiment (“what is the smallest thing we could build to learn something about the market?”) it is almost always used to describe a small product that could satisfy the customers' needs. But when push comes to shove that small usually isn’t very small. When MVP is used to mean “cut everything to the bone” the person saying it still seems to leave a lot of fat on the bone.

I think non-technical people hear the term MVP and think, “A product which doesn’t do all that gold plating software engineering fat that slows the team down.” Such people show how little they actually understand about the digital world.

MVPs should not about technology. An MVP is not about building things.

An MVP is a marketing exercise: can we build something customers want?

Can we build something people will pay money for?

Before you use the language MVP, you should assume:

The technology can do it. Your team can build it. The question is: is this thing worth building? –and before we waste money building something nobody will use, let alone pay for, what can we build to make sure we are right?

The next time people start sketching an MVP, divide it in 10. Assume the value is 10% of the stated value. Assume you have 10% of the resources and 10% of the time to build it. Now rethink what you are asking for. What can you build with a tenth?

Anyway, the cat is out of the bag, as much as I wish I could erase the abbreviation and name from collective memory I can’t. But maybe I can change the debate by differentiating between several types of MVP, that is, several different ways the term MVP is used:

  • MVP-M: a marketing product, designed to test what customers want, and what they will pay for.

  • MVP-T: a technical product designed to see if something can be built technologically – historically the terms proof-of-concept and prototype have been used here.

  • MVP-L: a list of MUST HAVE features that a product MUST HAVE.

  • MVP-H: a hippo MVP, a special MVP-L, that is the highest paid person’s opinion of the feature list. Unfortunately, you might find several different people who believe they have the right to set the feature list.

  • MVP-X: where X is a number (1,2, 3…), this derivative is used by teams who are releasing enhancements to their product and growing it (in the pre-digital age we called this a version number). Exactly what is minimal about it I’m not sure, but if it helps then why not?

  • MVP-M is the original meaning, while MVP-L and MVP-H are the most common types.

So next time someone says “MVP” just check, what do they mean?

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
mvp ,agile ,minimum viable product ,application development process

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}