Choose product management tools by tracing a user problem from discovery evidence through a priority decision to delivery and review. Define what each record means before configuring views or fields. Keep the reason for doing the work visible beside its status, and identify what evidence would show whether the delivered change helped the intended task.
A useful selection exercise begins with a real decision the team struggles to make. Perhaps requests arrive without evidence, priorities change without explanation or completed work cannot be connected to its original purpose. Describe that gap before comparing screens. The tool should support a clear record of the decision and its consequences.
What should discovery evidence establish?
The GOV.UK user-needs guide offers a method to adapt. GOV.UK’s discovery guidance asks who the likely users are and what they are trying to do. Write that task in language the intended user can recognise, keeping the proposed feature separate from the problem it is meant to address.
It includes reviewing existing evidence such as analytics and search logs. It includes interviewing and observing actual or likely users. Retain the relevant evidence reference, its context and the question it helps answer. A short finding should let a colleague understand why the request matters without reproducing unnecessary personal information.
Suggestions that do not come from users are treated as assumptions to research. Give an untested suggestion a clear status and an owner for the next investigation. This makes it possible to compare an observed difficulty with a proposed improvement without presenting both as equally established facts.
Its guidance asks teams to focus on the user’s problem rather than possible solutions. If a request says “add a dashboard”, ask what decision the user cannot make with the information currently available. The eventual solution may still be a dashboard, but the discovery record should preserve the underlying need and the evidence for it.
How should a priority decision remain understandable?
Create a proposed decision record containing the problem, evidence, intended benefit, relevant dependency and decision owner. Agree which considerations matter to this product before introducing a scoring formula. If the team uses a score, retain the basis for each input and make uncertainty visible to the people reviewing it.
A priority label communicates a decision; its meaning still needs an agreed explanation. Ask reviewers to compare the candidate with work already underway and identify why it should proceed now, wait for more evidence or be declined. Preserve that reasoning so a later change of priority can be understood in context.
GitHub’s Projects guide describes one implementation. GitHub Projects connects planning tables, boards and roadmaps with issues and pull requests. Use that documented relationship as an example of connecting planning with delivery records, rather than treating a separate planning board as the only evidence of progress.
Custom fields can add metadata to issues, pull requests and draft issues. A single-select field can represent a task’s priority. Define the intended values and owner before configuring them. Keep the explanation and source evidence close enough that another reviewer can challenge or confirm the label.
Which views should support different decisions?
Project views can be saved for reuse and made available to the team. Consider a discovery view for questions awaiting evidence, a decision view for candidates ready to compare and a delivery view for agreed work. These are proposed arrangements to demonstrate with representative records in the selected tool.
The original worksheet below specifies the relationship that should survive across those views. Use it to assess a sample candidate from initial request through follow-up, rather than judging the tool only from an empty board.
| Record stage | Evidence or decision to preserve | Question for the reviewer |
|---|---|---|
| Discovery | User task, observation and evidence reference | What problem has actually been observed? |
| Assumption | Proposed explanation and next investigation | What still needs to be established? |
| Priority | Decision, rationale and responsible owner | Why this work before the alternatives? |
| Delivery | Agreed scope and linked implementation record | What change is being delivered? |
| Acceptance | Intended task and review observations | Does the change meet the agreed requirement? |
| Follow-up | Outcome question and next decision | What should happen after release? |
Avoid creating a field for every possible question before testing the record with actual work. Ask a colleague to complete the worksheet for a representative candidate. Where the information is unclear, decide whether the problem is a missing field, an unclear instruction or an unresolved decision that the tool cannot supply.
Project changes to an issue or pull request are reflected in the underlying item. Show that behaviour during configuration review so the team understands which view is editing a shared record. Agree who owns changes to assignment and status, and inspect the result in both the project and the underlying work item.
What counts as delivery evidence?
For Scrum roles, backlog responsibilities and delivery reviews, continue with Scrum delivery: backlog, roles and review evidence. Use that guide for the delivery process while keeping this record focused on discovery, prioritisation and the evidence connecting a proposed change to the user’s need.
Define acceptance around the intended task and agreed scope. Link the relevant implementation record, review observations and any remaining exception. Ask the product owner to explain what was delivered and which question remains open after the change becomes available to its intended users.
Keep implementation status distinguishable from user outcome. Closing a work item may establish that the team completed its agreed delivery process; the follow-up question still needs the relevant observation or measurement. Specify that evidence in the plan so the team knows what to examine after delivery.
Retain rejected or deferred decisions in an appropriate form. A concise reason can help the next reviewer distinguish a deliberate choice from a forgotten request. If new evidence changes the decision, preserve the earlier reasoning and identify the new information that justified reconsideration.
Original repeated-enquiry discovery exercise
Consider a hypothetical product team receiving repeated requests for an additional notification. Prepare a sample discovery record that asks what users fail to notice and what they are trying to accomplish at that moment. Use fictional supporting material and identify the observations the team would need to collect.
Create a proposed priority record for the notification and an alternative that improves the existing information route. Have a reviewer compare their intended tasks, supporting evidence and unresolved assumptions. Record the decision and its rationale before assigning delivery work to the selected candidate.
Next, connect the agreed scope to a sample delivery item. Ask another colleague to follow the links from that item back to the original need, then inspect the acceptance requirement. They should be able to explain what the team plans to demonstrate and what would count as an unresolved exception.
Finally, write the follow-up question for the hypothetical release. Identify who will examine the relevant evidence and decide whether to retain, revise or investigate the change further. Keep that responsibility visible alongside completion so the product decision remains connected to the user problem it began with.
For related work, see custom software development and managed hosting. Get started with a sample request, its supporting evidence and the decision your current tools make difficult.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.