product-lens

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