Having worked in and with companies that are in the middle of some sort of “agile transformation”, I have found myself explaining MVP on multiple occasions. This topic usually involves the famous “Skateboard to Car” example and is usually met with a general head-nodding and seeming understanding. But several weeks or months later, I usually end up in a situation with the same person where they clearly can’t get on board with building the skateboard and I can’t understand why.
Finally one time, I had a person say what so many others in the enterprise are probably thinking: “Why are we messing around building the skateboard when our competitors already have the car and we’re going to build the car anyway?” Suddenly I realized where the breakdown was. It wasn’t just that people didn’t understand the value of building the skateboard. It was more that they assumed the skateboard was just an interim step to build the car that they wanted to build in the first place. What they really wanted was an MVP that was more like a Kia progressing to a Mercedes...always a car, but just less fancy.
To really build an MVP, you have to be willing to stop at the skateboard and admit you might not need the car at all! Too often we go into a project with the solution already in mind, and anything pulled out of scope for MVP feels like a “loss”. We go into an MVP thinking of it as an early draft of an already known end state, and get mentally committed to the car to the point where we can’t admit the skateboard is doing exactly what is needed.
We get to this point when we start with solutions, not with problems. Too often the conversation is, “I want to build a feature that lets users chat with each other” and then we back into the “why” to justify what we’re building. We should be starting with the outcomes we’re trying to drive, and then figuring out what solutions will make that real. You never know - the skateboard may just be enough.