Stakeholder Management

Principal PMs move outcomes through people they rarely manage. Map stakeholders, understand their constraints and settle decision rights early. Build trust through clear requests, reliable commitments, coaching and a team culture where problems surface quickly.

Why this matters

Sound product plans fail when finance sees pricing late, security discovers access requirements during an escalation or sales promises an unplanned connector. Early involvement is cheaper than repairing trust after a commitment.

Cagan’s July 2026 AI productivity argument makes the coordination task more urgent: cheaper building increases the importance of choosing well. Ravi Mehta’s August 2026 competency model also shifts senior expectations toward strategy and influence. Principal PMs must move outcomes across functions while developing the PMs around them.

This chapter covers stakeholder mapping, decision rights, conflict, managing up and product leadership. Chapters 34 and 35 cover the writing and meetings that carry this work.

Core concepts and frameworks

Who counts as a stakeholder

A stakeholder affects or is affected by the outcome while sitting outside the building team. In Cagan’s model, PM, designer and tech lead form that team, owning value/viability, usability and feasibility respectively. Resolve internal partnership problems through the team charter.

For a B2B or platform product, stakeholders fall into two groups, and it helps to map them separately.

• Internal: your manager and the executive team, peer PMs whose products you depend on or compete with for resources, sales, marketing, support and customer success, finance, legal, security and compliance, partner teams, and product operations.
• External: the customer’s economic buyer, champion and security reviewer, partners who build on or resell your product, and sometimes regulators or standards bodies.

Chapter 01 treats the external buying group as personas. Here both groups are relationships, each with a current position, a desired position and a plan to close the gap.

Stakeholder mapping: the power-interest grid

The power-interest grid is usually attributed to Aubrey Mendelow’s 1981 environmental-scanning paper. The familiar two-by-two and engagement labels are later practitioner adaptations. Use it as a convention for matching attention to influence.

The grid plots power (the ability to change your outcome) against interest (how much attention they pay to it):

For enterprise and platform work, this book adds three extensions.

Add stance. Record champion, supporter, neutral, skeptic or blocker. High-power champions and skeptics share a quadrant but need different engagement.

Draw the move. For each important stakeholder, mark where you need them to be, and by when. The arrows turn the map into a plan.

Engage gatekeepers early. Security, legal, procurement and finance may show little interest until a late veto becomes necessary. Involve them closely while their requirements can shape the design.

Map internal and external stakeholders on separate grids, because you reach your CFO and a customer’s security reviewer through entirely different channels.

Influence without authority: the exchange model

Cohen and Bradford’s Influence Without Authority (third edition, 2017) describes the Exchange Model. Cooperation depends on understanding what another person values, their currencies, and finding something useful you can offer.

Use the model to diagnose goals and constraints. Find trades that help both parties, rather than accumulating favors.

Cohen and Bradford list many currencies. For a B2B PM, this book groups the ones you can actually pay in into four kinds:

• Information: customer evidence, early visibility into the roadmap, a heads-up before a change lands on someone’s team.
• Task help: a feature flag that unblocks a deal, a field-ready demo, a known-issues page that cuts support’s escalations.
• Visibility: crediting a sales engineer’s customer insight in an executive review, putting a support lead’s analysis in front of the VP.
• Direction: a credible vision people want to be part of, and a clear answer to “why are we doing this?”

Start with their metrics: bookings for sales, ticket load for support, margin for finance and risk for legal. Explain how the proposal helps their goal, alongside its product benefit.

Decision rights: DACI and RAPID

Agree decision rights before debating options. Otherwise uncertainty about authority can masquerade as disagreement over evidence.

The DACI format, as Atlassian’s Team Playbook describes it, assigns four roles:

• Driver: gathers the stakeholders and information, sets the scope and gets a decision made by the agreed date.
• Approver: the one person who makes the decision. The playbook is emphatic that there is exactly one.
• Contributors: subject-matter experts who have a voice but no vote.
• Informed: people affected by the outcome who are told afterward, with no voice or vote.

Atlassian’s template opens with the decision phrased as a question (“DACI: [question we’re trying to answer]?”), then background, relevant data, decision factors, options with pros, cons and cost, and the outcome, which is shared and recorded.

Bain’s RAPID names Recommend, Agree, Perform, Input and Decide. Use Agree sparingly for mandatory constraints such as legal requirements, and Perform for execution ownership. Prefer one decider. If a group must decide, agree a deadlock rule first.

