Unless your company is literally a one-person show, your role as a product leader includes stakeholder management. And including stakeholders in your product planning process is a key part of product management. In today’s article we’ll take a look at which stakeholders need to be included in the product planning process, why they need to be included, and several tactics for including them.
Product Planning: Types of Stakeholders to Include
To manage your stakeholders, you must first understand who your stakeholders are and what they care about. You’ll probably want to conduct a stakeholder analysis to identify your key stakeholders, but here is a starting point. Your stakeholders are likely to be drawn from the following groups of people:
Executives
The folks with titles beginning with a capital “C” or who have a VP or SVP on their business card definitely care about where the product is going, how it aligns with company goals and the revenue implications of your product plans. Depending on the size of your company, they may have a lot of very specific opinions, or may only engage in very general terms. Regardless, if they don’t believe in you, you should probably be polishing up your resume.
Sales & Marketing
They’re selling what you’re making, so they care a LOT about what’s being built and when. They are on the front lines with customers and prospects and see first-hand when your product lacks key functionality that potential clients are demanding to close the deal. They know how the product is being received relative to the overall competitive landscape and don’t have a lot of patience for shortcomings that might prevent a sale.
Operations & Support
When customers complain, these are the people who hear it first and have to respond. They’re experiencing the pain points, dealing with unhappy campers, and will be pushing for less sexy changes that reduce support tickets and quiet the squeaky wheels among the customer base.
Product Development
The people actually building your product are stakeholders, too. They know how the sausage is made, know where the weak points are in your infrastructure, and probably have some technical debt they’d love you to pay down in some upcoming releases.
Why include stakeholders in the product planning process?
There are two fundamental reasons you should include stakeholders in your product planning process. First, they probably have some good ideas based on their experiences with customers, prospects, and within their own roles. Not to mention, the wisdom they may bring from previous places of business. Second, if you don’t, they’re going to make your life difficult in a plethora of ways.
Let’s focus first on the insights and suggestions your stakeholders have to offer. Your stakeholders are force multipliers when it comes to gathering market feedback and competitive intelligence. You’re only one person. While you may spend plenty of time surveying the landscape, knowing your customer, and building personas, it can’t substitute for the collective wisdom others have. Not tapping into that well is simply a missed opportunity.
On a more practical level, stakeholders can complicate matters if they’re not on board with what you’re planning. By incorporating their input earlier in the overall product planning process, you can avoid unpleasant vetoes and embarrassing “what about this…” moments when you’re presenting plans for approval. Understanding what matters to each stakeholder and giving it proper consideration early on ensures that you’ve at least accounted for their concerns, even if you ultimately opt to go in another direction.
How to involve stakeholders without letting them take over?
Now that you’ve realized the folly of going it alone, it’s time to include these opinionated individuals without having your entire process derailed or commandeered by a HiPPO. This necessitates the delicate balance of welcoming and considering their input while still running the show.
Reminding yourself (and others) that stakeholders don’t actually purchase what you’re building can be helpful.
“Designing for consensus of internal people who do not use or buy the products just creates terrible products,” says Melissa Perri, CEO of Produx Labs. “Stakeholders are responsible for informing the decisions the Product Managers make, but they should not be the ones making those decisions.”
Injecting the Voice of the Customer into the process and using personas to assess the true value and impact of stakeholder input can help you appropriately synthesize what you’re hearing and push back when necessary. Validating stakeholder requests against customer feedback is an invaluable tool to ground your prioritization activities in reality. If the customers don’t care about it, don’t want it, or don’t like it, it’s your job to say so and resist the enthusiastic but misguided opinions that may arise.
5 Tactics for Including Stakeholders in the Product Planning Process
1. Communicate with stakeholders early, often, and in private.
Frequent updates on plans and follow-through on requests are two ways to make sure stakeholders’ input is heard and valued. Even if it’s not necessarily being prioritized. And, the earlier you bring things up with stakeholders, the less likely you are to spend your time working on things that won’t fly due to constraints or strategic developments you weren’t aware of.
These check-ins should be regularly scheduled occurrences. They should not only happen when you have an “ask.” This builds your personal relationship with stakeholders and allows for more informal exchanges of information vs. strictly transactional interactions. And, there are specific ways to engage your stakeholders based on what phase of the overall product planning process you’re currently in.
Furthermore, meeting with folks individually has several benefits. First, they will feel more comfortable being open if they’re not worried about politics, “looking bad”, or about asking embarrassing questions in front of their peers or more senior staff. In addition, you will also avoid endless debates driven by emotion and personalities or “design by committee” sessions.
2. Drill into the root cause of requests.
When a stakeholder presents an idea, it’s often a specific feature or functionality they want.. Instead of just jotting the idea down and throwing it into your product backlog, probe deeper to get to the underlying problem that needs to be solved.
Just as developers don’t want you to specify exact implementation specs, a salesperson shouldn’t be telling you what features to include. And, if they can’t tell you the underlying rationale for the request, then it’s much easier to park it until they can.
3. Press stakeholders for context.
Stakeholders rarely ask for something they simply think will be cool. Their requests are often informed by interactions they’re having with customers, prospects, investors, or competitors. This is why context for a request and an attributable source is so valuable when receiving feedback from a stakeholder.
Pressing them to understand who’s asking for something and why—in a curious vs. dismissive manner—is an important step in validating the request while still empathizing with them.
4. Pull back the product development curtain.
Your stakeholders may not really understand what happens in the product development process or why. If this is the case, they may be frustrated that their requests aren’t being prioritized or that things are taking too long. Offering a glimpse of how you do what you do and why you do it that way can help.
“Walk your stakeholders through your own prioritization framework so that they understand how you estimate the size and impact of projects,” says Instacart co-founder Max Mullen. “Explain the metrics you use to track success and the ways you will assess the impact of projects.”
But you should also refrain from using your backlog as a communication tool; it’s way too much information and can lead to a ton of ratholes and distractions. Instead, rely on your product roadmap as the primary delivery tool for keeping stakeholders informed.
5. Leverage your unique perspective.
A product manager is often the only person in the company that actually talks to all of the different people and departments in a company that qualifies as stakeholders. This gives you a singular perspective, which is built on what you’re hearing from everyone else.
By listening to all of these different parties, it’s up to you to synthesize all of this data fit it into the big picture. You’re hearing from sales that the pricing structure is too rigid, from operations that the COGS are facing upward pressure from a supplier and from the support that customers are struggling to use a key feature that’s leveraging that expensive, third-party software.
Putting all of that together might mean your product should bring that work in-house and develop better solution yourselves, but that’s a connection only you are in a position to make. Reflecting those various inputs back to the larger stakeholder community when you make that sort of recommendation will both build consensus for the move and increase your perceived value to the organizations.
The TL;DR: Balance is key.
The love-hate nature of stakeholder inclusion is natural; your ENTIRE JOB is deciding what’s best for your products. You spend your time carefully considering ideas, validating them, and talking to customers. And stakeholders at times seem to just throw out opinions and ideas without doing their homework or basing them on any actual data. At the same time, their perspectives are an invaluable contribution to your process and provide information and context you could never acquire on your own.
If you can check your ego at the door, you can mine stakeholders for all kinds of wonderful nuggets of insight and wisdom. And, you will be well-served by having the time and patience to do so. However, setting proper expectations that their input, while valued, may not necessarily be acted upon is essential to creating a healthy and productive ongoing relationship with stakeholders.
