What should I include in my MVP scope?

{
  "_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-mvp-scope.html",
      "embed": "https://www.drawdecisiontree.com/embed/path/drawdecisiontree/product-mvp-scope",
      "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.344Z"
  },
  "author": {
    "handle": "drawdecisiontree",
    "first_name": "Andrew",
    "last_name": null,
    "avatar_url": "1d32d828-b6ca-40ec-bdd7-771fe7b9c36a/avatar-1778531481027.svg",
    "display_name": "Andrew"
  },
  "file": {
    "id": "27857b58-7ea8-4acb-9410-ce7cd2ef1a7a",
    "name": "What should I include in my MVP scope?",
    "public_slug": "product-mvp-scope",
    "updated_at": "2026-05-12T16:53:43.587978+00:00",
    "url": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-mvp-scope.html",
    "json_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-mvp-scope/tree.json",
    "dsl_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/product-mvp-scope/tree.dag"
  },
  "meta": {
    "description": "Determine whether a capability belongs in the MVP or should be deferred to a later release. Guides PMs through the core user journey, customer commitments, differentiation value, and interim workarounds to make a clear scoping call. Use this during feature kickoff and pre-launch scope reviews.",
    "mode": "decision",
    "entry": "Q1",
    "tags": [
      "product management",
      "mvp",
      "scope",
      "product strategy",
      "launch"
    ],
    "image": "https://images.unsplash.com/photo-1507925921958-8a62f3d1a50d?w=1200&q=80"
  },
  "questions": [
    {
      "id": "Q1",
      "text": "Does this capability block a user from completing the core job-to-be-done the MVP is designed to solve?"
    },
    {
      "id": "Q2",
      "text": "Has this capability been explicitly committed to a customer or partner as part of a signed agreement or public announcement?"
    },
    {
      "id": "Q3",
      "text": "Has this capability been explicitly committed to a customer or partner as part of a signed agreement or public announcement?"
    },
    {
      "id": "Q4",
      "text": "Does this capability meaningfully differentiate the product from direct competitors in a way that influences the target customer's buying decision?"
    },
    {
      "id": "Q5",
      "text": "Is there a manual or low-tech workaround that the team or customer can use in the interim without significant operational burden?"
    }
  ],
  "outcomes": [
    {
      "id": "CORE",
      "label": "Include in MVP (Core)"
    },
    {
      "id": "IF_CAPACITY",
      "label": "Include in MVP (If Capacity)"
    },
    {
      "id": "DEFER_V1_1",
      "label": "Defer to V1.1"
    },
    {
      "id": "DEFER_LATER",
      "label": "Defer to Later"
    },
    {
      "id": "CUT",
      "label": "Cut Entirely"
    }
  ],
  "dsl": "dag: What should I include in my MVP scope?\nversion: 1.0.0\nimage: https://images.unsplash.com/photo-1507925921958-8a62f3d1a50d?w=1200&q=80\ndescription: Determine whether a capability belongs in the MVP or should be deferred to a later release. Guides PMs through the core user journey, customer commitments, differentiation value, and interim workarounds to make a clear scoping call. Use this during feature kickoff and pre-launch scope reviews.\ntags: product management, mvp, scope, product strategy, launch\nentry: Q1\n\nQ1: Does this capability block a user from completing the core job-to-be-done the MVP is designed to solve?\n  hint: The core job-to-be-done is the primary reason a user would open your product. If removing this capability means a user cannot complete that end-to-end flow — not just have a degraded experience, but literally cannot finish — it is a blocker. Be ruthless here; scope creep often enters through loose interpretations of \"blocking\". Map the exact steps in the happy path and check whether this feature appears in them.\n  yes -> Q2\n  no  -> Q3\n\nQ2: Has this capability been explicitly committed to a customer or partner as part of a signed agreement or public announcement?\n  hint: Check contracts, order forms, launch blog post drafts, and any written or verbal commitments from sales or leadership. A committed capability is a trust and legal liability issue, not just a product decision. If there is any ambiguity, loop in your legal or commercial lead before making a scoping call. \"We mentioned it in a demo\" is not the same as a contractual commitment.\n  yes -> [CORE]\n  no  -> [CORE]\n\nQ3: Has this capability been explicitly committed to a customer or partner as part of a signed agreement or public announcement?\n  hint: Even if the capability is not on the critical path, a prior commitment to a customer or partner elevates its priority significantly. Missing a committed feature damages trust, risks churn, and can create legal exposure. Verify the commitment in writing before treating this as discretionary. If the commitment was informal, work with your commercial team to reset expectations proactively before launch.\n  yes -> [IF_CAPACITY]\n  no  -> Q4\n\nQ4: Does this capability meaningfully differentiate the product from direct competitors in a way that influences the target customer's buying decision?\n  hint: Differentiation that matters is differentiation that shows up in win/loss analysis, in sales call objections, or in customer interview transcripts. If you cannot point to evidence that this capability shifts a purchase decision, it is probably a table-stakes nice-to-have rather than a genuine differentiator. Table-stakes features can often be deferred if a workaround exists.\n  yes -> Q5\n  no  -> [DEFER_LATER]\n\nQ5: Is there a manual or low-tech workaround that the team or customer can use in the interim without significant operational burden?\n  hint: A viable workaround must be something the customer can realistically perform without dedicated support from your team every time. Spreadsheets, email processes, or manual configuration by an admin can qualify — but only if they do not create unsustainable support load or damage the customer experience in a way that affects retention. If the workaround is only viable internally (not exposed to customers), that is usually acceptable for an MVP window of three to six months.\n  yes -> [DEFER_V1_1]\n  no  -> [IF_CAPACITY]\n\n[CORE]: Include in MVP (Core)\n  color: #16a34a\n  description: This capability is non-negotiable for the MVP — either because it is on the critical user journey or because it has been committed to a customer or partner. Treat it as a must-ship item in your sprint plan and ensure it is covered by acceptance criteria and QA before the launch gate. Alert your engineering lead now if there is any risk to delivery so you can make scope trade-offs elsewhere rather than compromising this item. Track its readiness weekly in your launch checklist and do not allow it to slip without a deliberate decision from the full product and engineering leadership team.\n  code: PM_MVP_CORE\n\n[IF_CAPACITY]: Include in MVP (If Capacity)\n  color: #2563eb\n  description: This capability adds genuine value but is not strictly critical to the core journey. Include it in the sprint plan as a stretch goal that gets cut if velocity falls short, and communicate this status clearly to engineering and stakeholders so there are no surprises at the launch gate. Prepare a contingency plan — typically a manual workaround or a \"coming soon\" communication — that can be activated without delay if this item slips. Do not let it consume disproportionate engineering attention at the expense of core items.\n  code: PM_MVP_IF_CAPACITY\n\n[DEFER_V1_1]: Defer to V1.1\n  color: #d97706\n  description: A workaround exists and this capability does not block the core journey, making it a strong candidate for the first post-launch release rather than the MVP. Document the workaround clearly in your internal runbook and your customer-facing help content so support teams can handle incoming questions without escalating. Set a firm target to ship this in the first sprint cycle after MVP launch, and communicate the timeline to any affected customers proactively. Add it to the top of the V1.1 candidate list so it is not deprioritised again during the next planning cycle.\n  code: PM_DEFER_V1_1\n\n[DEFER_LATER]: Defer to Later\n  color: #9333ea\n  description: This capability is neither on the critical path nor sufficiently differentiated to justify MVP investment. Park it in the backlog with a note explaining the scoping rationale so future planners have context when revisiting it. If customer feedback after launch surfaces this as a recurring pain point, it should be re-evaluated in the next quarterly planning cycle with fresh evidence. Avoid letting deferred items linger indefinitely — schedule a backlog review 60 days after launch to assess whether post-launch data changes the prioritisation calculus.\n  code: PM_DEFER_LATER\n\n[CUT]: Cut Entirely\n  color: #dc2626\n  description: This capability does not belong in the MVP or foreseeable near-term roadmap. Formally remove it from the scope document and communicate the decision to any stakeholders who have previously discussed it, providing a clear rationale. Document it in your \"won't do\" list so the team does not re-litigate the decision repeatedly. If a customer or prospect asks about it, the commercial team should be briefed on the official position so messaging stays consistent.\n  code: PM_CUT\n"
}