# 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