# Pm User Translation

> Bidirectional translation between Product Managers and Users. Helps PMs explain features in user-friendly language, and helps Users articulate pain points into actionable requirements. Bridges the gap between product thinking and user needs.

- Skill: `mcltyl/pm-user-translation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mcltyl/pm-user-translation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mcltyl/pm-user-translation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mcltyl (https://skillmd.com/u/mcltyl)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mcltyl/pm-user-translation

---


# PM ↔ User Translation Skill

## Purpose

Bridge the communication gap between Product Managers and Users by translating concepts bidirectionally:

- **PM → User**: Explain features, changes, and decisions in user-friendly language
- **User → PM**: Transform vague pain points into clear, actionable requirements

## When to Activate

**Activation conditions (any one triggers):**
- PM needs to write release notes, help docs, or announcements
- User feedback needs to be translated into product requirements
- Explaining why a feature works a certain way
- Conducting user interviews and synthesizing insights
- Writing user-facing copy for features

## PM → User Translation

### Input: Feature/Technical Change
### Output: User-Friendly Explanation

**Translation Framework:**

1. **What Changed** → **What You Can Do Now**
   - "We implemented OAuth 2.0" → "You can now sign in with Google"
   - Lead with benefit, not mechanism

2. **Why We Built It** → **How It Helps You**
   - "Improved infrastructure" → "The app loads 2x faster"
   - Connect to daily experience

3. **How It Works** → **Simple Mental Model**
   - Use analogies to familiar concepts
   - 3 steps maximum

4. **Limitations** → **What to Expect**
   - Be honest about what it doesn't do
   - Set correct expectations upfront

### Template: Feature Announcement

```markdown
## [Feature Name]: [One-line benefit]

### What's New
You can now [action] to [benefit].

### How It Works
1. [Step 1]
2. [Step 2]
3. [Step 3]

### Good to Know
- [Important limitation or context]
- [Tip for getting the most out of it]

### Questions?
[Where to get help]
```

### Template: Why We Built It This Way

```markdown
## Why [Feature] works like this

**You asked:** [Common user question/complaint]

**The short answer:** [1-2 sentences]

**The longer story:**
[Context about constraints, trade-offs, or design decisions]
[Written like a human explaining to a friend]

**What's next:**
[Future improvements if any, or why this is the final design]
```

## User → PM Translation

### Input: User Feedback/Pain Point
### Output: Actionable Requirement

**Translation Framework:**

1. **Complaint** → **Underlying Need**
   - "This button is stupid" → "User expects X but gets Y"
   - Dig past the surface complaint

2. **Feature Request** → **Job to Be Done**
   - "Add a calendar view" → "User needs to see time-based patterns"
   - Understand the goal, not just the solution

3. **Confusion** → **Mental Model Gap**
   - "I don't get how this works" → "System model ≠ user expectation"
   - Map where understanding breaks down

4. **Workaround** → **Unmet Need**
   - "I export to Excel and then..." → "Missing feature: [X]"
   - Workarounds reveal product gaps

### Template: User Feedback → Requirement

```markdown
## Insight: [Title]

### Raw Feedback
> "[Exact quote from user]"
— [User type/context]

