Everyone knows the ‘Most Valuable Player’ acronym, but you may not have heard the term ‘Minimally viable candidate’. At first, it doesn’t sound too good, but let’s explore.
The Minimally Viable Candidate
I was first introduced to this term a few years ago when I was asked to participate in creating some certification exams. There was a professional company helping us (the test creators) understand the parameters of how to write good exam questions. For example, you cannot make up stuff in the answers just to trip someone up – but you could write answers that didn’t apply to the scenario, but where correct (i.e. you can’t make up a PowerShell cmdlet, but you could use a real one that has nothing to do with the scenario). The goal was to write it to weed out unqualified candidates.
The MVC is the person who is qualified, but just enough to pass the certification. There has to be some line drawn, and that’s the target for the level of complexity in the exam. In other words, they are qualified, but barely. This is true in all professional fields – you may have a doctor who just barely made it, but they are still qualified to be a doctor. Of course, we all like to think we’re working with the best and overlook the spectrum of quality that really exists.
Why do I bring this up? Lately, I’ve been leading design discussions with customers and a have a similar conversation around a ‘minimally viable product’.
Minimally Viable Product
Aim for the moon, shoot for the stars, never settle..the list of idioms goes on and on. I argue that this is great for having a lofty goal..but in reality when you need to get things done, this perfect state often becomes the paralysis of the perfect. When I lead design sessions, I often start with a simple framework of understanding current state, and envisioning a perfect end-state, then look at logical transition states. Understand that we may never get to the perfect end-state, its more of a true north or a sounding board to measure progress. It may be too costly, or more difficult than originally planned. Or, as we get to a closer transition state, we re-evaluate the end-state and it may change altogether.
Like the MVC, the concept of a minimally viable product doesn’t always feel good when you first hear it. We are conditioned to do our best, and planning for less feels like failure. It is in fact a tool to get started and realize value sooner. I’ve seen many projects that fail to launch since the scope cannot be locked in, and every detail must be accounted for.
In software projects, this is often the difference between a waterfall model and an agile model. With waterfall, the envisioning and requirements phases are completed before moving to the next step. By the time you get to implementation, often the benefits of long development times are lost, or the requirements have changed (or missed as its hard to know everything you want in the beginning). The agile model seeks to use quick sprints to deliver value quickly, and implement a less than complete solution, using iterations to over time deliver a fully flushed out solution. This is not just reserved for software project, most of my engagements are infrastructure or business transformation focused. They also suffer from the same challenges.
I help customers think and plan for what is good enough to go ‘live’ with whatever it is we are working on and overcome the fear of deploying with something that is less than perfect. I’m suggesting rather than the OnePlus motto of ‘Never Settle’, maybe be more like Nike and ‘Just Do It’. This approach is useful in many other aspects of life. Looking to hire someone? Consider the MVC rather than waiting for the MVP.