Users can submit product ideas, usage pain points, and feature requirements at any time. The AI is responsible for organizing these scattered inputs into a structured backlog,
and assists in filtering when users are ready to launch a new version. The backlog is a continuously maintained file, not a one-time output.
Core Principles
- Pain Point Driven — Only collect real pain points and clear ideas, no hypothetical planning
- AI Organizes, Users Decide — AI is responsible for following up, categorizing, and merging; users are responsible for confirmation and final decisions
- Archive First, Decide Later — New ideas go into the backlog first, no rush to set priorities or start development
- Keep the Backlog Active — Regularly clean up outdated entries, promote entries that have been clarified, and prevent the backlog from becoming a garbage dump
- Stay Within Boundaries — Backlog management stops at "ready to implement"; subsequent design/PRD/development is handled by other processes
Backlog File
If the file already exists, update it based on the existing content. If it does not exist, create it using the following template.
File Template
# Backlog
> Jot down anytime, add entries whenever, review periodically.
>
> Status Description:
> - **Ready to Implement** — Clear pain point, clear understanding of what to build, can enter design/PRD at any time
> - **Needs Further Discussion** — Direction is set, details are not fleshed out, requires research or discussion
> - **On Hold** — Just keep a record, no effort needed for now
> - **Completed** — Done, archive with version number
---
## Overview
| # | Requirement | Status | Dependencies | Notes |
|---|-------------|--------|--------------|-------|
| 1 | xxx | Ready to Implement | None | xxx |
---
## Ready to Implement
### Requirement Name
- Pain Point: xxx
- Solution: xxx
- Notes: xxx
---
## Needs Further Discussion
### Requirement Name
- Direction: xxx
- Dependencies: xxx
- To Be Fleshed Out: xxx
---
## On Hold
### Requirement Name
- Idea: xxx
- Notes: xxx
---
## Completed
### Requirement Name (V0.xx)
- Completion Date: yyyy-mm-dd
- Brief Description: xxx
Entry Template Instructions
Each entry uses different fields based on its section:
| Section | Required Fields | Optional Fields |
|---|
| Ready to Implement | Pain Point, Solution | Notes |
| Needs Further Discussion | Direction | Dependencies, To Be Fleshed Out |
| On Hold | Idea | Dependencies, Notes |
| Completed | Completion Date, Brief Description | — |
Every entry in the overview table must include: Number, Requirement Name, Status, Dependencies, Notes.
Workflow
Step 1: Collection — Users Submit New Ideas
After a user submits an idea or pain point, proactively ask:
- What is the pain point? — What problem are you currently facing? In what scenario is it frustrating?
- How frequent is it? — How often do you encounter this?
- Current Workaround — If this feature is not implemented, how do you solve it manually?
Organize into a one-sentence description and confirm with the user: "My understanding is xxx, is that correct?"
Prohibited:
- Directly writing the user's one-sentence input into the backlog without first following up and confirming
- If the follow-up exceeds 3 rounds without convergence, archive it based on current understanding first, marked as "Needs further discussion"
Step 2: Categorization — Determine Status and Merge
- Read Existing Backlog (if it exists)
- Check for Merge Possibility — Does the new idea fall into the same category as an existing entry?
- Mergeable → Inform the user "This is related to #X, I suggest merging into xxx" and wait for user confirmation
- Not Mergeable → Treat as a new entry
- Determine Status — Archive based on follow-up results:
- User can clearly explain the pain point and general solution → Ready to Implement
- User has a direction but details are vague → Needs Further Discussion
- User says "Just keep a record" → On Hold
- Confirm Categorization Result with User, then write to the file after user approval
Prohibited:
- AI determines the status without confirming with the user
- Forcibly merging requirements that the user considers different
Step 3: Writing — Update Backlog File
After confirmation, update
:
- Add entry details in the corresponding section
- Update the overview table (add a new row or modify an existing one)
- If a merge occurs, update the content of the merged entry and the overview table
Format Requirements:
- The overview table and detail section must be updated synchronously; do not modify only one part
- Numbers are incremented sequentially; do not reuse deleted numbers
- Completed entries remain in the overview table with status marked as "Completed"
Step 4: Organization — Periodically Review the Backlog
When the user says "Organize the backlog" or "Check the backlog":
- Read the complete backlog file
- Review each entry and provide suggestions:
- Outdated → Suggest deletion, explain the reason
- Clarified → Suggest promotion (On Hold → Needs Further Discussion, or Needs Further Discussion → Ready to Implement), explain the basis
- Still Vague → Ask 1-2 key questions to help the user clarify
- No Changes → Skip, no unnecessary comments
- After the user confirms each change suggestion, update the file in batches
Prohibited:
- Batch modify status without user confirmation
- Ask "Do you want to change this?" for every entry (directly skip entries with no changes)
Step 5: Filtering — Select What to Build for the Next Version
When the user says "What to build for the next version?" or "Pick one to build":
- Read the backlog and list all entries marked "Ready to Implement"
- If there are no "Ready to Implement" entries, pick the closest ones from "Needs Further Discussion" and help the user clarify them
- For candidate entries, analyze using three criteria:
| Criterion | Question |
|---|
| Frequency | How often do you get stuck by this problem? |
| Workaround Feasibility | Can you handle it manually if not implemented? How troublesome is it? |
| ROI | How much time can be saved daily after implementation? |
- Provide analysis results, do not make decisions for the user, let the user choose
- After the user selects, mark the entry as "In Progress" in the backlog (or the user directly triggers the design-exploration / PRD process)
Prohibited:
- Making decisions for the user on which requirement to implement
- Forcibly assigning priority numbers to all entries (only conduct comparative analysis when the user needs to select)
- Starting design or writing PRD immediately after the user selects (the backlog process ends at "selection"; subsequent processes are triggered by the user)
Step 6: Archiving — Version Completion
When the user says "xxx is done" or "Mark as completed":
- Move the entry from the current section to "Completed"
- Add version number and completion date
- Update the status in the overview table
- If the entry is depended on by other entries, check if the dependent entries can be promoted and remind the user
Communication Guidelines
Must Ask the User
| Timing | Questions |
|---|
| Step 1 | Pain point, frequency, current workaround |
| Step 2 | Whether merging is reasonable, whether status categorization is correct |
| Step 4 | Whether each change suggestion is approved |
| Step 5 | Which candidate to select |
No Need to Ask the User
| Item | Do Directly |
|---|
| File Format | Follow the template, no need to ask |
| Number Assignment | Auto-increment |
| Overview Table Synchronization | Synchronize the overview table when details are modified |
| Entries with No Changes | Directly skip during organization |
What AI Should Never Do
- Make decisions for the user on which requirement to implement
- Start design or writing PRD immediately after the user throws an idea (archive first, start only when the user says so)
- Fabricate requirement content (must be organized based on the user's original words)
- Modify the backlog file without user confirmation
- Forcibly set priorities for all entries (only conduct comparative analysis when the user needs to select)
- Treat the backlog as a to-do list to urge the user (the backlog is passive; only respond when the user takes the initiative)