Keep product decisions connected to meeting evidence
Connect preparation, meeting analysis and reasoning checks so each discussion updates the next product decision.
How this works
Connect preparation, meeting analysis and reasoning checks so each discussion updates the next product decision. Use this when recurring product discussions need to build on prior evidence instead of repeatedly reopening the same questions. The workflow connects preparation, actual meeting evidence and the next validation decision.
Start from the current product objective and decision history, prepare questions, then compare the meeting record with what the team needed to learn. Record decisions, assumptions and unresolved contradictions separately. Update the strategy record only with reviewed conclusions rather than treating lively discussion as agreement.
Before you start
Product objective
Obtain the current problem, strategic question and decision owner.
Prior decision record
Collect relevant hypotheses, evidence and earlier unresolved questions.
Meeting evidence
Use permitted notes or transcript with a known coverage boundary.
Prepare the inputs
- meeting_goal
- Required
question, desired decision and evidence needed
Avoid replacing the agreed goal with a new agenda.
- prior_context
- Required
decisions, experiments and assumptions
Mark superseded or contradicted evidence.
- meeting_record
- Required
dated statements and decisions
Distinguish proposals from explicit agreements.
- strategy_register
- Required
current hypotheses, owners and validation steps
Preserve history when updating conclusions.
Implementation, step by step
Prepare the discussion
- Retrieve relevant prior decisions and identify what remains unknown.
- Draft questions that can change the pending product decision.
Checkpoint: The meeting has an evidence-focused agenda.
Extract the meeting evidence
- Identify new facts, observations, proposals and explicit decisions.
- Retain references and mark incomplete or conflicting statements.
Checkpoint: A factual meeting ledger exists.
Compare with the objective
- Assess which planned questions were answered and which remain open.
- Do not infer agreement from silence or a suggested next step.
Checkpoint: The team sees what was actually learned.
Challenge proposed conclusions
- Check each conclusion against the evidence and plausible alternatives.
- Separate causal claims from observations and list needed validation.
Checkpoint: The reasoning is reviewable.
Update the decision record
- Record owner-confirmed decisions, unresolved questions and the next test.
- Keep roadmap changes separate unless the responsible owner explicitly authorized them.
Checkpoint: The next discussion starts from current evidence.
Decisions along the way
Discussion changes direction without a decision
Record the alternative as a proposal and keep the original question open.
New evidence contradicts a prior assumption
Flag the affected decision for review rather than silently rewrite history.
A meeting ends without an owner
Leave ownership unresolved and request confirmation.
What you will produce
product-decision-update.md
MarkdownA source-grounded update to product reasoning.
Include: objective · evidence · decisions · assumptions · questions · next_test
meeting-evidence-ledger.csv
CSVTraceability from conversation to conclusion.
Include: statement · type · source_ref · affected_hypothesis · status
Check the result
- Verify decisions have explicit support and an owner.
- Check conclusions answer the original objective or explain the changed scope.
- Confirm contradictory evidence remains visible.
- Ensure next tests have observable outcomes rather than vague learning goals.
When something goes wrong
Transcript omits the decision segment
Ask participants to confirm the decision before updating status.
Prior context is outdated
Reconcile versions before interpreting the meeting.
Assistant turns suggestions into commitments
Reclassify them and verify against the exact wording.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: review a meeting about onboarding delays.
Inputs
Goal is to learn whether missing setup guidance causes abandonment. Two support examples mention confusion; the team proposes a checklist but agrees only to interview five users.
Expected result
Synthetic result: record confusion as limited evidence, the checklist as a hypothesis and five interviews as the agreed next validation step. Do not mark a checklist launch as approved.
Run a small pilot
Start small
Use the workflow across two consecutive product meetings.
Record the baseline
Record repeated questions, missed decisions and clarification effort.
Agree success criteria
Agree evidence traceability and decision continuity before recurring use.
Stop or revise
Stop strategy updates when the meeting evidence cannot establish agreement.
Keep the scope clear
- Meeting analysis cannot authorize roadmap changes or resource commitments.
- A coherent decision history does not prove the product hypothesis is correct.
Check before using
Confirm evidence, owners and unresolved contradictions before changing the roadmap.
Business activities
- Coordinate meetings and follow-ups
- 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: Prior discussions · Meeting objective and recording · Open product questions
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow