Engineering Brief

You are writing an engineering brief — the document that translates a product decision into the context engineers need to make good technical choices, ask the right questions, and estimate accurately.

The goal is not to tell engineers how to build — it's to give them the "why" so they can make better decisions about "how". Engineers who understand the problem are more likely to propose better solutions than the PM thought of.

Step 1 — Load Context

Read

memory/user-profile.md

for stack context (issue tracker, code repo, technical context if known). Read the PRD or feature description provided.

Step 2 — Engineering Brief Structure

Context (why this matters): 2–3 sentences on the user problem being solved. Why now? What signals drove this prioritization? Engineers who understand the problem often find better solutions than the PM specified.

What we're building: A plain-language description of the feature — not technical jargon, just what the user can do. Include key flows in numbered steps. Keep it close to the PRD.

What we're NOT building: Explicit out-of-scope items. This is the most important section for preventing scope creep. Each item should have a brief rationale (why it's excluded).

Success criteria: The measurable outcomes that define success. These are the product success metrics — engineers should know what their work is optimizing for, not just whether it shipped.

Acceptance criteria: The binary, testable criteria from the PRD. Engineers use these for implementation decisions and QA uses them for testing.

Technical unknowns (from PM perspective): The things the PM knows are uncertain from a technical perspective and wants engineering input on. This invites engineering into the problem, not just the solution.

Examples:

• "We want < 500ms latency for this action — is that feasible with the current [stack detail]? What would be the trade-off?"
• "We need this to work offline — is that achievable in Phase 1 or should it be Phase 2?"
• "The design calls for real-time updates — is WebSocket the right approach here or would polling work at our scale?"

Decision points that need engineering input: Specific decisions where the PM needs engineering expertise. Be explicit about what kind of input is needed:

• "Need an estimate on feasibility and rough timeline before kickoff"
• "Need a recommendation on approach A vs. approach B"
• "Need to know if [dependency] is in place or if we need to build it"

Timeline context: When this needs to ship, what drives the date (if anything), and how firm the date is. This helps engineering make scope-priority tradeoffs without needing to ask.

Definition of done: Engineering-level definition — what does "complete" mean for this work? Include: feature-flagged? In staging? In prod? All tests passing? Metrics instrumented?

Step 3 — What to Leave Out

Do NOT include in the engineering brief:

• Market research or competitive analysis (not relevant to implementation)
• Stakeholder politics or organizational context
• Long-term roadmap items that aren't part of this sprint
• Design opinions that should be left to the designer's judgment

Step 4 — Output

Produce the engineering brief. Offer to:

• Create a Linear or Jira epic/ticket from this brief (if MCP connected)
• Save to

  outputs/eng-brief-[feature]-[date].md