Make legitimate security and legal vetoes explicit for production access and customer data. Bring reviewers in while their conditions can shape the options.

Alignment practices

Decision rights tell you who decides. Alignment practices make sure the decision sticks.

• Pre-wiring. Meet each key stakeholder one-on-one before the group meeting. Show them the recommendation, hear their objection in private and adjust where it is fair. Nobody should see your proposal for the first time in a room where they have to react in public.
• Written pre-reads. Send the decision document ahead and spend the meeting on disagreements (Chapter 34 covers the writing).
• A decision log. Record each decision, its date, the Approver, the options rejected and the reason, so that six months later nobody relies on memory.
• Disagree and commit. Amazon’s leadership principles describe the norm well: leaders challenge decisions they disagree with, respectfully and even when it is uncomfortable, and then commit fully once the decision is made. The second half matters as much as the first. A stakeholder who reopens a logged decision without new evidence is breaking the agreement.
• A standing escalation path. Atlassian’s Working Agreements play includes an explicit escalation process: who decides when the team cannot, and how the decision gets shared. Write yours down before you need it.

Managing conflict and saying no

Most stakeholder conflict in B2B products comes from five places: deal-driven requests from sales, launch timing with marketing, escalations from support, margin with finance, and risk with legal and security. Each function is defending its own metric, so treat the conflict as a clash of measures and look for the trade.

Jones and Cagan’s December 2025 stakeholder essay asks stakeholders to supply business constraints, bring problems with affected users and success measures, review prototypes early and seek firm dates only where necessary. Use that exchange to clarify requests.

Translate features into problems, owners and success measures, then apply the roadmap’s existing criteria. Four responses cover most requests:

Explain the request decision in writing and preserve respect for the person. Escalate unresolved peer disagreements jointly: shared goal, disputed choice and decision deadline. Avoid bypassing a peer.

Kim Scott’s Radical Candor combines caring personally with challenging directly. Caring alone becomes ruinous empathy, challenge alone obnoxious aggression, and neither manipulative insincerity. Honest limits protect relationships better than commitments you cannot deliver.

Managing up

Gabarro and Kotter’s “Managing Your Boss” (HBR, 1980) treats the relationship as mutual dependence. Understand your manager’s goals, pressures and working style alongside your own. Agree expectations, supply timely information and use their attention carefully.

Will Larson’s 2026 leadership writing emphasizes pressure across executives, peers and teams. Faster AI-era delivery needs prompt, binding decisions when teams disagree. Bring your manager the choice and recommendation needed to unblock work.

Three practices follow:

1. Bring decisions, not status. For each item that needs your manager, state the decision, your recommendation, the deadline and what happens if it slips.
2. No surprises. Bad news travels up from you before it arrives from anyone else. Your manager should never learn about a risk to your product in someone else’s meeting.
3. A weekly written update. Outcomes moved, decisions needed, risks and asks, on one page. It replaces most status meetings and gives your manager material to manage up in turn.

Leading across functions

Each function around the product has its own metric, its own calendar and its own way of being let down by product. Leading across them means knowing all three.

For deal requests, give sales a structured intake: the problem, the account, the revenue at stake, the deadline and whether other customers share the need. It converts features into problems before they reach you and turns one-off escalations into evidence you can aggregate. Chapter 27 covers the enablement side of the sales relationship and Chapter 29 the business reviews where these conversations become formal.

Hiring and growing PMs

Product leadership starts with a written picture of what good looks like. Without one, hiring runs on taste, promotion on visibility, and coaching has no target.

Ravi Mehta groups twelve competencies under execution, insight, strategy and influence. Expectations vary by level while business outcome ownership remains constant. His 2026 update adds definition clear enough for humans and agents, plus architectural judgment that distinguishes customer opportunities from technology seeking a use.

A career ladder turns the model into expectations. For each level, state four things:

• Scope: a feature, a product area, a product line or a portfolio.
• Impact: the outcomes the person is expected to move, and at what scale.
• Autonomy: how much direction they need, and how ambiguous a problem they can take on alone.
• Competencies: which ones matter most at that level, and at what proficiency.

Define equally credible paths above Senior PM: Principal individual contributors leading through expertise and influence, and Group PM/Director people managers. Clear expectations support advancement without forcing practitioners into management.

