{
  "_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"
}