How should I prioritise this product feature?
Decision tree
product managementprioritisationroadmapproduct strategy
Decide whether and how urgently to prioritise a feature request. Works through customer validation, strategic fit, business impact, and effort to route each request to the right outcome. Use this before committing any request to a sprint or quarterly roadmap.
Overview
Decision Tree
Start: Has this feature request been validated with real customers or users?
yes
- Continues to question: Does this feature directly support a stated company or product strategy goal for this half?
no
- Outcome: Needs More Discovery
Machine-Readable JSON (Canonical Model)
View JSON
{
"_meta": {
"schema": "https://www.drawdecisiontree.com/decision-dag.schema.json",
"source": "https://www.drawdecisiontree.com",
"description": "DrawDecisionTree.com is a free tool for building, sharing, and embedding interactive decision trees. This file is the machine-readable export of a published decision tree. The `dsl` field contains the original source in the Decision DAG DSL; the `dag` schema is documented at the URL in `schema` above.",
"links": {
"interactive": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-feature-prioritisation.html",
"embed": "https://www.drawdecisiontree.com/embed/path/drawdecisiontree/product-feature-prioritisation",
"dsl_reference": "https://www.drawdecisiontree.com/decision-tree-dsl-reference.html",
"guides": "https://www.drawdecisiontree.com/guides",
"schema_docs": "https://www.drawdecisiontree.com/decision-dag.schema.json",
"author_trees": "https://www.drawdecisiontree.com/trees/drawdecisiontree"
},
"generated_at": "2026-05-29T12:05:39.340Z"
},
"author": {
"handle": "drawdecisiontree",
"first_name": "Andrew",
"last_name": null,
"avatar_url": "1d32d828-b6ca-40ec-bdd7-771fe7b9c36a/avatar-1778531481027.svg",
"display_name": "Andrew"
},
"file": {
"id": "7184c836-7e91-47f2-b0e0-95bfbb2054e8",
"name": "How should I prioritise this product feature?",
"public_slug": "product-feature-prioritisation",
"updated_at": "2026-05-12T16:53:43.587978+00:00",
"url": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-feature-prioritisation.html",
"json_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-feature-prioritisation/tree.json",
"dsl_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-feature-prioritisation/tree.dag"
},
"meta": {
"description": "Decide whether and how urgently to prioritise a feature request. Works through customer validation, strategic fit, business impact, and effort to route each request to the right outcome. Use this before committing any request to a sprint or quarterly roadmap.",
"mode": "decision",
"entry": "Q1",
"tags": [
"product management",
"prioritisation",
"roadmap",
"product strategy"
],
"image": "https://images.unsplash.com/photo-1484480974693-6ca0a78fb36b?w=1200&q=80"
},
"questions": [
{
"id": "Q1",
"text": "Has this feature request been validated with real customers or users?"
},
{
"id": "Q2",
"text": "Does this feature directly support a stated company or product strategy goal for this half?"
},
{
"id": "Q3",
"text": "Would shipping this feature materially increase revenue or meaningfully reduce customer churn?"
},
{
"id": "Q4",
"text": "Can the engineering team deliver this within roughly one sprint of normal capacity?"
}
],
"outcomes": [
{
"id": "SPRINT",
"label": "Ship This Sprint"
},
{
"id": "NEXT_QUARTER",
"label": "Add to Next Quarter Roadmap"
},
{
"id": "BACKLOG",
"label": "Park in Backlog"
},
{
"id": "DISCOVERY",
"label": "Needs More Discovery"
},
{
"id": "DECLINE",
"label": "Decline / Won't Do"
}
],
"dsl": "dag: How should I prioritise this product feature?\nversion: 1.0.0\nimage: https://images.unsplash.com/photo-1484480974693-6ca0a78fb36b?w=1200&q=80\ndescription: Decide whether and how urgently to prioritise a feature request. Works through customer validation, strategic fit, business impact, and effort to route each request to the right outcome. Use this before committing any request to a sprint or quarterly roadmap.\ntags: product management, prioritisation, roadmap, product strategy\nentry: Q1\n\nQ1: Has this feature request been validated with real customers or users?\n hint: Validation means more than one person asking for it. Look for evidence across multiple customer interviews, support tickets, NPS verbatims, or sales call notes. A single loud stakeholder or a Slack message from a colleague does not count as customer validation. If you lack evidence, the request needs discovery before prioritisation.\n yes -> Q2\n no -> [DISCOVERY]\n\nQ2: Does this feature directly support a stated company or product strategy goal for this half?\n hint: Check your current OKRs, product strategy document, or leadership priorities. A feature can be customer-validated and still be a distraction if it pulls the team away from the strategic bets you have committed to. If it is not traceable to a current objective, it may belong in a future planning cycle regardless of customer demand.\n yes -> Q3\n no -> [BACKLOG]\n\nQ3: Would shipping this feature materially increase revenue or meaningfully reduce customer churn?\n hint: \"Materially\" means you can articulate a plausible ARR impact or a retention improvement tied to a specific customer segment. Work with your commercial or data team to size this. Requests that are nice-to-have but do not move a revenue or retention needle should be weighed against higher-impact alternatives in the queue.\n yes -> Q4\n no -> [NEXT_QUARTER]\n\nQ4: Can the engineering team deliver this within roughly one sprint of normal capacity?\n hint: A rough effort estimate is enough here — you are not writing a spec. Ask your tech lead whether this is a days-level or weeks-level effort. If it is weeks-level or requires significant platform work, the feature may still be worth doing but needs proper scoping before it can enter a sprint. Consider whether a smaller slice could ship sooner.\n yes -> [SPRINT]\n no -> [NEXT_QUARTER]\n\n[SPRINT]: Ship This Sprint\n color: #16a34a\n description: This feature is customer-validated, strategically aligned, commercially impactful, and scoped to fit within a sprint. Add it to the current sprint backlog and make sure the engineering team has a clear, accepted story before the sprint starts. Write acceptance criteria that reflect the specific customer problem, not just the implementation detail. Share the shipping plan with relevant customer-facing teams so they can set expectations or follow up with requestors. Measure the feature against a defined success metric within 30 days of release.\n code: PM_SHIP_SPRINT\n\n[NEXT_QUARTER]: Add to Next Quarter Roadmap\n color: #2563eb\n description: This feature has passed enough of the prioritisation bar to deserve a place in the next quarterly planning cycle, but it is not urgent enough to displace current sprint commitments. Add it to the candidate list for the next planning session with a brief rationale note so context is not lost. If it is customer-validated, loop in your customer success or sales team so they can manage expectations and avoid over-promising delivery timelines. Revisit the effort estimate during refinement before committing it to the roadmap.\n code: PM_NEXT_QUARTER\n\n[BACKLOG]: Park in Backlog\n color: #d97706\n description: This request does not align with the current strategic direction, which means prioritising it now would create opportunity cost against your committed goals. Add it to the backlog with a clear label that captures why it was deferred so future reviewers have context. Schedule a backlog grooming session each quarter to reassess items as strategy evolves. Communicate transparently to the requester — internal or external — that the item is captured but not on the near-term roadmap, and share what would need to change for it to move up.\n code: PM_BACKLOG\n\n[DISCOVERY]: Needs More Discovery\n color: #7c3aed\n description: Before this feature can be prioritised, the team needs evidence that it solves a real and widespread problem. Commission a targeted discovery sprint: run at least three to five customer interviews focused on the underlying job-to-be-done, then synthesise findings into a short problem statement. Avoid solutioning during discovery — your goal is to understand the problem, not validate the feature as described. Once discovery is complete, re-enter this prioritisation flow with the new evidence in hand.\n code: PM_DISCOVERY\n\n[DECLINE]: Decline / Won't Do\n color: #dc2626\n description: After review this feature does not meet the threshold for prioritisation in any foreseeable planning cycle. Document the decision and the specific reasons — lack of strategic fit, insufficient customer signal, or prohibitive effort — so the rationale is clear if the request resurfaces. Communicate the decision respectfully to the requester and, where possible, point to what the team is focused on instead. Revisit annually during strategy refresh in case the business context changes.\n code: PM_DECLINE\n"
}DSL Representation
dag: How should I prioritise this product feature?
version: 1.0.0
image: https://images.unsplash.com/photo-1484480974693-6ca0a78fb36b?w=1200&q=80
description: Decide whether and how urgently to prioritise a feature request. Works through customer validation, strategic fit, business impact, and effort to route each request to the right outcome. Use this before committing any request to a sprint or quarterly roadmap.
tags: product management, prioritisation, roadmap, product strategy
entry: Q1
Q1: Has this feature request been validated with real customers or users?
hint: Validation means more than one person asking for it. Look for evidence across multiple customer interviews, support tickets, NPS verbatims, or sales call notes. A single loud stakeholder or a Slack message from a colleague does not count as customer validation. If you lack evidence, the request needs discovery before prioritisation.
yes -> Q2
no -> [DISCOVERY]
Q2: Does this feature directly support a stated company or product strategy goal for this half?
hint: Check your current OKRs, product strategy document, or leadership priorities. A feature can be customer-validated and still be a distraction if it pulls the team away from the strategic bets you have committed to. If it is not traceable to a current objective, it may belong in a future planning cycle regardless of customer demand.
yes -> Q3
no -> [BACKLOG]
Q3: Would shipping this feature materially increase revenue or meaningfully reduce customer churn?
hint: "Materially" means you can articulate a plausible ARR impact or a retention improvement tied to a specific customer segment. Work with your commercial or data team to size this. Requests that are nice-to-have but do not move a revenue or retention needle should be weighed against higher-impact alternatives in the queue.
yes -> Q4
no -> [NEXT_QUARTER]
Q4: Can the engineering team deliver this within roughly one sprint of normal capacity?
hint: A rough effort estimate is enough here — you are not writing a spec. Ask your tech lead whether this is a days-level or weeks-level effort. If it is weeks-level or requires significant platform work, the feature may still be worth doing but needs proper scoping before it can enter a sprint. Consider whether a smaller slice could ship sooner.
yes -> [SPRINT]
no -> [NEXT_QUARTER]
[SPRINT]: Ship This Sprint
color: #16a34a
description: This feature is customer-validated, strategically aligned, commercially impactful, and scoped to fit within a sprint. Add it to the current sprint backlog and make sure the engineering team has a clear, accepted story before the sprint starts. Write acceptance criteria that reflect the specific customer problem, not just the implementation detail. Share the shipping plan with relevant customer-facing teams so they can set expectations or follow up with requestors. Measure the feature against a defined success metric within 30 days of release.
code: PM_SHIP_SPRINT
[NEXT_QUARTER]: Add to Next Quarter Roadmap
color: #2563eb
description: This feature has passed enough of the prioritisation bar to deserve a place in the next quarterly planning cycle, but it is not urgent enough to displace current sprint commitments. Add it to the candidate list for the next planning session with a brief rationale note so context is not lost. If it is customer-validated, loop in your customer success or sales team so they can manage expectations and avoid over-promising delivery timelines. Revisit the effort estimate during refinement before committing it to the roadmap.
code: PM_NEXT_QUARTER
[BACKLOG]: Park in Backlog
color: #d97706
description: This request does not align with the current strategic direction, which means prioritising it now would create opportunity cost against your committed goals. Add it to the backlog with a clear label that captures why it was deferred so future reviewers have context. Schedule a backlog grooming session each quarter to reassess items as strategy evolves. Communicate transparently to the requester — internal or external — that the item is captured but not on the near-term roadmap, and share what would need to change for it to move up.
code: PM_BACKLOG
[DISCOVERY]: Needs More Discovery
color: #7c3aed
description: Before this feature can be prioritised, the team needs evidence that it solves a real and widespread problem. Commission a targeted discovery sprint: run at least three to five customer interviews focused on the underlying job-to-be-done, then synthesise findings into a short problem statement. Avoid solutioning during discovery — your goal is to understand the problem, not validate the feature as described. Once discovery is complete, re-enter this prioritisation flow with the new evidence in hand.
code: PM_DISCOVERY
[DECLINE]: Decline / Won't Do
color: #dc2626
description: After review this feature does not meet the threshold for prioritisation in any foreseeable planning cycle. Document the decision and the specific reasons — lack of strategic fit, insufficient customer signal, or prohibitive effort — so the rationale is clear if the request resurfaces. Communicate the decision respectfully to the requester and, where possible, point to what the team is focused on instead. Revisit annually during strategy refresh in case the business context changes.
code: PM_DECLINE
Machine Access
- Static JSON:
/t/drawdecisiontree/product-feature-prioritisation/tree.json - Live JSON (SPA):
/json/drawdecisiontree/product-feature-prioritisation - Raw DSL:
/t/drawdecisiontree/product-feature-prioritisation/tree.dag - Canonical HTML:
/t/drawdecisiontree/product-feature-prioritisation.html
Questions in this decision tree
- Has this feature request been validated with real customers or users?
- Does this feature directly support a stated company or product strategy goal for this half?
- Would shipping this feature materially increase revenue or meaningfully reduce customer churn?
- Can the engineering team deliver this within roughly one sprint of normal capacity?
Possible outcomes
- Ship This Sprint
- Add to Next Quarter Roadmap
- Park in Backlog
- Needs More Discovery
- Decline / Won't Do
How to use this decision tree
Click "Open interactive version" to step through the questions. Your answers narrow the tree until a recommended outcome is reached. You can also embed this tree on your own site.
More decision trees by Andrew
Which API design pattern is right for my project?
Determine the right API design style for your integration scenario.
Authentication Method Selection
Authentication is a security-critical, high-friction decision to reverse — migrating users from one auth method to another requires coordinated password resets or credential migration campaigns. This tree eliminates methods that don't match your user type, enterprise requirements, and security posture, giving you a clear shortlist before you write a line of code.
Caching Strategy Selection
Premature or misapplied caching adds complexity — stale data bugs, invalidation logic, and distributed consistency problems — without solving the actual bottleneck. This tree routes you to the caching pattern that matches your data access profile, so you apply the right tool to the right problem rather than defaulting to Redis for everything.
CI/CD Pipeline Tool Selection
Choosing a CI/CD platform is a long-term infrastructure commitment — pipelines accumulate config, custom scripts, and team muscle memory that make switching painful. This tree eliminates tools that don't fit your source control host, infrastructure model, or team scale, leaving only the options genuinely viable for your situation.
Which cloud provider should I use — AWS, Azure, or Google Cloud?
Answer a few questions to identify the most suitable cloud platform for your workload.
Container Orchestration Platform Selection
Container orchestration is foundational infrastructure — the platform you choose shapes how you deploy, scale, network, and operate every service you run. This tree eliminates options that don't match your operational maturity, cloud provider commitment, and workload complexity, so you land on the platform that fits your team today without over-engineering for a scale you haven't reached.