For product teams
Keep the decision beside the issue.
Group the backlog by priority or a field your team defines, save the view for the planning meeting, move the picks into a sprint and write down why. This is issue-level planning for product and engineering together, not a portfolio roadmap.
From filed feedback to a decision you can find again.
Six steps in one project, all on the issue level. Each one links to the page that covers it in depth.
- 01
Start from feedback already filed
Whoever hears it first files it as an issue, with a type and a tag for the area it touches. One list is easier to compare than five inboxes.
tag: invitations #Unresolved
Issue tracking - 02
Group by priority or your own field
Priority is built in. Impact here is a select field the team added in Project settings, so its options mean what you agreed they mean.
High 2 · Medium 2 · Low 1 · Not triaged 1
Custom fields - 03
Save the view for the meeting
Save the search under a name and share it with the project. Everyone opens the same list, and a report can be scoped to it.
#{Invitation feedback}
Search and saved views - 04
Move the picks into the sprint
On the Backlog page, drag each chosen issue into the planned sprint, or use Space and the arrow keys on its grip.
Sprint 08 · 3 issues · 6 points from the view
Sprints and boards - 05
Check delivery against the plan
The burndown draws scope added after the start as its own line. Average issue age, grouped by Impact, names the oldest open issue in each group.
13 of 34 points left · 3 added after the start
Project reports - 06
Write the decision beside the issues
A decision record in the project’s knowledge base names the issue keys. Each issue then lists it under Referenced by.
article://ACME/invitation-links-and-expiry
Knowledge base
Priorities change. The reasoning should stay findable.
It is 3 Oct 2026, and Acme is planning Sprint 08 from a saved view of invitation feedback. Run the meeting yourself.
- Group the view by Impact, then by priority, and notice where the two disagree.
- Plan issues into Sprint 08. The sprint under the list keeps the count.
- Open ACME-12 and follow Referenced by to the decision record, then back.
Impact is a select field this team added in Project settings → Fields, with High, Medium and Low. It is not built in, and nothing scores it.
Impact:High2
- ACME-12Invite link blank after it expires
- ACME-15Resend invite from the members list
Impact:Medium2
- ACME-14Invite email subject names the org
- ACME-18Revoke a pending invitation
Impact:Low1
- ACME-16Reminder email before an invite expires
Impact:Not triaged1
- ACME-19Invite form explains each role
Priority:Major1
- ACME-12Invite link blank after it expires
Priority:Normal4
- ACME-15Resend invite from the members list
- ACME-14Invite email subject names the org
- ACME-18Revoke a pending invitation
- ACME-16Reminder email before an invite expires
Priority:Minor1
- ACME-19Invite form explains each role
Sprint 08Planned
From this view: 3 issues, 6 points
- ACME-123
- ACME-151
- ACME-142
- ACME-185
- ACME-163
- ACME-191
Invite link blank after it expires
Actual. Opening an invitation link older than seven days shows a blank page.
- Reporter
- Casey Kim
- Status
- Open
- Impact
- High
- Sprint
- Sprint 08
Decision record · Published to project members · Last updated by Alex Lee
Invitation links and expiry
Invitation links expire after seven days (INVITE_TTL_DAYS). An expired link must explain itself and offer a new one. A blank page or a redirect to sign-in is a bug.
Decided 2 Oct 2026. The expiry message is shown on the invitation landing page itself, before any sign-in prompt, because the person may not have an account yet. See ACME-12 for the first instance.
- Page
- /projects/ACME/articles/invitation-links-and-expiry
- For agents
- article://ACME/invitation-links-and-expiry
Hand-drawn product views with fictional data. In the product you move an issue into a sprint by dragging it on the Backlog page, or from the Sprint field on the issue; the buttons stand in for that.
How to prioritize a product backlog.
A backlog stays useful when anyone can explain its order. This routine suits a product team planning two-week sprints with engineering. The worked example follows Acme’s planning meeting on 3 Oct 2026.
Nothing here is automatic. The fields, the order and the reasons belong to the team; the tracker keeps them findable.
1Capture every candidate as an issue.
Customer reports, support threads and ideas from the team become issues before anyone ranks them, each with a type and a tag for the area it touches. Comparing one list is easier than comparing five sources.
AcmeCasey files ACME-12, Invite link blank after it expires, from two support emails and tags it invitations, next to five other requests.
2Group by impact and urgency.
Priority answers how urgent something is. A second field answers how much it matters to the people using the product. Add a select field such as Impact, agree what its options mean, then group the list by each in turn. Where the two disagree is where the conversation is.
AcmeACME-15, Resend invite from the members list, is Normal priority but High impact: admins ask for it every week. ACME-19 has no Impact yet, so it reads Not triaged instead of being guessed.
3Record the reason for the priority.
A priority without a reason gets argued again every sprint. Write one sentence in the issue. When the decision will outlive the issue, write a decision record in the project’s knowledge base that names the issue keys.
AcmeAlex writes Invitation links and expiry: an expired link must explain itself before any sign-in prompt. It names ACME-12, so the issue lists the article under Referenced by.
4Pick the next sprint.
Take from the top of the grouped list until you reach the points the team usually finishes, and leave the rest in the backlog with their reasons intact. Saved as a view, the same list opens the next meeting.
AcmeACME-12, ACME-15 and ACME-14 go into Sprint 08, six points towards the goal Make invitations clearer. ACME-18 is five points on its own and waits for Sprint 09.
5Revisit the decision after delivery.
When the sprint ends, check the burndown for scope that arrived late and the issue-age report for what keeps waiting. Then reread the decision records the sprint touched, and confirm or correct them while the reasoning is fresh.
AcmeACME-12 is fixed on 8 Oct, and its key is struck through in the article. The burndown shows three points added after the start, which goes into the next planning conversation.
For product managers who plan in the same place engineering delivers.
One tracker for the backlog, the sprint and the reasons behind both, without a separate planning tool to keep in sync.
Best for
Product teams that share delivery with engineering: one backlog, sprints planned together, decisions kept with the work.
Not built for
Portfolio roadmaps across many products, public feedback portals or roadmaps, and automatic scoring of requests.
Free for any team size during beta; the first 20 members of every organisation stay free.
What it gives a product manager
Prioritization you can explain.
Priority is a list the project defines; add a field such as Impact for the second question. Group and sort by either, save the list as a view, and scope a report to it.
Search and saved viewsTraceability from issue to reason.
A decision record names the keys, each issue lists it under Referenced by, and a resolved key is struck through in the text. A change such as Impact: Medium → High lands in the issue’s history with who and when.
Issue trackingClear ownership of the plan.
Each issue has its assignees and sits in one sprint at a time. Project Admins plan, start and finish sprints; Contributors move issues in and out; every move is recorded under whoever made it.
Sprints and boardsPrivate project context.
Issues and articles are readable only by the project’s members. Stakeholders who only need to read can join as Observers: they read published articles and issues, and can star, watch and vote.
Knowledge baseQuestions about planning with it.
What it does for a product backlog, and where the roadmap stops. The docs have the detail.
Is there a roadmap view?
Not a roadmap editor. Sprints plan the next few weeks, and the Gantt report draws a project’s issues from start date to due date, with an arrow for each depends-on link. It is a report: you change dates on the issues, and an issue missing either date is listed under the chart. There are no portfolio initiatives or roadmaps that span many products. Project reports
Does it score or rank feature requests?
No. Priority is a list your project defines, and fields such as Impact are ones you add. You can group and sort by them, and a report can count them, but nothing calculates a score or reorders the backlog for you. The order is whatever the team drags it into.
Can customers submit requests or vote on them?
Not from outside. There is no public portal or request form: issues are filed by members of the organisation. Members of a project can vote for an issue, one vote each, with the count shown on the issue. Treat it as a signal for the conversation, not a ranking.
Can we share a decision record with customers?
No. The knowledge base is private to the project: a published article is readable by every member, Observers included, and by nobody else. There is no public page or share link. Add a stakeholder as an Observer when they need to read along. Knowledge base
How does this work across several products?
Give each product a project with its own sprints, fields and knowledge base. A sprint belongs to one project, but search and reports can cover several projects at once, and a view shared with the organisation gives every member the same list. Two projects can share a field slug, so impact: High searches both.
Can an AI agent help prepare the planning meeting?
Yes, with your permissions and nothing more. It can run the saved view by name, count the result by a custom field, read the decision record and move an issue into a sprint. It does not decide what goes in; it saves you the gathering. MCP and AI agents
Bring it to your next planning meeting.
Join the beta, create a project and add an Impact field if your team needs one. Save the view you plan from, and write the first decision record beside the issues it explains.