Ask most product teams for their roadmap and you'll get a spreadsheet with quarters across the top and features down the side. It looks like planning. It behaves like a calendar with extra steps. The dates give everyone a comforting sense that the work is under control, right up until the quarter ends and half the boxes are still empty — not because the team was lazy, but because the roadmap was never actually testing anything. It was just a queue.
The distinction that matters is the one Marty Cagan draws in 'Inspired' between feature teams and product teams. A feature team takes requirements and ships them. A product team takes problems and is accountable for whether they're actually solved. A roadmap built by a feature team is a list of outputs. A roadmap built by a product team is a list of bets, each one attached to a number that's supposed to move.
At LogicLemons, when we sit down with a client to plan a quarter, we try to treat each roadmap line as a hypothesis rather than a commitment. Not 'build the referral feature' but 'we believe adding a referral flow will lift signups by some meaningful amount, and here's how we'll know if we're wrong.' It's a small wording change with a large consequence: it becomes possible to be wrong in public, which is the only way a team ever gets calibrated.
Teresa Torres' 'Continuous Discovery Habits' gives a concrete technique for this — the opportunity solution tree, which forces you to trace every proposed feature back to a specific customer opportunity and a specific outcome, instead of letting ideas drop straight onto the roadmap because someone senior liked them in a meeting. It's a simple diagram. Most teams skip it because it's uncomfortable to draw a line from 'the CEO wants this' to nowhere.
The practical fix is smaller than it sounds: put a metric on every roadmap line before it gets a date. If nobody can say what number is supposed to move, and by how much, it isn't ready to be on the roadmap yet — it's an idea, and ideas belong in a backlog, not a plan.
A roadmap that can't be wrong isn't a strategy. It's a to-do list with a due date, and due dates are the easiest part of product work to get right while getting everything else wrong.