In the beginning I would like to stress that this is not yet another article about Minimum Viable Product (MVP) mechanics. For theory and examples of its use in practice, please refer to the great article by Andrzej Winnicki. What made me share my thoughts on MVP is what I consider a prerequisite to start working with this method. Moreover, I also recognised this prerequisite as the biggest obstacle which is stopping many enthusiasts from fully understanding it.

In Agile world everybody talks about MVP. We all use it, we all care about minimising time to market and delivering just the right product to customers, and we are all aware how crucial the concept is in ever-changing market conditions. Product Owners plan their businesses so that they can monetize them promptly, scrum masters help teams understand the importance of customer feedback and developers learn how to build a solution using mocks and metrics tools (as it is practised in cases of mvp based development). That would be the theory. In practice, as an Agile Coach I usually hear from developers and product owners that it is a waste to build something small and indeterminate only to receive feedback, especially if it is known already what we are trying to build. Well, hard to argue with that. Unless we investigate such claim deeper. “Known already” is a phrase that grabs my attention.

For a quick reminder, I like Eric Ries’ definition of MVP: “The Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” What is more, apart from learning purposes and discovering what the market really needs, MVP is also about delivering value faster. And as I see it now, the mysterious “value” is what makes MVP so difficult to understand at “Ri” stage (practitioner’s level, where what you have learned is already natural and done automatically with space to question and evaluate against own experience and beliefs; Shu-Ha-Ri – concept describing stages of learning to mastery).

I’ve recently come back from a trip to Thailand, where apart from beautiful sceneries, cuisine and people, I also encountered a beautiful example of MVP. In Bangkok I stayed at a guesthouse that had been newly opened to visitors. What it offered were obviously rooms to sleep in but not much in terms of extra facilities. Instead of reception desk there was a school table in the middle of a foyer (frankly speaking, it was not a foyer per se), instead of a bar there was a refrigerator in a corner and a coffee machine on a basic table. As I see it, once opened to first customer, decision on where, how big or how organised a reception desk should be, would be made in the future depending on guests’ needs and number. Same with the bar - at this stage, the owner does not know whether people would only sleep at his place and maybe occasionally buy some refreshments or if they need extensive bar area serving different dishes and variety of drinks. It is still possible to arrange foyer space according to actual demand, but the key customer need (aka value) is already being met – visitors have beds to sleep in.

I found this example so great because majority of my debates about MVP described in the first paragraph of this text ended with an agreement from scrum teams that the concept is indeed desirable but not for common, simple goals with well known outcome, such as houses, bridges, new billing and vindication system, e-commerce application etc. Here comes “well known” expression again. If you stop for a moment and reflect why you are building a new self-managed job portal, complex data grouping dashboards or a brand new chat client, which archives everything, you might realise that the features you plan to offer are not the actual customer needs, or that you grasped the needs right but there are many more ways to meet them than you first planned. “Well known” outcome is not so well known, it is barely what you have in mind thinking about one initiative.

Whatever you are currently working on, think first what value you want to deliver to your customers, and only then move to planning how to deliver this value fast. A bridge may seem to be a well-known outcome of a project. However, depending on a value you want to deliver, it can take so many different shapes. Let’s say the need is straightforward and it is built solely to move across the river. It can still be done in multiple ways based on users (pedestrians only, vehicles, mixed, heavy machines), based on volume, frequency of traffic, climate etc. What is more, let’s say that to move across the river you actually do not need a bridge, because you may offer much cheaper or fun or efficient means of crossing i.e. boat, stilts, catapult, floating rags or zip line. On top of that, now imagine that the need to meet was not crossing the river, but prestige of investor, or a desire to build anything on one’s own, or a need to explore what is on the other side but with no need to physically be there. Now the alternative shapes of the bridge become almost infinite.

In order to capture this unique value your customer has in mind starting the project, I find it useful to apply coaching techniques. Dilts’ Neurological Levels Model, Cartesian Questions, change of perspectives, all of these techniques may serve to search inner motivation, to validate what and why you want to achieve. Such approach is essential to understand your customers’ needs, what is the hidden value one wants to obtain. Based on this value, you can now search for numerous approaches you can pursue to deliver it. Once you find them, only then start applying techniques that help in innovative and dynamic environment by verifying hypotheses, e.g. Minimum Viable Product. Minimum is this tacit value and the next crucial step is to plan your work so that you deliver end-to-end product soon. Small and prompt delivery enables you to verify whether you grasped this need correctly and to adapt your plans accordingly.

To sum up, it may feel like constant verification of what is needed, how it was understood and what is real vs. assumed. Indeed, I believe that assumptions are detrimental to any business and we should not only listen to our customers but also understand them. Searching for an apprehension of customer value and what kind of needs we are trying to address is a step closer to success.

If you would like to add anything to this post, inquire or simply comment, please go ahead and do that. I am more than curious to get to know your experience and reflections.