MVP - Experiences and Pitfalls

Agility and New Work
#1

Hi there,

Over the years, the usage of MVPs (Minimum Viable Product) became more and more common in the agile world. The idea is to learn about customer’s demands and behavior by quickly releasing products without bells and whistles instead of extensively developing a product without knowing details about the actual demand. In order to learn something from the MVP it is necessary to make changes to it to see how the feedback changes.

The challenge is to make the MVP viable enough to actually learn something from it and minimal enough to reduce the development time.

Personally, I like the MVP concept a lot, because it allows you to quickly learn about customer demand. However, in my experience it is challenging for teams not to just focus on the “minimal” and forget about the “viable” part. Also, actively changing the MVP to gain new insights can easily be forgotten.

I would like to learn about your experiences with MVPs. Do you like the concept? Do you have recommendations for developing a successful MVP?

1 Like
Agile Advent Calendar: 24 ideas around Transformability
#2

Hi there.

The downside of being a senior software developer is to fail a lot over the course of time. As failure has it, it also generates major learnings. In my professional carrier I experienced working with MVPs often as something that did not quite match the wording “minimal”, or “viable”, or seldomly even “product”.

From my point of view, one of the reasons was because some stakeholders’ expectations dominated too fast the idealized outcome rather than grasping the core aspects of the product-to-be. I’d like to share my experience with a concept that is not that young but worked out

User Story Mapping as means of distilling an MVP backlog

Then I learned about User Story Mapping during an agile workshop - for me a profound experience. I’d like to describe this workshop in brevity so I can present my argument:

In a group of 3-5, we broke down a seemingly trivial task in terms of user stories over several rounds. Our task was to build an imaginary product around the theme “Wake up and arrive at work” and, when finished, to present our user story mapping thereof.

So we started to gather a large backlog of tasks represented as user stories mainly because each group member’s daily routine differed just so much. Every round the moderator asked us if our task board included to course user stories or stories that could be shaved away if we REALLY REALLY REALLY were in a hurry.

The outcome was in my eyes amazing because the group achieved way more than I expected. My group started to concentrate on the most basic stories rather than throwing ideas in a hat and letting the imaginary developing team do the fickle rest. This allowed us a broad perspective which in the end could resemble a solution seen from a user’s eyes.

Result

What we built was the main line of stories that solely consisted of the utmost necessary stories in order to run the task. In my eyes, that story map was comparable to stories that would make an excellent MVP in a granularity or even clarity which I missed in other real-life MVPs.

Of course, we collected quite a detailed view of aspects being left out. I count that as a bonus because some gained insights to tasks that were oblivious to the other members of the group.

I am aware that a workshop is something different than a day-to-day development routine. That being said I still see it as an incredibly wonderful measure to see through the eyes of different stakeholders in order to create something small enough to see it running quickly.

A note on Event Storming:
My experience of this workshop may sound like Event Storming (which also has its own justification). Telling from the resulting user story map, we did focus on a finer granularity than on high-level aspects in order to gain a working “product”.

#3

Hey Boris,

I like the approach of User Story Mapping to really get to the core and create a minimal solution. However, I think that the challenge is to find the minimum that is just viable enough so that users can benefit from it and hence allows you to gather enough information to improve the solution.
If the solution is not viable enough, users are not interested in it at all and you don’t get any feedback.

And just because you mentioned Event Storming, this link might be interesting for others: How to do a Remote Event Storming – hands-on recommendations | Cloudogu Blog

#4

Hello all

In a time when digital products are becoming easier to develop and can get to market quickly, MVPs are an important tool - which unfortunately is often not fully understood when it is being used.
I agree with Daniel’s statement that MVP are more than a product with minimal features and I agree that it is very important that the product should already deliver real value to the users. This way you already achieve a good product on its own but not necessarily an MVP.

However, for this to become an MVP, in my oppinion, the solution should be based on a hypothesis, which needs to be verified with real data (for example: is there interest in the product at all, is there a market, etc.) and the product requires monitoring in order to collect the necessary data.
MVPs are not without risk as they walk the fine line of publicly testing a good idea in order to derive next iterations from the results without revealing too much to potential competitors.

2 Likes