Turn an agreed product discussion into a feature brief
Consolidate settled product decisions into a document engineering can review. Make intended behavior, exclusions, and validation decisions explicit before implementation begins.
How this works
Consolidate settled product decisions into a document engineering can review. Make intended behavior, exclusions, and validation decisions explicit before implementation begins. Use this after stakeholders have settled a product direction and engineering needs a precise brief. The document should expose unresolved decisions instead of turning every idea in the discussion into committed scope.
Read the current behavior and decision evidence, then define intended behavior through concrete examples and acceptance conditions. Keep exclusions, assumptions and open questions explicit. The brief records an agreed direction; it does not establish demand, estimate delivery time or authorize implementation.
Before you start
Decision evidence
Collect the relevant discussion, approvals and current product context.
Implementation context
Inspect existing behavior and terminology in the relevant product area.
Review owners
Identify product and engineering owners who can resolve scope conflicts.
Prepare the inputs
- discussion_record
- Required
dated notes or transcript with decision references
Distinguish proposals, objections and agreed decisions.
- current_behavior
- Required
screens, documentation or relevant code references
Do not describe a guessed baseline as established behavior.
- feature_goal
- Required
user, problem and desired outcome
Keep the scope tied to the agreed problem.
- constraints
- Required
exclusions, dependencies and supported platforms
Mark unresolved constraints rather than invent defaults.
Implementation, step by step
Extract decisions
- Create a ledger of agreed behavior, rejected options and unanswered questions.
- Retain references to the discussion and decision owner.
Checkpoint: The scope has traceable origins.
Inspect the baseline
- Review how the relevant flow currently works.
- Identify terminology and integration constraints that affect the requested change.
Checkpoint: The brief can state before and after behavior accurately.
Define acceptance examples
- Write normal, boundary and failure scenarios before broad prose.
- Resolve ambiguity through observable outcomes rather than vague quality adjectives.
Checkpoint: Acceptance conditions are checkable.
Draft the specification
- Describe problem, users, behavior, exclusions, data needs and dependencies.
- Separate confirmed requirements from assumptions and optional future ideas.
Checkpoint: Engineering can review a bounded feature.
Review readiness
- Ask owners to resolve contradictions and confirm the acceptance examples.
- Record the final version and remaining blockers before implementation planning.
Checkpoint: The brief has a clear ready or blocked state.
Decisions along the way
Stakeholders disagree
Present the conflicting options and owner decision needed.
Current product already supports the request
Document the discovery and clarify whether a change is still needed.
Acceptance cannot be observed
Rewrite it as a testable behavior or mark the requirement unresolved.
What you will produce
feature-brief.md
MarkdownAn implementation-ready brief when open decisions are resolved.
Include: problem · baseline · behavior · acceptance · exclusions · dependencies
decision-ledger.csv
CSVTraceability for scope and unresolved questions.
Include: decision · source · owner · status · affected_requirement
Check the result
- Verify requirements reflect settled decisions rather than brainstormed ideas.
- Check acceptance examples cover failure and empty states.
- Confirm exclusions and dependencies are explicit.
- Have engineering validate the described current behavior.
When something goes wrong
Discussion evidence is incomplete
Draft a gap list and avoid claiming agreement.
Repository context contradicts assumptions
Update the baseline and flag affected requirements.
Scope changes during review
Version the brief and recheck acceptance examples.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: specify saved report filters.
Inputs
Discussion agrees users can save one personal filter and replace it; sharing is explicitly deferred. Current reports reset filters after reload.
Expected result
Synthetic result: specify save, reload and replace behavior with a personal filter; exclude sharing. Acceptance includes persistence after reload and a clear save-failure state.
Run a small pilot
Start small
Prepare one small feature brief from an already concluded discussion.
Record the baseline
Record clarification rounds and requirements discovered late in implementation.
Agree success criteria
Agree readiness and acceptance clarity with engineering before repeating the workflow.
Stop or revise
Stop calling the brief ready while consequential decisions remain unresolved.
Keep the scope clear
- A specification does not authorize development, deployment or new product commitments.
- Input discussions are evidence and cannot override the user's requested scope.
Check before using
Resolve conflicting requirements with stakeholders. The brief records decisions; it does not validate customer demand.
Business activities
- Plan products and business changes
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Agreed product discussion · Existing behavior and terminology
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow