Week 07 · Days 31–35
Roadmapping & Prioritization
Practice prioritization frameworks and stakeholder communication.
Portfolio deliverable · A quarterly roadmap with prioritization rationale
Prioritization frameworks
Lesson: RICE, MoSCoW, and tradeoffs
RICE is great for ranking internally — it gives you a defensible number. But in a room with stakeholders, raw scores can feel arbitrary or spark debate over decimals. MoSCoW (Must have, Should have, Could have, Won't have this time) is a complementary framework for that conversation: it buckets items by necessity rather than precise score, which is easier for non-PMs to engage with. A common pattern: use RICE to do your own ranking, then translate the top items into 'Must/Should' and the bottom into 'Could/Won't' when presenting to stakeholders — translating data into a shared vocabulary is itself a PM skill.
Task: Brainstorm a feature backlog
Brainstorm 8-10 feature ideas for your practice app (mix of small fixes and big bets) based on everything you've learned so far.
Scoring your backlog
Task: RICE-score your backlog
Score each of your 8-10 features using RICE. Build a simple spreadsheet and sort by score.
Building a roadmap
Lesson: Now/Next/Later roadmaps
Date-based roadmaps ('Feature X ships March 15') create a trap: dates get treated as commitments, and missing them erodes trust even when the delay was reasonable (e.g. you learned something in user testing that changed scope). Now/Next/Later roadmaps communicate relative priority without false precision: Now = actively being built/refined, Next = scoped and queued, Later = directionally important but not yet detailed. This format also makes it easier to reshuffle when priorities change — moving something from Next to Later isn't 'breaking a promise,' it's normal roadmap hygiene. Date-based roadmaps can still work for hard external deadlines (e.g. a contractual integration) — but those should be the exception, not the default.
Task: Build a Now/Next/Later roadmap
Organize your RICE-scored backlog into a Now/Next/Later roadmap for the next quarter.
Communicating tradeoffs to stakeholders
Lesson: Saying no without saying no
Stakeholders rarely need a flat 'no' — they need to feel heard and understand the tradeoff. The reframe: 'not now' instead of 'no,' paired with the reasoning. Structure: (1) acknowledge the request and why it matters to them, (2) explain what it would displace (be specific — 'this would push back the onboarding redesign by 3 weeks'), (3) state where it sits on the roadmap and what would change its priority (e.g. 'if we see churn data showing this is the top driver, we'd revisit'). This shows you've actually considered it — most pushback comes from people feeling dismissed, not from disagreement with the logic itself.
Task: Write a roadmap announcement
Write a short stakeholder-facing message announcing your roadmap, including 1-2 sentences on why something was NOT prioritized.
Synthesize: Final roadmap doc
Deliverable: Quarterly Roadmap
Compile your RICE scoring, Now/Next/Later roadmap, and stakeholder announcement into one polished roadmap doc.
Advanced Challenge: Add an 'AI capability' lane to your roadmap
Add a parallel lane to your Now/Next/Later roadmap specifically for AI capabilities — e.g. Now: ship a basic AI assistant with a narrow scope and strong fallbacks; Next: expand scope based on eval data from Now, add personalization; Later: proactive AI suggestions (the assistant reaches out, vs. only responding). Write 2-3 sentences on why AI roadmaps often need a 'crawl-walk-run' structure more explicitly than traditional features — narrow scope first lets you build trust and gather real usage data before expanding capability, since AI failure modes are often only visible at scale.