Communication is hard
A few weeks ago, my co-worker Marc Phillips sparked up a conversation among Rafters about MVPs and why the term MVP sparks such a range of definitions and emotions. Minimal Viable Product? Minimal Viable Prototype? Optimal First Release? We chatted about it for a while and I believe it boils down to a fundamental communication problem. Words mean different things to different people. Consensus is hard to achieve and harder to keep. Even simple concepts like success and failure become complicated, especially for things like an MVP. When we communicate, we often assume that the other person understands the communication the way we do. You know what they say about making assumptions, right?
Words themselves are a made up construct to convey ideas. Alone, words are abstractions. Combined, words can make up a story, an argument, an inspiring speech, a computer program, a mathematical proof, a love song; The list is enormous, and yes, computer programs and mathematical proofs are built using languages. Not really human friendly languages, but languages none the less. Let’s look at 2 particular words in the context of an MVP, success and failure.
What is MVP Success?
Success is typically declared when all key objectives defined for the MVP have been met. These objectives are subjective relative to the domain, such as higher customer satisfaction, more paying users, better projections or processes, etc. Whatever success means for the MVP in the context of the project, it shows the project should continue. It is a validation that elemental building blocks, when combined, make up something that creates value. Most MVP projects seek to:
- Create a proof of concept that validates the problem can be solved.
- Create a proof of concept that indicates the problem should be solved.
- Create a base from which we can iterate to get closer to the bigger vision.
Can an MVP really fail?
Now let’s talk about the word failure. To some, it’s a bad word, because it usually involves bad consequences. From a young age, fail means bad. If you failed a test in school, it’s bad. Showing it to your parents may be worse. What happens if you fail to file your taxes on time? However, in the context of the MVP it depends how you fail. Failing “well” and learning from failures often leads to success. The earlier you can find potential failure points, before you commit more resources to a project or cause bad things to happen for users, the better.
It’s not what you know, it’s what they think
There’s a fourth bullet to add to the list of MVP project objectives. Regardless of what you and your team learn from the work, the MVP must also convince those in charge of project funding that your idea is worth continued investment. The Scout Motto “Be Prepared” should always be in your mind. That means thinking about all the ways your current MVP might fail. It may be that you can’t gain access to deploy or that your cluster fails under load. Maybe a NULL character or a leap year with an extra day blows things up. The point is that if we talk about it aloud, document it and come up with a plan, then a failure isn’t all bad. Then failure becomes a learning experience that can make the MVP better.
Every potential failure we can identify and remedy before each MVP demo day increases the chances of MVP success. If we can’t gain access, find our own system. If there is a chance your application will consume too many resources, perform a heavy load test and harden against it. If you can’t get all the security CVEs fixed, document the risks. Don’t leave anything to chance. Any failure you can address before deliverable is 1 less thing that could go wrong when it counts.
Show progress early and often
A demo at the end of a two-week sprint is just another day for an established project. However, during MVP development the demo at the end of each sprint feels much harder. Why? Scope creep and task estimation are always a challenge, but during rapid MVP development, they can be fatal. Eyes are upon you, and the margin for error is slim. That thing you thought could be done in 3 hours all of a sudden takes 3 days because no one has done it before. Googling for the answers leads you back to the same Stack Overflow question you asked a week ago!
Fortunately, being prepared can keep demo day productive and drama free. Success means everything works as the reviewers expected. If there are known failures or system limitations, everyone should be informed prior to the demo. And I don’t mean 10 minutes before. Managing your failures well means managing stakeholder expectations well. This doesn’t mean there aren’t exceptions. If your MVP needs AWS to run and AWS is down, or the power in the building is off there are limits to what you can do. Well, for an AWS outage, I guess you could have a backup server ready or have slides ready with screenshots of what you would have demonstrated otherwise. The key to MVP success is to never be surprised by failure.
