Minimum Viable Piece of Crap (MVP...oc)

For those who are unfamiliar with the phrase MVP, that has been floating around the product design community for the past few years, lemme give ya a quick whats-what.

MVP stands for, "Minimum Viable Product" (not: Most Valuable Player - took me a while to grasp that one). It was introduced in around 2011 in a book called The Lean Startup by Eric Ries. It's a good book, still really holds up 3 years later, and is geared towards entrepreneurs trying to get a product out the public. At its core, the concept of MVP says that it's better to get something out than wait until a product is 100% feature complete. It also helps redefine what, "100% complete," means. In contrast, this is almost the opposite of putting out a Beta release.

Let's say you're building an app that has 20 features. If you follow MVP, you'll do an audit of them and decide which ones are must-haves and which ones can be pushed off to a later release (or dropped all together). This suite of must-have features is defined as the minimum viable product with the idea that some time in the future the other features will be added. It's a really nice methodology, because you can bring a more-focused product to market quicker and get things moving (startups need investors or at least users to survive).

So far we're good, I like the concept of MVP for managing a product release; I've even used it personally on Gearing the Market. Where it seems to fall short is in the steps past MVP. Frequently I see people asking important questions far too late in the process, like: What happens next? How do these future features affect the MVP feature set? How do we scale this experience? Like most problems I've personally had in the Lean Startup method, this one seems to boil down to yet another communication problem (YACP?). We all suck at communication, it's ruining the product and making people write ranty blog posts.

Talk to each other

I've always been an advocate of bringing the representative product team into every meeting, especially the developers (unless the product you're discussing never actually has to be built...). Everyone should discuss every piece of the project to better understand the long term goals, but of course each domain expert should be making their own final decisions. The project manager will make final timeline decisions, the designer will make final design decisions, and the developer will make final development decisions. Why? Because they're the only ones qualified to do so. I don't make recommendations to my dentist about how she should clean my teeth and I certainly don't question my mechanic about the type of brake pads to use. I might have a conversation with both of them about my options, but ultimately you trust the expert. Same deal in product meetings. That's why everyone needs to be there, PMs and Designers are no more qualified to flag something as a, "development decision" as developers and copywriters are qualified to label something as a non-essential UI element. You never know when these situations will come up so why not just grab the entire team for a 30min meeting rather than having to hear about it secondhand? Ever play telephone? Same thing, but far less humorous.

I don’t make recommendations to my dentist about how she should clean my teeth and I certainly don’t question my mechanic about the type of brake pads to use.

Whenever you're in a meeting and you hear someone say, "Oh that's not information the designer/developer needs," you should throw coffee in that person's face. All information on a project is important. All of it. And the only person who can reasonably say that information isn't important to a designer... is a designer (same for the developers... I love you too). It's damn near impossible to make the correct decision on a project without all the information.

If your product features are: A, B, C, D, E, F and MVP is A, B, C, make sure you build A, B, and C with D, E, and F in mind. That can be done with nothing more than a conversation about D, E & F before a build starts.

Heck, one of the ways to make an introvert feel included is to invite them to things. You know most of us have been labeled introverted by society (I hate that term, but it's true). Team members feeling included + a better product... seems obvious to me. Correct me if I'm wrong, of course.

Communicating with MVP

The root of the MVP problem lies somewhere under the mask of communication. The product owner (usually a CEO or Founder) has all the features and blue sky scenarios in his/her head and through the course of a meeting to pare down the product to a reasonable size some of those features get pushed off and slowly but surely the minimum viable product is formed. So far everything is great.

The newly formed MVP is brought back to the design and development team for execution. They design and build it perfectly based on the MVP specifications. What happens to all the features that were pushed off? They're rarely communicated to the execution team., but eventually they do need to be added to the product. From someone who has been on both sides of that conversation, you can't plan for something (in design or development) if you don't know it exists.

This is when products get out of hand, and fail over the long term (in my opinion). MVP goes great, and then you hit a point where you either need to start from scratch to really add new features in a responsible way as to not "crap-up" the experience OR features start getting piled on and hacked together until inevitable failure.

MVP for a cake isn't a cake with no frosting, it's a cupcake. That's great but try and scale that cupcake up to a full size cake and see what happens.

In reality, this form of failure could have been easily avoided by having a conversation or involving the entire product team in the initial process.

In Closing

Don't get me wrong, I do think MVP is a great way to get something to market quickly (I really do - the whole Lean Startup methodology is outstanding and Eric's book is great), but beyond that, if you want to give your product the best chance to survive (assuming it's a good idea), you need to look past the basics of a "minimum viable product" and, for lack of a better term, "minimum viable team" to circle back to a good ole' conversation and getting shit done.