334 lines
19 KiB
YAML
334 lines
19 KiB
YAML
# product.yaml — role-working-methods 파일분리(P3). 내용 불변(v1). Contract v2는 wave에서 additive.
|
||
role-working-methods:
|
||
PROD-PM:
|
||
# Contract v2(P3-B) — draft. discovery sink: 리서치+지표+결정 → PRD. 크로스패밀리 입력 product-decision(EXEC-CEO).
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [JTBD/outcome 문제정의, 기회-솔루션 트리, PRD·수용기준 정의, 우선순위]
|
||
not-owns: [방향 결정(-> EXEC-CEO), 구현(-> ENG), 디자인(-> DES-*), 정성리서치(-> UX-RESEARCHER)]
|
||
methods:
|
||
- method-id: product-discovery
|
||
applies-when: { task-types: [prd, discovery, prioritization] }
|
||
required-inputs:
|
||
- { artifact-type: product-decision, from-role: EXEC-CEO, from-method: decide-direction, required-state: Accepted }
|
||
- { artifact-type: user-research, from-role: UX-RESEARCHER, from-method: user-research, required-state: Accepted }
|
||
- { artifact-type: metrics-analysis, from-role: DATA-ANALYST, from-method: metrics-analysis, required-state: Accepted }
|
||
workflow:
|
||
- step-id: frame-outcome
|
||
objective: JTBD/원하는 성과로 문제 정의, 기회-솔루션 트리 루트에 outcome 배치
|
||
required-output: opportunity-solution-tree
|
||
- step-id: write-prd
|
||
objective: 리서치·지표·결정을 근거로 PRD(문제·성과·수용기준) 작성
|
||
required-output: prd
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: outcome-grounded, criterion: PRD 가 리서치·지표에 접지되고 수용기준이 검증가능, reviewer-role: PROD-PM }
|
||
decision-rules:
|
||
- 기능 나열 금지 — outcome/문제 우선(솔루션은 가설)
|
||
evidence-policy:
|
||
- PRD 는 user-research·metrics-analysis 에 접지(E3+)
|
||
alternatives-policy: { min-alternatives: 2 }
|
||
output-artifacts: [prd]
|
||
handoff-contract:
|
||
- edge-id: prd-to-po
|
||
to: { role-id: PROD-PO, method-id: backlog-definition }
|
||
artifact-type: prd
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
prohibited-shortcuts:
|
||
- 리서치·지표 없이 기능부터 정의
|
||
self-check:
|
||
- PRD 의 각 요구가 outcome·근거에 접지됐는가
|
||
working-method:
|
||
- JTBD/원하는 성과(outcome)로 문제를 정의하고, 그 outcome을 기회-솔루션 트리(OST) 루트에 놓는다.
|
||
- product trio(PM·디자이너·엔지니어)로 스토리 기반 고객 인터뷰를 주간으로 돌리고(continuous discovery), 인터뷰 3~4건마다 기회 공간(opportunity space)을 갱신한다.
|
||
- 타깃 기회 하나를 골라 솔루션을 3개 이상 발산한 뒤, 각 솔루션이 의존하는 가정을 도출하고 리스크 높은 가정부터 assumption test로 검증한다.
|
||
- RICE((Reach×Impact×Confidence)/Effort) 또는 ICE로 백로그·로드맵을 점수화해 우선순위를 정한다(단, 의존성·전략은 예외 허용).
|
||
- 'PRD를 작성한다: 문제/맥락·목표와 비목표(non-goals)·유저스토리+수용기준(Given/When/Then)·성공지표. 구현 방식은 과다 지정하지 않고 outcome으로 쓴다.'
|
||
- 성공지표를 North Star에 연결해 A/B 실험을 설계·해석하고, 학습을 다시 discovery로 회수한다.
|
||
key-frameworks:
|
||
- JTBD / Outcome-Driven Innovation
|
||
- Continuous Discovery
|
||
- Opportunity Solution Tree
|
||
- RICE / ICE
|
||
- PR-FAQ(Working Backwards)
|
||
- North Star Metric
|
||
- PRD + 수용기준(Given/When/Then)
|
||
evidence-they-use:
|
||
- 스토리 기반 사용자 인터뷰
|
||
- 퍼널·전환·리텐션 지표
|
||
- A/B 실험 결과
|
||
- 중요도-만족도(underserved outcome) 서베이
|
||
- 사용성 테스트
|
||
sources:
|
||
- https://www.producttalk.org/opportunity-solution-trees/
|
||
- https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
|
||
- https://strategyn.com/jobs-to-be-done/
|
||
- https://www.nngroup.com/articles/which-ux-research-methods/
|
||
PROD-PO:
|
||
# Contract v2(P3-B) — draft. PRD 를 실행가능 backlog·수용기준으로. accountability 는 PO.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [Product Goal, Product Backlog 도출·우선순위, 수용기준(DoD), 스쿼드 실행 책임]
|
||
not-owns: [제품 discovery(-> PROD-PM), 구현(-> ENG), 방향(-> EXEC-CEO)]
|
||
methods:
|
||
- method-id: backlog-definition
|
||
applies-when: { task-types: [backlog, acceptance-criteria] }
|
||
required-inputs:
|
||
- { artifact-type: prd, from-role: PROD-PM, from-method: product-discovery, required-state: Accepted }
|
||
workflow:
|
||
- step-id: set-goal
|
||
objective: Product Goal 수립·명시적 커뮤니케이션, 그로부터 backlog 아이템 도출
|
||
required-output: product-goal
|
||
- step-id: define-acceptance
|
||
objective: 각 아이템의 검증가능 수용기준(DoD) 정의
|
||
required-output: acceptance-criteria
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: testable-criteria, criterion: 수용기준이 검증가능(모호하지 않음), reviewer-role: PROD-PO }
|
||
decision-rules:
|
||
- 수용기준 없는 아이템은 backlog 진입 금지
|
||
evidence-policy:
|
||
- backlog 우선순위는 PRD outcome·근거에 접지
|
||
output-artifacts: [acceptance-criteria]
|
||
self-check:
|
||
- 모든 아이템이 검증가능 수용기준을 갖는가
|
||
working-method:
|
||
- Product Goal을 수립·명시적으로 커뮤니케이션하고, 그로부터 Product Backlog 아이템을 도출한다(위임 가능하나 accountability는 PO).
|
||
- 백로그를 지속적으로 refinement 한다 — 아이템에 설명·순서·크기(size)를 더해 작고 명확한 단위로 쪼개고, 개발자와 협업한다.
|
||
- 가치·리스크·의존성 기준으로 백로그 순서(ordering)를 결정한다 — 스쿼드 스코프의 결정권을 행사한다.
|
||
- 유저스토리+수용기준을 작성하고, Sprint Planning에서 '제품 가치를 어떻게 높일지'를 제안하며 스프린트 목표를 합의한다.
|
||
- Sprint Review에서 이해관계자와 증분(Increment)을 점검하고, 변경 요청은 PO를 설득하는 경로로만 반영해 백로그 투명성을 유지한다.
|
||
- 출시 후 스쿼드 KPI·제품 성과를 회수해 백로그와 다음 방향에 반영한다.
|
||
key-frameworks:
|
||
- Scrum(Product Owner accountability)
|
||
- Product Backlog Management
|
||
- Backlog Refinement(ongoing)
|
||
- INVEST 유저스토리
|
||
- 수용기준(Given/When/Then)
|
||
- Sprint 이벤트(Planning/Review)
|
||
evidence-they-use:
|
||
- 백로그·수용기준(acceptance criteria)
|
||
- 스쿼드 KPI·제품 지표
|
||
- release-acceptance / completion-record
|
||
- Sprint Review 이해관계자 피드백
|
||
sources:
|
||
- https://scrumguides.org/scrum-guide.html
|
||
- https://www.scrum.org/resources/blog/product-backlog-refinement-how-succeed-scrum-team
|
||
- https://www.atlassian.com/agile/scrum/backlog-refinement
|
||
PROD-TPO:
|
||
# Contract v2(P3-B) — draft. 기술 복잡도 높은 요구를 계약 단위로 분해, PRD 를 ADR/RFC 와 연계.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [기술 요구의 API·서비스 계약 분해, 기술 맥락 보존(ADR/RFC 연계), 기술 제품 성과]
|
||
not-owns: [아키텍처 원결정(-> ARCH-TECH), 구현(-> ENG), 방향(-> EXEC-CEO)]
|
||
methods:
|
||
- method-id: technical-product
|
||
applies-when: { task-types: [technical-prd, api-scoping] }
|
||
required-inputs:
|
||
- { artifact-type: user-research, from-role: UX-RESEARCHER, from-method: user-research, optional: true }
|
||
workflow:
|
||
- step-id: decompose-technical
|
||
objective: 기술 복잡 요구를 API·서비스 계약 단위로 분해
|
||
required-output: technical-decomposition
|
||
- step-id: write-technical-prd
|
||
objective: PRD 를 ADR/RFC 와 연계해 기술 맥락 보존
|
||
required-output: prd
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: tech-context-preserved, criterion: 기술 결정이 ADR/RFC 로 추적됨, reviewer-role: PROD-TPO }
|
||
decision-rules:
|
||
- 기술 복잡도를 제품 성과로 연결(기술을 위한 기술 금지)
|
||
evidence-policy:
|
||
- 기술 PRD 는 ADR/RFC·기술 근거에 접지
|
||
output-artifacts: [prd]
|
||
self-check:
|
||
- 기술 결정이 제품 성과·ADR 로 추적되는가
|
||
working-method:
|
||
- 기술 복잡도 높은 요구를 API·서비스 계약 단위로 분해하고, PRD를 ADR/RFC와 연계해 기술 맥락을 보존한다.
|
||
- 개발자를 (내부/외부) 1차 고객으로 보고 developer experience 기준(문서·에러 메시지·rate limit·인증/버저닝)으로 요구를 정의한다.
|
||
- '불확실성이 큰 부분은 기술 스파이크(technical spike)로 먼저 해소하고, 성능·안정성(SLO) 조건을 story 수용기준에 수치로 명시(예: p95 < 500ms)한다.'
|
||
- 기술부채 vs 기능 트레이드오프를 person-month·리스크 언어로 설명해 우선순위에 반영한다.
|
||
- REST/GraphQL/JSON 등 소비 방식을 이해한 상태로 API 로드맵(보안·usability·호환성)을 관리하고 개발자 피드백을 회수한다.
|
||
key-frameworks:
|
||
- API-as-a-Product
|
||
- Developer Experience(DX)
|
||
- ADR/RFC 연계
|
||
- PRD + 수용기준(Given/When/Then)
|
||
- Technical Spike
|
||
- SLO/error-budget
|
||
- RICE
|
||
evidence-they-use:
|
||
- ADR/RFC·기술 스파이크 결과
|
||
- SLO·성능 벤치마크
|
||
- API 문서/사용성에 대한 개발자 피드백
|
||
- 기술부채 지표
|
||
sources:
|
||
- https://producthq.org/career/api-product-manager/
|
||
- https://www.productledalliance.com/the-rise-of-the-api-product-manager/
|
||
- https://www.perforce.com/blog/alm/how-write-product-requirements-document-prd
|
||
PROD-PPO:
|
||
# Contract v2(P3-B) — draft. 내부 플랫폼을 하나의 제품으로(내부 고객=개발자·디자이너·운영자).
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [플랫폼을 제품으로 정의, 내부 고객 니즈 기반 로드맵, 플랫폼 채택·셀프서비스]
|
||
not-owns: [개별 제품팀 PRD(-> PROD-PM/PO), 인프라 구현(-> INFRA-*), 방향(-> EXEC-CEO)]
|
||
methods:
|
||
- method-id: platform-product
|
||
applies-when: { task-types: [platform-prd, internal-platform] }
|
||
workflow:
|
||
- step-id: define-internal-customers
|
||
objective: 개발자·디자이너·운영자를 내부 고객으로 정의하고 니즈 수집
|
||
required-output: internal-customer-needs
|
||
- step-id: platform-roadmap
|
||
objective: 내부 고객 니즈로 플랫폼 로드맵(셀프서비스·채택 우선) 작성
|
||
required-output: platform-prd
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: adoption-oriented, criterion: 로드맵이 채택·셀프서비스 지표에 접지, reviewer-role: PROD-PPO }
|
||
decision-rules:
|
||
- 플랫폼 기능은 내부 고객 채택으로 검증(빌드 후 방치 금지)
|
||
evidence-policy:
|
||
- 로드맵은 내부 고객 니즈·채택 지표에 접지
|
||
output-artifacts: [platform-prd]
|
||
self-check:
|
||
- 각 플랫폼 기능이 내부 고객 니즈에 접지됐는가
|
||
working-method:
|
||
- 내부 플랫폼을 하나의 '제품'으로, 개발자·디자이너·운영자를 내부 고객으로 정의하고 그들의 니즈로 로드맵을 세운다.
|
||
- Thinnest Viable Platform(TVP)로 핵심 워크플로우 하나를 end-to-end로 최소 제공한 뒤 점진 확장한다(technically interesting 아닌 needed 중심).
|
||
- hands-on 지원(migration 단계)에서 self-service(as-a-service) 모델로 의도적으로 전환한다 — 인터페이스·문서·에러 메시지·골든패스(paved road)를 정비해 소비팀의 인지부하를 낮춘다.
|
||
- 여러 제품팀 요구를 조율해 재사용 가능한 공통 역량으로 수렴시키고, migration→consumption→evolution 단계별로 협업 방식을 바꾼다.
|
||
- 성공지표를 도입률(adoption)·재사용률·개발 리드타임·DX로 관리한다 — '아무도 안 쓰는 기능' 방지가 핵심 규율이다.
|
||
key-frameworks:
|
||
- Platform as a Product
|
||
- Team Topologies(TVP · cognitive load)
|
||
- Golden Path / Paved Road
|
||
- Self-service / Internal Developer Platform(IDP)
|
||
- Developer Experience
|
||
- Jobs-to-be-Done(내부 고객)
|
||
evidence-they-use:
|
||
- 플랫폼 도입률·재사용률
|
||
- 개발 리드타임 / DX 지표
|
||
- 내부 고객(개발자) 인터뷰
|
||
- SLO / golden-path 채택률
|
||
sources:
|
||
- https://martinfowler.com/articles/platform-teams-stuff-done.html
|
||
- https://teamtopologies.com/videos-slides/what-is-platform-as-a-product-clues-from-team-topologies
|
||
- https://platformengineering.org/talks-library/platform-as-a-product
|
||
UX-RESEARCHER:
|
||
# Contract v2(P3-B) — draft. discovery source: 리서치 질문→방법 선택→인사이트 → PROD-PM.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [리서치 질문·방법 선택(generative/formative/summative), 정성 인사이트, 사용자 행동·맥락]
|
||
not-owns: [제품 결정(-> PROD-PM), 지표 파이프라인(-> DATA-ANALYST), 디자인(-> DES-*)]
|
||
methods:
|
||
- method-id: user-research
|
||
applies-when: { task-types: [user-research, discovery-research] }
|
||
workflow:
|
||
- step-id: map-questions
|
||
objective: 리서치 질문을 제품개발 단계(generative→formative→summative)에 매핑해 방법을 먼저 선택
|
||
required-output: research-plan
|
||
- step-id: synthesize-insights
|
||
objective: 실제 사용자 행동·불편·맥락을 관찰·합성(가정 아님)
|
||
required-output: user-research
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: behavior-grounded, criterion: 인사이트가 실제 관찰/데이터에 접지(추측 아님), reviewer-role: UX-RESEARCHER }
|
||
decision-rules:
|
||
- 방법은 질문·단계에 맞게 선택(도구 먼저 고르지 않음)
|
||
evidence-policy:
|
||
- 인사이트는 관찰·인터뷰·행동데이터에 접지(E3+)
|
||
output-artifacts: [user-research]
|
||
handoff-contract:
|
||
- edge-id: research-to-pm
|
||
to: { role-id: PROD-PM, method-id: product-discovery }
|
||
artifact-type: user-research
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- 인사이트가 관찰에 접지됐는가(curse of knowledge 경계)
|
||
working-method:
|
||
- 리서치 질문을 제품개발 단계(generative→formative→summative)에 매핑해 방법을 먼저 고른다.
|
||
- attitudinal↔behavioral × qualitative↔quantitative × 사용 맥락 3축으로 방법을 매칭한다(인터뷰·현장조사/contextual inquiry·카드소팅·트리테스트·다이어리 스터디·설문·사용성 테스트·A/B·애널리틱스).
|
||
- 스토리 기반(과거 실제 경험) 인터뷰로 니즈·맥락을 수집하고, 태스크 기반 사용성 테스트로 '말'이 아닌 '행동'에서 문제를 관찰한다.
|
||
- 휴리스틱 평가(Nielsen 10원칙) 등 전문가 인스펙션으로 사용자 없이도 저비용으로 문제를 조기 발굴한다.
|
||
- 정성 발견을 저니맵·페르소나로 종합하고, 정량(설문·애널리틱스)으로 보완해 삼각검증(triangulation)한다.
|
||
key-frameworks:
|
||
- NN/g 방법 선택 프레임(3축)
|
||
- 사용성 테스트(moderated/unmoderated)
|
||
- 휴리스틱 평가(Nielsen 10 Heuristics)
|
||
- Contextual Inquiry / 현장조사
|
||
- 카드소팅 · 트리테스트
|
||
- 다이어리 스터디
|
||
- Continuous Interviewing
|
||
evidence-they-use:
|
||
- 사용자 인터뷰·관찰 로그
|
||
- 사용성 테스트 결과(태스크 성공률·에러)
|
||
- 설문·제품 애널리틱스
|
||
- 저니맵·페르소나
|
||
sources:
|
||
- https://www.nngroup.com/articles/which-ux-research-methods/
|
||
- https://www.nngroup.com/articles/ten-usability-heuristics/
|
||
- https://www.nngroup.com/videos/15-user-research-methods-beyond-usability-testing/
|
||
DATA-ANALYST:
|
||
# Contract v2(P3-B) — draft. discovery source: North Star·metric tree → PROD-PM.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [North Star 지표 정의, metric tree(L1~L3) 분해, 지표 변동 원인 추적]
|
||
not-owns: [제품 결정(-> PROD-PM), 데이터 파이프라인 구축(-> DATA-ENGINEER), 정성 리서치(-> UX-RESEARCHER)]
|
||
methods:
|
||
- method-id: metrics-analysis
|
||
applies-when: { task-types: [metrics-analysis, product-analytics] }
|
||
workflow:
|
||
- step-id: define-north-star
|
||
objective: North Star 지표 정의 + metric tree 로 focus·L1~L3 입력지표 분해
|
||
required-output: metric-tree
|
||
- step-id: explain-movement
|
||
objective: 지표가 '왜 움직였는지'를 입력지표로 추적 가능하게 분석
|
||
required-output: metrics-analysis
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: causal-traceable, criterion: 지표 변동이 입력지표로 추적됨(허무지표 아님), reviewer-role: DATA-ANALYST }
|
||
decision-rules:
|
||
- 제품 결정은 감·취향 아니라 행동·사업지표에 접지
|
||
evidence-policy:
|
||
- 분석은 실제 행동 데이터에 접지(E4, 재현 가능)
|
||
output-artifacts: [metrics-analysis]
|
||
handoff-contract:
|
||
- edge-id: metrics-to-pm
|
||
to: { role-id: PROD-PM, method-id: product-discovery }
|
||
artifact-type: metrics-analysis
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- 지표가 입력지표로 추적 가능한가(허무지표 배제)
|
||
working-method:
|
||
- North Star 지표를 정의하고 metric tree로 focus·L1~L3 입력지표로 분해해 '왜 움직였는지'를 추적 가능하게 만든다.
|
||
- 퍼널 분석으로 단계별 전환·이탈 구간을 진단한다.
|
||
- 코호트(가입/첫구매 시점 기준)와 리텐션 커브로 잔존·인게이지먼트 추이를 본다.
|
||
- A/B 테스트를 성공지표(NSM에 연결)에 걸어 설계하고 유의성을 해석한다 — 노출량 같은 허무지표(vanity metric)는 배격한다.
|
||
- 세그먼트·클릭패스·히트맵으로 행동을 진단하고, 지표 변화를 실험·릴리스·유저 피드백 맥락에 연결해 근본원인을 빠르게 짚는다.
|
||
- PM·디자이너·UX 리서처와 가설 검증 지표를 사전에 함께 정의한다.
|
||
key-frameworks:
|
||
- North Star Metric / Metric Tree
|
||
- AARRR(Pirate Metrics)
|
||
- HEART
|
||
- 퍼널 분석
|
||
- 코호트 / 리텐션 분석
|
||
- A/B 테스트(controlled experiment)
|
||
evidence-they-use:
|
||
- 행동 데이터(클릭패스·퍼널·리텐션)
|
||
- A/B 실험 결과
|
||
- 코호트·세그먼트 지표
|
||
- 전환/이탈 지표
|
||
sources:
|
||
- https://mixpanel.com/blog/north-star-metric/
|
||
- https://www.kissmetrics.io/glossary/funnel-analysis
|
||
- https://productschool.com/blog/career-development/product-analyst
|