Product Strategy, Roadmaps & Prioritization: Choosing What Not to Build

Every product team has more good ideas than it has months. The sales team wants a feature a big customer asked for. Engineering wants to fix the foundations. The designer has found a problem in onboarding. The founder read about something a competitor shipped. All of them are right that their thing matters, and all of them cannot go first.

Strategy is the reasoning that decides. A roadmap is how you show the decision without pretending you know more than you do. Prioritisation methods are the arithmetic people use to argue about the order. This piece takes each in turn, shows where the arithmetic is useful and where it is theatre, and ends with a one-page roadmap you can fill in.

This piece describes how practitioners reason; the products, scores and costs in the interactives are invented and labelled as such. It is not business advice.

Vision, strategy, roadmap: three different questions

People use these words loosely, so it helps to separate them by the question each one answers. A vision answers "what future are we trying to create?" It is long-range and deliberately general. A strategy answers "how will we get there, given what we have and what we face?" It involves choosing, so it excludes things. A roadmap answers "what are we working on, and what comes after?" It is the most changeable of the three, because it is built on what you know today.

The strategist Richard Rumelt, in Good Strategy/Bad Strategy (2011), gives the clearest test for the middle one. He says a good strategy has a kernel of three parts. The diagnosis names the challenge: what is going on, and which feature of it matters most. The guiding policy is the overall approach for dealing with it, which works by ruling things out. The coherent actions are the steps that fit together to carry out the policy. Bad strategy, he argues, skips the diagnosis and offers goals, slogans or a list of priorities as if they were a plan. "Be number one" is a wish. Rumelt's later book, The Crux (2022), is about finding the one challenge that is both important and solvable.

Without JavaScript: "Customers abandon account opening because it takes fourteen steps and a branch visit" is a diagnosis; "Win small businesses by making the first week painless, and decline what does not serve that" is a guiding policy; "Cut account opening to three steps" is an action; "Be the number one bank for everyone" is a wish, not a strategy.

North-star metrics, and the trap

Many teams pick one number that stands for the value they deliver to customers, often called a north-star metric, and say the whole product should move it. The idea became popular in product and growth circles in the 2010s. A good one measures customers getting value, not the company's takings: for a music service it might be minutes of music enjoyed, not subscriptions sold; for a marketplace, completed transactions that both sides rated well.

The trap is an old one. The economist Charles Goodhart made an observation about monetary policy in 1975 that the anthropologist Marilyn Strathern later phrased as "when a measure becomes a target, it ceases to be a good measure". A team told to maximise time in the app can find that notifications and friction raise it while customers get less value. Pairing the headline number with guardrails (complaints, refunds, retention after a month) and with a short list of input metrics the team can actually change keeps it honest. Metrics get a full piece in Product Metrics & Experimentation (36/98).

Roadmaps: outcomes or dates?

A traditional roadmap is a list of features with dates. Its problem is what readers do with it. Marty Cagan's article "Product Roadmaps" (SVPG, 2009) argues that roadmaps built from lists of feature requests are a mistake: a good roadmap is a high-level view of the objectives that move the product toward its strategy, it "is not intended to be a spec", and target dates are only hopes until discovery and scheduling have confirmed them. When a date-and-feature roadmap reaches a customer or a sales team, it becomes a promise, and the team spends its energy keeping the promise rather than checking whether the feature is still worth building.

The alternative many teams use is the Now-Next-Later roadmap, which Janna Bastow and a colleague at ProdPad sketched around 2012. Now is what the team is working on, defined and in progress. Next is what starts when Now finishes, less detailed and dependent on what is learned. Later holds bigger, vaguer problems kept in view. There are no dates because confidence falls as you look further out, which is the honest thing to show. Each item is written as a problem or outcome ("new customers find the right plan") rather than a solution ("add a quiz").