Hire with named competencies, structured questions and written rubrics. Include a realistic work sample, such as drafting a DACI from a messy thread. State AI-use rules in advance. Where AI is allowed, assess the candidate’s verification and editing as part of the work.

Coaching and the 1:1

Cagan and Jones’s Empowered makes coaching central to helping teams solve hard problems. Leaders develop capability rather than depending only on exceptional hires.

GROW, developed by John Whitmore and colleagues, structures coaching as Goal, Reality, Options and Will. Ask what the person wants, establish evidence, explore alternatives and agree an action and date. Hear the situation before proposing solutions.

First 1:1 questions. Lara Hogan recommends asking how frustration appears, how the person prefers feedback and recognition, what makes 1:1s useful, their goals and what support they need. Check challenge, reflection time and timely feedback.

The 1:1 belongs to the person you are coaching, so their agenda comes first. Listen, coach one real problem, give and ask for feedback, and leave with commitments on both sides.

Team charters

A team charter defines mission, ownership, working practices and outcome measures. Agree roles and decision rights before a contested decision exposes a gap.

Google’s Project Aristotle, a study of 180 teams (115 engineering project teams and 65 sales pods), identified five dynamics that distinguished effective teams. In order of importance: psychological safety, dependability, structure and clarity (clear roles, plans and goals), meaning and impact. A charter addresses structure and clarity directly.

This chapter’s charter template combines three sources: outcome framing from Cagan (teams get problems and are measured on outcomes); explicit ownership from Atlassian’s Roles and Responsibilities play, with a named primary owner wherever responsibilities overlap and a review every three to six months; and channels, meeting plan and escalation process from Atlassian’s Working Agreements play.

Product culture and psychological safety

Amy Edmondson’s 1999 study of 51 manufacturing teams defines psychological safety as a shared belief that interpersonal risk-taking is safe. It found associations with learning behavior and performance. Leader coaching and organizational support mattered. Google’s Project Aristotle later ranked it first among five team dynamics.

Psychological safety supports candid learning and high standards. Engineers need to report weak evals, designers to identify confusing flows and PMs to admit failed hypotheses without a social penalty. Edmondson’s The Fearless Organization (2018) extends the argument across organizations.

Cagan distinguishes delivery teams administering output, feature teams delivering stakeholder-selected roadmaps and empowered teams solving problems against outcome measures. Match charters and incentives to the model you intend. A fixed feature roadmap can override verbal promises of empowerment.

How to apply it

Use this method when you take on a new product, a new role or a major bet. The first six steps take about a month and then become a quarterly rhythm. The last three apply once you lead or coach other PMs.

1. Build the stakeholder map. List every internal and external stakeholder for the product or initiative. For each, record power, interest, current stance, what they are measured on and what they fear. Plot them on two grids, internal and external.
2. Mark the moves. For each high-power stakeholder, write where you need them to be and by when. Move gatekeepers (security, legal, finance, procurement) toward “manage closely” now, while they still have time to shape the work.
3. Write the engagement plan. For each stakeholder or group, set the objective (inform, consult, involve or decide), the message or ask, the channel, the cadence and the owner. Add the signal that tells you the engagement is working.
4. Settle decision rights for the next contentious decision. Write a DACI document before anyone debates options. Name one Approver. If legal or security can block, add a “Must agree” row. Pre-wire each Contributor one-on-one before the decision meeting.
5. Set up the request intake and the no. Give sales and other functions one structured path for requests, built around problems rather than features. Decide each request on the roadmap’s criteria, and answer in writing with one of the four responses.
6. Establish the upward rhythm. Agree with your manager on a weekly written update (outcomes moved, decisions needed, risks, asks) and on what counts as a no-surprises item.
7. Charter the team. Write the charter with the team, not for it: mission, problems owned, outcome metrics with baselines, out of scope, roles, decision rights, stakeholders, working agreements and escalation path. Set a review date three to six months out.
8. Calibrate competencies. Have each PM you coach complete the competency self-assessment with evidence. Review it together, agree on one or two development focuses per quarter and link them to real work.
9. Run coaching 1:1s. Use the 1:1 template weekly or fortnightly. Coach one real problem per session with GROW. Track commitments on both sides.

Repeat steps 1 to 3 every quarter and after any reorganization, major launch or incident.

The AI lens

Leading AI-powered products and AI-era teams

