Prioritization
You've got a backlog of two hundred items, a stakeholder who wants their pet feature yesterday, and a team that can realistically ship three things this quarter. Everyone has an opinion, and the loudest one usually wins. Prioritization is how you replace that volume contest with a decision you can defend - and roadmapping is how you show the plan without promising dates you'll have to break.
Learn on the move: press play and turn your commute, walk or drive into time that grows your design career.
Listen to the full Prioritization course on DesignPath
For a designer, this is where "I think we should build X" turns into "here's why X beats Y, scored the same way." That's the difference between having taste and being trusted with the roadmap.
What This Topic Covers
Two halves. First, prioritization: deciding what to build next, using frameworks that turn gut feel into something comparable - and learning to say no. Then roadmapping: turning those decisions into a plan you can communicate, in a shape that survives contact with a changing world.
Value vs Effort
When a backlog feels overwhelming, the quickest way to get a grip on it is also the simplest: for each item, ask two questions - how much value does it deliver, and how much effort does it cost? Plot those on a 2x2 and the pile sorts itself into a picture you can act on in ten minutes.
The Value/Effort Matrix
Draw two axes: value up the side, effort across the bottom. Every item lands in one of four quadrants:
High value, low effort - quick wins.Do these first. They build momentum and buy goodwill.
High value, high effort - big bets.Worth doing, but plan them deliberately; they're where your quarter goes.
Low value, low effort - fill-ins.Fine to slot in around the big work, but don't mistake busywork for progress.
Low value, high effort - time sinks.Avoid. This quadrant is where roadmaps go to die.
The magic isn't the chart; it's that plotting things next to each other forces a comparison you were avoiding.
Estimating Value
Value is how much an item moves something you care about - an outcome, a metric, a real user pain. Anchor it to your goals, not to how interesting the feature is to build. "Reduces the drop-off we measured at checkout" is value; "uses a cool new animation" usually isn't.
Estimating Effort
Effort is the cost to deliver - design, engineering, testing, risk. Get an engineer to weigh in; designers routinely underestimate the back-end work behind a simple-looking screen. A rough t-shirt size (S/M/L) is enough at this stage.
Pro tip: Do the plotting as a team, out loud. Half the value is the argument - when a designer and an engineer disagree on where something sits, you have just found a hidden assumption worth resolving.
Know Its Limits
Value versus effort is fast, which is its strength and its weakness. Both axes are guesses, and "value" quietly hides several different things - how many people it helps, how much, how sure you are. It's a great first pass to clear the obvious wins and time sinks. When you need to compare the harder middle cases, you reach for something with more rigour - which is exactly what RICE adds.
Where AI Helps
Prompt: "Here's my backlog: [paste]. For each item, estimate value (impact on [my goal]) and effort (S/M/L) and place it in a value/effort matrix. Flag the clear quick wins and time sinks, and note where you're most uncertain."
AI does the first sort; you correct it.It can place items and spot the obvious quadrants quickly, but it's guessing at effort without knowing your codebase and at value without knowing your users. Treat its matrix as a draft to argue with, not a verdict.
