In the context of Lean principles the Minimum Viable Product is known in practice as the MVP. For most, the use of that term is used liberally and sometimes even dangerously when used to represent a finished product. The problem arises when there are expectations well beyond actual possibilities at the time of signing, planning or initial sprint. Of course with reason, nobody knows what to expect until the product is completed.
Defining HPE
We are using the concept HPE as an acronym to represent High Product Expectation. In this context, High Product Expectation is what the client expects as the finished product right from the start, with the additional possibility of more features. As you could guess, the MVP should never be equal to the HPE. By this we mean that you should never expect the completed product as an MVP to have a full set of features and attributes.
MVP Expectation Pitfalls
The above sounds like common sense, but many projects from time and time again, are built with ridiculous expectations at the signing of a contract or initial product specifications, they become sealed with the expectation that a minimum viable product (MVP) will be built, even with the utmost transparency. This is not a problem in and of itself, but this step is seldom dived into or taken seriously during the different stages of a project from beginning to end. We tend to skip through the process, whether through ignorance or negligence, and as a result take for granted that should we actually “do things properly” so all will turn out well. This could also be from a lack of negotiation, rush to get started, because after all, everyone acts like there could be a ticking time-bomb that could go off at any time. Certainly, time of is of the essence, and nobody wants to lose out on the opportunity cost. But the loses incurred down the road would be best prevented at the very beginning.
The Lessons Learned and Questions Asked
In the end we could all be optimistic, and rely on good faith, but most projects start with best intentions, and how they end is a different story. Actually, the only real moment the customer starts to ask ‘serious’ questions about what was expected to be built, ends up being at the end of the project, or at signoff. Not to confuse, “definition of done” with actual “completed product,” but these terms may eventually be intertwined as well, and could be used at times of disagreement, leading to a never-ending cycle of argument, discouragement, disbelief, loss of trust, loss of morale, and just plain waste of time. The client may have had another understanding of what the MVP was. It is very likely they thought it just meant the “first version” of the product. That is where things can go seriously wrong.
Certainly if agile principles and methodology are being practiced properly, there shouldn’t be any surprises when the end of a project comes. We all know too well, that expectations or better yet “defining expectations” has no bounds. When it comes to meeting expectations, there’s a lot of politics, assumptions, and a lot of finger pointing as to who expected what and for what dollar amount, especially when there are hidden agendas.
So when we talk about MVP, we need to ask the client important questions like:
“What are you willing to accept?”
“What are you really looking for?”
“What are the features you’d be willing to let go of if there we run out of time or budget?”
“Who’s expert opinion is being questioned?”
“How much time do we have to learn about what the market wants?”
Preferably these are questions that you should ask at the very beginning, but definitely consider re-asking those questions and bring out those assumptions throughout the project, from sprint to sprint. The Product Owner or Business Analyst should be keeping tabs on these questions, but relevant questions should always be asked over and over again, with emphasis to determine those expectations. Keeping track of those answers is also key to making sure those expectations are met. You may eventually notice that the answers change as each sprint, stage, or phase is completed. With those changes you can eventually challenge why there have been changes and assumptions, in the hopes of getting those answers and dig deeper to find out who’s behind them, perhaps gaining some extra transparency. Don’t be afraid to ask who’s expectations (or assumptions) created those changes to the original ones. You may be surprised to find out it’s not the same stakeholders who are behind the original ones; more people may have gotten involved, or maybe switched in or out of the project.
With these basics covered, you should be able to gain higher levels of understanding on what the client was expecting. But to further this understanding, you should be able to gauge whether or not the client was setting them too high to begin with. Put differently, if the client had high expectations (HPE) at the beginning of the project (i.e. little or no knowledge of what they were going to get from the MVP) it would be unlikely for the client to lower their expectations by the end of the project. If expectations were described as a type of force, this explanation would represent a metaphoric ‘inertia’ that tends to increase in a project over time, once in motion it does not diminish.
[Image courtesy of jscreationzs at FreeDigitalPhotos.net]
Share this:
This work is licensed under a Creative Commons Attribution 4.0 International License.