AI-powered products change who your stakeholders are and how much power they hold.

• Gatekeepers gain power. When a product’s agent can act on production systems or touches customer data, security, legal and compliance move from occasional reviewers to holders of a real veto. Chapter 33 covers the regulatory substance. The stakeholder lesson is to treat their requirements as design inputs from the first prototype.
• Finance becomes a product stakeholder. Inference cost puts gross margin on the product agenda. Pricing, packaging and model choices now have direct margin consequences that finance will want to see before launch, not after (Chapter 15).
• Eval results become alignment evidence. Contentious AI decisions, such as how much autonomy to ship, should be decided on eval results and incident data that every Contributor can see. Chapter 31 covers evals. A DACI document for an AI decision without eval evidence in its data section is an opinion contest.
• Safety to report bad news becomes a quality control. On an AI product, the earliest warning of a hallucination problem usually comes from an engineer looking at eval results or a support agent reading a strange ticket. Whether that person speaks up is a question of psychological safety.

AI-era team structure remains contested, with limited evidence for either position.

LinkedIn CPO Tomer Cohen said in December 2025 that its Associate Product Builder program combined product, design and coding, alongside a Full Stack Builder career path. Atlassian’s early-2026 vendor survey of 12,035 workers and 173 executives found 77% of executives expecting flatter, more horizontal teams.

The same survey found 89% reporting faster work but only 6% confidently identifying organization-wide AI ROI. Cagan’s September 2026 “Experts Lead Experts” argues that cheaper building increases the need for skilled leadership and notes reversals of some manager cuts. Larson favors persistent teams that retain domain context. Cagan’s August role definition similarly emphasizes discovering valuable, viable solutions.

This book’s position: change the work before you change the boxes. Reskill your PMs in the skills that AI makes more valuable, measure whether outcomes (not output) improve, and then decide on team shape with evidence. The reskilling plan has four parts, each taught elsewhere in this book:

Doing the work with AI

Stakeholder work is mostly reading, remembering and preparing, which is where an AI harness with the right connectors helps most.

Refresh the map from evidence. With connectors to your CRM, ticketing and chat tools, ask the harness: “For each person on this stakeholder map, what have they said or asked about this initiative in the last 30 days? Link every item.” Update the stance column from what people said, not from your memory of a meeting two months ago.

Prepare the pre-wire. Before a contentious decision, have the harness draft a one-page brief per stakeholder: what they have said on the topic, what they are measured on, the objection they are likely to raise and the evidence that answers it.

Draft the DACI document. Point the harness at the decision thread and the data, and ask for a first draft in the DACI format. Rewrite the options section yourself, because how options are framed largely decides the outcome.

Gather competency evidence. For a self-assessment, the harness can collect links to a PM’s documents, decisions and results from the last two quarters. The rating stays a human judgment.

Use AI as a coach, with care. Cagan’s February 2026 essay recommends context-rich model coaching for PMs while reserving human coaching for leaders. Users must challenge variable responses. Supply team charter, strategy and competencies, then keep judgment, feedback and career development in human 1:1s.

Use approved tools for sensitive stakeholder and personnel notes. Check drafts before sharing: Larson warns that low-quality proposals impose costs on other teams. Treat stance predictions as hypotheses and maintain direct relationships.

The Beacon case: launching Beacon Agents through the organization

The map. Your first stakeholder map, built in your second week, shows the problem at once: the high-power, low-interest quadrant holds every function that can stop the launch. Security and legal have not looked at the autonomous-action design. Finance has not seen the per-resolved-incident pricing model against the new margin. Sales leadership is interested only when a large deal is at stake. You mark arrows moving all three into “manage closely” before the launch content is locked. You also move the Observe and Desk group PMs from “keep informed” up the grid, because the build-on-Observe question gives them a genuine stake. Externally, you map Marcus (economic buyer), Priya (champion), Sam (the security reviewer who gates production access) and Leo (the MSP partner) on a separate grid.

The currencies. You write one line per stakeholder before asking for anything. The support lead, measured on escalations and still handling fallout from the hallucinated root cause, values a known-issues page and a direct line into the eval work. Finance, measured on margin, values an early look at the cost model and a seat in the pricing decision. The sales leader wants deals closed before year-end and values a field-ready demo and early access for sales engineers.

