# Pm Engineer Translation

> Bidirectional translation between Product Managers and Engineers. Helps PMs translate requirements into technical specs, and helps Engineers explain technical constraints to PMs. Bridges the communication gap between product and engineering.

- Skill: `mcltyl/pm-engineer-translation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mcltyl/pm-engineer-translation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mcltyl/pm-engineer-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-engineer-translation

---


# PM ↔ Engineer Translation Skill

## Purpose

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

- **PM → RD**: Translate product requirements into technical specifications
- **RD → PM**: Translate technical constraints into business impact

## When to Activate

**Activation conditions (any one triggers):**
- PM needs to write technical requirements or specs
- Engineer needs to explain technical debt or constraints to PM
- Miscommunication between product and engineering teams
- Need to estimate effort or explain why something is complex
- Translating user stories into technical tasks

## PM → RD Translation

### Input: Product Requirement
### Output: Technical Specification

**Translation Framework:**

1. **What** → **System Behavior**
   - "Users should be able to..." → "The system shall..."
   - Focus on observable behavior, not implementation

2. **Why** → **Context & Constraints**
   - Business context engineers need to make good decisions
   - What's flexible vs. non-negotiable

3. **Acceptance Criteria** → **Test Cases**
   - "It should feel fast" → "Response time < 200ms at p95"
   - Quantify whenever possible

4. **Edge Cases** → **Error Handling**
   - What happens when things go wrong?
   - Expected behavior for invalid inputs

### Template: PM → RD

```markdown
## Feature: [Name]

### Business Context
Why we're building this. What problem it solves. Who it's for.

### System Behavior
- GIVEN [precondition]
- WHEN [action]
- THEN [expected result]

### Constraints
- Performance: [specific metrics]
- Security: [requirements]
- Compatibility: [platforms/versions]

### Out of Scope
What this feature explicitly does NOT do.

### Open Questions
Technical decisions that need engineering input.
```

## RD → PM Translation

### Input: Technical Constraint
### Output: Business Impact

**Translation Framework:**

1. **Technical Debt** → **Future Cost**
   - "This code is messy" → "Adding features will take 2x longer"
   - "We need to refactor" → "Current architecture can't support X users"

2. **Complexity** → **Time & Risk**
   - "This is hard" → "3 weeks instead of 3 days, with these risks..."
   - Always provide alternatives with trade-offs

3. **Dependencies** → **Blockers & Sequencing**
   - "We need X first" → "Without X, we can only do partial solution"
   - Make sequencing constraints visible

4. **Technical Risk** → **Business Risk**
   - "This might break" → "10% chance of 4-hour downtime"
   - Translate probability × impact

### Template: RD → PM

```markdown
## Technical Situation: [Name]

### The Challenge
Plain English explanation. No jargon.

### Business Impact
- What this means for users
- What this means for timeline
- What this means for future features

### Options

**Option A: [Name]**
- Effort: [X days/weeks]
- Trade-off: [What we give up]
- Risk: [What could go wrong]

**Option B: [Name]**
- Effort: [X days/weeks]
- Trade-off: [What we give up]
- Risk: [What could go wrong]

### Recommendation
Which option and why.
```

## Common Translation Patterns

| PM Says | RD Hears | Better Translation |
|---------|----------|-------------------|
| "Simple feature" | Underestimated | "Here's the scope, help me understand complexity" |
| "ASAP" | No planning | "Here's the priority context, when can we ship?" |
| "Just like [competitor]" | Reverse engineer | "Here's the user outcome we want, what's our approach?" |

| RD Says | PM Hears | Better Translation |
|---------|----------|-------------------|
| "Technical debt" | Excuse | "Current system limits us to X, fixing enables Y" |
| "It's complicated" | Pushback | "Here are 3 options with trade-offs, I recommend..." |
| "Edge case" | Over-engineering | "This affects X% of users, here's the impact if we skip" |

## Anti-Patterns

### PM Anti-Patterns
- ❌ Specifying implementation ("use React")
- ❌ Hiding constraints discovered late
- ❌ "Just make it work" without acceptance criteria
- ✅ Describe the outcome, let engineering choose the path

### RD Anti-Patterns
- ❌ "You wouldn't understand" (condescension)
- ❌ Only saying no without alternatives
- ❌ Technical jargon without translation
- ✅ Always provide options with trade-offs

## Response Principles

- Translate, don't advocate — help both sides understand each other
- Quantify whenever possible — "slow" → "2 seconds", "risky" → "20% chance"
- Surface assumptions — both sides often have hidden assumptions
- Provide templates — make good communication easy to repeat

## Estimation Negotiation

The most common PM-RD conflict. Here's how to navigate it.

### When RD Estimate Seems High

**PM response framework:**
1. **Understand, don't challenge:** "Help me understand what makes this complex"
2. **Break down:** "Can we split this into smaller deliverables?"
3. **Scope trade-offs:** "What if we cut X? How much time does that save?"
4. **Sequence:** "What's the minimum to learn if this works?"

**Template:**
```markdown
"This is higher than I expected, and I want to understand why.

1. What are the major chunks of work?
2. Which parts have uncertainty we should reduce first?
3. If we had to ship something in half the time, what would you cut?"
```

### When PM Pushes for Faster Delivery

**RD response framework:**
1. **Show the breakdown:** Make work visible
2. **Identify risks:** "Faster = these risks"
3. **Offer trade-offs:** "X weeks if we cut Y"
4. **Protect quality:** Explain tech debt cost

**Template:**
```markdown
"Here's what's in the estimate:

| Task | Days | Can Cut? |
|------|------|----------|
| Core logic | 5 | No |
| Tests | 2 | Risk: bugs in prod |
| Edge cases | 3 | Risk: 10% users affected |

**Options:**
- 10 days: Full scope, production-ready
- 7 days: Skip edge cases, add warning to release notes
- 5 days: Core only, needs fast follow-up

Which trade-off works?"
```

### Estimation Best Practices

| Instead of | Do |
|------------|-----|
| Single point estimate | Range: "5-8 days" |
| Padding silently | Explicit uncertainty: "±30% due to X" |
| Committing under pressure | "Let me break it down first" |
| "It's complicated" | "Here are the 5 things that make this complex" |

## Priority Discussion Framework

### When Priorities Conflict

**Shared framework for PM + RD:**

```markdown
| Item | User Impact | Business Value | Effort | Priority Score |
|------|-------------|----------------|--------|----------------|
| A | High | High | Low | P1 - Do first |
| B | High | Low | High | P2 - Revisit |
| C | Low | High | Low | P2 - Quick win |
| D | Low | Low | High | P3 - Backlog |
```

**Key questions:**
1. "What's the cost of NOT doing this now?"
2. "Does this unblock other work?"
3. "Is this reversible if we're wrong?"

## PM Participation in Technical Discussions

### When PM Should Join Tech Discussions

✅ **Join when:**
- Architecture decisions affect user experience
- Trade-offs need business input
- Estimating new feature areas
- Post-mortems with user impact

❌ **Skip when:**
- Implementation details within agreed scope
- Internal refactoring
- Routine bug fixes

### How PM Should Participate

**Do:**
- Listen first, ask clarifying questions
- Provide business context when asked
- Share user insights that inform decisions
- Say "I defer to engineering on this"

**Don't:**
- Suggest technical solutions
- Push for specific implementation
- Attend to "supervise"
- Make engineers justify every decision