In Support of Plain Language
Tuesday, May 27, 2025
I was trying to understand the MVP for a project, and the Business Analyst kept telling me, “We don’t do MVPs.” Obviously if you’re delivering a product you have to know what the minimum set of features are that will work for the consumers… only it turned out the term MVP had been so abused (as it often is) that it had lost its meaning.
She was pleasantly surprised when we talked later and understood I really meant a minimal set of FUNCTIONAL features, not the bloated corporate wishlist that the term MVP had become. She still wouldn’t call it an MVP but we did include in the epic some acceptance criteria a paragraph that described functionality (without specific solutions) that would allow us to demo and begin to socialize the product.
You know, an MVP…
For the most part I try to avoid jargon precisely because it often makes things more confusing. Sometimes the same acronym might mean different things to two different people, often our stakeholders aren’t all technical and don't know the terms. Jargon and acronyms are great shortcuts but they aren’t always clear, and honestly, this stuff is complicated enough without requiring a cheat sheet.
Some terms have simply changed over time. The new terms refer to exactly the old things, and sometimes it’s just convention. At some point data in flight became data in motion. I'm not sure why, and yes, you can find people arguing that one is better than the other but we’re just talking about data moving from one place to another.
I understand the societal reason to drop backlog grooming in favor of backlog refinement, although I don’t expect dog groomers to drop the term. But now, the word backlog itself is starting to be considered negative and some teams are using the term prioritization. What I find amusing is that we have the same disagreements over the actual ceremonies around who gets to do that prioritization and what actually happens in the process even if we agree to a new word.
Perhaps, one of the biggest reasons words are dropped is from the words being actively misused, or intentionally abused. I’m talking about words that have lost the original intent (like MVP) that are almost triggers for teams with PTSD.
Technical Debt has been used as a performance indicator in teams rather than an objective view of current code and standards. It’s not what we meant originally, we simply meant, “If I ever have to revisit this code, I’m going to have to change this thing.” Not even “fix this thing” but “change.” Now it's used as a bludgeon or a way of placing blame when, honestly, it doesn't matter WHY the thing needs to be changed.
Before I get to my core point about terminology fatigue, I can’t stress this enough – EVERYTHING you use has tech debt. You’re going to have to sharpen your kitchen knives, you’re going to have to change the oil in your car, you’re going to have to upgrade your laptop to run new software. It’s basically entropy – it’s nobody’s fault it’s just the fact things change and what works today won’t work tomorrow.
But because someone started using the term in a different way, i.e. to put blame on tech teams and to try to squeeze out another emergency coding session, engineers simply, and rightfully, do NOT want to use the term tech debt.
There are also words that just sound dated, like synergy or terms that were aspirational, but missed so badly (cloud-native comes to mind) that some people are likely to chuckle when they hear them.
So, in my role as a problem solver, one of the first things I have to get around is language. Yes, I know the tech terms, but I don’t always know your context for those terms. I know business terms like OKRs, KPIs and metrics, but the people I work with may have adopted slightly different applications of those terms (I personally would never apply an OKR to a team, but I have heard compelling arguments for why you might).
As we engage on larger and broader projects that encompass more stakeholders from tech to business to outside consumers, using plain language to define pragmatic solutions isn’t just a management style, it becomes absolutely necessary just to understand each other and, hopefully, avoid some of those tiggers.