The contentious decision. The hardest call is whether Beacon Agents should launch with autonomous actions enabled by default for customer-allowlisted, low-risk actions, or ship supervised-only. Sales wants autonomy as the headline; support and security want caution after the incident. You write a DACI document titled “DACI: Should Beacon Agents launch with autonomous low-risk actions on by default, or supervised-only?” You are the Driver. The VP of Product is the single Approver. The Beacon engineering lead, the applied AI engineers, security, legal, product marketing, the support lead and sales leadership are Contributors. The Observe and Desk group PMs, customer success and the partner team are Informed. Because security and legal can legitimately block anything that acts on production, you add a “Must agree” row for both, borrowing RAPID’s Agree role, and you meet each of them before anyone else sees the options.

The data section carries the diagnosis acceptance rate, the eval results and the incident review. The decision factors are customer trust, the launch story, legal exposure and margin. Pre-wiring changes the options: security will agree to autonomy only with per-action audit logs and a kill switch, which turns a binary choice into three options. The VP decides on supervised-only by default at launch, with autonomous low-risk actions available as an opt-in per customer, and the decision goes into the log with the reasons. Sales leadership disagrees in the meeting, says so clearly and commits.

Saying no. Two weeks before Northlight Live, a sales director asks for a custom connector for one large prospect. You convert the request into a problem: the prospect uses a ticketing tool Beacon does not cover. You ask the harness, through the CRM and support connectors, how many of Beacon’s roughly 420 customers use that tool and what revenue is attached. The answer is a handful of accounts. You reply in writing with “no, and here is an alternative”: the partner team can build an MCP-based connector after the event, and you will review the evidence again in the first quarter.

Managing up. Your weekly note to the VP leads with the North Star (incidents resolved with Beacon’s help per week), then decisions needed, risks (inference cost, customer trust after the incident) and asks. The DACI decision appears there a week before the meeting.

The culture moment. The blameless review of the hallucinated root cause turns up an uncomfortable fact: one of the applied AI engineers had flagged weak evals for that failure mode weeks earlier, in a channel where nobody acted on it. You make the fix structural. The new charter for the engineering team that owns Act (supervised remediation) sets “zero unapproved actions” as a hard constraint alongside its autonomous resolution rate, and its working agreements require eval regressions to be raised in the weekly product review, where the engineer who raises one is thanked by name.

Leading the PMs. As lead PM, you coach Beacon’s other PMs. Their self-assessments share two gaps: judging AI quality from eval results, and influencing sales. One PM shadows the eval reviews before launch; another runs the deal-request intake with the sales director.

The team shape memo. Late in the quarter, your VP asks whether Beacon should reorganize into smaller builder pods with fewer PMs. You write a short memo that sets out the builder model and the arguments from Cagan and Larson, notes that Atlassian’s own survey shows executives far more confident about AI speed than AI return, and recommends reskilling first: evals and AI product judgment, agent-ready specs, and building to learn. You propose revisiting team shape after two quarters of outcome data.

Product 360 artifacts

# Stakeholder map · [Product or initiative] · [Date]

**Owner:** [PM]   **Scope:** Internal / External   **Next review:** [Date, at least quarterly]

| Name and role | Team | Power (H/M/L, with reason) | Interest (H/M/L) | Quadrant | Current stance | Desired stance, by when | What they're measured on (their currency) | What they fear | Relationship owner | Last touch | Next action |
|---|---|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | | | |

Quadrants: Manage closely (high power, high interest) / Keep satisfied (high power, low interest) / Keep informed (low power, high interest) / Monitor (low power, low interest).

Stance: Champion / Supporter / Neutral / Skeptic / Blocker.

## Sleeping gatekeepers
High-power stakeholders who could block late (security, legal, finance, procurement) and the date each moves to "manage closely":
1.
2.

## Evidence for stance
For each stance rating, link what the person actually said or did, with dates. Refresh from evidence, not memory.

# Stakeholder engagement plan · [Product or initiative] · [Quarter]

**Owner:** [PM]   **Linked map:** [link]

| Stakeholder or group | Quadrant | Objective (inform / consult / involve / decide) | Message or ask | Channel (1:1, written update, review forum, demo) | Cadence | Owner | Signal they're engaged | Risk if neglected |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## Pre-wiring before key decisions
| Decision | Date | Stakeholders to pre-wire | Likely objection | Evidence that answers it | Done |
|---|---|---|---|---|---|
| | | | | | |