Dates are sometimes real, and pretending otherwise would be a different mistake. A law with an enforcement date sets one: the EU's General Data Protection Regulation applied from 25 May 2018, and products touching EU residents' data had to be ready by then. A hardware product that must reach shelves for a seasonal sales window, a conference demo or a contract milestone does too. The skill is to separate fixed dates (state them, and work backwards) from target dates (a hope, labelled as one), and to say in the roadmap which is which.

Other formats suit other settings. Basecamp's Shape Up (Ryan Singer, 2019) replaces estimates with an appetite, the amount of time a problem is worth, in six-week cycles, with work presented in written pitches and chosen at a "betting table". The design choice is the same: fix the time, vary the scope, and do not commit far ahead.

Scoring ideas: RICE and ICE

Once there are many candidates, teams reach for a formula. RICE, associated with Sean McBride's work on Intercom's product team around 2016, multiplies Reach (how many people in a period), Impact (how much it moves the goal for each of them), and Confidence (how sure you are of the other numbers), then divides by Effort (person-months). A common version scores impact on a small scale from 0.25 (minimal) to 3 (massive) and confidence as a percentage. ICE, popular in growth teams and associated with Sean Ellis, scores Impact, Confidence and Ease from 1 to 10 and multiplies or averages them (versions differ).

These formulas help in two ways: they make hidden assumptions visible, and they force a common comparison. They fail in four. The numbers are guesses, and multiplying four guesses multiplies the errors. Teams can inflate reach or confidence for a favourite idea. A precise-looking score gives false confidence. And the formula ignores timing and dependencies. The honest use is to treat the output as a conversation starter and to ask how fragile is this ranking? Try changing one number.

Without JavaScript: with the starting numbers, Dark mode scores 2,000 and Plan quiz 1,600 in RICE; halve the leader's confidence from 100% to 50% and the Plan quiz moves to first place.

Cost of delay: why the order changes the total

RICE ignores time. Cost of delay asks what it costs, per week, to ship a thing later. A compliance fix with a legal deadline might cost 30 thousand a week once the deadline passes; a nice-to-have report might cost almost nothing. Don Reinertsen, in The Principles of Product Development Flow (2009), argues that most teams do not know this number and that estimates by intuition can vary enormously, so even a rough number changes decisions.

When one team does jobs one after another, the order matters, because every job waits for those before it. A rule from scheduling theory (Wayne Smith, 1956) says the order that minimises total weighted waiting is to do the job with the highest cost of delay divided by duration first. Reinertsen calls the quotient CD3; the Scaled Agile Framework uses a related ratio called WSJF (weighted shortest job first), where it builds cost of delay from user-business value, time criticality and risk reduction or opportunity enablement. The rule assumes you can estimate both numbers and that jobs are independent and can be done in any order; real work has dependencies. But the lesson survives: short jobs with high urgency go first, and a big job with a modest cost of delay can wait.

Without JavaScript: for the four starting jobs, doing them in the order listed costs 705 thousand in total delay; sorting by cost of delay divided by duration (Compliance fix, Reporting add-on, Mobile rewrite, Checkout redesign) costs 465 thousand. Same work, same team.

What customers value: Kano, opportunity scoring and MoSCoW

Scores of reach and impact ask what the team thinks. Other methods ask customers. The Kano model, from Noriaki Kano and colleagues (1984, "Attractive quality and must-be quality", Journal of the Japanese Society for Quality Control), classes a feature by how its presence and absence affect satisfaction. A must-be feature is expected: its absence angers, its presence goes unnoticed (a phone that makes calls). A one-dimensional feature is better the more of it there is (battery life). An attractive feature delights when present and is not missed when absent. An indifferent one does not matter, and a reverse one is disliked by those who get it. A survey asks each person two questions: how would you feel if the product had this (functional), and if it did not (dysfunctional). The pair of answers is looked up in a table. Delights tend to become expectations over time, so the map changes.

Without JavaScript: answering "like it" when present and "dislike it" when absent gives one-dimensional; "like it" and "neutral" gives attractive; "expect it" and "dislike it" gives must-be; neutral on both gives indifferent.

