Sep 14, 2026 · 6 min read
Impact matrix, roadmap, or kanban? Pick the view that fits the decision
Every prioritization view answers one kind of question well and others badly. Here’s how to match the view to the decision in front of you.
One view can’t answer every question
Most product teams have a favorite view. Some live in the backlog, some in the roadmap, some in a spreadsheet of scores. The trouble starts when that one view gets used for every decision.
A kanban board is great at showing what’s stuck. It isn’t built to tell you what’s worth doing. A timeline roadmap is great for coordinating teams. It can quietly turn into a list of promises nobody meant to make. A scoring spreadsheet gives you a ranked list, but the ranking is only as good as the guesses behind it.
So before you pick a framework, name the question. Are you deciding what matters, what ships next, or how to keep work moving? Each question has a view that fits it.
Impact/effort matrix: fast, rough triage
The impact/effort matrix, which ProductPlan calls a value vs. complexity matrix, plots each idea on two axes. The four quadrants give you a quick sort: high value and low effort goes first, high value and high effort needs planning, low value and low effort fills gaps, and low value and high effort gets cut.
Good for:
• Sorting a long list of ideas in a single workshop
• Surfacing disagreement, since two people placing the same card in different quadrants tells you something
• Killing expensive work that doesn’t earn its keep
Bad for:
• Mature products. ProductPlan notes that established teams have usually already built the easy, high-value items, so that quadrant tends to be empty.
• Fine-grained ranking. Two ideas in the same quadrant look identical.
• Anything where “value” is contested. The matrix doesn’t tell you how you estimated it.
RICE and ICE: scoring when you need a ranked list
Scoring frameworks turn judgment into a number so you can compare ideas consistently.
RICE was introduced by Sean McBride at Intercom. It multiplies Reach (people affected in a time period), Impact (on a scale from 0.25 to 3), and Confidence (a percentage), then divides by Effort in person-months. The Confidence factor matters: it’s an explicit penalty for ideas you’re excited about but can’t back up. McBride admits the impact scale may feel unscientific, but argues the alternative is “a tangled mess of gut feeling.” He also says RICE scores shouldn’t be treated as a hard rule, since dependencies and strategy can justify doing a lower-scoring project first.
ICE is associated with Sean Ellis, who coined “growth hacking.” It rates Impact, Confidence, and Ease, each from 1 to 10, and multiplies them (ProductPlan; Lenny’s Newsletter). It’s lighter than RICE and popular for ranking experiments quickly.
Good for:
• Comparing many similar-sized ideas against the same goal
• Making assumptions visible, because every score has to be justified
• Picking a winner from a short list, which ProductPlan calls ICE’s best use
Bad for:
• Consistency across scorers. ProductPlan points out that an item’s ICE score can vary a lot depending on who’s scoring.
• Big bets. Because low Ease drags the whole score down, ICE can nudge teams toward quick wins.
• False precision. A score of 412 versus 398 isn’t a real difference if the inputs were guesses.
Timeline roadmaps vs. Now/Next/Later
A timeline roadmap places work on a calendar: this feature in Q2, that one in Q3. It’s the view most stakeholders expect, and it’s genuinely useful when dates are real, like a contract, a launch event, or a dependency between teams.
The risk is that dates harden into commitments before the team knows whether the idea will work. Marty Cagan at SVPG has argued that at least half of product ideas won’t work, and that even good ideas typically take several iterations to deliver the expected value. A roadmap full of dated features leaves no room for either reality. In The Alternative to Roadmaps, Cagan suggests giving teams business objectives and problems to solve, reserving date-based commitments for the cases that truly need them.
The Now/Next/Later roadmap, which Janna Bastow first sketched in 2012, drops the calendar. Now holds well-defined work in progress. Next holds work that’s less specified. Later holds problems you can see on the horizon but haven’t solved. Detail and confidence increase as items move toward Now.
Good for:
• Timeline: coordinating teams around real, fixed dates
• Now/Next/Later: communicating direction without promising dates, and replanning as you learn
Bad for:
• Timeline: early-stage bets, where the date becomes the goal instead of the outcome
• Now/Next/Later: stakeholders who genuinely need a date. Sometimes you still have to give one.
Kanban: keeping delivery moving
Kanban is a flow tool, not a prioritization tool. According to Kanban University’s guide, the method rests on visualizing work, limiting work in progress (WIP), and managing flow so work finishes smoothly and predictably. The guide stresses flow of work over keeping everyone busy, and treats finishing work as more valuable than starting new work.
WIP limits are the part teams skip most often. Without them, a board shows a lot of activity and hides the bottleneck.
Good for:
• Seeing where work is stuck and why
• Keeping a steady pace without overloading people
• Daily and weekly delivery conversations
Bad for:
• Deciding what’s worth building. The order of a backlog column isn’t a strategy.
• Showing why an item exists, which customer problem it solves, or which goal it serves
Prioritizing from the backlog is one of the most common traps. Whatever sits at the top gets built, and it sits at the top because someone put it there months ago.
Discovery maps: understanding how things connect
Some decisions aren’t about ranking or scheduling. They’re about understanding which problem to solve at all. That calls for a relationship view.
Teresa Torres’s opportunity solution tree is the best-known example. It starts with a desired outcome at the root, branches into opportunities (customer needs, pain points, and desires), then into possible solutions, then into assumption tests. It keeps the team’s reasoning visible and connects every solution back to the outcome it’s meant to move.
Good for:
• Choosing between problems before choosing between features
• Keeping discovery aligned with a business outcome
• Explaining to stakeholders why you’re not building the thing they asked for
Bad for:
• Tracking delivery or dates
• Quick decisions on a long list of small requests
Which view for which question
• “Which of these 40 ideas deserve a closer look?” → Impact/effort matrix
• “In what order should we tackle these comparable ideas?” → RICE or ICE
• “What are we committing to by a fixed date?” → Timeline roadmap
• “Where are we headed, and what’s coming up?” → Now/Next/Later roadmap
• “What’s blocked, and are we taking on too much?” → Kanban with WIP limits
• “Which customer problem should we solve to hit this outcome?” → Opportunity solution tree
Many real decisions touch more than one. You might use a discovery map to pick the problem, a matrix to shortlist solutions, a roadmap to sequence them, and a board to ship them.
The shared weakness: evidence
Every one of these views depends on estimates. Impact, reach, confidence, value, the size of an opportunity. The framework does the arithmetic. It can’t tell you whether the inputs were true.
That’s why RICE builds in a Confidence factor, and why opportunity solution trees end in assumption tests. When “high impact” means “a customer mentioned this on a call last quarter,” the score looks more certain than it is. Before debating the view, ask: where did this number come from, and can we point to the source?
Where Fijord fits
We’re building Fijord around this idea. Instead of choosing one view and bending every decision to fit it, Fijord offers four views over the same underlying context: Canvas for discovering what matters and tracing decisions back to evidence, an Impact Matrix for comparing opportunities by effort and customer impact, a Roadmap for planning across weeks, months, and quarters, and Kanban for keeping delivery moving.
That context comes from tools teams already use, like meeting notes and call recordings, Slack, Linear, Jira, Notion, GitHub, and Mixpanel. Fijord works alongside Jira and Linear rather than replacing them. The goal is that an impact estimate on the matrix and a card on the board both trace back to the same evidence.
Fijord is in early access. Whatever tools you use, the lesson holds: pick the view that fits the decision, and make sure the evidence behind it is real.