## Upward rhythm
- Weekly written update to [manager]: outcomes moved, decisions needed, risks, asks.
- No-surprises items (always escalate within 24 hours): [list]

## Request intake
Requests from [functions] arrive through [channel] with: problem, affected customers or accounts, revenue at stake, deadline, other customers with the same need.

# DACI: [Question we're trying to answer]?

**Status:** Not started / In progress / Decided   **Impact:** High / Medium / Low   **Due date:** [Date]

## People
| Role | Name |
|---|---|
| Driver (runs the process, gets a decision by the date) | |
| Approver (one person only) | |
| Must agree (veto for must-meet requirements, such as legal or security; use sparingly) | |
| Contributors (voice, no vote) | |
| Informed (told the outcome afterward) | |

## Background
[One or two sentences: why this decision, why now.]

## Relevant data
[Metrics, eval results, customer evidence, incident reviews, cost. Link sources.]

## Decision factors
1. [Factor, and how it will be weighed]
2.
3.

## Options considered
| Option | Description | Pros | Cons | Resources and cost | Must-agree requirements met? |
|---|---|---|---|---|---|
| A | | | | | |
| B | | | | | |
| C | | | | | |

## Pre-wiring log
| Contributor | Date | Position | Concern raised | How the options changed |
|---|---|---|---|---|
| | | | | |

## Outcome
[Decision, decided by (Approver) on (date). Reason in one paragraph. Options rejected and why.]

## Action items
| Action | Owner | Due |
|---|---|---|
| | | |

## Disagreements recorded
[Who disagreed, on what, and their confirmation that they commit to the decision.]

Format after Atlassian's DACI play, with a "Must agree" role borrowed from Bain's RAPID.

# Team charter · [Team name] · v[n] · [Date]

**Review date:** [3 to 6 months out]   **Charter owner:** [PM or lead]

## Mission
[One sentence: why this team exists.]

## Customers and problems we own
-
-

## Outcomes and metrics
| Outcome | Metric | Baseline today | Target | By when |
|---|---|---|---|---|
| | | | | |

Hard constraints (must never be violated): [for example, zero unapproved actions]

## Out of scope
[What this team does not own, and who does.]

## Members and roles
| Name | Role (PM, design, tech lead, engineering, applied AI, PMM) | Accountable for | Top 3 to 5 responsibilities |
|---|---|---|---|
| | | | |

Overlapping responsibilities and their named primary owner:

## Decision rights
| Decision type | Who decides | Must agree | Consulted |
|---|---|---|---|
| Roadmap priorities within our area | | | |
| Shipping to general availability | | | |
| Customer-specific requests | | | |
| [Other recurring decision] | | | |

## Key stakeholders and engagement
| Stakeholder | What they need from us | Cadence and channel |
|---|---|---|
| | | |

## Working agreements
- Core hours and time zones:
- Channels (urgent, async, decisions):
- Meetings (purpose, cadence, sync or async):
- How we give and receive feedback:
- How we raise bad news (eval regressions, incidents, slipped dates):

## Escalation path
When we can't agree: [step 1], then [step 2], decided by [role] within [time]. Decisions shared via [channel] and logged in [location].

## Interfaces and dependencies
| Team or system | What we depend on, or what depends on us | Contact |
|---|---|---|
| | | |

# PM competency self-assessment · [Name] · [Level] · [Period]

**Manager or coach:** [Name]   **Check-in date:** [Date]

Rate 1 to 5 against the expectation for your level (1 = well below, 3 = meets, 5 = well above). Every rating needs evidence from the last two quarters.

| Competency | Expectation at my level | Self-rating | Evidence (links to artifacts, decisions, outcomes) | Manager rating | Gap | One development action |
|---|---|---|---|---|---|---|
| Problem discovery | | | | | | |
| Customer insight | | | | | | |
| Data fluency (questions, evidence, reports) | | | | | | |
| Product definition for humans and agents | | | | | | |
| Delivery | | | | | | |
| AI product judgment (evals, cost, risk) | | | | | | |
| Strategy and roadmap | | | | | | |
| Business outcome ownership | | | | | | |
| Stakeholder influence | | | | | | |
| Communication (writing and presenting) | | | | | | |
| Managing up | | | | | | |
| Team leadership and coaching | | | | | | |

## Focus for next quarter (one or two competencies)
| Competency | Real work that will exercise it | What good looks like by [date] | Support needed |
|---|---|---|---|
| | | | |

