Feasibility study is out, MVP is in!

It is essential that we get to grips with new technologies. But what is the best way to do this? If a lot of time has to be invested to get to know a new technology, possibly by a team, then the classic way is the feasibility study (proof of concept, PoC). But be careful, especially in today's fast-moving world, we can easily tie up resources with studies without really making any progress. And there is a better alternative, an MVP:

The problem with the feasibility study

Feasibility studies are problematic for several reasons:

• They take place in an artificial environment and can therefore only make a limited statement about the business benefit: they merely show that something is feasible.
• They often focus on the technology: functions, compatibility, etc.. In doing so, they lose sight of the added value of the technology
• It is unclear what will happen next. Even if there are metrics to decide whether the feasibility study is a success or not, is it clear what happens next?

The better way: MVP

The alternative to the feasibility study is a MVP, Minimal Viable Product. An MVP is a minimum viable or viable product. It is important that an MVP already creates value for the stakeholders.

For an MVP to make sense, it must be used to help stakeholders. This is one of the most important differences to a feasibility study.

MVP cannot replace the feasibility study everywhere

The feasibility of many things can be studied and not every feasibility study should be replaced by an MVP. Systems engineering is usually about the feasibility of (1) new features in customer products or (2) completely new products.

The former can be realized through agile approaches. One example of this is Extreme Manufacturing. With this approach, almost all newly manufactured products differ from one another, albeit often only in the details. At Wikispeed, for example, the vehicle is developed, tested, built, certified and sold on a weekly basis.

Feasibility studies are also used for areas that do not involve the development of a product. One example would be the selection of a modeling tool for the team. In such a situation, we can only carry out a feasibility study, as we cannot demand a customized MVP from the tool manufacturer. However, if we commission development for an internal tool or even carry it out ourselves, then an MVP would be exactly the right way to go.

Conclusion

Of course, we will still need feasibility studies for certain situations in the future. But in systems engineering in particular, we will probably make much faster progress with MVPs.

In the worst case scenario, we carry out ten feasibility studies a year in the company and then go bankrupt due to outdated technologies...