# Technical Translator

> Translate a technical document (API spec, architecture doc, RFC, eng proposal) into PM-friendly language. What it means for the product and users.

- Skill: `mehdibargach/technical-translator` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mehdibargach/technical-translator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mehdibargach/technical-translator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: Mehdibargach (https://skillmd.com/u/mehdibargach)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/mehdibargach/technical-translator

---


# Technical Translator

Read a technical document and translate it into language a PM can act on. Not dumbed down — translated. The goal is to preserve nuance while making it actionable for product decisions.

## Process

1. Read the technical document at the provided file path.
2. Identify the core technical concepts, decisions, and trade-offs.
3. Translate each into product and user impact.
4. Flag what the PM must understand versus what is nice-to-know context.
5. Surface decisions the PM needs to make or influence.
6. List questions the PM should bring to engineering.
7. Save the output to a file in the current working directory as `translated-[original-filename].md`.

## Output Format

### TL;DR
1-2 sentences. What is this document about and why should the PM care?

### What This Means for the Product
- How does this change what we can build?
- Does this open new capabilities or close off options?
- Does this affect our roadmap or timelines?
- Any impact on product architecture or platform strategy?

### What This Means for Users
- Will users notice anything? (Performance, UI changes, new features, breaking changes)
- Does this affect specific user segments differently?
- Any migration, downtime, or behavior changes users need to know about?
- Impact on user data, privacy, or security?

### Key Decisions the PM Needs to Make
For each decision:
- What is the decision?
- What are the options?
- What are the trade-offs (in product terms, not technical terms)?
- What is the engineering team's recommendation and why?

### Questions to Ask Engineering
- Clarifying questions the PM should bring to the next sync
- "What happens if..." scenarios that aren't addressed in the doc
- Timeline and resource implications to validate

### Risks
- Technical risks translated to product impact ("If the migration fails, users will experience X")
- Timeline risks
- Dependency risks
- Things the doc assumes that might not be true

### Glossary (if needed)
- Technical terms used in the document with plain-language definitions
- Only include terms the PM will encounter again — skip one-off jargon

## Rules

- Do not dumb down. Translate. A PM reading this should understand the nuance, not a watered-down version.
- Clearly separate what the PM MUST understand (affects decisions) from nice-to-know context.
- When translating trade-offs, always frame them in terms of user impact, timeline impact, or cost impact.
- If the technical document is ambiguous, flag the ambiguity rather than guessing.
- Preserve the original document's structure references so the PM can go back to the source for specific sections.
- If the document contains code, don't reproduce the code — explain what it does and why it matters.
- Never invent product implications that aren't supported by the technical content.