본문으로 건너뛰기
cccskills
무료GitHub에 공개

roadmap-planning

When the user needs to organize product initiatives into a prioritized, time-sequenced plan with outcomes and dependencies.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md7.5 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Roadmap Planning

When to Use

Activate when a founder or PM has a set of product ideas, feature requests, or strategic bets and needs to organize them into a coherent roadmap. This includes situations like "help me plan our Q2 roadmap," "prioritize this feature backlog," "what should we build next," or "create a roadmap for the next 6 months." Also activate when an existing roadmap needs restructuring from output-focused (feature lists) to outcome-focused (customer and business impact).

Context Required

  • From startup-context: company stage, team size and composition, current product state, business model, key metrics, strategic goals, company OKRs.
  • From the user: current roadmap or list of candidate initiatives, known customer needs, resource constraints, hard deadlines, strategy documents or company objectives for alignment, and any committed work already in progress.

Workflow

  1. Gather the current state -- Collect the existing roadmap or feature list. If the user provides strategy documents or company objectives, review them to understand how the roadmap should align with broader goals.
  2. Transform outputs to outcomes -- For each initiative, ask: What customer problem are we solving? What business metric will improve? Is there a better way to achieve the same outcome? Rewrite each item as an outcome statement.
  3. Apply outcome statement format -- Use: "Enable [customer segment] to [desired customer outcome] so that [business impact]." Every roadmap item must pass this test.
  4. Score and prioritize -- Apply RICE scoring (Reach, Impact, Confidence, Effort) to rank initiatives. Adjust for strategic alignment with company objectives and OKRs.
  5. Identify dependencies and sequencing -- Map which initiatives depend on others. Note technical, data, design, and business dependencies.
  6. Sequence into time horizons -- Place initiatives into Now (0-6 weeks), Next (6-12 weeks), and Later (12+ weeks). Use flexible release windows (quarters, not specific dates) for Later items.
  7. Validate capacity -- Cross-check the plan against team capacity. A roadmap that requires 3x your engineering bandwidth is a wishlist, not a plan.
  8. Add strategic context -- Document how outcomes align with company strategy, key assumptions about customer needs, and review cadence.

Output Format

Strategic Context

One paragraph restating the company's current strategic priorities and how this roadmap serves them. Include key assumptions about customer needs.

Outcome-Focused Roadmap

Now (0-6 weeks) -- Committed

InitiativeOutcome StatementKey MetricOwnerDependencies
Original feature/projectEnable [segment] to [outcome] so that [impact]Metric + targetTeamList

Next (6-12 weeks) -- High Confidence

Same table format. Items here are planned but may shift based on learnings from Now.

Later (12+ weeks) -- Exploratory

Same table format. Items here are directional. Flexible time windows, no owners assigned yet.

Not Doing (and Why)

Initiatives explicitly excluded with reasoning. This section is as important as the roadmap itself.

Dependency Map

Visual or textual representation of which initiatives block or enable others.

Capacity Check

Summary of estimated effort vs. available capacity per time horizon.

Key Assumptions and Risks

Numbered list of what must be true for this roadmap to succeed.

