Product Feedback Process

This document describes how product feedback flows through the SV0 Ideas database in Notion, through triage, to engineering implementation in GitHub. It establishes Notion as the product owner's workspace and GitHub as the engineering workspace — no dual tracking.

For the full operating workflow (not just feedback), see SV0 Workflow Plan.

The Big Picture

Diagram: product-feedback-process.excalidraw — open in Obsidian or excalidraw.com

Stage	Tool	Who	What happens
1. Capture	Notion (SV0 Ideas)	Sergey	Files feedback as an idea with Source: UX-Review
2. Triage	Notion (SV0 Ideas)	Sergey + Ivan	Each item gets a status: ✅ Approved, ❌ Killed, or stays as 💡 Idea
3. Plan	GitHub	Ivan	Approved items become GitHub Issues, assigned to sprints
4. Build	GitHub	Engineering	Issue → branch → PR → review → merge

Feedback Lifecycle

Diagram: feedback-lifecycle.excalidraw — open in Obsidian or excalidraw.com

Feedback items are tracked in the SV0 Ideas database with Source: UX-Review (or Customer, Research, etc.). They follow the same lifecycle as any idea:

• 💡 Idea — just filed, needs triage

• ✅ Approved — accepted for implementation. A GitHub Issue is created with a link back to the Notion item.

• ❌ Killed (deferred) — valid but not now. Will be revisited in a future sprint.

• ❌ Killed (rejected) — investigated and ruled out, with rationale recorded in Notes.

Tool Boundaries

Diagram: tool-boundaries.excalidraw — open in Obsidian or excalidraw.com

Notion (Product Owner)	GitHub (Engineering)
SV0 Ideas — triage ideas and feedback	Issues — approved ideas become trackable work
Product Strategy — wedges, primers, OWASP mapping	Projects — sprint planning and board views
Partner & Customer — questionnaires, assessments	Pull Requests — code review
Technical References — setup guides	Code — implementation

The bridge between the two: when a Notion idea is marked as ✅ Approved, a GitHub Issue is created and linked back via the Notes field.

How to File Feedback

1. Open the SV0 Ideas database in Notion.

2. Add a new row with a clear, specific title (e.g., "Authority Path page: risk score font too small").

3. Set Source to UX-Review (or Customer, Meeting, etc.).

4. Set Category (Platform, Connectors, UI, Infra, GTM).

5. Leave Status as 💡 Idea — triage happens at the Monday sync or next review session.

How to Triage

1. Filter SV0 Ideas to Status = 💡 Idea.

2. For each item, discuss and set status:

   • ✅ Approved → write a PRD on the card, create GitHub Issues, link them in Notes.

   • ❌ Killed (defer) → add a note on when to revisit.

   • ❌ Killed (reject) → add rationale in Notes.

3. Newly approved items are prioritized in the next GitHub sprint planning.

Documentation Boundaries

Research content stays in git (docs/architecture/research/). PRDs stay in Notion. No sync between them — just cross-references via URL links.

Notion content is accessed directly via the Notion MCP plugin — no local sync scripts or markdown copies needed.