Hias Wrba: Opportunities instead of problems

Mathias "Hias" Wrba gave a keynote speech on the topic of MVP - Minimum Viable Product - on the 2nd day of Modern RE in Munich.

The keynote was very entertaining and I took a lot away from it. However, the most important point for me had nothing to do with MVP. Instead, he made an inspiring suggestion, namely to think less about problems and more about possibilities when it comes to requirements.

What is an MVP?

I had heard about the "problem" of MVP before. It often leads to confusion that there are contradictory definitions of MVP. One definition comes from Frank Robinsion from 2008, according to which an MVP is:

MVP: A product that is as small as possible but big enough to generate engagement, customer satisfaction and sales (Frank Robinson)

In other words, an MVP maximizes the ratio of ROI to risk.

This contrasts with the definition by Eric Ries (Lean Startup):

MVP: Collect as many validated insights as possible (Eric Ries)

It is pointless to ask who is right - it is a question of definition. But that's why it's important that everyone in the team has the same understanding of what is meant by MVP. I used to be a supporter of the first definition and called the second prototype. But as I said, a common understanding is important.

Henrik Kniberg's advice therefore also makes sense, the term MVP is best avoided.

Building to earn vs. building to learn

Three rules of thumb

We need MVPs to maintain an overview in these times of rapid change, uncertainty, complexity and ambiguity. Hias has given us three rules of thumb to follow:

Since there are so many uncertainties today, a rough goal must be kept in mind, but developed in small steps, with frequent adjustments, for example through demos. Nothing revolutionary, that's the idea behind Agility.

This is not revolutionary either: the result for the user should drive the development, not the technology or the economic viability. The background is that a suitable business model can certainly be found for something useful, which then also enables the technical implementation.

This rule surprised me, and was - at least for me - the most valuable thing from the keynote.

In requirements engineering, it is always said that the problem and the solution should be carefully separated. This is true, but is the problem really a problem?

He cited the "problem" of energy shortages as an example. One solution is to produce more energy. But perhaps the problem would not be a problem at all if, for example, energy demand could be reduced.

It could now be argued that we are only looking at two possible solutions (producing energy or reducing consumption) and are therefore back in the classic requirements analysis. Nevertheless, I like the term "possibility" much better than "problem". Incidentally, this approach comes from the designer Host Rittel.

Conclusion

Hias gave an entertaining keynote speech, particularly thanks to his entertaining style. What was said was not really new, but it is certainly not wrong to remind ourselves of these things.