MCP HubMCP Hub
스킬 목록으로 돌아가기

tool-foundation-sprint-basics

product-on-purpose
업데이트됨 2 days ago
2 조회
238
33
238
GitHub에서 보기
디자인general

정보

이 스킬은 파운데이션 스프린트의 초기 "기본 사항" 단계를 지원하며, 타겟 고객, 핵심 문제, 팀의 강점, 경쟁 환경에 대해 명시적이고 종합적인 결정을 내리도록 팀을 안내합니다. 이후 차별화 작업을 위한 단일 전략적 프레임을 생성합니다. 스프린트 브리프가 확정된 후, 1일차 오전 세션을 구성하는 데 사용하세요.

빠른 설치

Claude Code

추천
기본
npx skills add product-on-purpose/pm-skills -a claude-code
플러그인 명령대체
/plugin add https://github.com/product-on-purpose/pm-skills
Git 클론대체
git clone https://github.com/product-on-purpose/pm-skills.git ~/.claude/skills/tool-foundation-sprint-basics

Claude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요

문서

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Foundation Sprint Basics

Day 1 morning of a Foundation Sprint. The team makes four foundational choices explicit: who the product is for, what important problem it solves, why this team has a right to win, and what customers do today instead. The output is one coherent strategic frame, not four separable decisions.

Family contract: docs/reference/skill-families/foundation-sprint-skills-contract.md. This skill is a member of foundation-sprint-skills.

When to Use

  • Day 1 morning of a Foundation Sprint, after the brief is signed.
  • The team has sufficient customer and market knowledge (per readiness verdict) to make informed choices.
  • Each of the four sub-decisions is open or contested; the team has not pre-aligned on any of them.
  • The Decider is in the room and ready to sign off on the bundled output before lunch.

When NOT to Use

  • The team lacks enough customer knowledge to choose a target customer or name an important problem. Run customer research or problem framing first; revisit when readiness criterion 3 passes.
  • The team has already committed to a specific customer-problem pair and just wants to validate it. Use a lighter validation tool; Basics is for genuine decision-making, not ratification theater.
  • Day 1 morning has slipped into afternoon. Differentiation depends on Basics being complete; if Basics did not produce a coherent frame by lunch, do not start Differentiation. Reframe or postpone.

What This Skill Produces

A single bundled artifact with five sections:

  1. Target customer statement: a specific, named customer with markers (demographic, behavioral, contextual).
  2. Important problem statement: a customer-perceived pain strong enough to drive switching from alternatives.
  3. Team advantage inventory: the capabilities, insights, relationships, data, and timing edges that make this team credible against the problem.
  4. Competitor and alternative map: direct competitors, substitute workflows, manual workarounds, internal tools, and the strongest baseline of all: doing nothing.
  5. Note-and-Vote trace: a record of how each sub-decision was made, including alternatives considered and Decider rationale.

The artifact is treated as one coherent output, not four separate ones. The team signs off on the bundled frame, not on the components in isolation. See references/TEMPLATE.md for the canonical structure and references/EXAMPLE.md for the Brainshelf example.

The Four Sub-Decisions

Each sub-decision uses tool-note-and-vote (the silent ideation + voting + Decider supervote protocol). The skill structures the sequence but the decision protocol is the standalone note-and-vote tool.

1. Target customer (25-35 minutes)

The team produces 3-7 candidate customer descriptions through silent ideation, then votes, then the Decider supervotes one. The chosen customer MUST be specific (not "SaaS PMs" but "PMs at Series-B SaaS companies between 20 and 100 engineers"). The skill rejects vague segments and prompts the team to add markers until the description names someone the team can recognize.

2. Important problem (20-30 minutes)

The team names 3-7 candidate pains the chosen customer experiences. Vote, then Decider supervote. The chosen problem MUST be painful enough to drive switching from current behavior (including doing nothing). Mild annoyances are not Important Problems; the skill enforces this by asking explicitly: "What does the customer currently do, and why would they leave it for our solution?"

3. Team advantage inventory (20-30 minutes)

