Product Lens — 구축 전에 생각하라
이 스킬은 구현 가능한 명세 작성이 아닌 제품 진단을 담당합니다.
사용자가 지속 가능한 PRD-to-SRS 또는 기능 계약 산출물을 필요로 한다면 product-capability로 넘기세요.
사용 시기
- 기능을 시작하기 전 — '왜'를 검증할 때
- 주간 제품 리뷰 — 올바른 것을 만들고 있는가?
- 기능 선택이 막혔을 때
- 출시 전 — 사용자 여정을 점검할 때
- 막연한 아이디어를 엔지니어링 계획 전에 제품 브리프로 변환할 때
작동 방식
모드 1: 제품 진단
YC 오피스 아워를 자동화한 것과 같습니다. 까다로운 질문을 던집니다:
1. 이 제품은 누구를 위한 것인가? (특정 개인, '개발자'가 아님)
2. 어떤 불편함이 있나? (정량화: 얼마나 자주, 얼마나 심각한가, 현재 어떻게 해결하는가?)
3. 왜 지금인가? (무엇이 바뀌어서 이것이 가능/필요해졌는가?)
4. 10점 만점 버전은 무엇인가? (돈/시간이 무제한이라면)
5. MVP는 무엇인가? (가설을 증명할 수 있는 가장 작은 것)
6. 반대 목표는 무엇인가? (명시적으로 만들지 않는 것은?)
7. 어떻게 작동하는지 알 수 있나? (지표, 분위기가 아님)
결과물: 답변, 위험, Go/No-Go 추천이 포함된 PRODUCT-BRIEF.md
결과가 "예, 만듭시다"라면 다음 스킬은 product-capability이며, 더 이상의 창업자 극장은 없습니다.
모드 2: 창업자 리뷰
현재 프로젝트를 창업자의 시각으로 검토합니다:
1. README, CLAUDE.md, package.json, 최근 커밋 읽기
2. 추론: 이것이 무엇이 되려고 하는가?
3. 점수: 제품-시장 적합성 신호 (0-10)
- 사용량 성장 추세
- 유지율 지표 (반복 기여자, 재방문 사용자)
- 수익 신호 (가격 페이지, 청구 코드, Stripe 연동)
- 경쟁력 (복사하기 어려운 것은?)
4. 식별: 이것을 10배 성장시킬 한 가지
5. 표시: 중요하지 않은 것을 만들고 있는 부분
모드 3: 사용자 여정 감사
실제 사용자 경험을 매핑합니다:
1. 신규 사용자처럼 제품을 클론/설치
2. 모든 마찰 지점 문서화 (혼란스러운 단계, 오류, 누락된 문서)
3. 각 단계 시간 측정
4. 경쟁사 온보딩과 비교
5. 점수: 시간-가치 (사용자가 첫 번째 성공을 거둘 때까지 걸리는 시간)
6. 추천: 온보딩 개선을 위한 상위 3가지
모드 4: 기능 우선순위 지정
10가지 아이디어 중 2개를 선택해야 할 때:
1. 모든 후보 기능 목록 작성
2. 각각 점수: 영향(1-5) × 확신(1-5) ÷ 노력(1-5)
3. ICE 점수로 순위 매기기
4. 제약 조건 적용: 자금, 팀 규모, 종속성
5. 결과물: 근거가 포함된 우선순위 로드맵
결과물
모든 모드는 에세이가 아닌 실행 가능한 문서를 결과물로 냅니다. 모든 추천에는 구체적인 다음 단계가 있습니다.
연동
다음과 함께 사용하세요:
/browser-qa— 사용자 여정 감사 결과 검증/design-system audit— 시각적 완성도 평가/canary-watch— 출시 후 모니터링product-capability— 제품 브리프가 구현 가능한 기능 계획이 되어야 할 때