How to Make a Roadmap That Actually Supports Discovery

[
  {
    "__component": "shared.rich-text",
    "id": 287,
    "body": "**Roadmaps are one of the most misunderstood tools in product.**\n\nThey try to be everything at once: vision, backlog, commitment, status update, and shiny slide for stakeholders. They blur the line between strategy, prioritisation, and delivery. They often get outdated quickly or require significant effort just to maintain. And worst of all? They tend to squeeze out discovery altogether.\n\nIf your roadmap looks more like a feature delivery calendar than a living plan for outcomes, you’re not alone. Most roadmap templates—especially the timeline-based ones—favour certainty over exploration. But product discovery thrives in the uncertain.\n\nSo how do you build a roadmap that respects the unknown? One that guides your team without boxing them in?\n\nThis article explores the roadmap types out there, how to make them work in a discovery-driven environment, and what to do with ideas that aren’t ready yet.\n\n## **Strategy, Prioritisation, and Delivery: Not the Same Thing**\n\nLet’s get clear on the difference between three crucial but often conflated concepts:\n\n* **Strategy** \\= where you’re going and why\n\n* **Prioritisation** \\= what matters most now\n\n* **Delivery planning** \\= how and when you’ll do it\n\nA roadmap that tries to do all three at once tends to serve none of them well. It becomes vague, rigid, or overly tactical. And when you try to “fit” discovery into that system, you find there’s no room for it—because every line is already spoken for.\n\n## **Types of Roadmaps (and How They Help or Hinder Discovery)**\n\nThere’s no one “right” roadmap. Each format has its place—depending on your audience, company stage, and how discovery-driven your team is. Here’s a closer look at the most common styles, and how they either support or squeeze out early-stage thinking.\n\n### 📊 **Timeline / Gantt-Style Roadmaps**\n\n#### What It Is:\n\nA classic, linear view of projects plotted over time—usually broken down into features or phases. Think bars on a timeline. These are typically built in tools like Excel, PowerPoint, or tools like Aha\\! and Jira Advanced Roadmaps. They look polished and predictable.\n\n#### What It Looks Like:\n\nA cascading series of deliverables, often colour-coded by team or status. Each item shows a start and end date, sometimes with dependencies.\n\n#### PM View:\n\nFrustrating. It demands fixed timelines before real discovery has happened. Most features are too vague or under-scoped to estimate properly. Updates are labour-intensive and don’t reflect reality. Worst of all, teams often skip discovery entirely just to “make the roadmap”.\n\n#### Stakeholder View:\n\nComforting. Timelines feel like progress. But stakeholders often treat them as commitments, not estimates—which creates tension when things shift.\n\n#### Discovery Fit:\n\n❌ Low. This format assumes you already know what you’re building and how long it will take. It leaves no room for ambiguity, iteration, or upfront learning.\n\n#### Workaround:\n\nUse Gantt-style roadmaps only for high-level initiatives or known workstreams. Avoid assigning hard dates to unknowns. Label timeframes as tentative or use fuzzy markers like “Q1–Q2”. Only include work that:\n\n* Has been scoped for feasibility,  \n* Has a known goal and path,  \n* Is close to implementation.\n\nAvoid the trap of putting speculative discovery ideas into this format—they’ll be treated as commitments before they’re ready.\n\n#### Best Fit For:\n\n* Enterprise organisations with long planning cycles  \n* Projects with regulatory or contractual deadlines  \n* External stakeholders that demand high predictability\n\n#### Summary:\n\nLooks good on a slide, but dangerous if treated as gospel. Use sparingly and only for work that’s been through early validation."
  },
  {
    "__component": "shared.media",
    "id": 30,
    "file": {
      "id": 91,
      "documentId": "yh9i92zoqfr206kqvotch23j",
      "name": "gantt-roadmap-team-working-analysis.png",
      "alternativeText": "Gantt-style roadmap with product team analysing and working beneath timeline bars",
      "caption": null,
      "width": 1536,
      "height": 1024,
      "formats": {
        "thumbnail": {
          "ext": ".png",
          "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1745093701/thumbnail_gantt_roadmap_team_working_analysis_ea58440894.png",
          "hash": "thumbnail_gantt_roadmap_team_working_analysis_ea58440894",
          "mime": "image/png",
          "name": "thumbnail_gantt-roadmap-team-working-analysis.png",
          "path": null,
          "size": 42.02,
          "width": 234,
          "height": 156,
          "sizeInBytes": 42021,
          "provider_metadata": {
            "public_id": "thumbnail_gantt_roadmap_team_working_analysis_ea58440894",
            "resource_type": "image"
          }
        }
      },
      "hash": "gantt_roadmap_team_working_analysis_ea58440894",
      "ext": ".png",
      "mime": "image/png",
      "size": 504.7,
      "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1745093701/gantt_roadmap_team_working_analysis_ea58440894.png",
      "previewUrl": null,
      "provider": "cloudinary",
      "provider_metadata": {
        "public_id": "gantt_roadmap_team_working_analysis_ea58440894",
        "resource_type": "image"
      },
      "createdAt": "2025-04-19T20:15:02.473Z",
      "updatedAt": "2025-04-19T22:16:10.023Z",
      "publishedAt": "2025-04-19T20:15:02.475Z"
    }
  },
  {
    "__component": "shared.rich-text",
    "id": 288,
    "body": "### 🔀 Now / Next / Later Roadmap\n\n#### What It Is:\n\nA priority-based roadmap that divides work into three buckets:\n\n* **Now**: Currently in progress\n\n* **Next**: On deck\n\n* **Later**: Likely, but not scoped yet\n\n#### What It Looks Like:\n\nA simple three-column board, often in tools like ProdPad, Trello, or Notion. Sometimes enhanced with tags (e.g. team, goal) or effort estimates.\n\n#### PM View:\n\nFlexible and honest. Encourages realistic planning. Allows for shifting priorities without overhauling the roadmap. Helps manage the mess of uncertainty without pretending it’s all figured out.\n\n#### Stakeholder View:\n\nInitially confusing—there are no dates\\! But over time, this format builds trust by surfacing real-time decisions and showing priorities transparently.\n\n#### Discovery Fit:\n\n✅ **High.** Discovery work can live in the **Later** column while being explored. Nothing is promised until it’s validated and pulled forward. This lets ideas breathe without pressure.\n\n#### Workaround:\n\nAdd rough effort signals—e.g. Weeks, Months, Quarters—to give some time-based context without firm dates. Use high-touch stakeholder comms (emails, demos, show-and-tells) to keep them informed, since this format doesn’t show timelines.\n\n#### Best Fit For:\n\n* Startups and scaleups  \n* Product teams with discovery embedded in their workflow  \n* Teams working on platform, internal tools, or iterative UX work\n\n#### Summary:\n\nRespects uncertainty. Easy to update. Perfect for lean, exploratory teams who value transparency over prediction."
  },
  {
    "__component": "shared.media",
    "id": 31,
    "file": {
      "id": 101,
      "documentId": "l8p8j5c7rxmyc7qnpn0pifma",
      "name": "now-next-later-roadmap-product-team-working.png",
      "alternativeText": "Now Next Later roadmap with product team analysing and working beneath timeline bars",
      "caption": null,
      "width": 1536,
      "height": 1024,
      "formats": {
        "thumbnail": {
          "ext": ".png",
          "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1745101038/thumbnail_now_next_later_roadmap_product_team_working_86619fed8a.png",
          "hash": "thumbnail_now_next_later_roadmap_product_team_working_86619fed8a",
          "mime": "image/png",
          "name": "thumbnail_now-next-later-roadmap-product-team-working.png",
          "path": null,
          "size": 44.14,
          "width": 234,
          "height": 156,
          "sizeInBytes": 44141,
          "provider_metadata": {
            "public_id": "thumbnail_now_next_later_roadmap_product_team_working_86619fed8a",
            "resource_type": "image"
          }
        }
      },
      "hash": "now_next_later_roadmap_product_team_working_86619fed8a",
      "ext": ".png",
      "mime": "image/png",
      "size": 430.98,
      "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1745101039/now_next_later_roadmap_product_team_working_86619fed8a.png",
      "previewUrl": null,
      "provider": "cloudinary",
      "provider_metadata": {
        "public_id": "now_next_later_roadmap_product_team_working_86619fed8a",
        "resource_type": "image"
      },
      "createdAt": "2025-04-19T22:17:19.996Z",
      "updatedAt": "2025-04-19T22:17:19.996Z",
      "publishedAt": "2025-04-19T22:17:19.997Z"
    }
  },
  {
    "__component": "shared.rich-text",
    "id": 289,
    "body": "### 🎯 Goal-Oriented or Outcome-Based Roadmaps\n\n#### What It Is:\n\nA roadmap structured around outcomes—not features. Each entry answers the question: “What are we trying to achieve?” rather than “What are we shipping?”\n\n#### What It Looks Like:\n\nOften grouped by product goal or business objective. Under each goal, teams list experiments, opportunities, or potential features. Commonly managed in Notion, FigJam, or whiteboard tools like Miro.\n\n#### PM View:\n\nEmpowering. Gives room to explore. Supports iterative thinking. Helps tie backlog work back to broader business bets.\n\n#### Stakeholder View:\n\nRequires education. Some stakeholders prefer concrete features. But others (especially execs and founders) appreciate seeing how product work supports KPIs.\n\n#### Discovery Fit:\n\n✅✅ **Very High.** Discovery is central to this model. Teams are aligned on **why** they’re working on something, but the **what** and **how** are still up for grabs.\n\n#### Workaround:\n\nProvide light-weight timelines (e.g. “We aim to hit this goal this quarter”), and list possible ideas under each goal to help stakeholders visualise the work.\n\n#### Best Fit For:\n\n* Product-led organisations\n\n* Teams running continuous discovery\n\n* Cross-functional groups solving complex problems\n\n#### Summary:\n\nThe gold standard for discovery-centric teams. Ties day-to-day work to real impact and encourages outcome-first thinking."
  },
  {
    "__component": "shared.media",
    "id": 32,
    "file": {
      "id": 102,
      "documentId": "wjp9vznzyfdlb8ndifmzdu7t",
      "name": "goal-oriented-roadmap-illustration.png",
      "alternativeText": "Flat illustration of a team working on a roadmap focused on goals and KPIs",
      "caption": null,
      "width": 1536,
      "height": 1024,
      "formats": {
        "thumbnail": {
          "ext": ".png",
          "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1745101076/thumbnail_goal_oriented_roadmap_illustration_852388cc48.png",
          "hash": "thumbnail_goal_oriented_roadmap_illustration_852388cc48",
          "mime": "image/png",
          "name": "thumbnail_goal-oriented-roadmap-illustration.png",
          "path": null,
          "size": 36.68,
          "width": 234,
          "height": 156,
          "sizeInBytes": 36677,
          "provider_metadata": {
            "public_id": "thumbnail_goal_oriented_roadmap_illustration_852388cc48",
            "resource_type": "image"
          }
        }
      },
      "hash": "goal_oriented_roadmap_illustration_852388cc48",
      "ext": ".png",
      "mime": "image/png",
      "size": 374.34,
      "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1745101078/goal_oriented_roadmap_illustration_852388cc48.png",
      "previewUrl": null,
      "provider": "cloudinary",
      "provider_metadata": {
        "public_id": "goal_oriented_roadmap_illustration_852388cc48",
        "resource_type": "image"
      },
      "createdAt": "2025-04-19T22:17:58.776Z",
      "updatedAt": "2025-04-19T22:17:58.776Z",
      "publishedAt": "2025-04-19T22:17:58.776Z"
    }
  },
  {
    "__component": "shared.rich-text",
    "id": 290,
    "body": "### 🧩 Theme-Based or Problem-Led Roadmaps\n\n#### What It Is:\n\nA roadmap organised around high-level themes or user problems, rather than timelines or individual features. Think “Improve activation for new users” or “Reduce support requests for billing” instead of “Build onboarding tour” or “Add FAQ page”.\n\n#### What It Looks Like:\n\nA list or board grouped into big buckets like “Conversion Improvements,” “Performance,” or “Customer Retention.” Under each theme, you might list ideas, experiments, or work in progress. Some teams use Kanban boards or OKR dashboards to visualise them. Others break these themes into quarterly focuses.\n\n#### PM View:\n\nStrategic and flexible. It helps keep attention on meaningful problems rather than pre-scoped solutions. Encourages experimentation within a problem space. Particularly useful when your backlog is filled with small requests and you need to zoom out.\n\n#### Stakeholder View:\n\nMixed. Some stakeholders love the clarity of “what we’re focusing on.” Others may push back, asking “but what are you *doing*?”—especially if they’re used to timelines or concrete deliverables.\n\n#### Discovery Fit:\n\n✅ **High.** This format invites exploration. Teams can run discovery, ideation, testing, and delivery all within the bounds of a theme. It gives permission to iterate toward a better solution without prematurely committing.\n\n#### Workaround:\n\nIf your stakeholders are feature- or delivery-focused, combine this format with regular updates (demo days, changelogs, impact reports) that show what has been delivered or tested within each theme. This provides reassurance without constraining the process.\n\n#### Best Fit For:\n\n* Mid-stage product teams juggling tech debt, user problems, and growth bets\n\n* Cross-functional teams managing a high volume of inbound ideas\n\n* Any org that wants to focus effort without locking down solutions\n\n#### Summary:\n\nA powerful tool for shaping roadmap conversations around *why* and *what matters*, not just *what’s next*. Helps balance structure and exploration."
  },
  {
    "__component": "shared.media",
    "id": 33,
    "file": {
      "id": 89,
      "documentId": "o6703yx693iwvnm260upgn1q",
      "name": "Roadmapping Tools Matrix – Discovery vs Flexibility.png",
      "alternativeText": "Matrix chart showing roadmap tools by discovery friendliness and flexibility",
      "caption": null,
      "width": 1536,
      "height": 1024,
      "formats": {
        "thumbnail": {
          "ext": ".png",
          "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1745090745/thumbnail_Roadmapping_Tools_Matrix_Discovery_vs_Flexibility_a646294973.png",
          "hash": "thumbnail_Roadmapping_Tools_Matrix_Discovery_vs_Flexibility_a646294973",
          "mime": "image/png",
          "name": "thumbnail_Roadmapping Tools Matrix – Discovery vs Flexibility.png",
          "path": null,
          "size": 24.98,
          "width": 234,
          "height": 156,
          "sizeInBytes": 24979,
          "provider_metadata": {
            "public_id": "thumbnail_Roadmapping_Tools_Matrix_Discovery_vs_Flexibility_a646294973",
            "resource_type": "image"
          }
        }
      },
      "hash": "Roadmapping_Tools_Matrix_Discovery_vs_Flexibility_a646294973",
      "ext": ".png",
      "mime": "image/png",
      "size": 449.98,
      "url": "https://res.cloudinary.com/dmkbljcg2/image/upload/v1745090745/Roadmapping_Tools_Matrix_Discovery_vs_Flexibility_a646294973.png",
      "previewUrl": null,
      "provider": "cloudinary",
      "provider_metadata": {
        "public_id": "Roadmapping_Tools_Matrix_Discovery_vs_Flexibility_a646294973",
        "resource_type": "image"
      },
      "createdAt": "2025-04-19T20:25:44.628Z",
      "updatedAt": "2025-04-19T22:18:47.653Z",
      "publishedAt": "2025-04-19T20:25:44.628Z"
    }
  },
  {
    "__component": "shared.rich-text",
    "id": 291,
    "body": "## Discovery Deserves Its Own Lane\n\nOne of the biggest problems with traditional roadmaps is that they only show ideas that are ready to build.\n\nThat leaves all your early-stage thinking—your sparks, your explorations, your “we’re still figuring it out”—off the radar. And that’s dangerous.\n\nEarly ideas may not be roadmap-ready. But they still matter. They still deserve time, space, and visibility.\n\nThat’s why having a parallel **idea stream** or **discovery workflow** is essential. Something that tracks what you’re exploring, learning, or validating—before it ever becomes a ticket.\n\n## What Should Actually Go on the Roadmap?\n\nThis is where things often fall apart. Too often, the roadmap becomes a dumping ground for every feature idea, no matter how untested or undefined it is. But a good roadmap isn’t a wishlist—it’s a commitment to explore or deliver the most valuable work next.\n\nThe question is: **how do you know what’s actually ready to go on the roadmap?**\n\nA roadmap-worthy initiative doesn’t need to be 100% defined. But it does need to meet some basic thresholds:\n\n* You understand the **problem space** well enough to justify attention.\n\n* You have **stakeholder alignment** that the problem is worth solving.\n\n* The **technical feasibility** is scoped enough to avoid total guesswork.\n\n* You have at least some sense of **effort** (e.g. weeks vs. quarters).\n\n* There’s a clear **connection to company or product goals**.\n\nThat doesn’t mean you need to write a full spec or know every requirement. It just means the idea has passed the threshold from “we’re curious” to “we’re serious.” That it’s no longer just a spark, but something ready to be prioritised alongside other work.\n\nThis is where your **discovery workflow** feeds the roadmap. Ideas that are still being explored stay in your discovery system. But once they’ve cleared key questions—what problem are we solving, for whom, and why now—they graduate onto the roadmap.\n\nThat graduation might mean being placed in the “Next” column of a Now/Next/Later board. Or getting grouped under a theme like “Onboarding Improvements.” Or listed as a quarterly objective under “Improve Conversion Rate.” The format is less important than the rigour of how something makes it onto the roadmap.\n\nIn short: the roadmap is a signal of focus and intent. It’s not a backlog, and it’s not a bet on every possible idea. It’s a way to say: “this is what we’re exploring or delivering next, based on everything we’ve learned so far.”\n\n## Outputs vs Outcomes: The Roadmap Trap\n\nOne of the biggest dangers in roadmap planning is mistaking **outputs** for **outcomes**.\n\nAn output is what you *build*—a new feature, an interface update, an integration. An outcome is what that output is *meant to achieve*—higher conversion, lower churn, faster onboarding, fewer support tickets.\n\nIt’s easy to fall into the trap of filling your roadmap with features: \"Launch new dashboard\", \"Add live chat\", \"Build dark mode\". But if you stop there, you’ve missed the point. Because building things doesn’t equal delivering value.\n\nFocusing on outcomes forces you to stay grounded in impact. Why are we doing this? What behaviour are we hoping to influence? What business result should we see?\n\nAnd here’s where most roadmaps break down: once the feature is delivered, it disappears. The outcome is never measured. The impact is never validated. And the team moves on to the next shiny thing.\n\nWhen that happens, you’re essentially flying blind. You don’t know if what you shipped actually worked. You can’t learn from it. You’re not compounding your insight—you’re resetting with every sprint.\n\nGreat roadmaps are not just a plan to build. They’re a plan to test, to observe, and to adapt. When outcomes are tied to every initiative, you create feedback loops. You surface what’s working. You flag what’s not. You give your team the permission—and the expectation—to change direction if something isn’t landing.\n\nAnd that’s how you end up with a **learning roadmap**, not just a delivery plan. One that evolves with the business, not despite it.\n\n## How to Connect Metrics to Your Roadmap\n\nMetrics bring meaning to your roadmap. Without them, it’s hard to know whether your features are doing anything more than shipping code.\n\nBefore you even think about how to store roadmap metrics, ask yourself why it matters.\n\nMetrics help you:\n\n* **Validate outcomes**: Did the thing you shipped actually move the needle?  \n* **Tell better stories**: When stakeholders ask “what impact did we make?”, you’ll have the answer.  \n* **Make smarter decisions**: Features that perform well can be expanded. Features that flop can be learned from—or avoided.  \n* **Close the loop**: You can’t claim a roadmap was successful without knowing whether the goals were met.\n\nSo what should you track?\n\nFor every roadmap item (or experiment), you want to capture:\n\n* **The goal** – What’s the intended impact? (e.g. improve sign-up rate)  \n* **The metric(s)** – What are you measuring? (e.g. conversion %, time on task)  \n* **The baseline** – Where were you before the change?  \n* **The result** – What happened after release?  \n* **The final decision** – What did you learn? What’s the next step?  \n* **Unexplored options** – Were there other ideas that were shelved? Note them for the future.\n\nThis isn’t just helpful for product teams—it’s valuable for marketing, sales, support, design, and anyone else who relies on the product’s performance to inform their work. It becomes a reference library of what works (and what doesn’t).\n\nThis is exactly the point of keeping track of test and feature history. If you haven’t already, check out [our full blog on how to do that well](https://produmo.com/blog/how-to-keep-track-of-a-b-tests-and-feature-launches-and-why-it-matters).\n\nWhen metrics are linked directly to roadmap initiatives, you also unlock future-facing benefits:\n\n* **Prioritisation** becomes easier. You can lean on what’s worked in the past.  \n* **Board reporting** becomes faster. You’re not digging through old decks for numbers.  \n* **Discovery becomes richer.** You can spot patterns and revisit ideas that showed promise.\n\nAnd for features that don’t move forward? Store *why*. What blocked it? What needs to change for it to be viable in future? These are breadcrumbs for your future self—or your successor.\n\nIn short: every roadmap item should have a measurable purpose and a visible result. If not, what’s it doing on the roadmap?\n\n## Internal vs External Roadmaps (And Why You Probably Need Both)\n\nLet’s be honest: most of the tension in roadmap creation comes from trying to serve two very different audiences with one document.\n\n* Your **internal team** needs flexibility, clarity on priorities, and room to change course when discovery shifts.  \n* Your **external stakeholders** (execs, clients, sales, marketing) want visibility, confidence, and ideally, some dates.\n\nSo instead of trying to make one roadmap do both jobs poorly, it’s smarter to separate them.\n\n#### **Internal Roadmap**\n\nThis is for your **product and delivery teams**.  \n Its purpose is to:\n\n* Align cross-functional work  \n* Plan priorities  \n* Track discovery progress  \n* Organise what’s ready to build and what’s still in the pipeline\n\nIt should be honest, messy, and iterative. A living document that supports real-time decision-making. It might be structured in a Now/Next/Later format, a theme-based board, or even a discovery workflow that feeds into delivery.\n\nIt’s not always pretty. But it works.\n\n#### **External Roadmap**\n\nThis is for **stakeholders who need confidence**—sales teams pitching deals, execs planning budgets, marketing lining up campaigns.\n\nIt should communicate:\n\n* What you’re aiming to solve and why  \n* What’s in progress (without overcommitting)  \n* What you’ve recently delivered (with impact, if possible)\n\nThis roadmap isn’t about raw planning. It’s about **managing expectations** and **building trust**.\n\nSome teams use timelines here—but only with caveats. A more discovery-friendly version might group upcoming work by themes or problem areas, without fixed dates. Think: \"Improving onboarding\" or \"Optimising payments\".\n\nIt helps show direction without pretending you’ve mapped the next 12 months perfectly (because you haven’t).\n\n#### **One Source of Truth, Two Views**\n\nThe mistake isn’t having multiple roadmaps. The mistake is **not connecting them**.\n\n* Your internal roadmap should reflect the *reality* of where your team is.  \n* Your external roadmap should reflect the *narrative* of where you’re going.\n\nBoth should pull from the same source of truth—your discovery system, planning sessions, prioritisation models—but they serve different communication needs.\n\nThe result? Fewer stakeholder freakouts. More trust across the business. And a team that’s empowered to do real product work—not just project theatre.\n\n## Real-World Example: Roadmaps That Actually Worked\n\nAt a fast-moving scale-up I worked at, we had a lean tech team supporting a surprisingly complex organisation. We were a team of: A small number of developers, 2 Product Managers, 1 Designer, and 1 Data Analyst\n\nThat was it. And we were responsible for **6–7 distinct product lines**, serving over **100 employees across 9 different teams**, from Sales and Marketing to Operations and Customer Support.\n\nWith so many competing priorities and so few resources, we had to get creative. A one-size-fits-all roadmap wasn’t going to work. Instead, we created different roadmap formats for different parts of the business—tailored to how those products operated, what level of discovery they needed, and how their stakeholders worked.\n\n#### **Internal Software (Operations Tools)**\n\nFor our internal software used by customer service, sales, and ops teams, we used a **Now/Next/Later** roadmap.\n\nWe’d tag each item with a rough **effort estimate**—but not in story points or days. We used time horizons:\n\n* **Weeks** – quick wins we understood well  \n* **Months** – medium-sized projects with known complexity  \n* **Quarters** – initiatives with more unknowns or cross-functional work\n\nThis kept things loose enough for discovery, while still giving leadership a sense of relative size. Our CTO would assign these estimates—not Product—based on feasibility, which kept expectations realistic.\n\n#### **Customer-Facing Website**\n\nHere, we used a **goal-based outcome roadmap**.\n\nEach quarter, we defined a key theme or goal—like *“Improve conversion in the lead generation flow”*—and listed potential ideas against that. This format gave us freedom to run **lots of A/B tests** and move quickly. We weren’t locked into building Feature X by Month Y—we were free to chase outcomes.\n\nIt worked beautifully for growth, but required **constant communication** with stakeholders. We kept them in the loop with Slack updates, monthly showcases, and a living dashboard showing what was shipping and what results we were seeing.\n\n#### **SEO Engineering**\n\nOur Principal Engineer had a **blank roadmap**.\n\nInstead, he was given a **north star goal**: *“Make us the most SEO-friendly travel site in the market.”* No timeline. No feature list. Just a direction and the autonomy to chase it.\n\nHe ran experiments, improved technical SEO, coordinated with Marketing, and delivered massive results over time. This wouldn’t work for every role—but it showed how powerful it can be when the **roadmap is a principle, not a plan**.\n\n#### **Reporting Upwards**\n\nFor the board and exec team, we built a high-level monthly summary:\n\n* What shipped  \n* What’s in progress  \n* What’s coming next\n\nWe tied each feature to a goal or OKR where possible, and shared early data when we had it. No timelines. Just transparency and trust.\n\n## Tools and Approaches: What’s Out There?\n\nIf you’re looking for roadmapping software, there’s no shortage of options. But not all tools are built with discovery in mind. Here's a closer look at how the most popular tools stack up—especially if you're trying to build a roadmap that balances strategy, execution, and exploration.\n\n#### ProdPad\n\n**Best for:** Outcome-oriented teams focused on discovery.\n\n* **What it does well:** ProdPad was built to support **lean product thinking**, not just delivery. It separates discovery work from the delivery roadmap by using **idea backlogs**, **product experiments**, and **goal-led roadmaps**. You can assign confidence levels to roadmap items, create problem statements instead of features, and connect everything to OKRs.  \n* **Where it falls short:** The UI has a learning curve. If your team expects a clean backlog-to-ticket flow, it might feel a bit abstract. More opinionated than other tools—which is great for alignment, but harder for flexibility.  \n* **Discovery fit:** Excellent. Arguably the tool most focused on discovery workflows.  \n* **Org size fit:** Startups and scaleups, but also used in large orgs that embrace dual-track agile or lean methodologies.\n\n#### Aha\\!\n\n**Best for:** Larger teams and organisations that need structured strategy alignment and layered planning.\n\n* **What it does well:** Aha\\! supports complex hierarchies—**goals, initiatives, features, releases, epics**, and so on. It gives you roadmaps, Gantt charts, timelines, value scoring, and dependencies all under one roof. It also supports **idea portals** for capturing external requests.  \n* **Where it falls short:** It can feel heavy, and onboarding takes time. Discovery is possible, but it’s often **treated as a front-loaded planning phase** rather than an ongoing loop.  \n* **Discovery fit:** Moderate. You can do discovery work, but the system leans toward upfront planning and delivery alignment.  \n* **Org size fit:** Mid-market to enterprise. Very powerful for large teams.\n\n#### Miro\n\n**Best for:** Collaborative brainstorming, visual roadmapping, and early discovery phases.\n\n* **What it does well:** Miro is a flexible canvas for visual thinkers. Many PMs use it to **co-create problem statements**, **map journey flows**, and even sketch **goal-based roadmaps**. Its templates are useful for early-stage ideation and alignment across cross-functional teams.  \n* **Where it falls short:** It’s not a roadmap tool in itself. There’s **no structured tracking**, no dependencies, no integration with delivery platforms. You’ll have to **export and maintain manually**.  \n* **Discovery fit:** High for early discovery. Low for tracking or execution.  \n* **Org size fit:** Any size. Used from startups to enterprises for whiteboarding and workshops.\n\n#### Notion\n\n**Best for:** Teams looking for flexibility and a centralised documentation \\+ roadmap hub.\n\n* **What it does well:** Notion gives you the power to build your own lightweight roadmap templates. You can create pages for goals, features, backlog, and link test results, discovery notes, and team input. You can even build a Now/Next/Later view.  \n* **Where it falls short:** It’s **not purpose-built for product management**. There's no built-in metrics, integrations with delivery tools, or idea scoring.  \n* **Discovery fit:** Strong if you're willing to build your own structure.  \n* **Org size fit:** Startups and scaleups. Can be scaled up with a good internal process.\n\n#### Jira Advanced Roadmaps (formerly Portfolio)\n\n**Best for:** Teams already deep into Jira and needing a connected view of roadmap and delivery.\n\n* **What it does well:** Full visibility of **epics, features, releases** across teams with granular control over timelines, dependencies, and team velocity. Built directly into Jira.  \n* **Where it falls short:** **Heavy on delivery**, light on early discovery. Difficult to visualise work unless it’s already been scoped and ticketed. Limited support for upstream idea management.  \n* **Discovery fit:** Low. Best for execution planning and tracking.  \n* **Org size fit:** Mid-to-large companies with multiple squads using Jira heavily.\n\n#### Airtable\n\n**Best for:** Customisable lightweight roadmaps with tagging and views.\n\n* **What it does well:** Airtable can be built into almost any structure you want. You can tag initiatives by status, team, priority, and more. Great for lean teams who want to prototype their own roadmap format before investing in a full product tool.  \n* **Where it falls short:** **No opinions or guidance**—you have to define your own process. Doesn’t integrate deeply with PM tools out of the box.  \n* **Discovery fit:** Depends on your setup. Can work well if structured properly.  \n* **Org size fit:** Startups and scaleups. Great for experimental or evolving product teams.\n\n### What About Enterprise Tools?\n\nIf you're in a larger org, you may also encounter tools like:\n\n* **Roadmunk** – Built for sharing clean, visual roadmaps with external stakeholders. Good for transparency, but lacks built-in discovery features.  \n* **Craft.io** – Balances roadmapping and backlog management. Great integrations. Better than Jira for some, but still opinionated around linear workflows.  \n* **Productboard** – Strong at **centralising feedback**, linking it to features, and prioritising accordingly. Less focused on early discovery, but very good for aligning delivery with user needs.\n\n## Final Thought: Discovery Deserves a Seat at the Roadmap Table\n\nRoadmaps don’t have to kill discovery. But if you’re not careful, they will.\n\nWhen your roadmap becomes a glorified backlog or a set of deadlines that no one believes in, it stops being useful. It becomes a liability—something you defend, massage, or ignore rather than use.\n\nBut a good roadmap?  \n A good roadmap is alive. It’s shaped by strategy, grounded in prioritisation, and responsive to learning. It points in a direction while still leaving room to explore how to get there. It doesn’t treat ideas as fixed, but as evolving bets—ones that deserve validation, iteration, and sometimes, shelving.\n\nYou don’t have to pick just one format.  \n You don’t have to solve all problems with one roadmap.  \n And you definitely don’t need to lock yourself into a 12-month Gantt chart to look like you’ve got a plan.\n\nIn our team, with a small number of developers, two PMs, a designer and data analyst, and over 100 people across 9 teams to support, we couldn’t afford to be rigid. We ran *multiple* roadmap formats depending on the product line. Some used Now/Next/Later with effort tags like “Weeks”, “Months”, “Quarters”. Others had outcome-oriented roadmaps tied to business goals. One engineer had no roadmap at all—just a North Star objective and full autonomy. It worked because we matched format to function.\n\nAnd when we shared updates with the wider business? We reported on what had been delivered, what was in flight, and what might come next. It didn’t overpromise. But it still gave clarity. That’s the balance to aim for.\n\n### The Bigger Picture\n\nThis blog isn’t just a teardown of roadmap types—it’s a call to reframe how we approach them. Stop treating the roadmap as a static plan. Start treating it as an evolving conversation—fed by discovery, prioritisation, delivery, and reflection.\n\nIf you’ve ever struggled to show stakeholders what’s coming *without killing optionality*, or felt forced to commit before you’re ready, or found yourself defending old timelines instead of solving real problems—know that you’re not alone.\n\nThis challenge is one of the core reasons I started building **Produmo**: to give product people a more honest, flexible, discovery-aligned way to work.\n\nBecause roadmaps should help you think. Not just ship."
  }
]