How should I prioritise competing roadmap items?

{
  "_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-roadmap-trade-off.html",
      "embed": "https://www.drawdecisiontree.com/embed/path/drawdecisiontree/product-roadmap-trade-off",
      "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.347Z"
  },
  "author": {
    "handle": "drawdecisiontree",
    "first_name": "Andrew",
    "last_name": null,
    "avatar_url": "1d32d828-b6ca-40ec-bdd7-771fe7b9c36a/avatar-1778531481027.svg",
    "display_name": "Andrew"
  },
  "file": {
    "id": "8d1ec584-004a-4b6c-b90e-d968c028647a",
    "name": "How should I prioritise competing roadmap items?",
    "public_slug": "product-roadmap-trade-off",
    "updated_at": "2026-05-12T16:53:43.587978+00:00",
    "url": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-roadmap-trade-off.html",
    "json_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-roadmap-trade-off/tree.json",
    "dsl_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-roadmap-trade-off/tree.dag"
  },
  "meta": {
    "description": "When engineering capacity is constrained, decide what to prioritise across new features, bug fixes, technical debt, performance improvements, and security or compliance work. Guides product managers through urgency, customer impact, and business risk to make a defensible trade-off call. Use during sprint planning, quarterly roadmap reviews, or whenever a new urgent item competes with committed work.",
    "mode": "decision",
    "entry": "Q1",
    "tags": [
      "product management",
      "roadmap",
      "prioritisation",
      "trade-offs",
      "engineering"
    ],
    "image": "https://images.unsplash.com/photo-1454165804606-c3d57bc86b40?w=1200&q=80"
  },
  "questions": [
    {
      "id": "Q1",
      "text": "Is there an active security vulnerability or compliance deadline that carries a regulatory, contractual, or reputational risk if missed?"
    },
    {
      "id": "Q2",
      "text": "Is there a bug that is actively blocking customers from completing a core workflow or causing significant data loss or integrity issues?"
    },
    {
      "id": "Q3",
      "text": "Is technical debt actively slowing down feature delivery — for example, causing engineers to spend more than 20% of sprint capacity on unplanned rework or workarounds?"
    },
    {
      "id": "Q4",
      "text": "Is there a committed new feature — promised in a contract, a public roadmap announcement, or a sales deal — that is at risk of missing its delivery date?"
    },
    {
      "id": "Q5",
      "text": "Is there a measurable performance degradation — such as increased page load times, API latency, or error rates — that is affecting user experience or SLA compliance?"
    }
  ],
  "outcomes": [
    {
      "id": "SECURITY_COMPLIANCE",
      "label": "Security / Compliance Work"
    },
    {
      "id": "BUG_FIX",
      "label": "Bug Fix"
    },
    {
      "id": "TECH_DEBT",
      "label": "Technical Debt"
    },
    {
      "id": "NEW_FEATURE",
      "label": "New Feature"
    },
    {
      "id": "PERFORMANCE",
      "label": "Performance Improvement"
    }
  ],
  "dsl": "dag: How should I prioritise competing roadmap items?\nversion: 1.0.0\nimage: https://images.unsplash.com/photo-1454165804606-c3d57bc86b40?w=1200&q=80\ndescription: When engineering capacity is constrained, decide what to prioritise across new features, bug fixes, technical debt, performance improvements, and security or compliance work. Guides product managers through urgency, customer impact, and business risk to make a defensible trade-off call. Use during sprint planning, quarterly roadmap reviews, or whenever a new urgent item competes with committed work.\ntags: product management, roadmap, prioritisation, trade-offs, engineering\nentry: Q1\n\nQ1: Is there an active security vulnerability or compliance deadline that carries a regulatory, contractual, or reputational risk if missed?\n  hint: Security and compliance work is non-negotiable when there is a known exploit, a customer data exposure risk, a SOC 2 or ISO audit finding, or a regulatory deadline (e.g., GDPR, HIPAA, PCI-DSS). These items carry legal liability and can escalate faster than any feature work. Check with your security, legal, and engineering leads before deprioritising any item in this category. If the deadline is more than 60 days away and the risk is low severity, it may be schedulable without displacing current sprint work.\n  yes -> [SECURITY_COMPLIANCE]\n  no  -> Q2\n\nQ2: Is there a bug that is actively blocking customers from completing a core workflow or causing significant data loss or integrity issues?\n  hint: A customer-blocking bug is one where a user cannot complete a key action — checkout, login, data export, or a contracted workflow — without a workaround from your support team. Distinguish this from bugs that are annoying but non-blocking. Check your support ticket volume, severity labels from your engineering team, and whether a workaround exists that does not require hands-on help from your team. A bug affecting more than 5% of active users or any enterprise customer is typically an immediate priority.\n  yes -> [BUG_FIX]\n  no  -> Q3\n\nQ3: Is technical debt actively slowing down feature delivery — for example, causing engineers to spend more than 20% of sprint capacity on unplanned rework or workarounds?\n  hint: Tech debt becomes a roadmap priority when it creates a compounding velocity tax — each sprint costs more than the last because of accumulated shortcuts. Signals include frequent unplanned rework, repeated \"just five more minutes\" scope creep on simple tickets, fragile deployments that require manual intervention, and engineering estimates that keep increasing for similar-sized features. Ask your tech lead to quantify the velocity cost; if the team is losing a full sprint's worth of capacity every quarter to debt, the case for addressing it is strong.\n  yes -> [TECH_DEBT]\n  no  -> Q4\n\nQ4: Is there a committed new feature — promised in a contract, a public roadmap announcement, or a sales deal — that is at risk of missing its delivery date?\n  hint: A committed feature is one where missing the date has commercial consequences: a contract clause, a deal contingency, or a public commitment that has been communicated to customers. Check your order forms, renewal terms, and any written communication from your sales or account management team. If the commitment is informal (\"we mentioned it on a call\"), work with your commercial lead to determine whether a formal commitment exists before elevating this above other work. Prioritising uncommitted features over genuine tech debt or bugs is one of the most common sources of long-term velocity loss.\n  yes -> [NEW_FEATURE]\n  no  -> Q5\n\nQ5: Is there a measurable performance degradation — such as increased page load times, API latency, or error rates — that is affecting user experience or SLA compliance?\n  hint: Performance improvements sit in a grey zone: they rarely feel as urgent as bugs or security issues but can quietly erode retention and conversion if left unaddressed. Check your p95 and p99 latency trends, your SLA uptime commitments, and whether your error budget is being consumed faster than your reliability targets allow. If a performance issue is within SLA and not trending toward a breach, it can typically be scheduled into the next sprint cycle. If it is approaching or breaching SLA thresholds, treat it with similar urgency to a customer-blocking bug.\n  yes -> [PERFORMANCE]\n  no  -> [TECH_DEBT]\n\n[SECURITY_COMPLIANCE]: Security / Compliance Work\n  color: #dc2626\n  description: Security and compliance items must be addressed before any discretionary engineering work — the legal, reputational, and customer trust risks of delay far outweigh any short-term feature velocity gain. Work with your security lead to scope the fix, establish a clear deadline, and identify the minimum change needed to close the risk without introducing new instability. Communicate the trade-off explicitly to stakeholders: explain what sprint commitments are being moved, why, and when deferred items will be rescheduled. After resolving the immediate issue, schedule a post-mortem to identify how the vulnerability or compliance gap arose and what process changes will prevent recurrence.\n  code: PM_SECURITY_COMPLIANCE\n\n[BUG_FIX]: Bug Fix\n  color: #f97316\n  description: A customer-blocking bug takes immediate priority over new feature work because it is actively degrading the experience of users who are already committed to your product. Escalate the bug to your engineering lead and agree on a hotfix or patch release timeline — ideally within one to three business days for critical severity. Communicate proactively to affected customers through your customer success or support team, providing a clear timeline and a workaround if one exists. Once the fix is shipped, conduct a lightweight root cause analysis to determine whether the bug indicates a systemic testing gap, a missing monitoring alert, or an architecture issue that needs to be addressed in a future tech debt sprint.\n  code: PM_BUG_FIX\n\n[TECH_DEBT]: Technical Debt\n  color: #d97706\n  description: When technical debt is measurably slowing delivery, investing a dedicated sprint or a fixed percentage of capacity (typically 20%) in debt reduction pays compounding dividends in future velocity. Work with your engineering lead to identify the highest-leverage debt items — those that touch the most frequently changed code paths or that carry the greatest risk of causing future incidents. Frame the trade-off to stakeholders in terms of velocity recovery: \"spending two weeks here will recover one week per quarter going forward.\" Avoid treating debt sprints as a dumping ground for everything — pick a focused theme (e.g., test coverage, dependency upgrades, data model normalisation) and measure the velocity impact after the work is complete.\n  code: PM_TECH_DEBT\n\n[NEW_FEATURE]: New Feature\n  color: #2563eb\n  description: A committed new feature has commercial and trust implications that make it the right priority when no urgent bugs, security issues, or crippling tech debt are present. Confirm the exact delivery commitment in writing before proceeding — scope, date, and any acceptance criteria specified in the contract or announcement. Break the feature into the smallest shippable slice that fulfils the commitment and defer non-essential enhancements to a follow-up sprint. Communicate progress weekly to the relevant account manager or sales lead so they can manage customer expectations in real time. After shipping, confirm with the commercial team that the feature has been formally accepted before closing the sprint commitment.\n  code: PM_NEW_FEATURE\n\n[PERFORMANCE]: Performance Improvement\n  color: #16a34a\n  description: Performance improvements become a priority when there is a measurable user impact or an SLA risk, and should be treated with similar urgency to a bug fix if thresholds are being breached. Start by instrumenting the specific bottleneck — do not optimise blindly. Use profiling data, APM tooling, and real-user monitoring (RUM) to isolate the highest-impact target before writing a line of code. Set a clear, measurable success criterion (e.g., \"reduce p95 API latency from 800ms to under 300ms\") so the team knows when the work is done. After shipping the improvement, update your SLA monitoring and alerting thresholds so similar degradation is caught earlier in future.\n  code: PM_PERFORMANCE\n"
}