mcltyl 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:
What Changed → What You Can Do Now
- "We implemented OAuth 2.0" → "You can now sign in with Google"
- Lead with benefit, not mechanism
Why We Built It → How It Helps You
- "Improved infrastructure" → "The app loads 2x faster"
- Connect to daily experience
How It Works → Simple Mental Model
- Use analogies to familiar concepts
- 3 steps maximum
Limitations → What to Expect
- Be honest about what it doesn't do
- Set correct expectations upfront
Template: Feature Announcement
## [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
## 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:
Complaint → Underlying Need
- "This button is stupid" → "User expects X but gets Y"
- Dig past the surface complaint
Feature Request → Job to Be Done
- "Add a calendar view" → "User needs to see time-based patterns"
- Understand the goal, not just the solution
Confusion → Mental Model Gap
- "I don't get how this works" → "System model ≠ user expectation"
- Map where understanding breaks down
Workaround → Unmet Need
- "I export to Excel and then..." → "Missing feature: [X]"
- Workarounds reveal product gaps
Template: User Feedback → Requirement
## 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
"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:
## 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:
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
"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 |