tool-foundation-sprint-basics
정보
이 스킬은 파운데이션 스프린트의 초기 "기본 사항" 단계를 지원하며, 타겟 고객, 핵심 문제, 팀의 강점, 경쟁 환경에 대해 명시적이고 종합적인 결정을 내리도록 팀을 안내합니다. 이후 차별화 작업을 위한 단일 전략적 프레임을 생성합니다. 스프린트 브리프가 확정된 후, 1일차 오전 세션을 구성하는 데 사용하세요.
빠른 설치
Claude Code
추천npx skills add product-on-purpose/pm-skills -a claude-code/plugin add https://github.com/product-on-purpose/pm-skillsgit clone https://github.com/product-on-purpose/pm-skills.git ~/.claude/skills/tool-foundation-sprint-basicsClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
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:
- Target customer statement: a specific, named customer with markers (demographic, behavioral, contextual).
- Important problem statement: a customer-perceived pain strong enough to drive switching from alternatives.
- Team advantage inventory: the capabilities, insights, relationships, data, and timing edges that make this team credible against the problem.
- Competitor and alternative map: direct competitors, substitute workflows, manual workarounds, internal tools, and the strongest baseline of all: doing nothing.
- 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
| Input | What the skill does with it |
|---|---|
| Sprint brief | Reads the Decision Target to scope which customers and problems are in-scope; out-of-scope candidates are flagged before voting |
| Customer/market context packet | Pre-populates the silent ideation board with previously-surfaced candidates so the team doesn't reinvent them |
| Competitor knowledge | Pre-populates the alternative map with already-known competitors; the team adds and discusses rather than starts cold |
| Team advantage notes | Surfaces 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:
- Frame each of the four sub-decisions (or approve the facilitator's framing).
- Listen during silent ideation and vote discussion without dominating.
- Supervote each sub-decision with explicit rationale when the supervote diverges from the team's top choice.
- 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 저장소
연관 스킬
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 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.