## Strengths to use more
-

# 1:1 · [Name] and [Manager or coach] · [Date]

The 1:1 belongs to [Name]. Their agenda comes first.

## Their agenda
1.
2.

## Wins since last time
-

## One challenge, coached with GROW
- **Goal:** what do you want from this conversation, and from this problem?
- **Reality:** what is true now? What evidence do you have? What have you tried?
- **Options:** what could you do? What else? What would you advise someone else to do?
- **Will:** what will you do, by when? How will I know?

## Feedback, both ways
- From me (specific, with an example; care personally and challenge directly):
- From you to me:

## Competency focus this quarter
[From the self-assessment.] Progress since last time:

## Commitments
| Who | What | By when |
|---|---|---|
| [Name] | | |
| [Manager] | | |

## What I owe you
[Introductions, decisions, air cover, resources.]

## For a first 1:1, also ask
- What frustrates you at work, and how will I be able to tell?
- How do you like to get feedback and recognition: in public or in private?
- What would make our 1:1s useful to you?
- What are your short- and long-term goals? What do you need from me, the team and your peers?
- Do you have enough challenge, time to reflect and timely feedback right now?

Prompts

Goal: Get a first stakeholder map grounded in what people have actually said, not in your memory.
Paste in (or connect the harness to): CRM notes, support tickets, chat threads, meeting notes and the org chart for the initiative. Use only tools approved for internal and customer data, and do not paste private conversations about colleagues into an unapproved model.

For [initiative], build a stakeholder map. List every internal and external stakeholder who appears in the material or the org chart.

For each person give: role and team; power over this initiative (high, medium or low, with the reason); interest (high, medium or low); quadrant (manage closely, keep satisfied, keep informed, monitor); current stance (champion, supporter, neutral, skeptic or blocker); what they appear to be measured on; what they seem worried about. Cite the source and date for every stance and concern.

Then:
1. Flag high-power, low-interest stakeholders who could block late, such as security, legal, finance or procurement.
2. Flag anyone whose stance has changed in the last 30 days, with the evidence.
3. Write "No evidence" wherever the material doesn't support a field. Don't guess stance from job title.

Check the output: open three of the cited sources and confirm they say what the map claims. Correct any stance you know to be wrong from direct conversation, and note why.

Goal: Walk into each one-on-one before a decision knowing the likely objection and the evidence that answers it.
Paste in: the DACI document, the stakeholder map, and anything each Contributor has said on the topic. Use an approved tool.

For each Contributor and Must-agree stakeholder on this DACI document, write a half-page pre-wiring brief:
- What they have said about this decision or topic, with sources and dates.
- What they are measured on, and how each option affects that measure.
- The objection they are most likely to raise.
- The evidence in the DACI data section that addresses it, or a note that no evidence covers it.
- One thing I could offer that they value (information, task help, visibility or direction).
- One question I should ask them rather than tell them.

Ground positions in cited statements. If someone has not addressed the topic, identify the gap and suggest a question.

Check the output: any brief where the "likely objection" isn't supported by a source is a guess; treat it as a question to ask, not a position to rebut.

Goal: Turn a long debate into a decision document with clear rights and real options.
Paste in: the discussion thread or meeting notes, relevant data (metrics, eval results, incident reviews, cost), and who you think should hold each role.

Draft a DACI decision record for [decision]. Use this structure: the decision phrased as a question; status, impact and due date; people (Driver, one Approver, Must agree if legal or security can block, Contributors, Informed); one- or two-sentence background; relevant data with sources; decision factors; at least three options with description, pros, cons, resources and cost, and whether each meets the must-agree requirements; action items; outcome left blank.

Rules:
- Name exactly one Approver. If the thread suggests several people believe they decide, flag it as the first issue to resolve.
- Present each option in its strongest form, including options I seem to disfavor.
- Separate facts from the thread from opinions in it.

Check the output: rewrite the options section yourself. Ask the person most likely to disagree whether their preferred option is represented fairly before you circulate it.

Goal: Answer a stakeholder request on the same criteria as the rest of the roadmap, and say no well when you need to.
Paste in: the request as written, the current roadmap themes and their success metrics, and (or connect the harness to) CRM and support data. Use only tools approved for customer data.

A stakeholder has asked for: [request]. 