The team enumerates its specific edges: capabilities, insights, relationships, data, technology, distribution, timing. Vote to surface the top 2-3 (multi-vote), Decider confirms. The skill rejects generic advantages ("great team," "passionate") and prompts for specific evidence ("Sam previously built X at Y company"; "Riley has a 12k-member network in our target segment").

4. Competitor and alternative map (20-30 minutes)

The team maps the full alternative space: direct competitors, substitute workflows, manual workarounds, internal tools, and "do nothing." For each, the team notes what customers use it for and why people leave (or stay). The skill enforces inclusion of "do nothing" as a competitor; many teams forget that inertia is often the strongest alternative.

Inference Inputs

InputWhat the skill does with it
Sprint briefReads the Decision Target to scope which customers and problems are in-scope; out-of-scope candidates are flagged before voting
Customer/market context packetPre-populates the silent ideation board with previously-surfaced candidates so the team doesn't reinvent them
Competitor knowledgePre-populates the alternative map with already-known competitors; the team adds and discusses rather than starts cold
Team advantage notesSurfaces the team's existing self-assessment; voting refines and prioritizes

Common Pitfalls

  • Vague customer. "SaaS PMs" or "readers" is not a target customer. The skill prompts for markers until the team can name a specific person archetype.
  • Mild-annoyance problems mistaken for painful ones. If the customer would not switch from doing nothing or from a paid alternative, the problem is not painful enough. The skill tests this explicitly.
  • Generic team advantages. "Great engineers" is not an advantage; "Sam built the original Pocket sync engine and knows offline-first patterns" is. The skill rejects unspecific advantages and prompts for evidence.
  • Ignoring "do nothing" as a competitor. The most common oversight. Many teams skip it because they think of competitors as named products; the skill forces inclusion.
  • Treating the four sub-decisions as separable. A target customer whose important problem is not solvable by the team's advantage cannot win. The skill ratifies the BUNDLED artifact, not the components; if the components don't cohere, the team revisits.
  • Skipping note-and-vote trace. The decision moments are load-bearing. Without the trace, Day 1 PM Differentiation begins on a fragile foundation and may end up re-litigating Basics under a different name.

Decider Role

The Decider's job during Basics is to:

  1. Frame each of the four sub-decisions (or approve the facilitator's framing).
  2. Listen during silent ideation and vote discussion without dominating.
  3. Supervote each sub-decision with explicit rationale when the supervote diverges from the team's top choice.
  4. Sign off on the bundled artifact as a coherent strategic frame before Differentiation begins.

A Decider who blesses everything without challenge is not adding value; a Decider who overrides without rationale is not building trust.

Canonical Sources

  • Character Capital. "Foundation Sprint guide." Basics agenda and decision sequence.
  • Knapp, J., and Zeratsky, J. Click. Day 1 morning sequence.
  • Knapp, J., and Zeratsky, J. "Introducing the Foundation Sprint." Lenny's Newsletter. Target customer and important problem framing.

Cross-Skill Usage

Prerequisites: tool-foundation-sprint-brief. The Brief's Decision Target tells the skill which customer-problem space is in-scope.

The skill invokes tool-note-and-vote four times (once per sub-decision). Each invocation produces its own decision record; the four traces are aggregated into the bundled artifact.

Next invocation in the sprint: tool-foundation-sprint-differentiation on Day 1 afternoon, immediately after lunch.

Decider Checkpoint

This skill ends with a Decider Checkpoint in references/TEMPLATE.md. The Decider signs off on the bundled artifact as a coherent strategic frame, not on the components individually. Without sign-off, Differentiation cannot start cleanly because the inputs are still under negotiation.

GitHub 저장소

product-on-purpose/pm-skills
경로: skills/tool-foundation-sprint-basics
0
agent-skillsai-skillsclaude-codeclaude-desktopdesign-sprintfoundation-sprint

연관 스킬

executing-plans

디자인

executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.

스킬 보기

requesting-code-review

디자인

이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.

스킬 보기

connect-mcp-server

디자인

이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.

스킬 보기

web-cli-teleport

디자인

이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.

스킬 보기