MVP — Not a 3 Letter Licence for Cutting Corners

MVP. A three letter acronym, that easily slips off the tongue and has the magical ability to give you licence to cut corners. At least I believe that is some people’s perspective of it.

Minimum Viable Product

It has been about 10 years since this term came into common parlance in agile development after featuring in Eric Ries’ book “Lean Startup”. Personally, I think it is a fantastic approach and is quintessentially agile. It is all about delivering the minimum piece of functionality at a viable level of quality in order to learn from it. Teams can then use those learnings for the next iteration. It is ideal for trying concepts out with consumers, and gaining that feedback to evolve the product.

Misuse of MVP

People use this term incorrectly however, and possibly because it is wrapped up in a nice acronym, they don’t really need to think about the proper meaning. There are a couple of ways I have seen this manifest itself.

Scenario 1

“Using service x is not the right approach, it is going to be retired next year, there are more appropriate services to use, it is going to impact application y and have risk z. Essentially this is just poor design.”

“Ahhh but this is just MVP, so that’s the way we are doing it. We’ll change it down the line”

12 months later, nothing has changed with the MVP. No feedback has been sought. No iterative improvements, just a poor quality process in production inevitably impacted by the retirement of service x.

Scenario 2

Teams wanting to deliver something, anything, to be able to say to more senior people that your team have delivered. In order to do this they chime out the old MVP term. Simply by referring to it as MVP enables you to justify poor design choices, and gaping holes in logic.

You may be able to get away with not thinking through designs of MVP and cutting endless shortcuts. Best case scenario, it works and you can improve it down the line. However, the worst case scenario, you have learn nothing from it, introduce technical debt, cause failures, open up security flaws, and leave yourself open to legal action.

Breeding Technical Debt

Poorly considered, rushed MVP deliveries that are not truly MVP, leads to a myriad of Technical Debt scattered throughout production.

CCHQNCCFIIOTLAA

I propose we stop using the easy term MVP and instead use a stupidly difficult term that you have to completely stop and think through what you are saying. CCHQNCCFIIOTLAA — Carefully Considered, High Quality, No Corner Cutting, First Iteration, In Order To Learn And Adapt. It’s a lot harder to try and justify your short cuts in a meeting when you are saying “oh its just CCHQNCCFIIOTLAA so….”

When is your delivery truly CCHQNCCFIIOTLAA?

You have solid design.
You are not saying “ahhh we’ll fix that massive flaw later”.
If your team disbanded the day after delivery, the code is robust enough for long term in production.
You are not introducing any security concerns.
You are not introducing any legal concerns.
You are not causing undue risk to existing functionality.
You have a solid plan in place on how you get the necessary feedback.
You have a timeline for when you are going to seek that feedback.
It is high priority on your backlog to then act on that feedback.