Who’s the real MVP? The MVC!


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

Image result for never settle oneplus logo

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.

Consulting 101


Lately, I’ve been working with a lot of new hires – many are college hires with zero real world experience. I occasionally get an opportunity to mentor them, or sometimes it’s a consultant struggling on the job.  Mentoring people is something I have done on and off during my almost 20 year career at Microsoft and I enjoy it.  The good news is that I’ve made a lot of mistakes in my career, so you don’t have to, and I share them without hesitation.

Here are the top 3 things I tell new consultants to master first.

1. Deliver on What You Promise


This is easily my #1 rule.  If you make a promise to do something, do it.  Don’t try to make the mistake of over promising with just the hope of delivering.  If you fail to deliver, it destroys trust and confidence people have in you.  You are far better off setting realistic expectations and meeting them.  Its fine to set a ‘stretch goal’ and be clear its not what you are committing to.  If you find that you are likely unable to meet your commitment – let everyone know as soon as possible to reset expectations.  You probably can do this once.

2. Don’t Go Dark


This easily goes in the top three delivery sins.  For some reason a consultant just disappears – they don’t tell the customer, their manager, or the project manager. Emergencies do happen, that is understandable, but I’m referring to someone who does this repeatedly.  I’ve not had a customer ever complain of over-communication in this scenario.  These days we have to manage multiple active projects, so its important to set expectations up front like availability, working hours, response time for emails, etc.  I can only guess why this happens – for me its usually due to an uncomfortable situation.  Not responding or being clear actually just makes matter worse.  People may not like your answer, but they will be much more upset if you don’t respond and they think you are in agreement.

3. Documentation

docuementsThe final tip is to document everything.  You never know what the future holds –  project owners change,  things fail well after the project ends, personality conflicts, and honest miscommunications. The only thing you will have to defend a decision or work you did will be a written record. As much as I hate to write status reports – these are critical to chronicle decisions, risks, work completed and other project information.  If you have a decision made over a phone call or in a meeting, follow up with an email summarizing and ask for confirmation this was what was said or agreed to.  Plan for the time it takes to deliver some form of documentation for any work you do.  Sometimes on really short engagements its easy to walk away without ever handing the customer any documentation. Even if it’s some up notes from meetings, clean them up and socialize them.

I learned this the hard way on a project that went sideways, and when they brought in “the Wolf” to fix things – I had no documentation or status reports.  I could have had all of my hours stripped away – which ultimately would have made me miss my delivery targets and put my job in jeopardy.

Get Started

That’s it.  If you can at least do these three things you will have established good habits that will serve you well.  Once you are consistently delivering – we’ll cover some other habits in a future post.

Bonus Homework

I just completed a course on Coursera: Presentation skills: Speechwriting and Storytelling (a great class by Alexei Kapterev, who authored ‘Death by PowerPoint’).  In one of the section resources was a link to a video of Mike Monteiro’s Keynote from a design conference (forewarned, Mike uses colorful language).  In his presentation he talks about the top mistakes designers make – and many of these are really applicable to consulting as well.  Once you make it past my top three – I would check his content for some more great tips.