Translate Customer Needs into Engineering Requirements

Steps

1. 1

   Find the underlying job and verify demand

   Reconstruct the triggering workflow, actors, frequency, current alternative, breakdowns and measurable consequences from customer evidence. Distinguish directly observed user need from a proposed feature solution. Capture examples, counterexamples, stakeholder disagreements and the number of distinct customers affected when visible. Validate where the request fits the intended product or deployment strategy. Gate: the team can articulate the user problem and business reason independently of any proposed implementation.

   V2 practical protocol:
   Problem evidence template: customer role, job-to-be-done, trigger, actual example, frequency, impact, current workaround, requested feature, strength of evidence and contrary examples. Assign provisional requirement identifiers only after the user outcome is clear, e.g. R-001; do not treat every raw request as a requirement. Trace observed problems to user impact and intended measurable outcomes, keeping customer-specific exceptions visible. If no user example exists, design a targeted validation question before committing to product scope.

   Expected outputs
2. 2

   Bound scope and compare solution directions

   Draft functional outcomes, in-scope workflows, non-goals, quality attributes, integration boundaries, data constraints, exceptions, and dependencies. Explore at least one simpler workaround and one full solution; note trade-offs and reusable versus customer-specific work. Seek engineering/product input on critical feasibility or architecture claims rather than assuming them. Distinguish contractual commitments from wishes. Gate: solution direction can be chosen with risk and scope clearly visible.

   V2 practical protocol:
   Requirement boundaries: for each proposed solution compare status quo, workflow workaround, minimal reusable product change and customer-specific customization. Record goals/non-goals, supported and unsupported actors, data ownership, integration surfaces, failure and recovery behavior, latency/load/security needs, contract restrictions and dependency assumptions. Flag whether requests change product strategy or security model and require product/engineering approval. Reserve IDs for requirements only when sufficiently testable; avoid writing architecture as if it were customer-approved fact.

   Expected outputs
3. 3

   Write a testable PRD or technical specification

   Use write-spec if accessible for structure and acceptance-criteria discipline; otherwise create a self-contained PRD. Include problem, users/personas, goals, scope/non-goals, user journeys, requirements prioritized by criticality, exception cases, permission/security behavior, integrations, measurable success metrics and explicit assumptions. Each requirement must be independently testable; avoid vague words such as fast, easy or secure without acceptance criteria. Gate: an engineer and QA reviewer can infer the required behavior without reverse-engineering a sales conversation.

   V2 practical protocol:
   Traceability table: Requirement ID | user problem evidence | priority (Must/Should/Could) | behavior and boundary | acceptance scenario ID | system/data dependency | non-goal/exception | status/open question. For each acceptance criterion use Given [context], When [event], Then [observable outcome], with explicit failure/permission behavior and measurable units where relevant. Separate functional behavior from nonfunctional constraints and operational requirements. Refer to the optional write-spec skill for structure if accessible but preserve this minimum in the playbook itself. Each Must requirement needs at least one positive and one material negative/error test, or an explicit explanation why not applicable.

   Skills anthropics/knowledge-work-plugins · product-management/skills/write-spec · github

   Expected outputs
4. 4

   Review feasibility, edge cases and acceptance

   Review the draft with engineering, product, security/data owner and customer-facing owner where relevant. Challenge missing edge cases, error and recovery behavior, scale assumptions, integration ownership, dependencies and build-versus-buy. Record conflicts, decisions and open issues in the document without silently choosing for the team. Define what customer acceptance can observe versus what only engineering tests can validate. Gate: material ambiguities are resolved or labeled as blockers before implementation is promised.

   V2 practical protocol:
   Review protocol: walk one happy path, one permission failure, one bad input/empty result, one integration error/retry and one scaling/latency constraint relevant to the use case. Verify that every Must has an acceptance test and every high-risk acceptance test maps to a requirement; identify dangling needs, untestable adjectives and implied product promises. Engineers review feasibility, QA reviews testability, product reviews priority, security/privacy reviews access/data impact, and customer-facing owner reviews user outcome. Record disagreement and authority rather than guessing consensus.

   Expected outputs
5. 5

   Make the specification ready for engineering commitment

   Present a concise change summary, recommended scope, remaining assumptions, test cases, priorities, dependencies and measurable acceptance. Separate a ready-to-estimate specification from an approved development commitment. Obtain acknowledgement of feasibility or identify exact missing decisions; do not imply sprint, budget or delivery-date approval. The final result is the quality of the spec itself, without adding an unrelated generic handoff ceremony. Gate: the receiving team can estimate and plan from the artifact and knows which issues remain unresolved.

   V2 practical protocol:
   Ready-to-estimate gate: requirement IDs unique, top problem traceable to evidence, non-goals explicit, external dependencies and data contracts stated, Must-level acceptance criteria independently verifiable, severity of unresolved risks identified, and actual review status documented. Produce two short views if needed: engineering estimation detail and a customer-facing outcome summary that does not reveal internal implementation assumptions. Make clear that an estimate-ready PRD is not a delivery-date, budget or roadmap commitment.

   Expected outputs