Your Product Roadmap Should Be Problems, Not Features

Open most product roadmaps and you'll find a tidy column of features marching toward quarterly dates: SSO in Q2, a redesigned dashboard in Q3, "AI summaries" penciled in for Q4. It looks like a plan. It reads like a promise. And it is almost always the wrong artifact. A feature-list product roadmap commits a team to a solution before anyone has agreed on the problem — and it quietly converts every engineer, designer, and stakeholder into an order-taker. The fix is not a better-looking roadmap. It's a different one: a list of problems to solve, not features to ship.

I've shipped both kinds. The feature roadmap feels safer in the room and costs you everywhere else. Here's the case for flipping it, how to build the alternative, and how to defend it to the people who showed up wanting dates.

Why a feature-based product roadmap quietly fails

A roadmap of features encodes two assumptions that rarely hold. The first is that you already know the right solution. The second is that you can predict when it will deliver value. Marty Cagan is blunt about why this breaks: a typical roadmap is "a prioritized list of features or projects that someone believes will actually solve some problem (even if that problem is often not explicitly stated or understood)" — and most of those bets simply don't work out the way the list implies (SVPG, "The Alternative to Roadmaps").

That's the trap. When the unit of planning is the feature, the team's job becomes shipping the feature — not moving the metric the feature was supposed to move. Melissa Perri named this exactly: organizations fall into the "build trap" when they "live and die by outputs," "cranking out features to meet their schedule rather than the customer's needs" (melissaperri.com). The roadmap becomes a production schedule for outputs, and nobody notices that none of it was the point.

There's a more human cost, too. Hand a team a feature and a date and you've answered the most interesting question for them — what should we build? — before they've touched the problem. You get compliance, not invention. The best ideas your engineers and designers have never make it onto the board, because the board was already full.

A problem-based roadmap: now, next, later

The alternative has a well-worn shape. Janna Bastow sketched it in 2012 while building ProdPad, after a month of timeline roadmaps taught her that customers kept demanding she move things she hadn't delivered. Her replacement organized work into three horizons — Now, Next, and Later — borrowed from the cone of uncertainty: the further out you look, the less certain anything is, so stop pretending otherwise. "I invented the Now-Next-Later roadmap," she writes, "because I believe that, rather than focusing on deadline-based delivery, product teams should stay focused on discovery" (ProdPad).

Notice what fills the columns. Not features — problems and the outcomes you're chasing. Now: checkout abandonment is bleeding revenue. Next: new users hit value too slowly to stick. Later: enterprise buyers can't prove ROI. Each is a problem with a metric attached, not a solution with a ship date.

Roman Pichler's goal-oriented (GO) roadmap makes the discipline concrete. Its goals "describe outcomes or benefits such as user acquisition, activation, and retention, which form the backbone of the plan" (romanpichler.com). Features still exist on a GO roadmap — but as second-class citizens, illustrative examples of how you might hit a goal, never the goal itself.

How to build one

You don't need a tool or a workshop. You need to change the column headers.

Start from the strategy, not the backlog. Each item on the roadmap should ladder up to a business objective. If you can't say which outcome a problem serves, it doesn't belong on the page yet.

Write problems, then attach a measure of success. "Reduce time-to-first-value for new accounts from 9 days to under 3" is a roadmap item. "Onboarding wizard" is not. Cagan's own transition advice is refreshingly low-drama: take your existing feature roadmap and, for each item, ask what the underlying problem is and how you'd measure success. That single rewrite moves you most of the way (SVPG).

Use horizons, not dates. Now is committed and roughly scoped. Next is intended and loosely shaped. Later is a direction, deliberately fuzzy. The honesty is the feature, not a bug — it stops you minting promises you'll be forced to break.

Leave room for solutions to change. The whole point is that the team gets to discover the best answer to the problem. If you've pre-decided the feature, you've kept the build trap and just relabeled it. Worth remembering that even great features go unused when they don't trace back to a real problem — something I've written about in why most of what you ship goes unused.

Selling it to people who want dates and features

This is where most problem-based roadmaps die — not in design, but in the stakeholder meeting. An executive wants to know what's launching and when. Telling them "we're focused on outcomes now" sounds like you're dodging.

Don't dodge. Translate. A few moves that work:

Lead with the outcome they care about. "We're going to cut checkout abandonment by 20% this quarter" lands harder than any feature name, and it's a commitment — just to the result, not the recipe.
Keep dates where dates are real. Now-next-later doesn't ban deadlines; it confines them to the Now column, where you actually have enough certainty to honor one. Contractual and regulatory commitments still get hard dates. Everything speculative stops pretending.
Show features as evidence, not promises. Under each problem, list the candidate solutions you're exploring. Stakeholders see the concreteness they wanted, and you keep the freedom to swap an approach that isn't working.
Make discovery visible. Report on what you learned and which metric moved, not just what shipped. That's also how the maturing PM role increasingly earns trust — a shift I've described in how the PM role is splitting.

The reframe you're selling is simple: a feature roadmap promises activity; a problem roadmap promises results. Once a stakeholder feels that difference, most stop asking for the feature list. They were never in love with the features. They wanted to believe the work would matter.

The takeaway

A roadmap is a communication tool, and what it communicates is what you value. List features, and you've told the team their job is to ship — whether or not it works. List problems with outcomes attached, and you've told them their job is to win, and handed them the freedom to figure out how. Keep dates where they're honest, show features as evidence of thinking rather than as promises, and report on the needle you moved. Your next product roadmap doesn't need to be prettier. It needs to be a list of problems worth solving.