### Translation
**What they said:** [Surface complaint/request]
**What they meant:** [Underlying need]
**Job to be done:** [What they're trying to accomplish]

### Evidence Strength
- [ ] Single user mention
- [ ] Multiple users (N = ?)
- [ ] Behavioral data supports this
- [ ] Revenue/retention impact observed

### Potential Solutions
1. [Option A] — Effort: [L/M/H], Impact: [L/M/H]
2. [Option B] — Effort: [L/M/H], Impact: [L/M/H]

### Open Questions
- [What we need to validate]
```

## User Interview Translation

### Questions That Uncover Real Needs

| Instead of | Ask |
|------------|-----|
| "Would you use X?" | "Tell me about the last time you [did related task]" |
| "Do you like this?" | "What would you do differently?" |
| "Is this useful?" | "How are you solving this today?" |
| "Any feedback?" | "What's the most frustrating part of [workflow]?" |

### Translating Vague Feedback

| User Says | Underlying Need | PM Action |
|-----------|-----------------|-----------|
| "It's confusing" | Mental model mismatch | Map user expectation vs. system behavior |
| "Too slow" | Perceived performance issue | Measure actual vs. perceived speed |
| "I want [competitor feature]" | Unmet job-to-be-done | Understand the job, not the solution |
| "It's fine" | Unexpressed friction | Observe behavior, don't trust words |
| "I don't use it" | Activation failure | Identify where journey breaks down |

## Common Pitfalls

### PM → User Pitfalls
- ❌ Jargon ("We optimized the API latency")
- ❌ Feature-first ("New dashboard!")
- ❌ Assuming context ("As you know...")
- ✅ Benefit-first, plain language, assume nothing

### User → PM Pitfalls
- ❌ Taking requests literally ("They said add a button")
- ❌ Ignoring negative feedback ("Just one user")
- ❌ Asking leading questions ("Wouldn't it be great if...?")
- ✅ Translate to needs, look for patterns, stay neutral

## Response Principles

- Write at 8th-grade reading level for user-facing content
- Lead with benefits, follow with mechanics
- One idea per sentence, one topic per paragraph
- Always translate both directions — PM thinking ↔ User language
- Validate translations — "Did I understand correctly that...?"

## Saying No to Users

One of the hardest PM skills. How to decline requests gracefully.

### The Framework: Acknowledge → Explain → Redirect

**1. Acknowledge** the need (not the solution)
**2. Explain** why we can't/won't (honest, brief)
**3. Redirect** to alternative or future possibility

### Template: Declining a Feature Request

```markdown
"Thanks for this suggestion — I can see how [underlying need] 
is important for your workflow.

We're not building this right now because [honest reason]:
- [Constraint 1]
- [Constraint 2]

What you can do instead:
- [Workaround 1]
- [Workaround 2]

I'm adding this to our feedback log. If more users share this 
need, it'll influence our roadmap."
```

### Honest Reasons (Pick One)

| If true... | Say... |
|------------|--------|
| Not enough users need it | "This affects a small % of users, so we're prioritizing X which helps more people" |
| Technically hard | "This would require rebuilding [system], which delays other features you've asked for" |
| Doesn't fit strategy | "We're focused on [direction]. This pulls us toward [different direction]" |
| Resource limited | "Our team is focused on [priority]. Adding this means delaying [other thing]" |
| Bad idea (nicely) | "We've seen [pattern] suggesting this might create more problems than it solves" |

### What NOT to Do

- ❌ "We'll consider it" (meaningless)
- ❌ "Great idea, added to backlog" (backlog graveyard)
- ❌ "Not in our roadmap" (sounds bureaucratic)
- ❌ Ghost them (worst)
- ❌ Blame others ("Engineering said no")

## Managing User Expectations

### Setting Expectations Proactively

**Release communication template:**
```markdown
## What's New in v2.3

### ✅ Now Available
- [Feature 1]: [One-line benefit]
- [Feature 2]: [One-line benefit]

### 🔄 Coming Soon
- [Feature]: [Expected timeframe]

### ℹ️ Known Limitations
- [Limitation]: [Why + workaround if any]

### 💬 Feedback?
[Where to send feedback]
```

### When You'll Miss a Promised Date

**Template:**
```markdown
Subject: Update on [Feature] timeline

Hi [Name],

I want to give you an honest update. [Feature] won't ship by 
[original date] as planned. New target: [new date].

**What happened:** [Brief, honest explanation — not excuses]

**What this means for you:** [Impact on their workflow]

**What we're doing:** [Actions to hit new date]

I'm sorry for the delay. [If appropriate: compensation/alternative]

[Your name]
```

## Handling Angry Users

### De-escalation Framework

**1. Validate** — "I understand this is frustrating"
**2. Clarify** — "Let me make sure I understand the issue"
**3. Own** — "This shouldn't have happened" (if true)
**4. Act** — "Here's what we're doing right now"
**5. Follow up** — "I'll update you by [time]"

### Template: Responding to Angry User

```markdown
"I hear you — this is frustrating, and I'm sorry you're dealing 
with it.

Let me make sure I understand: [restate the problem].

Here's what's happening right now:
1. [Immediate action]
2. [Timeline for resolution]

I'll personally follow up by [specific time] with an update.

[If appropriate:] This shouldn't have happened. We're looking 
into how it did and how to prevent it."
```

### What to Avoid with Angry Users

| ❌ Don't | ✅ Do |
|---------|------|
| "Calm down" | "I understand this is frustrating" |
| "That's not our fault" | "Let me see what happened" |
| "Per our policy..." | "Here's what I can do" |
| Copy-paste response | Personalize with their specifics |
| Promise what you can't deliver | Under-promise, over-deliver |