In the context of Lean principles the Minimum Viable Product is known in those circles as the MVP. For most, the use of that term is used liberally and sometimes even dangerously to represent a finished product. The problem arises when there’s an expectation well beyond actual possibilities at the time of creation, and of course within reason, nobody knows what to expect until the product is completed. For this we are using the acronym HPE to represent High Product Expectation. 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. We are describing HPE as the opposite spectrum of what an MVP is meant to have when it comes to expectations.
The above sounds like common sense, but many projects from time and time again, are built with ridiculous expectations at the contractual level and with that they are signed with the expectation that a minimum viable product will be built, even with the utmost transparency. This is not a problem in and of itself, but this step is seldomly explained or taken seriously during the different stages or phases of a project from beginning to end. We tend to take the process for granted that should we actually “do things properly” that it all will turn out well. Sure it’s all in good faith, but most projects start with best intentions, however how they end, is a different story. Actually, the only real moment the customer starts to ask ‘serious’ questions about what is 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, 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. Most 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 won’t necessarily be any surprises when the end of a project arrives. 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 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 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, 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 created those changes to the original ones. You may be surprised to find out it’s not the same people who are behind the original ones; more stakeholders 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 (with little or no knowledge on 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 happen in a project over time.
[Image courtesy of jscreationzs at FreeDigitalPhotos.net]
The post The Dangers of MVP with High Product Expectations (HPE) appeared first on The Agile Times.
