Alternate Acronyms to Inspire Great Work!
Disclaimer: Some of what I’m about to say here doesn’t really apply if time is NOT on your side – or a hard and fast market driven deadline is staring you in the face.
I’m going to propose some ideas here that are controversial but that’s ok, hopefully the discussion and the end result will be worth it. This also might challenge some of the notions you have about Running Lean, or Lean methodologies, and that’s ok. I have read a handful of books on lean approaches and feel like they have merit so don’t want to discount those.
One of my favorite references here is that instagram waited two years while refining their iOS app before developing an android version of their product. I also worked on a product with Intel and Oakley that despite the pressure to get “something” to market early, took the time to develop the product for 2 years before announcing it to the public. If they can wait to get it right before trying to scale so can you.
The ideas and putting it into practice however are often two different things. IRL the process can get a little messy.
A couple of quotes to get us started:
“the plan is the plan until it is not the plan” – Chris Croteau, Intel
“the plan is useless, but planning is indispensable” – Dwight Eisenhower
“nobody ever plans to fail, they only fail to plan” – my Dad
As a UX person the last thing you want to hear is that product leadership is focused on getting the MVP out the door. If you don’t have a UX capacity in your organization then I get it. Releasing an MVP into the wild will somewhat fill the gaps that a UX team would and you’re likely to get some insights and learning. But I feel strongly that if you have a UX team in house then consider one of these as an alternate approach.
- Invest just enough development resources to support an MVP in the form of a POC. If your PDM (product manager) has a relationship with a client who is willing to work with this alpha version POC and provide feedback then this is great. Once validated you can get that on the production roadmap.
- If your product is an app or new app features then release it in a control group via TestFlight, get it out to up to 2,000 people and observe how it performs. Fire up a private Facebook group for users to share feedback.
- You have a UX team in-house, and you pay them to do their job, let them test and validate feature viability and empower them as key stakeholders in your product development process
- Triangulate your research efforts. You’re still in the definition and design phase here and if you can line up qualitative feedback, quantitative data and market analysis you can get a good gauge if you’re on the mark.
- Don’t wind up in the vicious cycle where people aren’t using your product, you ask them what features are missing, you build those features and still no-one uses your product.
As a UX person it’s second nature to put myself in the customers shoes and ask myself why I might care about this feature, or this function. Just for a second though think about this from the perspective of your customer, are you willing to tell them:
“this [product] is fully equipped with the minimum feature set we were willing to invest in before asking you to pay for it, don’t worry though the next version will have more limited features, at which time we might charge you again, the software might break, you might lose your data, or the update notification just won’t go away. Thanks”
Nobody wants that, people want to know that it was thoroughly thought through and tailored to their needs, or they will buy it, return it, throw it away, cancel their subscription, tell their friends it sucks, download it and delete it or a number of other actions that result in consumers discrediting your brand.
Finding Your North Star Vision
The number one thing your release should be focused on is getting to market with feature functionality that is:
- Desirable – identified by an expressed customer request who is willing to pay you for it, or an observed market insight and opportunity
- Useful – as a utility it provides a core functions that simplify my life, or it converges other product solutions into one and save me time, or somehow elevates my social status because I own it
- Usable – ergonomically or otherwise simple and straightforward to work with
Set your sights on a North Star Vision for your product. That is the optimal and ideal outcome you are aiming for and hold that close, communicate to your team, publish it, print it out, post it on the walls, print T-shirts, whatever it takes. Bake that into the culture of the team you are working with. Back that vision up with market analysis, research, observation, interviews, and data. Arm yourself with the ammo to back up the decision for this vision and get the team excited about going in this direction.
Frankly it’s hard to get excited about the MVP. In big bold letters the MVP says “HI I’M THE WORK YOU STARTED LAST WEEK, THAT YOU’LL CONTINUE TO WORK ON NEXT WEEK, AND WILL BE HERE IN SOME FORM FOR WEEKS ON END UNTIL NOBODY CARES ANYMORE”. Super exciting right?
Of course you need to be open to new findings along the way. If you have a leadership team aligned with a good UX team that can craft the narrative and vision you’re trying to achieve you’ll be in a good spot to pivot or persevere when necessary.
People at this point start to fear the word “waterfall”. I’m here to say that the MVP is is a myth, and waterfall is not a bad word. The waterfall will never go away, the C-suite and shareholders will always work on a strategy, evaluate their infrastructure and resource needs, communicate that to their lower level managers who will further distill it to the people doing the work. The point is that the plan and tactics will come down line and ultimately wind up in development and some level of design and definition will always be the “tip of the spear”.
How MVP Thinking is Failing You
Before we get into it, let’s think for a minute about the MVP. Contrary to the world of sports where it refers to the most valuable player, (which would seem to make sense when you consider that you want to go to market with your All-Star bringing their A-game). In software development however it is somewhat the opposite and defined as the minimum viable product.
If you think about the semantics of it you are subconsciously setting the bar incredibly low, and communicating that you’re looking to do the least amount of work to “just get the job done”. There are so many things wrong with this thinking I’m not sure where to start. I’ve heard directors and executives declare that “we’ve got to get something to market asap, because something is better than nothing”. If that’s the case for you then it’s hard to reason with a person in that state of mind. Simply because they are acting out of fear.
The next statement you’ll hear is “fail fast, take risks” and we’ll iterate our way to success. Again, I’ve seen people lose their jobs because they “failed fast”, or have taken risks that have bombed and well, it all rolls down hill. Product managers and UX leaders typically have the most at stake when it comes to the credibility of their successes – which is why they fight so hard for taking to market the right solution, even if it takes a couple more sprints. They know that if they lose credibility with consumers the product is dead in the water.
Returning to the coaching analogy, when I think of the psyche that surrounds the MVP terminology it conjures up the image of a coach sitting in a locker room with a team at half-time saying something like this, “thanks everyone for showing up today, glad to see you could all get your uniforms on, since the score is currently tied and no one is injured we can go ahead and call it a game now and you can take the rest of the day off. We’ll come back next week and put in just enough effort to do a good enough job.”
In Jeff Gothelf’s book “Lean UX” he makes a reference to a creative director he worked with who challenged this thinking with something along the lines of “going for the bronze”. I’m probably quoting him out of context here but the essence of where I’m going is that I believe engineers, designers and product owners aspire for more.
I’m not alone on this, and there are a handful of thought leaders in our industry moving this direction. I’m merely proposing we stop using terminology that encourages complacency.
“we ship on quality” – from how Spotify builds products
Introducing the CVP
If you follow the approach above where you build out your MVP in order to test it’s viability and get validated learning with a control group you shelter yourself from significant expense and risk. Interaction and Industrial Designers (IxD / ID) have tools at their disposal to build reference prototypes or wizard of oz scenarios very quickly with little infrastructure. How is it that engineers refer to it, something along the lines of “when I write a line of code I’m creating technical debt”. IxDs and IDs are typically happy to produce prototypes and iterate toward a solution.
When I worked at Thunderhead inc. based in London we followed this model and aimed to take to market a CVP (Consumer Viable Solution), the leadership and product management team there were huge advocates for user experience and understood that getting it wrong was a risk they weren’t willing to take. Fortunately when I was also working at Intel in partnership with Oakley they felt strongly that going to market with the right product without sacrificing quality was a core pillar of their brand.
Since being exposed to this notion of the CVP I’ve carried that forward in other roles that I’ve had with mixed reactions. Essentially if your company is risk averse then they will be perfectly comfortable with an MVP mindset. If you want to push past the competition and grab that ever so valuable consumer mindshare then I’d encourage thinking about going to market with a CVP.
Creating a Set of GMR Guidelines
So, if you can get on board with MVP’s being an iterative step toward developing a CVP or consumer viable solution then let’s introduce another acronym to the mix. GMR stands for General Market Readiness, this is a set of criteria that you set for yourself or that might be set for you in order to distribute your product. In some cases that may include security, or privacy guidelines, compliance with Apple app store policies or those that are set by a regulatory oversight group.
Setting aside those criteria you must comply with I’d encourage you to think about the GMR as a final set of acceptance criteria for your release candidate or product.
Some criteria could include:
- This feature / functionality is developed in response to a customer request or validated market opportunity
- This feature / functionality is marketable and has parity with and key differentiators from our competition
- This feature / functionality promotes operational efficiency and production or organizational scale
A Paradigm Shift to the way we Work
I can’t take full credit for suggesting this model, but if we consider the acronym RACI, which stands for Responsible, Accountable, Consulted, Informed we can start to look at how we approach the MVP and CVP differently. Think of it as a relay race where you pass the baton from one individual to the other. Depending on your role on the team, at different points you may be responsible or consulted based on where you are in the project. Early on leadership will be accountable for defining a strategy, UX will be responsible for research and prototypes to support that strategy, engineering will be consulted to evaluate resource or infrastructure needs and program management will likely be informed.
“Protect your ugly babies” (Ed Catmull, CEO Pixar)
I love this quote from Ed Catmull in Creativity Inc. The important thing is that you have your [product’s] best interest in mind. You want to see it succeed and provide it with the tools necessary to do so. Protect that idea until it has a chance to blossom and take on a life of its own. You wouldn’t watch it fall down, and therefore determine that you shouldn’t teach it to walk. You might try a different approach, mixed with encouragement, and some assistance.
The thing that worries me about taking the MVP to market is the misconception of validated learning. On smaller teams that have no UX or design team in house, there is a tendency to think this may substitute for concept testing, or usability testing. “We’ll get real data that we can react to”, some might say. While this is partially true, the data is biased, skewed and in order to make informed decisions based on it you should correlate it with the rest of the picture. How does this align with your persona’s, your market segment, use cases, value proposition, user expectations, perception, as well as the metrics you’re aiming to drive.
Sticking with this “protect your baby analogy”, shipping the MVP then pivoting based on user feedback without the bigger picture in mind is like having someone else tell you what’s best for your child. The truth is that what customers say they want vs what they do are typically miles apart.
As a UX professional I have a hard time accepting that you can get valuable feedback from your consumers when you release a partial solution to the market and look at the numbers without talking to the people. People will react to your partial product without the context of your larger vision and you will get feedback that will likely take you off course. Again – do release an MVP to a control group, this gives you a way to filter the bias and respond to the feedback with focus, but protect yourself from the market risk of going to production with it.
Ultimately I’m not proposing that we truly do away with the term MVP or that it can’t be a valuable way to work. I’m simply proposing that we think carefully about where it gives us the most value in terms of taking great products to market and elevate our thinking to include the CVP and GMR criteria. I believe that almost everyone on the team wants to produce a high quality product or experience that people love.
So yes, let’s ship on quality, protect our ideas and aim for delivering Consumer Viable Products.