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

## 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

## 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

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:

"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:

"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

Priority Discussion Framework

When Priorities Conflict

Shared framework for PM + RD:

| 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