dvcrn Product Roadmap
Overview
A product roadmap is your plan for what to build and when. For solopreneurs, roadmaps prevent scope creep, keep you focused on high-impact work, and help you say no to distractions. This playbook shows you how to build a roadmap that drives business outcomes, not just feature bloat.
Step 1: Understand What a Roadmap Is (and Isn't)
A roadmap IS:
- A prioritized list of problems to solve or outcomes to achieve
- A plan for the next 3-12 months
- A tool to communicate direction to customers and stakeholders
- Flexible — it evolves as you learn
A roadmap is NOT:
- A promise ("we will ship X on Y date")
- A list of every feature request you've ever received
- Set in stone — expect to revise quarterly
Key principle: Roadmaps are about outcomes, not features. Don't say "Build a dashboard." Say "Help users understand their data at a glance."
Step 2: Gather Input (Where Feature Ideas Come From)
Before prioritizing, collect all the inputs. Ideas come from multiple sources:
Input sources:
- Customer feedback (support tickets, feature requests, user interviews)
- Your vision (where you want the product to go long-term)
- Competitive gaps (features competitors have that you don't)
- Data/analytics (usage patterns, drop-off points, low-adoption features)
- Business goals (what needs to happen for revenue/growth targets?)
Collection method:
- Create a backlog (a running list of all ideas). Use Notion, Trello, Linear, or even a Google Sheet.
- For each idea, note: source, problem it solves, who requested it, and rough estimate (small/medium/large).
Rule: Don't prioritize while collecting. Just capture everything first.
Step 3: Prioritize Using a Framework
You can't build everything. Prioritization is about choosing what NOT to build.
Framework: RICE Score
RICE = Reach × Impact × Confidence ÷ Effort
For each feature or project, score:
Reach: How many users will this affect in a given time period?
- Example: 100 users/month = 100
Impact: How much will this impact those users?
- Massive = 3, High = 2, Medium = 1, Low = 0.5, Minimal = 0.25
Confidence: How confident are you in your Reach and Impact estimates?
- High = 100%, Medium = 80%, Low = 50%
Effort: How many person-weeks will this take?
- Example: 2 weeks = 2
RICE Score = (Reach × Impact × Confidence) / Effort
Example:
Feature: "Add bulk export"
Reach: 200 users/month
Impact: 2 (high)
Confidence: 80%
Effort: 1 week
RICE = (200 × 2 × 0.8) / 1 = 320
Sort your backlog by RICE score. Highest score = highest priority.
Alternative Framework: Value vs Effort Matrix
Simpler than RICE. Plot each feature on a 2×2 grid:
High Value
|
Quick Wins | Big Bets
------------|------------
Time Sinks | Low Priority
|
Low Value
- Quick Wins (high value, low effort) → Do these first
- Big Bets (high value, high effort) → Do these after quick wins
- Time Sinks (low value, high effort) → Never do these
- Low Priority (low value, low effort) → Do these if you have free cycles (usually don't)
When to use which:
- Use RICE when you have data on reach and impact
- Use Value vs Effort when you're early and estimates are rough
Step 4: Structure Your Roadmap
Organize your roadmap into time horizons. Solopreneurs should plan in quarters, not months (too much changes too fast for monthly roadmaps to stay accurate).
Roadmap structure:
NOW (Current Quarter)
Theme: [What's the focus this quarter?]
Features/Projects:
1. [Highest priority item from Step 3]
2. [Second highest priority]
3. [Third highest — only if capacity allows]
NEXT (Next Quarter)
Theme: [What's the likely focus?]
Features/Projects:
- [Top 3-5 candidates, but not committed]
LATER (6-12 months out)
Theme: [Strategic direction]
Features/Projects:
- [High-level goals, not specific features]
Why themes matter: Themes give your quarter focus. "Improve retention" is a theme. It helps you evaluate whether a feature request fits the current priority or should wait.
How many features per quarter? For a solo builder: 2-4 meaningful features or projects. Don't overcommit. Expect only 60-70% of your plan to ship — bugs, customer issues, and life happen.
Step 5: Communicate the Roadmap
A roadmap in your head is useless. Share it with customers and stakeholders.
Where to share:
- Public roadmap (Trello, Notion, or a dedicated roadmap tool like Canny, ProductBoard)
- In-product (link to roadmap from your app's menu or help section)
- Email updates (quarterly email to customers: "Here's what we're building next")
- Social media (share progress updates, celebrate shipped features)
What to share publicly vs privately:
- Public: Themes, top priorities, rough timelines (Q1, Q2, not specific dates)
- Private (internal only): Detailed specs, technical decisions, rejected ideas
Language for roadmap items:
- Instead of: "We will launch X on March 15"
- Say: "We're planning to ship X in Q1. Timelines may shift based on learnings."
Why this matters: Overpromising and underdelivering kills trust. Underpromise and overdeliver builds it.
Step 6: Integrate Customer Feedback
Customers will ask for features. Some requests are gold. Most are noise. Your job is to filter.
How to handle feature requests:
- Acknowledge and thank them. "Thanks for the suggestion! We're tracking this."
- Ask clarifying questions. "What problem are you trying to solve with this?" (Often the requested feature isn't the best solution to their actual problem.)
- Log it in your backlog. Don't commit to building it, but track it.
- Look for patterns. If 10 people ask for the same thing, it's signal. If 1 person asks, it might be noise (or an edge case).
When to prioritize a request:
- Multiple customers ask for it (signal of demand)
- It aligns with your product vision and business goals
- It scores high on RICE or Value vs Effort
When to say no:
- It's a one-off request with no pattern
- It pulls you away from your theme or strategic focus
- It benefits a tiny minority at the expense of the majority
- It would add complexity that's not worth the value
How to say no:
"Thanks for the suggestion! We're focused on [current theme] right now, so this
won't make it into the next few months. We'll keep it on the radar and revisit
as priorities evolve."
Rule: Every "yes" is a "no" to something else. Protect your roadmap ruthlessly.
Step 7: Review and Adjust Quarterly
Roadmaps are living documents. Review and update every quarter.
Quarterly roadmap review (60-90 min):
- Look back: What shipped this quarter? What didn't? Why?
- Measure impact: Did the features we shipped move the metrics we cared about? (retention, revenue, activation, etc.)
- Collect new inputs: What feedback came in? What changed in the market? What did we learn?
- Re-prioritize: Re-run your prioritization framework on the backlog. What should move into "Now" for next quarter?
- Set the theme: What's the focus for next quarter?
- Communicate: Share the updated roadmap with customers.
Red flags to watch for:
- You're shipping tons of features but none are moving key metrics (you're building the wrong things)
- Your roadmap hasn't changed in 6 months (you're not learning or adapting)
- You're constantly reacting to the loudest customer voice (you've lost strategic direction)
Step 8: Balance Fast Iteration with Strategic Vision
As a solopreneur, you can move faster than big companies. Use that advantage.
How to stay nimble:
- Ship small, test fast. Don't wait 3 months to launch a "perfect" feature. Ship a small version in 2 weeks, learn, iterate.
- Build MVPs of new features before committing to the full version.
- Use feature flags or beta access to test with a small group before rolling out to everyone.
How to stay strategic:
- Don't chase every shiny object. Stick to your quarterly theme unless something major changes.
- Protect 20-30% of your time for foundational work (refactoring, performance, UX polish). These don't go on the customer-facing roadmap but they matter.
Balance: 70% execution on the roadmap, 30% exploration and learning.
Product Roadmap Mistakes to Avoid
- Building everything customers request. You're not a feature factory. Focus on solving problems, not collecting features.
- Not saying no. Every yes is a no to something else. Learn to decline feature requests that don't align with your vision.
- Committing to specific dates too far in advance. Roadmaps are plans, not promises. Give quarters, not dates.
- Not measuring impact after shipping. If you don't check whether a feature moved the needle, you'll keep building low-impact stuff.
- Keeping the roadmap secret. Customers appreciate transparency. Share what you're working on (at a high level).
- Letting the roadmap go stale. If you haven't updated it in 6+ months, it's useless. Review quarterly.