Frameworks & Best Practices

  • Outcomes over outputs. "Build advanced search filters" is an output. "Enable customers to find products 50% faster through intuitive discovery" is an outcome. Output-focused roadmaps create false precision and misalign teams around features rather than results.
  • The outcome statement format. "Enable [customer segment] to [desired customer outcome] so that [business impact]." This forces clarity on who benefits, what changes, and why it matters.
  • The "So What?" test. If you cannot articulate the outcome a feature drives, keep asking "So what?" until you reach real customer or business value. Multiple outputs may achieve one outcome -- focus on the outcome.
  • RICE scoring.
    • Reach: How many users/accounts will this affect per quarter?
    • Impact: On a scale of 0.25 (minimal) to 3 (massive), how much will this move the target metric?
    • Confidence: As a percentage, how sure are you about reach and impact estimates?
    • Effort: Person-weeks required.
    • Score: (Reach x Impact x Confidence) / Effort.
  • Three-horizon structure. Now/Next/Later avoids the false precision of Gantt charts. Commit to Now, plan for Next, explore Later.
  • Outcome roadmaps are resilient to change. Because they describe the "why" rather than the "what," they survive strategy pivots and new information better than feature roadmaps.
  • Say no explicitly. A roadmap is defined as much by what it excludes. Maintain a "Not Doing" list and share the reasoning.
  • Align with OKRs. Every outcome statement should map to a company or product OKR. Orphan initiatives signal misalignment.
  • Revisit quarterly. Roadmaps older than one quarter are stale. Build in review cadences.
  • Stage-appropriate planning.
    • Pre-PMF: Roadmaps should be 4-6 week sprints focused on learning. No 12-month plans.
    • Post-PMF: Quarterly roadmaps tied to OKRs. Balance growth features with infrastructure and debt.
    • Scaling: Semi-annual roadmaps with cross-team coordination. Dependencies become the hard problem.
  • Avoid roadmap theater. Do not create elaborate roadmaps to appease stakeholders if the team lacks the capacity or conviction to execute.

Related Skills

  • prd-writing -- Once an initiative is committed in the Now horizon, write a PRD to spec it out.
  • mvp-scoping -- Before placing an initiative on the roadmap, scope its MVP to get a realistic effort estimate.
  • user-research-synthesis -- Use customer insights to validate which outcomes matter most to your target segments.

Examples

Example 1: Output-to-outcome transformation

User: "Our Q2 plan says: build advanced search filters, implement AI recommendations, redesign dashboard. Help me turn this into an outcome roadmap."

Good output excerpt:

Transformation:

  • Output: "Build advanced search filters" --> Outcome: "Enable customers to find products 50% faster through intuitive discovery"
  • Output: "Implement AI recommendations" --> Outcome: "Increase average order value by 20% through personalized discovery"
  • Output: "Redesign dashboard" --> Outcome: "Help operators monitor all systems with 80% reduction in dashboard load time"

Each outcome is now testable, measurable, and opens the door to alternative solutions beyond the originally specified feature.

Example 2: Feature backlog to roadmap

User: "Here's our feature backlog: Slack integration, SSO, reporting dashboard, mobile app, API v2, onboarding wizard. Help me build a roadmap."

Good output excerpt:

Now (0-6 weeks): | Onboarding Wizard | Enable new signups to reach first value within 10 minutes so that activation rate increases from 35% to 55% | Activation rate | Growth team | None |

Not Doing This Quarter:

  • Mobile app -- Current usage data shows <5% of sessions are mobile. Revisit when mobile demand signal is stronger. Asking "So what?" reveals no compelling customer outcome today.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

When the user wants to apply to startup accelerators, incubators, or fellowship programs. Also use when the user mentions "YC application", "Techstars", "accelerator", or "apply to programs".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

shawnpang/startup-founder-skills3682026년 3월 17일 업데이트

When the user needs to design or evaluate system architecture — service boundaries, data models, API contracts, infrastructure topology, database selection, or dependency analysis. Also activate for "design the system", "how should I architect this", "monolith vs microservices", or architecture decision records.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

shawnpang/startup-founder-skills3682026년 3월 17일 업데이트

When the user needs to write a monthly or quarterly investor update, prepare a board deck, or communicate company progress to stakeholders.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

shawnpang/startup-founder-skills3682026년 3월 17일 업데이트

When the user needs to identify at-risk accounts, understand why customers are leaving, reduce churn rate, build health scores, design save plays, or create win-back campaigns.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

shawnpang/startup-founder-skills3682026년 3월 17일 업데이트

When the user needs to set up or improve CI/CD pipelines — GitHub Actions, GitLab CI, deployment automation, or says "set up CI", "automate deployment", "add tests to pipeline", "fix my build".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

shawnpang/startup-founder-skills3682026년 3월 17일 업데이트

When the user asks for a code review, shares code for feedback, or says "review this", "check my code", "what's wrong with this". Also activate when reviewing a pull request or diff.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

shawnpang/startup-founder-skills3682026년 3월 17일 업데이트

shawnpang의 스킬 모두 보기

이 스킬의 문제 신고