samarv/dual-roadmap-strategy

The Dual Roadmap Strategy separates product development into two distinct tracks: the Public Roadmap (driven by user feedback and table stakes) and the Secret Roadmap (driven by unique technical insights and unasked-for innovation). This prevents a company from becoming a "feature factory" that only builds what competitors already know about.

The Two Roadmaps

1. The Public Roadmap

This track contains features that users explicitly ask for through support tickets, reviews, and feedback sessions.

• Characteristics: High certainty, table stakes, parity-focused.
• The Competitive Risk: If a user is asking you for it, they are likely asking your competitors for it, too. Prioritizing only this roadmap ensures you stay in the race but guarantees you will never lead it.
• Goal: Maintain retention and satisfy core utility.

2. The Secret Roadmap

This track contains features that "nobody asked for." These are derived from a unique understanding of technology shifts and deep user empathy.

• Characteristics: High novelty, revolutionary, "science fiction made real."
• The Competitive Edge: Competitors cannot see this roadmap because it isn't reflected in public user demand.
• Goal: Change user behavior and win the market through "hits."

---

Implementation Workflow

Step 1: Divide Incoming Requests

Categorize every item in your current backlog.

• Public: "Add undo/redo," "support longer uploads," "dark mode."
• Secret: "AI that shifts your eye gaze to the camera," "automatic translation that maintains your original voice."

Step 2: Run "Company-Wide Brainstorming"

Once a quarter, ignore the current backlog and hold a session with all functions (Engineering, Marketing, Recruiting, etc.).

1. Prompt: "Given what is now possible with new technology (e.g., AI/LLMs), what could we build that would make our current process look obsolete?"
2. Filter: Look for "Internal Virality." If you build a prototype of a secret idea and share it internally, does it explode? Do VPs and engineers start sharing it without being told to?
3. Feasibility Check: Hand the top "Secret" ideas to a small "Design Engineering" team to build a one-week MVP.

Step 3: Resource Allocation

• Allocate 60-70% to the Public Roadmap: Keep the lights on and stop the "leaky bucket" of users leaving for missing table-stakes features.
• Allocate 30-40% to the Secret Roadmap: Invest in the high-risk, high-reward "hits" that will drive your next wave of growth.

Step 4: The "Marketable Product" Test

For every feature on either roadmap, apply the "Weekly Marketable Product" constraint:

• Can an engineer ship a version of this in one week?
• Is it "Marketable"? (i.e., would a user subscribe or download the app specifically for this one feature?)
• Aggressive Scoping: Cut every element (hue/saturation, cloud picking, complex UI) until only the core utility remains. If the "naked" feature isn't useful, the polished version won't be either.

---

Examples

Example 1: Video Editing App

• Public Roadmap Item: "Support 4K exports." (User-requested, competitor-available).
• Secret Roadmap Item: "AI Eye Contact." Users didn't ask to have their eyeballs digitally moved; they asked for better teleprompters. The secret roadmap solves the root problem (looking at the camera) in a way the user didn't know was possible.
• Result: The secret feature goes viral on social media and drives massive new user acquisition, while the public feature prevents existing users from churning.

Example 2: Productivity Tool

• Public Roadmap Item: "Google Calendar Integration." (Table stakes).
• Secret Roadmap Item: "Predictive Rescheduling." An AI agent that looks at your biometrics/output and moves deep-work blocks automatically.
• Result: Users come for the "Predictive" magic and stay because the Calendar integration works as expected.

---

Common Pitfalls

• Ignoring the Public Roadmap: If you only build "Secret" features, your app will feel like a "playground"—cool to visit once, but useless for daily work because it lacks basic table stakes (like undo/redo or basic formatting).
• Letting the Public Roadmap Win: Most companies default to 100% public because it is easier to justify with "user data." If you do this, you will eventually be commoditized by a competitor who ships one "Secret" feature that renders your entire roadmap obsolete.
• Polishing Before Proving: Don't build the "Secret" idea to production quality immediately. Ship the MVP in a week. If users don't complain about the missing settings, the feature wasn't actually a "hit."
• Talking About the Secret Roadmap: Do not share "Secret" items in public marketing or community forums until they are ready to ship. The advantage is that your competitors don't know you are working on it.