Photo by Nick Fewings on Unsplash

Product has a language problem. And we need to fix it.

We undermine ourselves with loose terminology and hand-wavy definitions

Every profession has it’s own language precepts and terminology. Legal, Medicine, Dentistry, Engineering, Epidemiology, Finance, Project Management etc. all have specific terminology to clearly identify important and common concepts.

And even if you’re not in those professions, you’ve heard some of those terms and may have an idea of what they might be: Burden of Proof, Chapter 11, Idiopathic, Relapse, Comorbidity, Vector, EBITDA, P/E Ratio, Critical Path and Opportunity Cost etc.

And while some terms, like the legal term Habeus Corpus, have a very specific meaning and could not be misconstrued with any common language terms, other legal terms like Brief and Claim, which have common language equivalents, also have specific definitions in law that are unambiguous and widely understood. e.g.

Brief: A written statement submitted in a trial or appellate proceeding that explains one side’s legal and factual arguments.

No one is going to confuse a (legal) brief with any common language meaning of the word brief.

The benefits of precise language

And why do these professions have these precise and well-defined terms?

Because precise language fosters:

• clear communication
• minimum ambiguity
• alignment
• better focus on outcomes

Seems like a good idea…no?

If we (in Product) want to move our profession forward, a profession that itself is defined by deep understanding of customer and market problems, and finding focused and specific solutions, how can we justify loose language and ambiguity in the work that we do?

Language in other professions

Consider the following:

“I have a motion to dismiss with prejudice that I would like to file on behalf of my client, but I need to ensure that we have standing and jurisdiction before proceeding.”

contains a number of specific legal terms, but every one of them is easily understood by other legal professionals and there is no ambiguity about their individual meanings, nor that of the entire sentence.

Consider this from the medical profession:

“We need to get this patient to the operating room immediately. She has a grade III splenic laceration and is showing signs of shock. Start an IV, administer a bolus of normal saline, and call for a surgical consult.”

Any trained medical professional would hear this and know exactly what is being requested.

In both cases, you could go to ANY court or ANY hospital and those sentences would be understood exactly the same way, without ambiguity. A new lawyer at a firm or a new doctor in an ER wouldn’t have to ask any questions to know what was expected.

But in Product, things are different

And yet, if you look at Product Management, we’re almost in the opposite state. Consider the following that one Product Manager might say to another in a meeting:

“I think it’s important for us to prioritize feature development based on customer feedback and data from user testing. Can you create a roadmap that outlines the MVP and subsequent iterations, taking into account dependencies and resource constraints?”

If this was said in 2 different companies, what are the odds that it would be understood and executed the same way? Roadmap? MVP? Iterations? Prioritize? Are any of those terms understood in the same way across different companies?

Let’s take “Roadmap” as an example, and forget about understanding across different companies. Even within the same company, or same team, the word “Roadmap” will have very different definitions.

To some it’s a plan of exactly what will be delivered in the next few sprints. To others, it is what should to be delivered in the next couple of quarters. And to others it is a statement of direction for the product, tied to objectives and strategies.

And each of those interpretations leads to different sets of actions to create a “Roadmap”, and implications on how it will be used by the Product team and the rest of the company.

The language we use and how we interpret it defines how we work. THIS, is a really important point to understand.

Most of the key words we use need further explanation and certainly a new Product Manager in one of those companies hearing this would require a lot more context before knowing how to proceed.

But…But…But…

Now I know what you’re thinking. This is really not a fair comparison. There’s no way we (in Product) will ever be as precise as doctors or lawyers etc. Their work is more structured. In Law, a court case is a court case, and in Medicine, a human body is a human body etc.

And you’re right. Our work is not as specific as that of doctors and lawyers, but what about Finance, Sales, Marketing etc.? They don’t seem to have the same language problems we have. Here’s a marketing example. How much ambiguity is there in this text?

I’m planning on launching a new email campaign targeting our existing customer base with a drip campaign strategy. Can you help me create a segmented list based on past purchase history and create an A/B test for the subject line to maximize open rates?”

Yes, there are some questions to be answered before someone can execute on what is stated, but it’s clear to everyone what will be done to a good level of specificity. It’s not like the definitions of A/B test or open rates are completely different in different companies.

Now if we go back to the Product Management example, terms like MVP and Roadmap could be interpreted VERY differently by different people in the SAME company, let alone different companies.

And it’s not just MVP and Roadmap that are poorly defined and interpreted very differently by different people. Here are a few more:

• Product Market Fit (PMF)
• Persona
• KPI
• Product Vision
• Value Proposition
• can you think of any others

These are not rare or esoteric terms. They are part of the core terminology of Product Management.

Heck, there isn’t even a commonly understood definition of Product Management itself. How bad is that?

But let’s dig into MVP as an example.

An experiment

Try this experiment at your work: Ask every member of your team to write down the following two things and then share them with the group:

1. Their definition of MVP
2. The objective of MVP

I bet no two are the same.

MVP—Most Variable Principle

MVP is such a wonderfully clear term that numerous people have tried to redefine it with replacement terms such as:

• MVP — Minimum Valuable Product
• MVP — Minimum Viable Prototype
• MLP — Minimum Lovable Product
• MMP — Minimum Marketable Product
• MSP — Minimum Sellable Product
• MVE — Minimum Viable Experiment
• MAP — Minimum Awesome Product
• RAT — Riskiest Assumption Test
• Have you heard other variants?

First off, kudos to the creator of RAT — Riskiest Assumption Test — for not sticking with the herd and for defining their own term, trying to make it meaningful and descriptive.

