When’s the last time you worked towards, accepted, and released a Minimum Viable Product?
Minimum. The least you can do. No more than absolutely necessary.
I’ve often felt this is one of the more difficult concepts to get momentum behind. This has long baffled me. The logic feels very sound to me. Deliver the smallest complete product that delivers value, gather feedback on it, tweak the direction of the final product, and deliver the next smallest complete product delivering value based on this new direction.
Side effects of doing this properly include less time spent on things the market doesn’t care about, increased customer satisfaction with the product, faster ROI, and greater team satisfaction. Why don’t teams and companies want this? I can’t claim to have all the answers, but I have a couple of ideas.
In the United States children are taught to do their best, never give up, always finish what they start, and the list goes on. The idea of haphazardly putting together something that barely passes muster goes against the culture. Of course, that’s not what MVP is truly about – but it sure can feel that way.
By the sheer nature of the word “Minimum”, the concept is already facing an uphill battle for acceptance. Minimum doesn’t delight customers. Minimum doesn’t win awards. It’s not a market leader. From early on we’re told to do our best, not the minimum. The problem here is that a false narrative has been accepted as true, that minimum is equivalent to rushed, shoddy, or some similar term.
It’s not a hard narrative to accept. A minimally cleaned house isn’t a nice as a house that’s been given a solid two-day spring cleaning. When someone does the minimum required to build a dog house and their work is put next to the work of someone who went above and beyond, almost everyone will pick the latter as best.
The problem lies in what happens before that moment of presentation, and the context of the presentation. That house? If it was being cleaned out for a remodel then the spring cleaning becomes overkill and wasted money. That custom doghouse which went above and beyond took weeks of labor and hundreds of dollars of materials. The simple one took an afternoon and $50. If the goal was a doghouse to sell for under a hundred bucks, which is more likely to succeed?
A minimum viable product isn’t about avoiding doing what is best, it’s about finding what is truly best instead of pursuing what is assumed as best.
That leads us to the other thing I feel we fight against when we try to push for an MVP approach, a little thing I like to call BDUF – Big Design Up Front.
Of course, this is near the core of what Agile methods and practices are fighting against. It’s the mentality Agilists mean when we toss around terms like “Classic Project Management” or “Waterfall.” The fight here is against the idea that a product can be completely planned out from day one and succeed. Instead, we try to embrace the fact that we cannot know until we do some testing, and producing an MVP is part of that.
Imagine a dart competition. Two people each with an identical dartboard. They both stand 20 feet back with everything needed to assemble darts. They are given an hour to make a bullseye. Those classic approaches would include taking a lot of measurements and spending a large amount of time creating the perfect dart to throw and get the best score possible. The have an hour to produce their product, so they will likely take an hour to build it. The agile approach eyeballs it, puts together a passable dart, throws it, modifies their design based on the result, and throws again. They do this as rapidly as possible for the entire hour. At the end of the hour, there’s a chance the first team will get a better score, but it’s a small chance. The second team is much more likely to get the better score.
This is the point of an MVP. You get something that will at least meet the need, gather feedback on how well it meets the need, adjust based on feedback, and make proper modifications to get closer to the “right” solution.
There have been many numbers tossed around about what percentage of a software solution doesn’t get used. I’m not going to quote any as Abraham Lincoln once told me anyone can make up anything on the internet. I do think we can all agree there’s a level of truth in those numbers, and if we look hard enough there are a couple of studies behind them somewhere. I only bring them up because this what MVP is fighting. Whatever that percentage is, that’s the percentage that was more or less wasted work by the team creating the software. With an MVP approach, the team will get enough early feedback to lower that percentage dramatically. The goal is to eliminate that number completely. The reality is that we get a little closer with each step of our journey.
Properly utilizing the concept of an MVP is only one of the things I can help your team learn. I’d love to help your team move to the next step in its agile journey. Contact me today to discuss where your team might benefit from an outside coach and trainer.
