Topic 6 — Prioritization and roadmapping

Goal: Decide what to build first, say no gracefully, and communicate the plan.

Lesson 6.1 — There's never enough time, and that's the job

Maya opens her notebook on a Monday and stares at the list. Fix the slow loading screen. Build the Excel export everyone keeps asking for. The CEO's "AI assistant." A bug in checkout. Twelve more things below those. Every single one is a real, good idea. And there are maybe two of them she can ship this quarter.

That gap, more good ideas than time, never closes. It doesn't mean Lumi is badly run or that Maya is behind. It's just the permanent condition of the job.

This is the part that surprises people coming into product. Choosing what to do, and what not to do, is the heart of being a PM. Having the most ideas wins you nothing. The skill is looking at twenty good things and picking the three that matter most right now.

And those twenty are all good. Maya isn't sorting good ideas from bad ones. If only it were that easy. She's choosing among things that all deserve to exist, knowing that picking three means the other seventeen wait, and some never happen at all. That's the trade-off she has to make her peace with.

The PM who refuses to choose, who tries to keep all twenty alive, doesn't get more done. The team spreads thin, ships nothing well, and burns out. Focus is the whole skill.

Lesson 6.2 — Saying no without making an enemy

Dan from sales catches Maya by the coffee machine. A big customer wants a custom permissions setting, and he wants it this month.

Maya can't build it this month. So she has to say no. And she has to do it without Dan walking away feeling like she blew off a real revenue deal.

Prioritization means saying no a lot. No to customers, to teammates, sometimes to the CEO. The trick is to say no to the request while honoring the problem behind it. What Maya says is something like: "We're not building that exact setting this quarter, because we're heads-down on checkout. But tell me more about what that customer is actually stuck on, so I can keep it on the radar."

That sentence does three things at once. Worth pulling them apart.

• Explain the why. "We're focused on checkout right now" is a no Dan can respect. A no with no reason behind it just feels like a brush-off, and that's what breeds resentment.
• Acknowledge the problem. Dan mostly wants to feel heard, and the customer mostly wants to feel understood. Maya can validate the underlying need even while she declines the specific ask.
• Offer a "later," honestly. "Not now" lands far better than "never," as long as it's true and not a polite dodge.

Every yes is a no to something else. A thoughtful no is really a yes to your priorities.

Maya isn't being difficult by turning Dan down. She's protecting the team's focus so the most important work actually ships. That's a different thing, and over time people come to trust it.

Lesson 6.3 — The fastest tool: value against effort

Back at her desk, Maya needs a way to look at the list that's faster than agonizing over each item for an hour.

The simplest one she reaches for is Value vs. Effort. For each idea she asks two rough questions: how much would this help users or the business (value), and how hard is it to build (effort)? Then she drops each one onto a 2×2 grid.

Four corners fall out of that:

• High value, low effort are the quick wins. Do these first, almost always.
• High value, high effort are big bets. Worth doing, but plan them deliberately.
• Low value, low effort are maybes, fine as fill-ins when there's slack.
• Low value, high effort are money pits. Avoid them.

What makes this worth the five minutes is how fast it exposes two things teams keep getting wrong: the expensive ideas that quietly aren't worth it, and the easy wins sitting in plain sight that nobody bothered to do. It won't make the decision for Maya. It makes her thinking visible, to herself and to anyone who asks why.

Lesson 6.4 — When you need more than a gut grid

The Value vs. Effort grid is quick, but sometimes Maya needs something she can defend with numbers. Sam, her senior engineer, won't move on a vibe. He wants to see the reasoning.

That's when she reaches for RICE. It scores each idea on four things:

• Reach — how many people it affects.
• Impact — how much it helps each one.
• Confidence — how sure she is about those estimates.
• Effort — how costly it is to build.

The score is (Reach × Impact × Confidence) ÷ Effort. Higher score, better bet.

The clever piece is Confidence. Reach, Impact, and Effort are all guesses dressed up as numbers. Confidence is the factor that forces Maya to admit how much she's actually guessing. An idea she's sure about keeps its full score. An idea she's hand-waving gets discounted, hard. It's a built-in check against the optimism that makes every PM's pet project look better than it is.

Then Maya watches a colleague fall into the trap. The point of RICE was never the exact number. The number exists to force an honest, comparable conversation instead of building whatever was loudest in the last meeting. The moment you treat the score as the answer, you've handed your judgment to a spreadsheet.

A PM who blindly follows a RICE score is making the same mistake as one who ignores frameworks entirely. Both have stopped thinking. Frameworks organize judgment. They don't replace it.

Lesson 6.5 — The roadmap is a promise of direction, not dates

Maya has her priorities. Now she has to tell everyone (Sam, Priya, Dan, the CEO) what's coming and roughly when. That's the roadmap.

Her first instinct, the one most new PMs have, is to make a calendar: Excel export on March 14, checkout fix on April 2. It feels responsible. It's a trap. The second a date slips, and dates always slip as the team learns, every change reads as a broken promise.

So good roadmaps do two things differently.

They're organized by time horizon, not exact dates. Maya uses Now / Next / Later buckets instead of pinning each feature to a calendar day. That sets direction without making promises she can't keep. It leaves room for the loop from Topic 3 — plans change as you learn, and the roadmap is allowed to change with them.

And they're framed around problems and outcomes rather than a feature checklist. "Reduce sign-up drop-off" tells the whole team the goal and leaves room for whoever finds the best solution. "Build feature X" locks in one answer before anyone's sure it's the right one.

A roadmap is a statement of intent, not a contract.

Its job is to align everyone on direction while staying honest that priorities shift. Treat it as a binding list of dates and every normal adjustment feels like a betrayal. Frame it as intent with horizons and the team can adapt without anyone losing trust.

Worked example — Five ideas, one quarter

Maya's actual Monday list comes down to five requests:

1. A tiny tweak that fixes a top complaint for thousands of users.
2. A flashy AI assistant the CEO loves, that no user has asked for.
3. A niche permissions setting one big customer wants (Dan's request).
4. A redesign the engineers are itching to do.
5. A checkout bug quietly losing sales.

She runs a quick Value vs. Effort pass. The checkout fix and the tiny tweak are both high value, low effort — clean quick wins. Those go in Now.

The AI assistant is high effort, low confidence. Nobody's validated that users want it. Rather than commit a quarter to a guess, Maya parks it behind a small discovery spike to test the idea first. It lands in Next, pending validation.

The niche setting is low reach, just one customer, so it waits. The redesign is a genuine big bet, valuable but expensive, so it goes to Later where it can be planned properly.

Her Now / Next / Later roadmap communicates all of this, framed around outcomes like "reduce checkout drop-off" rather than a raw feature list. And she sits down with the CEO to explain why the AI idea is "Next, pending validation," not a no — honoring the request while protecting the team's focus.

One list, one grid, one roadmap, one hard conversation handled well. That's prioritization and roadmapping doing their job together.