Section 2.1: Shrink and Delegate

We've all faced the situation: a new meeting request from a key stakeholder, leading to a fervent pitch of a grand, vague solution, often with poorly defined problems and little regard for feasibility. They expect your team to pivot toward this evidently brilliant idea, but alarm bells are ringing in your mind.

How do you transform this into a productive conversation instead of a frustrating rejection?

Start by listening and validating their vision. This is your "yes." Pose insightful questions to grasp their objectives fully and ignite their enthusiasm.

Next, begin to SHRINK the scope. Steer them toward distilling their idea down to its essential components. Utilize product jiu-jitsu to explain how a Minimum Viable Product (MVP) approach can facilitate quicker validation and enhancement. Continue to minimize until you reach a point where a simple prototype or manual process is all that’s left.

Now, here's the key: DELEGATE that manual process back to the stakeholder. Frame this as a chance for them to initiate their brilliant idea immediately: "You can start without waiting for my team to take on the workload or secure funding!" Position yourself as a guide who can help refine and expand their simplified concept—entirely leveraging their team’s efforts.

Pros:

• Shows respect for their vision while introducing realism.
• Breaks down large ideas into manageable experiments.
• Keeps your developers out of the initial discussions, earning you brownie points with the stakeholder.

Cons:

• Requires time-intensive discussions—your time is valuable!
• There’s a risk of scope creep occurring post-initial shrink.
• Stakeholders may not follow through (which could also be a pro!).
• You might still need to deliver a firmer "no" eventually.

Example:

A product manager friend in healthcare tech shared an enlightening experience: a stakeholder proposed a concept for a "Tinder for therapists" to connect users with ideal mental health professionals—a massive undertaking that wasn’t part of the roadmap!

The PM first responded with a "yes," acknowledging the need for improved therapist access and the stakeholder's passion for enhancing mental healthcare.

Then came the SHRINK and DELEGATE: "What if we create a manual version where your team manages user requests and matches them to therapist profiles? We’ll learn a lot, and you can start today without waiting for my team's prioritization or funding! I can help with planning and data review."

The stakeholder embraced this speedy solution and rallied their team to create a simple spreadsheet for tracking requests. They quickly discovered that users were hesitant to provide that information and that getting therapists’ attention was challenging!

Ultimately, the stakeholder realized on their own that the idea lacked market fit. Instead of a costly process with wasted resources, my PM friend emerged as a hero to the stakeholder. It was a win-win!

Section 2.2: "I'll Put It In the Backlog"

This classic method allows you to politely postpone requests to an uncertain future. You acknowledge the idea—perhaps even affirm its significance—but make no firm commitment to execution.

Pros:

• Provides a straightforward response that clarifies expectations.
• Works well if there’s a defined intake process for feature requests.
• Quick and easy, avoiding protracted debates.
• Often serves as a "soft no," allowing stakeholders to move on for the time being.

Cons:

• This tactic has become a cliché and can feel insincere to seasoned stakeholders.
• Only temporarily deflects follow-up questions regarding prioritization and roadmap.
• Risks creating a backlog filled with stale ideas, leading to team frustration.
• Might delay a more difficult "no" conversation when stakeholders seek insight into your roadmap.

In essence, this reliable fallback has its place, but it should not be your go-to for every non-essential request. Be aware that stakeholders will eventually seek clarity on your product vision and roadmap. If you misuse this tactic too often, your backlog will overflow with items you never intend to implement, which can undermine trust over time.

Have a strategy for when backlog purgatory can no longer be a solution for a particular request. How will you redirect the conversation to establish priorities? What criteria will you utilize to prune outdated ideas? Know when to shift from "I'll log it" to a more strategic discussion.

Section 2.3: Invoke Higher Powers

This technique involves referencing factors beyond the PM's direct control—priorities, roadmaps, or constraints set by leadership, key customers, or legal teams.

Your ability to clearly and convincingly communicate your product roadmap and priorities is crucial. If you cannot do this, this method becomes ineffective.

When declining a request, be transparent about how it aligns with or diverges from external factors. Position yourself as the bridge between stakeholders and the broader business strategy.

Make it clear that you value the stakeholder's idea and understand their challenges. You can even offer to advocate on their behalf, but only if it’s genuinely a worthwhile idea!

Pros:

• Redirects the blame from you, the PM, to external influences.
• Shows that you grasp the stakeholder's problem and are on their side.
• Provides transparent insights into your team’s priorities.
• Positions you as an ally to the stakeholder.

Cons:

• Overusing this method can make you appear ineffective.
• Similar to the "I'll put it in the backlog" approach, it may just delay the conversation.
• You need a supportive leadership team to back you up!

I cannot emphasize enough how critical it is to communicate your product roadmap and strategy effectively to make this "no" work. It must never appear as a mere excuse to avoid difficult discussions. When employed judiciously and backed by leadership support, this approach conveys "no" while fostering trust in the process.

Section 2.4: "We're Already Doing It"

Vague requests, such as "we need a mobile app version" or "let's boost dashboard adoption," can be incredibly frustrating, especially when they come unexpectedly from disengaged executive stakeholders.

Instead of bluntly stating, "No, that doesn’t matter; I have the analytics to prove it," which could lead to more issues, it's often more effective to regroup and address this through backchannels.

A poor response would be, "Oh, great idea, we'll consider that," which risks making you seem weak or lacking vision.

The ambiguity of the request, however, gives you a chance to shine and advocate for your product and roadmap.

Example:

Expanding on our previous scenario, suppose you're set to release UI contrast improvements for accessibility. While you hadn't initially considered the dashboard in this feature, it will undoubtedly be affected.

Reframe that feature as actively addressing their concern: "Excellent point about the dashboard! I’ve been considering it as well. We've identified that contrast and clarity issues significantly hinder user experience, especially regarding dashboard visibility, which affects adoption of the dashboard reports. We're launching that improvement this Friday!"

This response demonstrates your attentiveness and proactive approach, while subtly educating them about your roadmap. More importantly, you've preserved your credibility and deflected potential criticism while validating the executive stakeholder’s concerns. Product jiu-jitsu!

Pros:

• Allows you to reframe current efforts as successes.
• Often, vague requests are forgotten after the meeting.
• Positions you as responsive to stakeholder needs.
• Educates stakeholders about your roadmap and problem-solving strategies.

Cons:

• Limited applicability—there may be times when you have nothing to point to.
• You must follow through on cited plans.
• Stakeholders may still desire new dedicated efforts, so be ready for that.

With careful consideration, this technique can convert nebulous asks into proof of your alignment. However, be prepared for a more definitive discussion if requests persist.