Use this when a client has overlapping roles (ProdOps / PM / PMM / PMO / others) causing friction, confusion, or duplicated effort — and needs a structured way to sort it out.
How it works
- You describe which roles overlap and where the friction is
- The skill generates a RACI-style activity map and facilitation plan
- It returns a ready-to-run workshop with discussion prompts and a decision framework
Prompt
You are designing a role clarity workshop for Kate Makrigiannis. Kate is a product strategist and consultant. She uses this when clients are scaling, adding new functions (like product ops), or experiencing role confusion between adjacent functions. The goal is not to create rigid job descriptions — it's to create shared understanding and reduce friction.
Inputs I will provide:
- Roles involved: {{ROLES}} (e.g., "Product Ops, PM, PMM", or "PM, Engineering Manager, TPM")
- Org context: {{ORG_CONTEXT}} (company size, stage, team structure)
- Friction points: {{FRICTION}} (specific examples of overlap, confusion, or conflict)
- Who asked for this (optional): {{REQUESTER}} (e.g., "VP of Product", "the product ops manager", "the PMs themselves")
Step 1: Map the activity landscape
Based on the roles and friction points, identify 15-25 key activities that these roles share or contest. Group them by domain:
- Customer & Market (feedback collection, user research, competitive analysis, customer communication)
- Strategy & Planning (roadmap ownership, goal setting, prioritization, OKRs)
- Execution & Delivery (sprint management, launch coordination, status reporting, QA)
- Enablement & Communication (internal education, stakeholder updates, documentation, tool management)
- Measurement & Learning (metrics, experiments, dashboards, retrospectives)
Step 2: Create the RACI draft
For each activity, suggest an initial RACI assignment:
- R (Responsible): Does the work
- A (Accountable): Owns the outcome
- C (Consulted): Provides input
- I (Informed): Needs to know
This is a DRAFT — the workshop participants will finalize it. Mark activities where the assignment is genuinely ambiguous with [DISCUSS].
Step 3: Design the facilitation plan
Pre-Workshop
- What to send participants in advance (context, the activity list, their "homework")
- How to frame the purpose (collaboration, not turf war)
Workshop Agenda (90 minutes)
- Opening (10 min): Frame the goal — shared understanding, not rigid boundaries
- Individual reflection (5 min): Each participant marks which activities they think they own
- Reveal and discuss (30 min): Compare answers. Where there's agreement, lock it in. Where there's disagreement, discuss.
- Friction deep-dives (25 min): Pick the top 3 most contested activities. For each, use the "Core Customer" test: who is the primary customer of this activity? That often clarifies ownership.
- Decision framework (10 min): Agree on a decision principle for future ambiguity (e.g., "when in doubt, the role closest to the customer owns it")
- Close and next steps (10 min): Capture decisions, assign follow-ups, schedule 30-day check-in
Post-Workshop
- How to document and share decisions
- 30-day check-in template
- How to handle new ambiguities that arise
Step 4: Add the "Core Customer" decision framework
For each role, articulate who their core customer is:
- Product Ops → PMs and the product team
- PM → End users and the business
- PMM → Sales, prospects, and external market
- PMO/TPM → Engineering and delivery teams
When ownership is unclear, ask: "Who is the primary customer of this activity?" The role whose core customer benefits most should own it.
Step 5: Generate output
Context
Why this workshop is happening and what success looks like.
Activity Map (RACI Draft)
Table of all activities with suggested RACI assignments and [DISCUSS] markers.
Facilitation Plan
Pre-workshop prep, 90-minute agenda with timing and facilitator notes, post-workshop follow-up.
Core Customer Decision Framework
Role-by-role core customer mapping for resolving future ambiguity.
Common Pitfalls
3-5 things to watch out for during the workshop (e.g., "the loudest person claims everything", "people agree in the room but revert after", "nobody wants to own the unglamorous stuff").
For diagnosing the product ops function before facilitating role clarity, use the product-ops-assessment skill. For team formation exercises, use team-user-manual.
Examples
Input
- Roles: "Product Ops, PM, PMM"
- Org context: "Series C, 120 people, 6 PMs, 1 product ops manager (6 months in), 2 PMMs"
- Friction: "PMM and product ops both think they own customer feedback routing. PMs don't know who to go to for launch coordination. Product ops and PMM both create enablement materials for sales."
Output (abbreviated)
Activity Map (excerpt):
| Activity | Product Ops | PM | PMM |
|---|---|---|---|
| Customer feedback routing | R, A | C | C |
| Launch coordination | R, A | C | C |
| Sales enablement (product) | R | C | I |
| Sales enablement (positioning) | I | C | R, A |
| Competitive analysis | C | C | R, A [DISCUSS] |
| Roadmap communication (internal) | R | A | I |
| Roadmap communication (external) | I | C | R, A |
Facilitation Note on the Friction Points: The feedback routing conflict is a classic "Core Customer" test case. Product ops routes feedback to serve PMs (their core customer). PMM collects market feedback to serve sales and prospects (their core customer). The resolution: Product ops owns the internal feedback system. PMM owns external market intelligence. They sync weekly on overlap...
Example Output
Input
- Roles: "Product Ops, PM, PMM"
- Org context: "Series C, 120 people, 6 PMs, 1 product ops manager (6 months in), 2 PMMs"
- Friction: "PMM and product ops both think they own customer feedback routing. PMs don't know who to go to for launch coordination. Product ops and PMM both create enablement materials for sales."
Output (abbreviated)
Activity Map (excerpt):
| Activity | Product Ops | PM | PMM |
|---|---|---|---|
| Customer feedback routing | R, A | C | C |
| Launch coordination | R, A | C | C |
| Sales enablement (product) | R | C | I |
| Sales enablement (positioning) | I | C | R, A |
| Competitive analysis | C | C | R, A [DISCUSS] |
| Roadmap communication (internal) | R | A | I |
| Roadmap communication (external) | I | C | R, A |
Facilitation Note on the Friction Points: The feedback routing conflict is a classic "Core Customer" test case. Product ops routes feedback to serve PMs (their core customer). PMM collects market feedback to serve sales and prospects (their core customer). The resolution: Product ops owns the internal feedback system. PMM owns external market intelligence. They sync weekly on overlap...