Ecosystem roadmap prioritization framework · free AI skill

Scores and sequences platform ecosystem investments across developer tooling, third-party integrations, and marketplace dimensions using a weighted RICE-plus-strategic-fit model, then produces a 3-horizon roadmap with…

Purpose

Turn a messy backlog of ecosystem bets — SDKs, APIs, integrations, marketplace features, partner programs — into a defensible, scored, and sequenced roadmap across three time horizons. Solves the problem of ecosystem teams over-indexing on the loudest partner request or the shiniest tooling project instead of the investments that compound platform value.

When to Use

Invoke this skill when the user asks to:

Prioritize or sequence competing ecosystem investments for the next quarter or year
Decide which integrations, connectors, or partner builds to fund first
Build a developer platform or ecosystem roadmap from a backlog
Justify investment sequencing to leadership or a steering committee
Compare developer tooling work against marketplace or integration work on a common scale
Cut a bloated ecosystem backlog down to a fundable shortlist

Inputs Required

Before starting, collect:

Initiative list: The candidate ecosystem investments (rough names + 1-line description each)
Strategic goal: The platform's primary objective this period (e.g., grow active developers, increase integration depth, expand marketplace GMV)
Time horizon: Planning window — quarter, half, or year
Team capacity: Approximate engineering capacity available (headcount or eng-weeks)
Known constraints: Hard dependencies, compliance blockers, partner commitments, or deadlines
Adoption signals: Any data on demand — partner requests, support tickets, developer survey themes, integration pull requests
Investment categories in play: Which dimensions apply — developer tooling, integrations, marketplace, or all three

If team capacity or adoption signals are missing, score qualitatively and flag the assumption in the output.

Instructions

Step 1: Normalize the Backlog

Restate each initiative in a consistent format: [Verb] [object] for [audience] (e.g., "Ship TypeScript SDK for third-party developers"). Tag each with its primary dimension:

Developer Tooling: SDKs, CLIs, docs, sandboxes, API improvements, DX
Integrations: Connectors, webhooks, partner APIs, data sync
Marketplace: Listing flow, discovery, revenue share, partner onboarding, governance

If an initiative spans dimensions, assign the dominant one and note the secondary.

Step 2: Score Each Initiative on the Weighted Model

Score every initiative across six factors on a 1–5 scale. The model is RICE adapted for ecosystem dynamics:

Reach (R): How many developers/partners/end-users does this touch? 1 = niche, 5 = broad platform-wide
Impact on Strategic Goal (I): How directly does this advance the stated strategic goal? 1 = tangential, 5 = core lever
Ecosystem Compounding (E): Does this make future ecosystem work easier or unlock other initiatives? 1 = one-off, 5 = foundational platform primitive
Confidence (C): How sure are we in the Reach/Impact estimates given the data? 1 = guess, 5 = validated by signals
Adoption Demand (D): Strength of pull from the market — requests, tickets, partner asks. 1 = no signal, 5 = loud and repeated
Effort (F): Eng cost. 1 = quarters of work, 5 = days. (Inverted so higher = cheaper.)

Weighted Priority Score = (R×1) + (I×2) + (E×2) + (C×1) + (D×1.5) + (F×1)

Impact and Compounding are double-weighted because ecosystem value is driven by leverage, not volume. Show the math per initiative in a table.

Step 3: Apply the Strategic-Fit Overlay

Independent of raw score, flag each initiative:

Table Stakes: Required to remain credible (e.g., basic OAuth, core SDK). Cannot be deferred regardless of score.
Differentiator: Creates a moat or pulls partners away from competitors.
Bet: High-uncertainty, high-upside — fund deliberately, not by default.
Nice-to-Have: Real but non-urgent value.

A high-scoring Nice-to-Have can outrank a low-scoring Table Stake only after the Table Stake is funded.

Step 4: Map Dependencies and Sequencing Constraints

For each top initiative, identify:

Hard prerequisites: What must ship first (e.g., "Marketplace revenue share requires billing API")
Unlocks: What this enables downstream
Shared infrastructure: Where two initiatives compete for or share the same foundational work

Surface any case where a lower-priority initiative is a blocking prerequisite for a higher-priority one — those get pulled forward.

Step 5: Build the 3-Horizon Roadmap

Sequence funded initiatives into horizons, respecting capacity and dependencies:

Now (this horizon): Highest-scored Table Stakes + Differentiators that fit capacity and have no blocking dependencies
Next: Initiatives unlocked once Now-items ship; Bets with validated confidence
Later: Lower-confidence Bets, deferred Nice-to-Haves, initiatives awaiting more adoption signal

Each horizon must respect the stated team capacity — call out when the Now horizon is over-subscribed and what gets bumped.

Step 6: Produce the Kill/Defer List

Explicitly name initiatives that should not be funded this cycle, with a one-line reason each (low compounding, no demand signal, blocked dependency, or insufficient confidence). Being opinionated here is the point — an unfiltered roadmap isn't a roadmap.

Output Format

Structure: Scoring table → strategic-fit overlay → dependency map → 3-horizon roadmap → kill/defer list
Length: 1,000–1,400 words
Format: Scoring presented as a table; horizons as grouped lists with rationale; dependencies as a short structured map
Sections: Normalized backlog → Weighted scoring table → Strategic-fit tags → Dependency & sequencing map → Now/Next/Later roadmap → Kill/Defer list → One-paragraph recommendation
Tone: Platform PM / EM — analytical, decisive, leadership-ready. No hedging on the final sequence.

Quality Checklist

Before delivering output, verify:

[ ] Every initiative has all six factor scores and a computed Weighted Priority Score (show the arithmetic)
[ ] Impact and Ecosystem Compounding are double-weighted in the formula
[ ] Each initiative carries a strategic-fit tag (Table Stakes / Differentiator / Bet / Nice-to-Have)
[ ] Any prerequisite that blocks a higher-priority item is pulled forward and noted
[ ] The Now horizon respects stated team capacity, with bumped items called out if over-subscribed
[ ] The kill/defer list names at least one initiative with a specific reason — not empty

Notes

The most common error is funding loud partner requests (high Demand) that have low Compounding — the model surfaces these as Nice-to-Haves to defer.
Foundational tooling (auth, SDK, billing primitives) almost always scores high on Compounding and unlocks integration and marketplace work downstream — sequence it early even when its standalone Demand looks modest.
When capacity data is absent, deliver the full scored roadmap but mark horizon boundaries as "capacity TBD" rather than inventing headcount.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
<your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

Drag this file into a new chat, or copy and paste its contents
Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills