Generating and Prioritizing Deliverables from Impacts for Your Product Manager Roadmap
This skill teaches you how to brainstorm candidate features, content, and activities for each impact on your impact map, then prioritize them based on their assumed contribution to measurable business goals—turning strategic intent into an actionable product manager roadmap.
To generate deliverables from impacts, brainstorm candidate features, content, and activities for each mapped behavior impact. Then prioritize them by scoring each deliverable's assumed contribution to your business goal relative to its cost and risk. This transforms your impact map's third level into a focused, goal-driven product manager roadmap where every item traces back to a measurable outcome.
Outcome: You can systematically generate a comprehensive set of deliverable options for each impact and rank them so your team works on the highest-value items first, building a product manager roadmap grounded in strategic outcomes.
Prerequisites
- Understanding of Impact Mapping structure (goals, actors, impacts, deliverables)
- A completed impact map with defined business goals, actors, and desired behavior impacts
- Basic knowledge of prioritization frameworks (e.g., RICE, MoSCoW, or cost-of-delay)
Overview
The deliverables layer is where an impact map transitions from strategy to execution. After you've defined your business goal, identified actors, and mapped desired behavior changes through Impact Mapping, the next step is to brainstorm what you could build or do to create each impact—and then decide which of those options deserves a place on your product manager roadmap.
This skill is critical because it prevents the common trap of jumping straight to a feature list without strategic justification. Every deliverable you generate is explicitly linked to a behavior change you want to cause in a specific actor, which in turn serves a measurable goal. This traceability is what makes Impact Mapping so powerful for product managers who need to defend prioritization decisions to stakeholders.
Generating deliverables is a divergent-thinking exercise—you want volume and creativity. Prioritizing them is a convergent-thinking exercise—you want discipline and evidence. Mastering both halves of this skill ensures your product manager roadmap is both imaginative and ruthlessly focused on outcomes.
How It Works
Deliverable generation works by treating each impact (desired behavior change) as a design brief. For every impact on your map, you ask: What could we build, create, change, or do that would cause this behavior change in this actor? Deliverables aren't limited to software features—they can include content, policies, services, partnerships, experiments, or even things you choose not to build.
The key conceptual shift is that deliverables are hypotheses, not commitments. Each one represents an assumption: 'If we build X, actor Y will change behavior Z, contributing to goal G.' This framing is essential because it opens the door to lightweight validation before heavy investment, and it keeps the team honest about uncertainty.
Prioritization then applies a lens of expected value. You assess each deliverable's assumed contribution to the goal (impact magnitude), weigh it against effort, risk, and confidence, and rank accordingly. The result is a product manager roadmap where the top items have the strongest strategic rationale—and you can articulate exactly why to any stakeholder who asks.
Step-by-Step
Step 1: Select an Impact Branch to Work On
Choose one impact (behavior change) from your impact map to focus on. If you're working through the full map, start with the impact your team believes has the highest potential contribution to the business goal. Pull up the actor and impact definition so everyone is clear on the context.
For example, if your goal is 'Increase trial-to-paid conversion by 15%' and the impact is 'New trial users complete onboarding within 24 hours,' you'll brainstorm deliverables specifically aimed at making that behavior change happen.
Tip: Work one impact at a time to avoid conflating deliverables across different behavior changes. This keeps traceability clean.
Step 2: Divergent Brainstorming of Candidate Deliverables
Run a structured brainstorming session to generate as many deliverable ideas as possible for the selected impact. Use techniques like silent writing (each participant writes ideas on sticky notes for 5 minutes), followed by round-robin sharing. Encourage wild ideas—features, content pieces, in-app nudges, email sequences, partnerships, manual processes, policy changes, and even removing existing features.
The goal is volume. Aim for at least 8-12 candidate deliverables per impact. Don't evaluate or critique during this phase. Remind participants that deliverables are hypotheses about what could cause the behavior change, not commitments to build.
For the onboarding example, candidates might include: interactive product tour, simplified signup flow, personalized onboarding checklist, welcome email drip sequence, live onboarding webinar, in-app progress bar, reduced feature set for first session, peer community invitation, or a 'quick win' template library.
Tip: Include at least one 'non-software' deliverable per impact. Often the cheapest path to a behavior change is content, a policy, or a human touchpoint—not code.
Step 3: Cluster and De-duplicate Deliverables
Group similar ideas together and merge true duplicates. You'll often find that several brainstormed items are variations of the same concept. Create clusters like 'onboarding guidance' (product tour, checklist, progress bar) and 'communication' (email drip, webinar invitation). Give each cluster a descriptive label.
This step reduces noise without killing creativity. Keep distinct ideas separate even if they're in the same cluster—a product tour and a checklist are different deliverables with different effort profiles and assumptions.
Tip: If two deliverables seem identical, ask 'Would we A/B test these against each other?' If yes, they're distinct.
Step 4: Articulate the Assumption Behind Each Deliverable
For each candidate deliverable, write a one-sentence hypothesis statement: 'We believe that [deliverable] will cause [actor] to [impact/behavior change], contributing to [goal] by [mechanism].' This forces clarity about why you think each deliverable would work.
For example: 'We believe that an interactive product tour will cause new trial users to complete onboarding within 24 hours by reducing confusion about where to start, contributing to our 15% conversion increase.'
This step is crucial because it exposes weak assumptions early. If you can't articulate the mechanism, the deliverable may be a pet feature rather than a strategic choice. Document these assumptions visibly—they become the basis for later validation, which you can explore in Validating Impact Map Assumptions with Experiments.
Tip: Use the format 'We believe [deliverable] will [impact] because [mechanism]' consistently. It becomes a powerful artifact for stakeholder communication.
Step 5: Score Deliverables on Contribution, Confidence, Effort, and Risk
Create a simple scoring matrix. For each deliverable, assess four dimensions:
- Contribution: How much will this deliverable move the needle on the desired impact? (High / Medium / Low)
- Confidence: How sure are we that this deliverable will actually cause the behavior change? (High / Medium / Low)
- Effort: How much time, money, and team capacity is needed? (Small / Medium / Large)
- Risk: What's the downside if it fails or has unintended consequences? (Low / Medium / High)
Use relative scoring rather than precise numbers—the goal is to create a defensible ranking, not false precision. Have the team discuss and converge on scores together. Disagreements are valuable signals about hidden assumptions.
For a product manager roadmap grounded in Impact Mapping, the most important dimension is Contribution × Confidence. A high-contribution, high-confidence, low-effort deliverable is your top priority. A high-contribution, low-confidence deliverable is a candidate for a lightweight experiment first.
Tip: If your team can't agree on a Confidence score, that's a strong signal you need to run a validation experiment before committing to build. See the sibling skill on [validating assumptions](/skills/validating-assumptions-with-experiments).
Step 6: Stack-Rank Deliverables and Identify the First Batch
Using your scores, create a prioritized list for each impact branch. Place deliverables into tiers:
- Tier 1 — Do First: High contribution, high confidence, reasonable effort. These go on your immediate product manager roadmap.
- Tier 2 — Validate Then Do: High contribution, low confidence. Design a cheap experiment to test the assumption before committing.
- Tier 3 — Do Later: Medium contribution, or high effort relative to contribution. These sit in the backlog.
- Tier 4 — Don't Do (Yet): Low contribution or high risk with unclear payoff. Park these explicitly so they don't creep back.
Be disciplined about the 'Don't Do' tier. One of Impact Mapping's greatest strengths is helping teams say no to deliverables that don't connect to goals. Document why items are parked so the decision is transparent.
Tip: Limit Tier 1 to 2-3 deliverables per impact. If everything is Tier 1, you haven't actually prioritized.
Step 7: Map Prioritized Deliverables Back to the Impact Map and Roadmap
Add your Tier 1 and Tier 2 deliverables to the impact map as the fourth level, visually connected to their parent impact. This completes the traceability chain: Goal → Actor → Impact → Deliverable. Then transfer prioritized deliverables to your product manager roadmap or backlog tool, tagging each with its parent impact and goal.
This integration step is where Impact Mapping pays off for ongoing planning. When stakeholders ask 'Why are we building this?' you can trace any roadmap item back through the map. When goals change, you can quickly identify which deliverables are no longer justified. For deeper guidance on this integration, see Integrating Impact Maps with Product Roadmaps.
Tip: Review the full map after adding deliverables. If one impact has 10 deliverables and another has 1, ask whether you've under-explored the second or over-invested in the first.
Examples
Example: SaaS Onboarding Conversion — From Impact to Roadmap
A B2B SaaS company has an impact map with the goal 'Increase trial-to-paid conversion from 8% to 12% in Q3.' One actor is 'New trial user (solo practitioner)' and one mapped impact is 'Experiences a meaningful success within 48 hours of signup.' The product team needs to generate and prioritize deliverables for this impact to populate their product manager roadmap.
The team runs a 12-minute silent brainstorm and generates 11 candidate deliverables: (1) interactive product tour, (2) pre-built template gallery, (3) 'quick win' wizard that creates a shareable output in 5 minutes, (4) personalized onboarding email drip, (5) in-app checklist with progress bar, (6) live webinar for new users, (7) Slack community invitation at signup, (8) simplified first-run UI hiding advanced features, (9) a short video walkthrough in the welcome screen, (10) a human-sent personal email from a CSM after first login, (11) removing the credit card requirement from trial signup.
After clustering and de-duplication, they have 9 distinct deliverables. They write assumption statements for each. For example: 'We believe the quick-win wizard will cause new trial users to experience meaningful success within 48 hours because it removes the blank-canvas problem and produces a tangible output they can share.'
Scoring reveals: the quick-win wizard scores High contribution, Medium confidence, Medium effort. The personal CSM email scores Medium contribution, High confidence, Small effort. The simplified first-run UI scores High contribution, Low confidence, Large effort.
Final tiers: Tier 1 — quick-win wizard and personal CSM email (ship this sprint). Tier 2 — simplified first-run UI (run a prototype test with 20 users first to validate the assumption). Tier 3 — product tour, email drip, checklist. Tier 4 — removing credit card requirement (data shows it doesn't correlate with this impact).
The Tier 1 items go onto the product manager roadmap for the current cycle, tagged with their parent impact and goal for full traceability.
Example: Marketplace Seller Retention — Prioritizing Across Two Impacts
An online marketplace has mapped two impacts for the actor 'Small seller with 10-50 listings': Impact A is 'Lists 5+ new products per month' and Impact B is 'Responds to buyer inquiries within 2 hours.' The team needs to generate deliverables for both impacts and decide which to tackle first on the product manager roadmap.
For Impact A, the team brainstorms: bulk upload tool improvement, AI-generated listing descriptions, listing quality score with tips, seasonal product suggestions email, and a referral bonus for inviting other sellers. For Impact B: push notifications for new inquiries, pre-written response templates, auto-responder for after-hours messages, and a seller response-time badge visible to buyers.
After scoring, the standout for Impact A is the AI-generated listing descriptions (High contribution, Medium confidence, Medium effort) and for Impact B, push notifications (High contribution, High confidence, Small effort). The team decides to ship push notifications immediately (small effort, high confidence) and run a concierge experiment for AI descriptions (have a human write descriptions for 20 sellers and measure listing velocity change). This approach builds the product manager roadmap incrementally, validating the bigger bet before committing engineering resources.
Best Practices
Always brainstorm deliverables per impact, not in a single undifferentiated session. This maintains the strategic link between what you build and the behavior change you're targeting.
Include non-software deliverables in every brainstorm—content, manual processes, policy changes, and partnerships are often cheaper and faster paths to behavior change than code.
Write explicit assumption statements for every deliverable before prioritizing. This turns gut-feel prioritization into evidence-based discussion and creates artifacts for future validation.
Use relative scoring (High/Medium/Low) rather than precise numerical models. False precision wastes time and creates an illusion of objectivity that doesn't exist at this stage.
Re-prioritize deliverables when you learn new information. Impact maps are living documents—update the deliverables layer after every experiment result, customer interview, or market shift.
Timebox brainstorming to 10-15 minutes per impact to maintain energy and prevent groupthink. You can always add ideas later.
Common Mistakes
Jumping straight to favorite features without brainstorming alternatives
Correction
Force a minimum number of ideas (e.g., 8+) per impact before any evaluation. Include at least one 'weird' option and one non-software option. The best deliverable is often the fifth idea, not the first.
Prioritizing by effort alone ('Let's just do the easy stuff first')
Correction
Always lead with contribution to the impact and goal. A low-effort deliverable that doesn't move the needle is waste. Use a multi-dimensional scoring approach that weights contribution and confidence alongside effort.
Treating deliverables as commitments instead of hypotheses
Correction
Frame every deliverable as 'We believe X will cause Y.' This mindset shift opens the door to experimentation and prevents emotional attachment to features. If an experiment disproves the assumption, celebrate the learning and move on.
Generating deliverables in isolation from the people who'll build them
Correction
Include engineers, designers, and subject matter experts in brainstorming. They bring implementation awareness that shapes better ideas and more accurate effort estimates. A deliverable that engineering says takes 2 weeks but product assumed takes 2 days will wreck your roadmap.
Failing to document parked (deprioritized) deliverables and the reasons why
Correction
Maintain a visible 'Not Now' list with rationale. Without it, the same ideas resurface in every planning cycle, wasting time and creating the impression that the team isn't listening to suggestions.
Other Skills in This Method
Integrating Impact Maps with Product Roadmaps
How to translate a completed impact map into a prioritized, outcome-driven product roadmap that communicates strategy to leadership and engineering teams.
Identifying Actors and Stakeholders in Impact Mapping
How to systematically discover and prioritize the users, customers, and internal stakeholders whose behavior changes will drive your business goal.
Defining Measurable Business Goals for Impact Maps
How to formulate clear, measurable business objectives that serve as the root of an impact map and align product work to strategic outcomes.
Validating Impact Map Assumptions with Experiments
How to treat each branch of an impact map as a hypothesis, design lightweight experiments, and use results to iterate on the map.
Facilitating Collaborative Impact Mapping Workshops
How to run a cross-functional impact mapping session, including preparation, facilitation techniques, and achieving alignment among diverse stakeholders.
Mapping Desired Behavior Impacts on Actors
How to articulate the specific behavioral changes you want each actor to make, forming the impact layer that connects goals to deliverables.
Frequently Asked Questions
How many deliverables should I generate per impact on an impact map?
Aim for 8-12 candidate deliverables per impact during brainstorming. You'll typically prioritize 2-3 for immediate action. The larger initial set ensures you've explored creative options beyond the obvious first idea.
How do I prioritize deliverables for a product manager roadmap when data is limited?
Use relative scoring on contribution, confidence, effort, and risk rather than precise metrics. Where confidence is low, design a lightweight experiment to test the assumption before committing to build. Prioritize high-confidence, high-contribution items first and treat low-confidence items as experiments.
What's the difference between deliverables and user stories in impact mapping?
Deliverables in an impact map are strategic options—candidate features, content, or activities hypothesized to cause a behavior change. User stories are implementation-level descriptions of functionality. A single impact map deliverable may break down into multiple user stories during sprint planning.
Can a single deliverable serve multiple impacts on an impact map?
Yes, and these are often high-value items. However, be cautious—multi-impact deliverables can become bloated. Score the deliverable's contribution to each impact separately and ensure it genuinely serves both rather than being a compromise that underserves each.
How often should I revisit and re-prioritize deliverables on my product manager roadmap?
Re-prioritize after every significant learning event: experiment results, major customer feedback, competitive shifts, or quarterly goal reviews. Impact maps are living documents. A deliverable that was Tier 1 last month may drop to Tier 4 after new data invalidates its underlying assumption.
Should I include 'do nothing' or 'remove a feature' as a deliverable option?
Absolutely. 'Stop doing X' or 'remove feature Y' are valid deliverables that can cause behavior change. Including them prevents feature bloat and forces the team to consider whether subtraction might achieve the impact more efficiently than addition.