Translate Customer Needs into Engineering Requirements

{"category":"operations","description":"Use when an FDE or solution consultant owns the conversion of observed customer needs into a clear, testable engineering specification for product or implementation teams. The output is an implementation-ready problem and requirement definition, not a commitment that engineering has accepted a roadmap date. Do not use when the request is only a bug reproduction or an already-approved change ticket.","inputSchema":{"additionalProperties":false,"properties":{"customer":{"description":"Customer or engagement identifier.","minLength":1,"type":"string"},"knownConstraints":{"description":"Platform, integration, security, contractual and delivery constraints.","items":{"type":"string"},"type":"array"},"requestOrProblem":{"description":"User request, observed pain, or desired workflow.","minLength":1,"type":"string"},"sourceMaterial":{"description":"Customer interviews, recordings, support cases, examples, and relevant specs.","items":{"type":"string"},"type":"array"}},"required":["customer","requestOrProblem"],"type":"object"},"schemaVersion":1,"steps":[{"expectedOutputs":[{"description":"Problem statement, affected users, evidence, impact and unknowns.","kind":"validated-problem"}],"id":"93TF","instructions":"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.\n\nV2 practical protocol:\nProblem 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.","resourceHints":[],"title":"Find the underlying job and verify demand"},{"expectedOutputs":[{"description":"Scope and non-goals, alternatives, constraints and decisions.","kind":"scope-options"}],"id":"R0HW","instructions":"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.\n\nV2 practical protocol:\nRequirement 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.","resourceHints":[],"title":"Bound scope and compare solution directions"},{"expectedOutputs":[{"description":"Structured PRD with prioritized requirements, non-goals and acceptance criteria.","kind":"requirements-spec"}],"id":"0VDA","instructions":"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.\n\nV2 practical protocol:\nTraceability 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.","resourceHints":[{"kind":"skill","ref":"github:anthropics/knowledge-work-plugins","selector":"product-management/skills/write-spec"}],"title":"Write a testable PRD or technical specification"},{"expectedOutputs":[{"description":"Reviewed specification, edge-case checklist, and decision/open-question register.","kind":"reviewed-spec"}],"id":"08WP","instructions":"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.\n\nV2 practical protocol:\nReview 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.","resourceHints":[],"title":"Review feasibility, edge cases and acceptance"},{"expectedOutputs":[{"description":"Estimation-ready PRD with acceptance tests, constraints and explicit approval status.","kind":"engineering-ready-prd"}],"id":"XIR0","instructions":"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.\n\nV2 practical protocol:\nReady-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.","resourceHints":[],"title":"Make the specification ready for engineering commitment"}],"title":"Translate Customer Needs into Engineering Requirements"}