5 Product Jedi Mind Tricks to Better Manage Stakeholders

Or, how to say no without pulling a Kylo Ren

As Product Managers, we receive a constant stream of ideas and requests from all kinds of stakeholders (engineers, designers, marketers, customer service… the list goes on). It might be tempting to tell your colleague to shut up like C-3PO so you can focus on executing your roadmap. Restrain yourself — you might miss out on a great idea or seriously damage your relationship with a coworker. (Or more cynically, you may shoot yourself for peer performance reviews.)

Instead, tap into the Light side of the Force with these Jedi-worthy responses whenever you receive a feature request or suggestion from a stakeholder. With luck, you’ll be able to focus on higher impact initiatives that put your user first, while coming off as cuddlier than BB-8.

• “What is the problem you’re trying to solve?” A lot of times when I receive feature requests from colleagues, they phrase it in terms of a solution rather than the underlying issue. For example, a customer service representative may ask, “Can we add a link in the checkout flow that takes users to a page with instructions on how to ship internationally?” In this scenario, your job as a PM is to ask your stakeholder clarifying questions about their suggestion, and distill it down into the actual user problem. In this case, it might be: “International customers are confused because they don’t understand how to enter overseas shipping and billing information”. From there, you can figure out if solving this problem helps you reach your team goal, and how it stacks up against your other initiatives (see below).

“Find out your users’ real problems, you must.”

• “From the user’s perspective…” Another issue with stakeholder feature requests is a tendency to focus on impact for their team rather than impact for the user. For example, a marketer may say, “We need a content management system so we can configure things more easily on the website.” What this request fails to take into account is whether users actually benefit from better merchandising. A good response to this suggestion could be, “That’s interesting, let’s chat about why we think this will improve the experience from the user’s perspective.” If it turns out that your users think the current website is sterile and boring, then a CMS could be worthwhile because it will help deliver a better user experience.
• “This is a great idea, but our current team goal is [X].” Let’s say your product team is focused explicitly on increasing existing user engagement in the app this quarter. The Growth team proposes a 6-week project aimed at driving new traffic to the website — a valuable initiative, but not something that relates to our actual goal. Responding back with this statement reminds stakeholders that your overarching goal is paramount, while leaving the door open to tackling the suggestion when the team’s goal changes. (Note: This response only works if your company and team have quarterly/annual goals — for more information on why these are so important, check out this great post here.)
• “We can do this, but it’ll mean not doing X, Y, or Z. Which one would you cut?” In general, you should have some sort of product prioritization framework to rank which initiatives to tackle first. We use Intercom’s RICE approach — it doesn’t work as well for internal features, but it provides a good, quick-and-dirty way to compare user-facing features. Use this framework to stack-rank an incoming feature request against your other initiatives, then communicate the results clearly to your stakeholder. Whenever I’ve used this response in the past, my colleagues have walked away agreeing we’re making the right product decision, while not feeling like I arbitrarily rejected their ideas.

“These are not the features we’re looking for.”

• “Thanks for the suggestion, and keep them coming!” This may be surprising, but submitting a feature request can be daunting. A lot of business stakeholders find the technical side of a company intimidating; some have anxiety over bothering the engineering team or appearing dumb. The worst thing you can do is to say no in a way that discourages your coworkers from ever making another suggestion. Not only are you closing yourself off to a lot of potentially great ideas, you’re basically becoming an agent of the Dark Side.

Ultimately, developing great relationships with stakeholders is similar to becoming a successful Jedi — it’s all about finding balance between opposing forces. In our case, it’s the balance between doing what’s best for your user, while being open and respectful to your colleagues’ suggestions. That, and lifting rocks with your mind.