Anthony Ulwick's opportunity scoring (from his outcome-driven innovation) surveys customers on how important each outcome is and how satisfied they are with current options, and ranks by importance + max(importance − satisfaction, 0). The big opportunities are important and poorly served. MoSCoW (Dai Clegg, 1994, later used in the DSDM framework) sorts requirements into Must, Should, Could and Won't (this time). Its value is the last word: writing down what is out. Each method answers a different question, and none of them replaces judgement.

Saying no, specs and stakeholders

Strategy shows up in what a team declines. Saying no works better when it is specific and gives a reason tied to the guiding policy: "this request does not serve the outcome we are pursuing this quarter; here is what is ahead of it and why." Offering the trade-off ("we could do it by moving this later") treats the requester as a partner. A big customer's request is data about a need, not an order: ask what job they are trying to get done, and whether other customers share it.

How much to write down is a related choice. A traditional product requirements document (PRD) describes the problem, users, requirements and success measures at length. Lighter forms exist: a one-page brief; Amazon's practice of writing a mock press release and FAQ before building, described by Colin Bryar and Bill Carr in Working Backwards (2021); or Shape Up's pitch. What they share is a clear problem statement and a stated way to tell whether it worked. The length matters less than the clarity.

Working with sales, executives and engineering is mostly about shared context. Show the strategy and the evidence, not just the outcome; explain how items get ranked; and invite people to challenge the numbers. A transparent method that gets an argument about the inputs is better than an opaque one that gets an argument about the result. And when strategy changes, change the roadmap visibly, saying what you learned.

A roadmap template

Use this to write a Now-Next-Later roadmap for something you are working on. Put problems or outcomes, not features, in each column, and write down what you are not doing.

Without JavaScript, copy the headings by hand: product and outcome, Now, Next, Later, Not doing, Fixed dates and target dates.

What a graduate just sees

• A strategy names a challenge, chooses an approach that excludes things, and lines up actions; a list of goals is not a strategy.
• A roadmap built on dates and features turns into a promise; one built on problems and confidence stays honest.
• Some dates are real (laws, contracts, seasons), and they should be labelled apart from hopes.
• A headline metric becomes a bad target once people are paid to push it, so pair it with guardrails.
• Scoring formulas multiply guesses; change one number and see whether the ranking survives.
• Order matters when one team does jobs in turn: high cost of delay and short duration go first.
• Features have kinds (must-be, one-dimensional, attractive), and delights become expectations.
• "Not now" and "not doing" are decisions to be written down and explained.

Where it shows up next

• Launching & Growing Products (36/99): a launch is a roadmap item with a real date, and the strategy decides who the first customers are.
• Product Discovery & Customer Research (36/96): confidence scores should come from interviews and tests, not mood.
• Product Metrics & Experimentation (36/98): north-star and guardrail metrics, and experiments that settle debates your formula cannot.
• Strategy & Competition (34/54) and Operations Management (34/52): where product choices meet competitors and capacity.
• In the world: a ride-hailing company deciding which city to enter next, a bank adding a payment rail by a regulator's deadline, a hardware maker working back from a launch date.

If you want to go deeper

• 📘 Textbooks. Richard Rumelt, Good Strategy/Bad Strategy (Crown Business, 2011), on the kernel; and Marty Cagan, Inspired: How to Create Tech Products Customers Love (Wiley, 2nd edition, 2017), on product vision, strategy and discovery.
• 📘 Gentler. Melissa Perri, Escaping the Build Trap (O'Reilly, 2018), on outcomes over output; and Don Reinertsen, The Principles of Product Development Flow (Celeritas, 2009), for cost of delay.
• 🌐 Free resources. Shape Up (Basecamp's free online book); Marty Cagan, Product Roadmaps; ProdPad on the Now-Next-Later roadmap; and the Kano model (Wikipedia overview with the original citation).