The Challenge: Our customers have needs: one of them is how to manage smart metering reliably and efficiently, especially cost-efficiently. They want a solution that fulfils their needs. As software professionals, we have excellent ideas on how to do this, of course. So what’s the challenge?
The challenge is in understanding the customer’s needs, rather than just delivering what he or she wants. Imagine that we build a system according to initial customer requirements without discussing and collaborating with the customer: In the end, we have built (hopefully) a beautiful cathedral, when the customer needed a nice parking facility. This leads to big and expensive refactoring in the end and is a waste of time, money and energy. And we are trying to avoid waste.
So our challenge is twofold, and this post focuses on the first:
1. The Right Problem: learning what the customer needs, in addition to what the customer wants.
2. Efficiently delivering what the customer needs.
Here I define efficiency as minimizing the total time, money, and energy for the lifetime of the product. This includes new features and bug fixes.
Getting the requirements right in the beginning is challenging, but not impossible. More often than not, the initial requirements get refined, changed and sometimes completely overhauled during the development process. This happens because during development we gain more insight into the specific customer needs. What if we could embrace this change, instead of trying to avoid it?
Minimum Viable Product
In our case, we would like to learn the actual customer needs so that we can deliver a solution for the right problem and minimize waste. One good way to do this is to start working on a Minimum Viable Product (MVP), as defined by Frank Robinson.
MVP is not an end goal in itself. Rather, it is a mindset and a way of learning true customer needs. It fits nicely with the lean and agile way of doing things: iterations produce a new MVP, which is ideally one step closer to the final product. In other words, it enables us to fail fast if the approach we have taken is not viable.
Collaboration with the customer is the key to learning whether the MVP is heading in the right direction and to solving the actual problem. As Yevgeniy Brikman says: “The only way to find that out — the only way to test your assumptions — is to put your product in front of real users as quickly as possible.” I must emphasize that collaboration with the customer is bidirectional - it is a dialogue where we try to work out the best solution together.
The black path in the image is a path to the target end product (green circle) using MVPs and an iterative approach. The orange line shows a path where implementation is based on initial requirements and no feedback is gathered during development: only at the end is it discovered that this is not what is needed. The effort required to get to the target is much greater, because the work done has been heading in the wrong direction from the beginning.
MVP is a viable solution. It should work and answer the customer’s needs within the given requirements: both functional and non-functional. The given requirements here are worked from the initial set of requirements, by splitting them into smaller self-contained requirements. Usually it pays off to start with the requirement containing the biggest uncertainties. This gives the maximum feedback early on.
MVP is minimal. It has the minimum set of functionality that is required. Refactoring a minimal solution takes less time and money: if we have produced a garage, it is easier to start refactoring towards a parking facility. The more bells and whistles the solution contains, the more time and effort has been spent on it. The more lines of code there are, the more bugs there are (but lines of code is not a measure of minimalism here).
Finally, the MVP is a product. Ideally it should not contain too many rough edges, it should behave well, and it should have useful interfaces (both APIs and user interfaces).
Implementing MVP
What does a good MVP look like? Here are two figures, of MVP A and MVP B. Both are minimal, but there is a clear difference. MVP A implements a thin vertical slice of each element, whereas MVP B implements a thin horizontal line of the Business Service element. For a nice example, see Joe Armstrong’s blog post about the Erlang Ticket System (he is one of the inventors of Erlang).
MVP A is a proper Minimum Viable Product: it implements a minimum set of features through the full stack, so that the whole approach can be tested and evaluated together with the customer. It provides a vision to the resulting system, which can be adjusted based on feedback. Further, each implemented element is an MVP on its own.
MVP B is not a proper MVP: The UI, Integration and Comms Services elements have no implementation at all; furthermore, it tries to implement only half of each feature in the Business Services element. It is minimal, but not viable: it is difficult to use and test, making evaluation with the customer difficult or even impossible.
Conclusion
Rapid prototyping and iterative design using the MVP mindset brings several advantages. We have a full stack product from the beginning, which is usable and testable. By working together with the customer we learn the true problems in the customer’s needs and can solve them. The product can be changed during development as required.
Do note that this is not a silver bullet: especially collaboration between the customer, product management and developers requires a lot of effort and commitment from all parties.