1. Rewrite the request as a problem: who is affected, in what situation, what it costs them and how we'd measure success.
2. Using the CRM and support data, estimate how many customers share the problem and what revenue is attached. Show the evidence and how you counted.
3. Compare the problem against the roadmap themes and metrics. Where does it rank, and what would it displace?
4. Recommend one response: "not now, and here is when we'll revisit," "yes, if" (state what drops), "no, and here is an alternative," or "no, and here is why."
5. Draft a short written reply to the requester in that form. Keep it respectful and specific, and say no to the request, not the person.

Check the output: verify the customer count against a second source before sending. Make sure the reply names a date or a condition for revisiting, not a vague "later."

Goal: Give your manager decisions, risks and asks on one page, every week.
Paste in (or connect the harness to): this week's metric readouts, the decision log, the risk list, project trackers and notes from key meetings.

Draft my weekly update to [manager] for [product]. Use four headings:
1. Outcomes moved: the North Star and two or three input metrics, with this week's change and a one-line explanation.
2. Decisions needed: each with my recommendation, the deadline and the cost of delay.
3. Risks: anything my manager would not want to hear about from someone else, with what I'm doing about it.
4. Asks: specific help, introductions or air cover.

Keep it under 300 words. No activity lists. If a metric moved for a reason you can't explain from the data, say "cause unknown" rather than guessing.

Check the output: would your manager learn anything here they'd be surprised to hear in another meeting next week? If something is missing, add it yourself.

Goal: Ground a PM competency conversation in evidence rather than impressions.
Paste in (or connect the harness to): the competency self-assessment template, the person's documents, decisions, launches and metric results from the last two quarters. Use an approved tool; this is personnel information.

For [name], at [level], gather evidence for each competency in the self-assessment. For each competency:
- List up to three pieces of evidence from the last two quarters, with links and dates.
- Note where evidence is thin or missing.
- Don't assign ratings. Ratings are for the person and their manager.

Then suggest two competencies where focused development would have the most effect on the person's current work, and propose one real piece of upcoming work that would exercise each.

Check the output: the person should review the evidence list first and add what the harness missed. Treat missing evidence as a question, not a judgment.

Goal: Give a PM between-session coaching grounded in your team's context, while keeping human coaching for judgment and career.
Paste in: the team charter, the product strategy, the competency model, and the PM's chosen development focus for the quarter. Use an approved tool.

Act as a product coach for [name], a [level] PM on [team]. Use the charter, strategy and competency model below as your context.

How to coach:
- Use the GROW structure: ask about the Goal, then the Reality with evidence, then Options, then what they Will do and by when.
- Ask before you advise. Offer at most one suggestion per turn, and only after the person has described the situation.
- Hold them to outcomes, not output. If they describe a feature, ask what problem and metric it serves.
- Challenge directly when their plan contradicts the strategy or the evidence, and say why.
- If they raise a career, compensation, conflict with a colleague or wellbeing issue, tell them to take it to their manager.

[charter, strategy, competency model, development focus]

Check the output: in your next human 1:1, ask the PM what the coach told them that week and whether they disagreed with any of it. Expect answers to vary between sessions, and correct the setup if it drifts from your team's way of working.

Anti-patterns

Checklist

• Internal and external stakeholders are mapped on separate power-interest grids, with stance, currency and a desired position with a date.
• Gatekeepers who can block late (security, legal, finance, procurement) are in “manage closely” well before launch.
• An engagement plan sets an objective, channel, cadence, owner and engagement signal for each key stakeholder.
• Stance ratings are refreshed at least quarterly from evidence of what people said or did.
• The next contentious decision has a DACI record with one Approver, explicit Must-agree roles and at least three options.
• Every Contributor was pre-wired before the decision meeting.
• Decisions, rejected options and recorded disagreements are in a decision log.
• Requests from other functions arrive as problems through one intake and get a written answer with a reason.
• Your manager gets a weekly written update led by decisions needed, risks and asks.
• Your team has a charter with outcome metrics and baselines, decision rights, working agreements, an escalation path and a review date.
• Every PM you lead or coach has a competency self-assessment with evidence and one or two development focuses for the quarter.
• 1:1s follow the report’s agenda, coach one real problem and end with commitments on both sides.
• Eval regressions, incidents and slipped dates have a defined, safe path to be raised early.
• Any change to team shape for AI follows a reskilling plan and outcome data, not output data alone.