As a Product Owner
Track goals, open issues, and product decisions — and keep findings separate from choices.
You own outcomes, priorities, and stakeholder alignment — not implementation detail. Recordari is where product intent lives: goals, open questions, decisions the business made, and the evidence that informed them.
This guide is about usage patterns, not workspace permissions. For who can change someone else's memory on a shared team, see When memories disagree.
The scenario
You're the PO for a payments migration. Engineering files technical decisions daily. You need to walk into planning knowing which outcomes are committed, which customer promises are open, and what the team decided about EU launch timing — without re-reading every ticket and Slack thread.
What product owners file
Product owners get the most value from memory types that express intent and uncertainty:
| Type | File when… | Example |
|---|---|---|
| goal | A desired outcome or milestone | "Goal: EU merchants can accept SEPA Direct Debit by Q4." |
| decision | Stakeholders or the team settled direction | "Decision: defer EU launch until Q4 — compliance review did not clear in time." |
| issue | An open product question | "Issue: do we support partial refunds in v1 or defer to v2?" |
| finding | Evidence from research, data, or customer feedback | "Finding: 40% of churned EU trial users cited missing SEPA in exit surveys." |
| standing | A durable product rule | "Standing: no new payment methods ship without fraud review sign-off." |
The most common PO mistake is filing a finding or issue as a decision before stakeholders have actually chosen. "Users want SEPA" is a finding. "We are building SEPA in Q4" is a decision.
Orient before planning
You do not need a technical deep-dive every morning. You need where product intent stands:
"Orient on payments-platform — what product decisions and open issues should I know about?"
"Any goals or issues in payments-platform that changed since last week?"
Search when you need a specific thread:
"What did we decide about EU launch timing?"
"What findings do we have about SEPA demand?"
Trust what engineering and the architect filed for technical choices. Your job is the why we are building this layer, not duplicating their implementation memories.
Findings vs decisions — keep them separate
Good product memory chains evidence to choice:
"File a finding: exit surveys show 40% of churned EU trials cite missing SEPA."
Later, after stakeholder alignment:
"File a decision: SEPA Direct Debit ships in Q4 — connect it to the exit-survey finding."
If you only file the decision, the next PO loses why it was prioritised. If you only file the finding, orient reads like an open research backlog with no commitments.
When direction changes, your agent supersedes the old decision rather than silently rewriting it — see When memories disagree.
Goals and open threads
Use goal for outcomes you are driving across sprints — not sprint tasks:
"File a goal: reduce checkout abandonment below 12% this quarter."
"File a goal: hand off EU compliance requirements doc to legal by end of month."
Use issue for questions that block prioritisation:
"File an issue: pricing for SEPA — finance has not confirmed fee model yet."
Handoffs to the next session work well as goals:
"File a goal: next planning session — resolve partial-refund scope with customer success."
What to read vs what to file
| You file | You read (usually filed by others) |
|---|---|
| Stakeholder and product decisions | Implementation decisions |
| Customer research findings | Architecture constraints |
| Goals and success metrics | Technical findings and spikes |
| Open product issues | Code-level debugging notes |
When you were in the room for a cross-functional decision, file it once:
"File a decision: v1 launches UK and US only — EU deferred to Q4 pending compliance."
When you were not, read instead:
"What did engineering decide about webhook retry behaviour?"
If a tech lead or architect will file the same thing, skip duplicating.
A planning session — step by step
1. Before backlog refinement
"Orient on payments-platform for today's planning — goals, open issues, recent product decisions."
2. Stakeholder input from yesterday
"File a finding: enterprise sales flagged three deals blocked on invoice billing — not card-only checkout."
3. Team settles scope
"File a decision: invoice billing is out of scope for v1 — connect it to the enterprise sales finding."
4. Something stays open
"File an issue: partial refunds — need customer success input before we commit."
5. Next week's session
"Orient on payments-platform — catch me up on EU and billing scope."
The Q4 EU decision, the invoice billing rejection, and the open partial-refund issue are all there.
What product owners usually skip
You do not need to:
- File sprint task lists — use your backlog tool
- Duplicate engineering's technical decisions unless you owned the product trade-off
- Run graph audits — orient surfaces contradictions; answer when your agent asks
- File every standup update
You are curating what the product committed to and why, not documenting the entire programme.
Standing rules (planned)
Per-role setup templates are planned but not shipped yet. Until then, file standing memories for product constraints that should apply every session:
"File a standing rule: no payment method ships without fraud review sign-off."
When role templates ship, this guide will link to them.
Next steps
- As an engineering manager — status and light filing for people managers
- As a tech lead — turning findings into team decisions
- When memories disagree — contradictions on shared domains
- MCP Tools Reference — memory types, goals, issues, orient