| name | product-lens |
| description | 구현에 들어가기 전에 "왜"를 검증하고, 제품 진단을 수행하며, 요청이 구현 계약으로 굳기 전에 제품 방향을 압박 테스트하는 스킬입니다. |
| origin | ECC |
Product Lens — 만들기 전에 생각하기
이 레인은 구현 준비 명세를 쓰는 곳이 아니라 제품 진단을 담당합니다.
오래 남는 PRD-to-SRS 또는 capability-contract 산출물이 필요하면 product-capability로 넘깁니다.
사용 시점
- 어떤 기능이든 시작하기 전에 "왜"를 검증할 때
- 주간 제품 리뷰에서 우리가 맞는 것을 만들고 있는지 점검할 때
- 기능 선택 사이에서 막혔을 때
- 출시 전에 사용자 여정을 sanity check할 때
- 모호한 아이디어를 엔지니어링 계획 전 제품 브리프로 바꿀 때
동작 방식
모드 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. Time-to-value 점수화(첫 성과까지 걸리는 시간)
6. 온보딩 개선 상위 3개 권고
모드 4: 기능 우선순위화
아이디어가 10개인데 2개를 골라야 할 때:
1. 후보 기능 전체 나열
2. impact(1-5) × confidence(1-5) ÷ effort(1-5)로 점수화
3. ICE 점수순 정렬
4. runway, 팀 규모, 의존성 제약 반영
5. 근거가 있는 우선순위 로드맵 출력
출력
모든 모드는 에세이가 아니라 실행 가능한 문서를 출력합니다. 모든 권고에는 구체적인 다음 단계가 있어야 합니다.
연동
다음과 함께 사용합니다.
/browser-qa로 사용자 여정 감사 결과 검증/design-system audit로 시각 완성도 평가/canary-watch로 출시 후 모니터링- 제품 브리프를 구현 준비 capability plan으로 바꿔야 하면
product-capability