Second, it should be obvious that any term that has caused so many people to create so many variants to “fix” the term shows how problematic it is.

Third, from its very earliest incarnation, MVP has been confusingly defined.

Frank Robinson

MVP was first defined in 2001 by Frank Robinson and later redefined and popularized by Eric Ries.

Robinson described it as:

“The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.”

I’ll be honest. This is both motherhood and apple pie, and severely problematic. Every single line there is questionable. i.e. what does “Technically, it is the product with maximum ROI divided by risk.” mean, let alone, how would you even measure that? Maximum ROI — based on what?

I won’t get into the rest of the paragraph here. Ask me on Linkedin or in the comments and I will dig into it further.

Few people heard of Robinson’s concept, but one of them must have been Eric Ries.

Eric Ries

Ries popularized MVP in his Lean Startup model and book. You can see from the chart below (Google NGram) that the term grew in usage starting in 2009.

Google NGram of “Minimum Viable Product” starts in 2009 and grows from there

Back in 2009, when Ries was first talking about MVP, he stated the following in this interview:

“The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to gave you feedback on.”

There are several problems here.

The first is that, similar to Robinson’s definition, this is also basically motherhood and apple pie: “just those features and no more” that “at least *some* [early adopters] pay you money for”. Yeah. Sure. Who wouldn’t want that at the start?

The second problem with this definition is that it’s such a lagging indicator — people don’t just pay you money right away. They need to learn about the product, evaluate it and then decide if a purchase is necessary. But you have to build the “features” in advance of their purchase, and the only real way to know what is valuable is to do a lot of discovery, assumption testing, and experimentation in advance.

The third problem is it will likely take multiple product iterations until you deliver “just those features and no more” that people will pay for. If so, what are all those previous iterations called? And what are those iterations AFTER that one (MVP) iteration? What are they called? You see the problem?

Releases over time. What are the releases BEFORE MVP called? What are the releases AFTER MVP called?

The MVP is not a milestone of any kind. At best, the MVP is just a transient state in the process of building your product, and thus, itself rather meaningless.

But…But…But…

But in the VERY SAME interview, Ries describes MVP in a very different way. He says, when talking about a feature that failed to get traction:

“What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.

What we would have found out if we were doing that experiment is 0% of people would have clicked through, which means it doesn’t matter what is on the second page.”

So in this case, the MVP is NOT “just those features”, but a set of experiments to test some assumptions they had about some potential use case or capability. e.g. a landing page, some AdWords, an offer etc.

So an MVP, in this case, is NOT a product in any sense of the word.

So which is it? A product with “just enough” features, or a set of experiments? And if the answer is both, then the answer is none.

It’s much better to call an experiment an experiment. In fact, Ries’ landing page/Adwords/offer example is absolutely logical, but then why rename experiment as MVP?

MVP in use

The reality is that MVP has become a term that means different things to different people and it’s pretty obvious why. Just look at the definitions above from Ries himself.

It’s much better to use specific words that have specific intent and align to specific actions and objectives. They provide much needed clarity and alignment.

A major goal in product development is risk reduction. While we live in a world of uncertainty, we need to identify assumptions and risks and work to remove enough uncertainty so that we can make good decisions.

In this context, I point to Rich Mironov’s article — I’ve abandoned MVP.

It’s worth a read, but Rich recommends using specific language and specific objectives at each step along the product development path.

Concept Test — Have we identified the right root problem? Can we learn what’s really broken and test-close a few imaginary solutions? etc.

UX test—Can sample users complete a task? What inputs are we missing? etc.

Engineering concept validation — Will X work? Does it blow up our cloud servers? Can we find actionable signals in the data? Is our architecture sensible? etc.

Technical beta test — See if a few friendly customers can get an early product version to work at all (for free). What can we learn about their environment? Where do they get stuck? etc.

Early Adopter Program — Provide a (mostly) complete version of the product to a few early customers who have specific needs addressed by the new functionality. Upon completion, have them be a sales reference and purchase the product (possibly at a discount)

You may have (slightly) different terms for all of these and that’s fine. The point is while NONE of these is an MVP, all of them could be, depending on people’s loose interpretations of that term, and yet all of them are VERY different.

So, as Rich says at the top of his article:

I’m advising all of my clients and product leader coachees to stop using the term “MVP”. Not to stop doing validation, discovery, prototyping or experiments they may associate with that acronym, but to remove the label from all of their docs and presentations and talks. To delete the letters MVP from roadmaps and product charters. To banish it from their vocabularies, not let it cross their lips.

I couldn’t agree more.

So let’s bring precise and intentional language to the Product profession. MVP isn’t the only term we should abandon. We should also stop using other ambiguous terms like Product Market Fit.

And let’s come up with solid, precise and unambiguous definitions for other necessary terms (e.g. roadmap, product vision etc.). It will only help us and help our fellow Product professionals improve our craft.

Saeed

A little feedback please

If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take just 1 minute, but will really be valuable to me. Thanks in advance.

===> Click Here <===

Update — Dec. 2023

Jeff Gothelf wrote this on MVP. — hhttps://jeffgothelf.com/blog/stop-saying-mvp/

Disclosure

The legal, medical, marketing and product language quotes referenced in this article were generated via ChatGPT using the following prompt:

Please give me a meaningful sentence that a <lawyer/doctor/marketer etc.> might say to another <lawyer/doctor/marketer etc.> that contains terms that are specific to the <legal/medical/marketing etc.> profession

In all cases, I used the 1st response provided by ChatGPT.