I’m teaching a Product Owner workshop this week, and I had an insight about a Minimum Viable Product.
An MVP has to fulfill these criteria:
- Minimum means that it’s the smallest chunk of value that allows us to build, measure, and learn. (Yes, Eric Ries’ loop.)
- Viable means that the actors and users can use it.
- Product means that you can release it, even if to a small, specific group of test users.
My insight came when I was discussing with the class how their data moves through their system. Think of data like an onion: there are an inside kernel and concentric rings around the inside. (If you prefer, a cut-down tree, but I like the onion.) Often, you start with that inside and small (round) piece of value. You then add layers around it every time you do another MVP (or Experiment, if you’re prototyping).
The data has to do a round trip. That’s why I thought of it in circles like an onion. If you only implement half (or some other part) of the entire round trip, you don’t have the entire circle of minimum functionality.
The image above, where you see the feature go through the architectural layers, might be a better image.
The actions that the user — whomever the user is — has to go into the system and come out. In an MVP, you might not have a very thin slice all by itself, but it still needs to be a thin slice.
When I think about the idea of the onion, I think, “What is the smallest piece I can define so we can see some results?” That’s the idea of the MVP.
I realize that MVPs might be useful for the team to learn about something in a small test environment. The smaller chunk of value you deliver, the more experiments you can run, and the faster you can learn. Maybe the idea of the onion or the round trip through the feature will help you think about your MVPs.