In my years of experience I have been learning about a bunch of methodologies, processes, frameworks, concepts, and so on. While applying something we learned, we can face the advantages and disadvantages of it, and we can also see that some technics work for some situations but can be terrible for others. Therefore, I have this habit of looking at tools and technics in a way to find the best generalization of it, and how it fits better to solve the problem I have in my hands.
Although I believe the introduction above could be used in many posts here, my focus in this one is on MVPs. Everybody knows what’s an MVP, right? Minimal viable product. And I’ve seen people using MVP in its most basic concept: a minimal product that can already be valuable for the business. I think it is a too limited view of a powerful tool. I will try to tell you a bit of how I think that going deeper into its concept and generalizing it could empower a product.
The main change in how to treat a MVP for me is to use it to test hypotheses. It doesn’t matter if we are talking about a new product or a new feature, the MVP can save money, time, and effort if used in the right way. The problem is that there is no recipe for this right way to use it. This depends on the hypothesis you wanna prove, the problem this hypothesis is targeting to solve, the users, the business model, just to mention some.
You may be thinking now that I am just changing the wording here to make it look like another approach, but it is more than that.
Let’s suppose we want to release a new feature for an existing product. What I usually see people doing is finding the minimal scope in which this new feature can be released and make a MVP out of it. This would give us the expected output: the new feature. What I am suggesting here is to change completely the focus. To be more didactic, I will break it down in the next paragraphs.
First, I would analyze the new feature to see its outcome. If this new feature showed up and was prioritized it means that there is a problem we are trying to solve here. When we focus on the output we are looking for the feature we idealized. The advantage of looking at the outcome is that we are looking at the impact of this feature. How does it solve the problem? How does it impact the users’ behavior? What are the impacts on the business results? If this feature was a request from users, we are going to evaluate the problems or difficulties they face on the system instead of just the desired output. It is not easy for users to visualize what they need or want, if we look for the impacts on their interaction with the system we will deliver something more valuable. In this brief elucidation, can you already see how outcomes can be measurable driven? This is what testing a hypothesis means to me, with measurable results to check where to go next.
The next topic is related to how we could strengthen ties with different processes and methodologies we have in all sides of an agile team, targeting even more benefits of each one of them. For instance, it is typical in agile developers teams the use of CI/CD. I am not going to go deep on what it means or how it works because it is too technical and I would not do it well, but Continuous Integration and Continuous Delivery (CI/CD) allows developer teams to deliver changes more frequently and more reliable. Going back to our feature example, we have a scope of the outcome we target with MVP. It will be translated into some stories for the developer team. Why do we need to have all the MVP scope done to start testing our hypothesis? I know that not all stories that are done will give us a concrete result to work with, but some of them can, or maybe a couple of them together. Perhaps it can already be used internally at the company to give us the fist measurable results of it. It can bring valuable changes, or even cancel a feature designated to fail as soon as possible.
To close it up, I would like to bring back the generalization I mentioned in the introduction. In general, I see that we tend to get too attached to the concepts of a methodology, or the definition of a concept, or the mandatory steps of a process. And we forget the principal propose of all of it: help us to be more productive, to fail fast and recover faster. We need to look at technics in a way to extract what can work better for the problem we are dealing with at the moment. One thing that still makes us, humans, better than machines is our ability to generalize. Looking into a technic beyond the theory, understanding its propose, and generalizing it to work as it is needed in the current scenario we have. Don’t say that’s not an MVP because it is not a minimal viable solution and does not make us a user focus company, instead sees as a way to give you a better outcome at the end and really make a difference for users.