Use this skill when the user asks to build a product roadmap grounded in behavioral or business data, reprioritize the backlog based on what the numbers say, or turn a dashboard into a sequenced set of bets. Trigger phrases include "build a roadmap from this data", "reprioritize the backlog", "where should we focus next", "roadmap based on usage", "roadmap a partir de datos", "priorizar con data", "data-driven roadmap", "planning from metrics". Produces a roadmap structured as a sequence of bets, each with impact, uncertainty, cost, and kill criteria.
Use this skill when the user asks to build a product roadmap grounded in behavioral or business data, reprioritize the backlog based on what the numbers say, or turn a dashboard into a sequenced set of bets. Trigger phrases include "build a roadmap from this data", "reprioritize the backlog", "where should we focus next", "roadmap based on usage", "roadmap a partir de datos", "priorizar con data", "data-driven roadmap", "planning from metrics". Produces a roadmap structured as a sequence of bets, each with impact, uncertainty, cost, and kill criteria.
roadmap-from-data
Anchor: A roadmap is a prioritized view of what we want to learn. Data tells you what to learn first.
When to use
Use this skill when the user needs to convert signals from dashboards, usage logs, support tickets, or interviews into a sequenced set of product bets. Works for:
A quarterly or semester planning cycle that is overloaded with feature requests.
A new PM or team inheriting a backlog that lost its narrative.
A pivot or repositioning that needs a clear sequence of bets.
A portfolio-level view across multiple product areas.
Do not use when:
The user is writing a PRD for an already-chosen feature. Use prd-authoring.
The user is pitching a single feature for approval. Use feature-proposal.
The user is scoping a client engagement with fixed deliverables. Use proposal-scoping.
Philosophy
A roadmap is not a forecast. Three handbook concepts apply directly. Output vs outcomes: the roadmap is a sequence of changes in user or business behavior, not a list of features. Product as a portfolio of bets: each line is a bet with a known size, placed deliberately among others. Roadmap as conversation, not contract: the roadmap's purpose is to help the team and the business agree on what to learn first, not to lock commitments against which the team will be measured in a quarter. A roadmap that cannot change when the data changes is theater.
ES outputs match the register of the handbook: direct, self-aware, no reverence for process, comfortable naming failure.
EN outputs use direct US business register. Do not soften bluntness into corporate-speak.
Language switches based on audience, not author.
Bilingual handling
ES. Rioplatense register. Vos over tú. Keep standard terms in English: bet, backlog, roadmap, MVP, feature flag, experiment, OKR, north star, cohort, retention, activation, churn, funnel, sprint, quarter.
EN. Direct US business register. Avoid "strategic" and "transformative" as adjectives for bets.
Metric names and flag names stay in the language of the data model.
Method
Step 1. Decide what you are prioritizing
Roadmaps go wrong when teams confuse what they are prioritizing. Pick one:
Outcomes. Changes in user behavior or business metrics.
Bets. Hypotheses to test, each with a potential outcome.
Themes. Problem areas that contain multiple bets.
Features. Concrete deliverables. Avoid this at the roadmap level; it collapses the conversation back into a backlog.
This skill defaults to bets. Themes become groupings. Outcomes become success measures on each bet. Features show up only inside individual bets, not in the roadmap row itself.
Step 2. Pull the data
Before any opinion, assemble the evidence. Three categories:
Qualitative. Interview notes, support themes, sales objections, win-loss patterns.
Business. Revenue by segment, margin, CAC, churn, expansion, pipeline.
For each data source, note:
What it measures.
Its freshness.
Its known biases.
Whether it is trusted by the team that will read the roadmap.
If a source is mistrusted, say so and include it anyway. Do not hide data the audience could pull themselves.
Step 3. Cluster signals into problem areas
Group the data into themes. A theme is a cluster of signals that point at a shared user problem or business constraint. Themes are coarse, not features.
For each theme:
Name. Short, names the problem.
Signals. Three to seven pieces of evidence that define it.
Scale. How many users, how much revenue, how frequent.
Current hypothesis. What the team believes is driving the signals.
A theme without signals is an opinion. Drop it.
Step 4. Convert themes to bets
A bet is a hypothesis that, if true, would move an outcome. For each theme, write one to three candidate bets.
Each bet has:
Hypothesis. If we change X for user Y, metric Z would move by roughly W.
Type. Discovery (learn something), product (ship something), operational (change how we work).
