One of the biggest challenges product innovators in established companies face in defining an MVP is getting buy-in from internal stakeholders.
These could be senior execs, peers, other departments, partners, or even your boss.
You might say, “This is all about politics, and that just comes in the way of innovation.” That’s being naive.
You might say, “Consensus driven product development kills creativity and innovation.” You’d be right, but I’m by no means advocating a “decision by committee” approach.
You might say, “Internally defined products with no customer input leads to lousy products that fail in the market.” That statement is correct. I 100% agree with it. But it’s not the whole picture.
The reality is that product managers and corporate product innovators have multiple internal constituents to manage.
It is imperative that they somehow make everyone feel a part of the process. Else, they risk their product idea being run over, shelved, sidelined, destroyed before it’s even left the concept stage.
I call these folks internalvangelists.
So how do you get internal traction on your product idea? How do you get buy-in on your customder-driven MVP without it getting railroaded by others?
How do you build traction internally and develop these internalvangelists?
You use good old fashion product management techniques. Specifically, by leveraging a process every Product Manager should know: roadmap prioritization.
- Setting strategic goals
- Objective prioritization
- Shuttle diplomacy
These same pillars can be used for defining an MVP and getting stakeholder buy-in.
Setting Strategic Goals
The first step is to capture your product strategy. You can use the Product Canvas to get started.
What’s great about the Product Canvas is it allows you to document your vision in a simple, portable and shareable way on just a single page. The trick is to be concise. The intent isn’t to capture every nuance of the customer’s problems, nor detailed requirements. Just stick to the top 3-5 problems and the top 3-5 key elements of your solution.
This forces you to not only sharpen your thinking, but also your communication with stakeholders. This, in turn, encourages more constructive feedback, which is what you really need at this stage.
You’ve probably received a lot of internal input (solicited and unsolicited) on features for your product. Most have probably been articulated as “must-have’s” for one reason or another. Of course, you know that most of them are probably not really needed at this early stage, certainly not for an MVP.
To quote from the book Getting Real by the founders of Basecamp: “Make features work hard to be implemented. Each feature must prove itself.” For an MVP, each feature must be tied to tangibly solving a top customer problem.
Bruce discusses using a scorecard type system to objectively prioritize features for product roadmapping — in particular, assigning a value metric for a feature’s contribution toward the product’s business goals, and balancing it against a level-of-effort (LOE) metric. The exercise can easily be done in a spreadsheet or using almost any product management software.
A similar approach can be used to prioritize the features for your MVP:
1. Rank each Problem documented in your Product Canvas in terms of your understanding of what is the customer’s top-most problem to be solved, followed by the second, etc.
2. Map Solution elements to Problems. These may not necessarily be one-to-one, as sometimes multiple elements of your Solution may work together to solve a particular customer problem.
3. For each Solution element, identify if it’s a “must-have” for your MVP. Solution elements meant to solve customer Problem #1 are automatically must-have’s. The trick is in making the determination for the remaining Problem/Solution mixes.
4. Identify all features for each Solution element. If you already have a list of feature ideas, this becomes more of a mapping exercise. The net result is every feature idea will be mapped directly back to a specific Problem, which is awesome.
5. Mark each feature as “In MVP” or not. Be ruthless in asking if a feature really, really needs to be part of the MVP. (Tip: not every feature under a “must-have” Solution element necessarily needs to be “In MVP”.)
6. “T-shirt size” the LOE for each feature, if practical. Just L/M/S at this point. A quick conversation with your engineering lead can give you this.
Like with roadmap prioritization, this entire exercise can also be done via a simple spreadsheet. Here’s a template I’ve used that you can freely download.
The beauty of the spreadsheet is it brings into sharp focus a particular feature’s contribution toward solving customers’ primary problems. And an MVP must attempt to do exactly that.
To paraphrase Bruce from p26 of his presentation, this is probably the most important part of the process.
You need to get buy-in from your key stakeholders for your product strategy and MVP definition to be approved and “stick over time”. Bruce shares some excellent tips on how to do this on pp26-30.
When you practice shuttle diplomacy:
“A magical thing happens. ‘Your’ plan becomes their plan too. This makes [review and approval] more of a formality, because everyone has had a hand in putting together the plan.”
To be clear, you’re not looking for “decision by committee”.
As the product owner, you will still be looked upon as the final decision maker. (Remember to stand your ground). But you need to actively try to bring others along by encouraging input and providing visibility.
Lean Startup purists may vomit at this, but that ignores the realities of getting things done in an established company as a product manager. As Henry Chesbrough writes:
“You have to fight — and win — on two fronts (both outside and inside), in order to succeed in corporate venturing.”
This means corporate innovators “must work to retain support over time as conflicts arise (which they will).”
This means Stakeholder Development. And that requires shuttle diplomacy.