Product Discovery & UX Flow

분류: Layer 13 - Product Engineering & Growth Systems

핵심 질문

Product discovery는 아이디어를 많이 만드는 활동이 아니다. solution delivery(선택한 해결책을 제품 품질로 구현하고 출시하는 일)에 큰 비용을 쓰기 전에, 무엇을 아직 모르는지 드러내고 틀린 생각을 싸게 폐기하는 학습 활동이다.

Product Engineer가 discovery에 참여한다는 것은 기획과 디자인을 독점한다는 뜻도 아니다. 사용자의 문제, 제품의 위험, UX(User Experience, 사용자가 제품과 상호작용하며 겪는 전체 경험), 구현 상태, 관찰할 증거를 같은 판단 흐름으로 연결한다는 뜻이다.

1. Discovery가 다루는 판단 단위

먼저 비슷해 보이는 말을 분리해야 한다. 이 구분이 없으면 관찰한 사실, 팀의 해석, 만들고 싶은 해결책이 한 문장에 섞인다.

용어	이 문서에서의 뜻	팀 초대 기능의 예
Problem(문제)	특정 사용자가 목표를 이루는 과정에서 반복해서 겪는 관찰 가능한 격차나 비용. 해결책 이름을 포함하지 않는다.	관리자가 멤버 초대를 시작하지만 가입 완료까지 이어지지 않는다.
Opportunity(기회)	문제 안에서 제품이 개입해 사용자 행동이나 결과를 바꿀 수 있는 필요, 불편, 욕구. 모든 문제가 제품 기회인 것은 아니다.	초대 전에 권한과 좌석 비용을 이해시킬 여지, 초대받은 사람의 만료·재진입 마찰을 줄일 여지
Assumption(가정)	해결책이 성공하려면 참이어야 하지만 아직 검증되지 않은 믿음.	관리자가 좌석 비용을 몰라 초대를 중단한다.
Hypothesis(가설)	어떤 조건과 개입이 어떤 관찰 결과를 낼지 반증 가능하게 쓴 문장.	비용 안내를 제출 전에 보여주면 분석 기간의 `invite_creation_rate = unique workspace with invite_created / unique workspace with invite_modal_opened`가 오른다.
Evidence(증거)	불확실성을 줄이는 관찰이나 데이터. 출처·표본·과업·측정 방식에 따라 강도가 다르며, 한 조각이 곧 증명은 아니다.	이탈 로그, 최근 행동 인터뷰, 프로토타입 과업 관찰, 출시 후 전환 데이터

“초대 모달이 복잡하다”는 문제처럼 들리지만 이미 UI를 원인으로 지목한 해석일 수 있다. 반면 “유료 workspace 관리자 1,200회의 초대 시도 중 28%가 제출 전에 끝났다”는 관찰은 해결책을 아직 고정하지 않는다. 좋은 문제 정의는 해결책 후보를 넓게 남기고, 좋은 가설은 틀렸다고 판정할 조건을 남긴다.

2. 선행 방식의 한계: 왜 delivery 앞에 discovery가 필요한가

요구사항 전달 중심 개발은 할 일이 명확하고 일정 예측이 쉽다. 그러나 요구사항이 다음 믿음을 암묵적으로 참이라고 가정하면, 구현 품질만으로는 실패를 막을 수 없다.

사용자가 이 문제를 실제로 중요하게 여긴다.
제안한 흐름을 이해하고 사용할 수 있다.
현재 기술과 시간 안에 제품 품질로 만들 수 있다.
가격, 법무, 보안, 영업, 운영 정책과 함께 성립한다.

코드를 완성한 뒤 첫 번째 가정이 틀렸다고 알게 되면, 테스트와 확장성에 들인 비용까지 함께 버리게 된다. Product discovery는 이런 불확실성을 모두 제거하는 단계가 아니다. 다음 투자 전에 가장 위험한 가정을 찾아, 실제 제품보다 싸고 빠른 방식으로 학습하는 앞단 루프다.

Discovery가 solution delivery 전에 학습하거나 폐기하려는 것은 보통 세 가지다.

문제 해석: 우리가 본 증상이 실제 원인과 기회를 가리키는가.
해결 방향: 사용자가 선택하고 사용할 만한 접근인가.
투자 전제: 기술과 사업 경계 안에서 만들 가치가 있는가.

모든 불확실성이 사라질 때까지 조사하는 것은 목표가 아니다. 작은 변경이고 되돌리기 쉬우며 실패 비용이 낮다면 30분 리뷰와 기존 데이터 확인으로도 충분할 수 있다. 반대로 결제 정책, 권한 모델, 마이그레이션처럼 되돌리기 어렵고 실패 비용이 큰 결정은 더 강한 증거가 필요하다.

2.5 선행 기술의 한계 - Discovery와 UX Flow가 등장한 이유

화면 명세와 API(Application Programming Interface, 프로그램 사이의 상호작용 계약) 목록은 “무엇을 만들지”는 보여주지만, “왜 이 흐름이어야 하는지”와 “어떤 관찰이 결정을 뒤집을지”까지 보장하지 않는다. 그 결과 문제 정의가 틀리면 화면을 다시 만들고, 실패 상태는 막판에 붙고, 이벤트는 출시 직전에 추가되어 원인을 설명하기 어려워진다.

Product Discovery & UX Flow는 이 빈틈을 사용자 문제, 핵심 행동, 위험 가정, 상태 전이, 증거 설계로 메운다. 이 문서의 목표는 discovery를 별도 조사 단계로 늘리는 것이 아니라, 제품 학습과 구현 사이의 번역 손실을 줄이는 것이다.

3. 네 가지 제품 위험

제품 위험은 “프로젝트가 왠지 불안하다”는 감상이 아니라, 해결책이 성공하기 위해 답해야 할 서로 다른 질문이다. SVPG의 canonical 명칭은 value risk, usability risk, feasibility risk, business viability risk다. 다른 프레임에서 쓰는 desirability는 사용자가 해결책을 원하거나 선택할지를 묻는다는 점에서 value와 가까운 질문이지만, 이 문서에서는 SVPG 명칭으로 표기하지 않는다.

Discovery가 먼저 줄여야 할 네 위험

value risk

선호 가능성 위험. 대상 사용자가 문제를 중요하게 여기고 이 해결책을 선택하거나 계속 사용할 것인가?

확인 후보: 실제 과거 행동, 대안에 지불한 비용, 선택·예약·사용 데이터

usability risk

사용성 위험. 사용자가 설명을 받지 않고도 흐름을 이해하고 목표 과업을 완료할 수 있는가?

확인 후보: 현실적인 과업을 준 프로토타입 또는 제품의 사용성 테스트

feasibility risk

실현 가능성 위험. 가진 기술, 데이터, 역량, 시간 안에 필요한 품질과 규모로 만들 수 있는가?

확인 후보: 버릴 코드로 기술 불확실성만 확인하는 technical spike, API·데이터 확인, 성능·보안 제약 검토

business viability risk

사업 성립 위험. 가격, 비용, 법무, 보안, 영업, 브랜드, 운영 정책과 함께 지속 가능한가?

확인 후보: 책임 있는 이해관계자 검토, 단위 경제성, 정책·계약 확인

네 위험은 역할별 체크박스가 아니다. 예를 들어 “좌석 비용을 미리 보여주자”는 해결책은 이해하기 쉬워 usability risk를 통과해도, 가격을 본 사용자가 초대를 포기하면 value risk에서 실패한다. 기술적으로 정확한 예상 금액을 계산할 수 있어도 기존 영업 계약과 충돌하면 business viability risk에서 멈춘다.

가장 위험한 가정은 불확실성이 가장 큰 문장이 아니라, 틀릴 가능성 x 틀렸을 때 손실이 가장 큰 문장이다. 버튼 문구보다 “이탈 원인이 관리자에게 있다”는 가정이 틀렸을 때 해결책 전체가 무효가 되므로 먼저 확인해야 한다.

4. Dual-track과 continuous discovery의 철학

Dual-track은 discovery와 delivery를 서로 다른 종류의 일로 보이게 만드는 운영 모델이다.

Discovery track	Delivery track
목표: 빠른 학습과 잘못된 아이디어의 폐기	목표: 예측 가능한 품질로 가치 전달
결과: 증거, 바뀐 가설, 중단·계속·전환 결정	결과: 운영 가능한 코드, 데이터, 문서, 관측성
최적화: 작은 시간 상자, 낮은 충실도, 여러 대안	최적화: 정확성, 보안, 접근성, 확장성, 유지보수성

두 트랙은 두 팀, 두 개의 고정 단계, “디자인 완료 후 개발팀에 산출물만 넘기는” handoff를 뜻하지 않는다. 같은 제품 팀이 delivery를 진행하는 동안 다음 위험을 작게 탐색할 수 있다. Discovery에서 살아남은 아이디어도 delivery 중 기술 제약이나 실제 사용 데이터로 다시 바뀔 수 있다.

Continuous discovery는 큰 조사 프로젝트를 가끔 여는 대신, 제품 결정을 앞두고 작은 고객 접점·프로토타입·데이터 확인을 반복하는 습관이다. Teresa Torres의 정의는 제품을 만드는 팀이 원하는 outcome(산출 기능이 아니라 바꾸려는 사용자·사업 결과)을 향해 매주 고객과 접점을 갖는 리듬을 제안한다. 핵심은 “매주 인터뷰 횟수”를 성과로 세는 것이 아니라 최근 증거가 다음 결정을 바꾸게 하는 것이다.

Discovery가 실패한 신호는 인터뷰 수가 적다는 사실 자체가 아니다. 결론이 이미 정해져 있고 확인 자료만 모으거나, discovery 담당자가 별도 팀이 되어 delivery 팀에 문서를 넘기거나, 같은 질문을 반복하면서 결정은 계속 미루는 상태가 더 직접적인 실패 신호다.

5. 도구마다 답하는 질문이 다르다

산출물의 모양이 비슷해도 증거의 종류는 다르다. 아래 도구는 서로 대체재가 아니며, 그 자체로 사실을 증명하지도 않는다.

도구	정의와 답하려는 질문	만들거나 관찰하는 것	증거의 한계
User flow(사용자 흐름)	제품 안에서 한 목표를 달성하는 단계와 분기를 표현한다. “어떤 상태와 선택을 거쳐 완료하는가?”	진입점, 화면·행동, 분기, 오류, 성공 상태	팀이 그린 flow는 설계 가설이다. 실제 사용자가 이해하는지, 제품 밖 맥락이 어떤지는 알 수 없다.
Journey map(여정 지도)	사용자가 목표를 이루는 더 긴 시간과 채널의 경험을 표현한다. “전후 맥락과 접점 어디에서 마찰이 생기는가?”	단계, 채널, 행동, 생각·감정, pain point	인터뷰·관찰 없이 만든 지도는 팀의 추측을 시각화할 뿐이다. 시스템 내부 원인도 직접 설명하지 않는다.
Service blueprint(서비스 청사진)	사용자에게 보이는 접점과 뒤의 조직·시스템을 연결한다. “경험을 제공하려면 누가 무엇을 수행하는가?”	사용자에게 보이는 frontstage, 내부 backstage, 지원 프로세스, 시스템 의존성	내부 운영 모델에는 강하지만 사용자가 해결책을 원하거나 쉽게 쓸 것이라는 증거는 아니다.
Prototype(프로토타입)	학습하려는 위험만 표현한 임시 해결책이다. “이 상호작용이나 기술 접근이 성립하는가?”	종이 화면, 클릭 모델, 구현 전 관심 행동만 재는 fake door, 버릴 코드로 기술 불확실성만 확인하는 technical spike	충실도 밖의 것은 검증하지 못한다. 클릭 모델의 성공은 운영 성능·실데이터·구매 의사를 증명하지 않는다.
Interview(인터뷰)	사용자의 과거 경험, 맥락, 동기, 언어를 듣는다. “최근 실제 상황에서 무엇이 일어났고 왜 그렇게 판단했는가?”	사건의 서술, 대안, 우회 행동, 인식	자기보고 증거다. 미래 의향과 예의상 긍정은 실제 행동과 다를 수 있고, 인터페이스 사용성은 말만으로 판정할 수 없다.
Usability test(사용성 테스트)	현실적인 사용자가 과업을 수행하는 행동을 관찰한다. “목표를 이해하고 도움 없이 완료하는가?”	성공·실패 경로, 막힘, 오류, 발화, 필요 시 시간	선택한 참가자·과업·환경·프로토타입 범위의 행동만 보여준다. 시장 수요, 장기 유지, 사업성까지 증명하지 않는다.

같은 초대 기능도 질문에 따라 도구가 달라진다

“초대 전후에 관리자가 어떤 채널과 승인 절차를 거치는가?”는 journey map 질문이다.
“제출 후 이메일 발송과 좌석 결제는 어느 시스템·운영팀에 의존하는가?”는 service blueprint 질문이다.
“만료된 링크에서 재발송까지 어떤 상태를 거치는가?”는 user flow 질문이다.
“관리자가 비용 안내를 발견하고 이해하는가?”는 prototype을 이용한 usability test 질문이다.
“최근 초대를 포기했던 순간에 무엇을 했는가?”는 interview 질문이다.

한 참가자가 “이 기능이면 쓸 것 같다”고 말한 것은 value risk의 약한 단서일 수 있지만 usability risk의 증거는 아니다. 반대로 프로토타입 과업을 5명이 모두 완료해도 실제로 초대할 필요가 없다면 value risk는 남는다. 그래서 질문 하나에 맞는 최소 방법을 고르고, 다른 위험까지 검증했다고 확대 해석하지 않는 것이 중요하다.

6. UX Flow를 구현 단위로 번역하기

UX Flow는 화면 순서도가 아니라 제품 상태의 흐름이다. 사용자 의도만 그리면 구현 경계가 빠지고, 서버 상태만 그리면 사용자가 실패를 이해하고 회복하는 과정이 빠진다.

UX Flow를 구현 단위로 번역하는 네 층

사용자 의도

사용자가 지금 하려는 일과 성공이라고 느끼는 순간

예: 멤버가 실제로 가입해 협업을 시작한다

상태 전이

화면과 서버 도메인·권한 상태가 어떤 조건에서 바뀌는지

예: draft invite -> sent invite -> accepted membership

실패 복구

권한 없음, 네트워크 실패, 결제 한도, 중복 요청에서 어디로 돌아가는지

예: seat limit이면 결제 안내, expired이면 기존 초대를 재발송

관찰 이벤트

시작, 전환, 실패, 완료를 어떤 privacy 경계의 이벤트로 남기는지

예: invite_modal_opened, invite_created, invite_expired, invite_accepted

이 네 층을 함께 쓰면 디자인은 상태를 설명하고, API는 허용된 전이를 보장하며, analytics는 어느 전이에서 가설이 깨졌는지 보여준다. 예를 들어 invite_accepted는 이메일 클릭이 아니라 membership이 실제 생성된 뒤 기록해야 중복 클릭과 만료 재시도를 성공으로 잘못 세지 않는다.

invite_modal_opened는 L13 tracking 문서와 맞춘 canonical start event다. 버튼 클릭이나 route 진입 의도가 아니라 초대 UI가 실제로 렌더링되어 사용자에게 표시된 시점에 기록한다. raw event가 재렌더링으로 반복될 수 있으므로 지표에서는 분석 기간(analysis window)마다 unique workspace 또는 actor 중 질문에 맞는 한 단위를 사전에 선택해 중복 제거하고, 한 지표 안에서 두 단위를 섞지 않는다.

흐름에는 main path만 아니라 entry, empty, error, retry, permission, success 상태를 둔다. 서버 쪽에서는 명령마다 멱등성(idempotency) 책임을 분리하고, 두 관리자가 동시에 요청할 때의 동시성(concurrency) 경계를 확인한다. resend command idempotency는 같은 invitation의 반복 재발송을 하나의 send job/message로 수렴시킨다. accept command idempotency와 DB invariant는 같은 invitation을 반복 수락해도 Membership이 하나만 생기고 seat가 한 번만 증가하도록 보장한다. 이벤트 속성의 workspace_id는 개인정보가 없는 값이 아니라 pseudonymous identifier(가명 식별자)다. 분석에는 workspace_id, role, seat_limit_state, source처럼 목적에 필요한 맥락만 넣고, 이메일·이름 같은 direct identifier와 초대 메시지·오류 본문 같은 민감 원문은 제외한다. 수집 목적과 보존 정책 없이 PII(Personally Identifiable Information, 개인 식별 정보)나 별도 동의가 필요한 값을 추가하지 않는다.

Activation은 화면 노출보다 늦게 온다

Activation은 사용자가 제품의 핵심 가치를 처음 경험한 상태다. 단순히 화면을 본 vanity event(가치 경험과 거리가 먼 노출·클릭 지표)와 구분한다.

제품/기능	activation에 가까운 행동	단순 vanity event
협업 도구	첫 팀원이 가입해 문서에 댓글을 남김	회원가입 완료
개발자 도구	첫 API key로 성공 응답을 받음	대시보드 방문
분석 도구	첫 이벤트가 수집되고 차트가 저장됨	SDK 설치 페이지 조회
결제 기능	구독 상태와 entitlement(기능 접근 권한)가 실제 접근을 바꿈	결제 버튼 클릭

퀴즈

새 온보딩 화면의 성공 지표로 page_view만 두면 왜 부족한가?

힌트: 사용자가 화면을 봤다는 사실과 가치를 경험했다는 사실은 다르다.

정답 보기

page_view는 노출만 말한다. 첫 프로젝트 생성, 첫 팀원 가입, 첫 API 호출 성공처럼 사용자의 목표와 제품 가치가 만나는 행동을 함께 관찰해야 한다.

Activation event도 절대적인 진실은 아니다. 팀 초대 제품에서 invite_accepted는 협업 가치의 proxy(직접 측정하기 어려운 결과를 대신하는 관찰값)이고, 첫 공동 작업이나 재방문이 더 강한 증거일 수 있다. 너무 이른 이벤트를 쓰면 숫자는 좋아져도 가치 경험은 바뀌지 않는다.

7. Worked example: 비용 안내 표현을 수정하고 가설을 미해결로 남기기

다음 수치는 방법을 손으로 따라가기 위한 가상 예시다. 목표는 “좋은 아이디어를 증명”하는 것이 아니라, 정성 사용성 판정과 정량 인과 판정을 분리해 증거가 답할 수 있는 범위 안에서 다음 선택을 바꾸는 것이다.

시나리오

7-day accepted/modal_opened funnel outcome이 낮다

분석 기간에 유료 workspace 1,200개에서 초대 UI가 실제 표시되었고, unique workspace의 28%는 invite_created 전에 이탈했으며, 초대를 생성한 unique workspace의 32%는 7일 안에 invite_accepted까지 도달했다. 팀은 좌석 비용 안내 모달을 제안했다.

무엇을 먼저 만들지 말고, 어떤 가정이 틀리면 이 제안 전체를 폐기해야 하는지 찾는다.

7.1 가설을 반증 가능하게 쓴다

초기 problem은 “유료 workspace 관리자의 초대가 멤버 가입으로 충분히 이어지지 않는다”다. “비용 안내 모달이 없다”는 problem이 아니라 해결책 설명이다.

팀의 첫 opportunity는 관리자가 제출 전에 권한과 추가 좌석 비용을 이해하도록 돕는 것이다. 여기서 가설을 다음처럼 쓴다.

유료 workspace 관리자에게 제출 전에 권한과 예상 좌석 비용을 보여주면, 비용 불확실성 때문에 중단하던 사용자가 초대 생성을 완료하여 invite_creation_rate가 사전에 정한 목표만큼 오른다. 단, invite_error_seen 비율과 초대 관련 지원 문의는 악화되지 않아야 한다.

이 개입의 지표는 다음처럼 단계와 분모를 분리한다.

역할	지표	분모와 단계의 의미	비용 안내가 직접 바꿀 수 있는 범위
Primary immediate	`invite_creation_rate = unique workspace with invite_created / unique workspace with invite_modal_opened`	분석 기간에 초대 UI를 실제 본 unique workspace 중 서버가 초대를 생성해 발송 단계로 넘긴 workspace 비율이다.	안내를 본 관리자의 비용·권한 불확실성과 제출 전 중단을 줄이거나 늘리는 구간이므로 직접 효과 범위다.
End-to-end outcome	`unique workspace with invite_accepted / unique workspace with invite_modal_opened`	같은 시작 cohort 중 7일 안에 수신자의 membership 생성까지 끝난 unique workspace 비율인 discovery funnel outcome이다.	개입은 제출 전 구간을 통해 이 결과에 기여할 수 있지만, 이메일 전달·수신자 행동·만료까지 직접 바꾸지는 않는다.
Recipient diagnostic	`unique workspace with invite_accepted / unique workspace with invite_created`	초대를 생성한 같은 시작 cohort 중 7일 안에 수신자가 수락해 membership이 생긴 unique workspace 비율이다.	생성 이후 전달·열람·만료·수락 구간의 진단값이다. 개입의 직접 효과 범위 밖이며, 생성된 초대의 구성이 달라져 수치만 움직일 수도 있다.

이 표는 discovery 단계의 약식 정의다. 다음 Tracking 문서의 정본 계약에서는 분석 기간의 first qualifying open을 cohort 진입으로 고정하고, modal→created를 같은 flow_id와 반열린 creation window [opened_at, min(closed_at, opened_at + 30분))로 연결하며, created→accepted를 같은 invite_id로 연결한다.

가상 baseline에서 invite_creation_rate = 72%, recipient diagnostic은 32%, 두 구간을 잇는 end-to-end discovery funnel outcome은 약 23%다. 이 funnel outcome은 초대 UI를 본 기존·신규 workspace를 분모로 삼는다. 반면 Intro의 신규 workspace 7-day activation_rate는 해당 주에 생성된 신규 unique workspace를 분모로 삼고, 생성 후 7일 안에 invite_created와 최소 하나의 invite_accepted를 모두 만든 workspace를 분자로 삼는다. 관찰 기간이 7일로 같아도 모집단과 질문이 다른 지표이므로 서로 대체하거나 같은 이름으로 부르지 않는다.

정량 experiment 전에 primary immediate metric의 최소 의미 개선을 **+8%p, 즉 80%**로 사전 선언한다. 모든 비율은 분석 기간에 invite_modal_opened가 발생한 시작 cohort를 기준으로 unique workspace를 한 번만 세며, actor 단위 질문으로 바꿀 때는 분자와 분모를 모두 unique actor로 바꾼다. 표본 크기와 실험 기간은 이 문서에서 임의로 정하지 않고, baseline traffic과 통계 조건을 바탕으로 다음 Product Analytics & Tracking Plan, Experimentation & Feature Flags 문서에서 설계한다. 분모와 7일 관찰 기간을 함께 고정해야 제출 전 개선을 수신자 수락 개선으로 오해하지 않는다. 지원 문의와 오류율은 한 지표를 올리면서 다른 손실을 만드는지 보는 guardrail metric(부작용 방지 지표)이다.

7.2 가장 위험한 가정을 고른다

이 가설에는 여러 assumption이 숨어 있다.

가정	틀리면 생기는 일	먼저 확인할 위험
초대 이탈의 주원인은 관리자의 비용·권한 불확실성이다.	제안한 모달이 원인과 무관해 해결책 전체를 폐기해야 한다.	value risk
제출 전 금액을 보여주면 관리자가 이해한다.	정보는 있어도 과업 수행이 나아지지 않는다.	usability risk
현재 billing API가 초대 시점 예상 금액을 일관되게 계산한다.	UI는 만들 수 있어도 잘못된 금액을 표시한다.	feasibility risk
계약별 가격 공개가 영업·법무 정책과 충돌하지 않는다.	사용자에게 보여줄 수 없는 해결책이 된다.	business viability risk

가장 위험한 가정은 첫 번째다. 나머지를 완벽히 풀어도 실제 원인이 초대받은 사람의 만료 링크라면 비용 안내는 성과를 만들지 못한다. 다만 작은 정성 usability test는 이 인과 가정을 판정할 수 없다. 팀은 정량 experiment에 앞서 첫 비용 안내 표현이 과업 수행에 쓸 만한지만 별도의 solution-level gate로 확인한다.

7.3 정성 테스트는 첫 표현 방식의 usability만 판정한다

팀은 실제 계약 조건을 반영한 클릭 프로토타입을 만들고 관리자 5명에게 “새 멤버 한 명을 초대하면서 이번 결제에 추가되는 비용을 확인하라”는 과업을 준다. 참가자가 비용 안내를 찾는지, 총액과 추가 청구액을 정확히 설명하는지, 도움 없이 초대를 생성하는지를 관찰한다.

결과를 보기 전에 decision rule(판정 규칙)을 선언한다. 5명 중 최소 4명이 비용을 정확히 설명하고 도움 없이 90초 안에 초대를 생성하면 첫 표현 방식을 다음 검증으로 계속한다. 3명 이하가 두 조건을 모두 충족하면 첫 표현 방식을 폐기하거나 수정한 뒤 usability를 다시 검증한다.

이 rule은 선택한 참가자·과업·프로토타입에서 solution을 계속할지 수정할지 정하는 정성 usability 판정일 뿐이다. 모집단 성공률 80%를 추정하지 않으며, 비용 불확실성이 초대 이탈의 원인인지 또는 invite_creation_rate가 +8%p 오를지를 판정하지 않는다.

7.4 판정: 첫 표현 방식을 폐기하거나 수정한다

가상 결과는 다음과 같다고 하자.

5명 중 3명만 총액과 추가 청구액을 정확히 설명했다.
5명 중 4명은 90초 안에 초대를 생성했지만, 2명은 월 중간 일할 계산을 월 전체 비용으로 오해했다.

사전 rule을 통과하지 못했으므로 결론은 첫 표현 방식 폐기/수정이다. 이 실패는 비용 안내의 정보 구조와 문구가 아직 충분히 usable하지 않다는 뜻이다. 비용 불확실성이 이탈의 원인이라는 causal hypothesis는 미해결로 남고, invite_creation_rate의 정량 효과도 반증되지 않았다.

7.5 다음 선택: usability를 다시 확인한 뒤 정량 검증을 설계한다

팀은 총액, 추가 청구액, 일할 계산을 분리해 표현을 수정하고 같은 decision rule로 새 참가자에게 다시 usability를 확인한다. 통과하면 첫 비용 안내 solution을 계속 검토할 수 있지만, 그 결과만으로 delivery나 효과를 확정하지 않는다.

그다음 정량 experiment는 baseline invite_creation_rate = 72%와 최소 의미 개선 +8%p, 즉 target 80%를 사전에 고정하고 설계한다. 필요한 표본 크기와 기간, 분석 단위, guardrail 판정은 다음 Product Analytics & Tracking Plan, Experimentation & Feature Flags 문서에서 다룬다. 정량 결과가 나오기 전까지 causal hypothesis와 전환 효과는 계속 미해결이다.

8. 검증 깊이를 선택하는 기준

모든 기능에 같은 리서치 절차를 붙이면 discovery가 새로운 관료제가 된다. 방법의 크기는 문서 양이 아니라 결정의 위험에 맞춘다.

상황	적절한 최소 수준	더 깊게 볼 신호
문구·배치처럼 되돌리기 쉬운 변경	기존 데이터 확인 + 30분 discovery review	핵심 전환을 바꾸거나 접근성 위험이 큼
새 사용자 흐름	user flow + 5명 안팎의 정성 usability test	여러 segment(공통 조건으로 묶은 사용자 집단)·권한·채널에서 흐름이 달라짐
원인이 불명확한 행동 문제	행동 데이터 + 최근 사건 중심 interview	자기보고와 실제 행동이 충돌함
기술·데이터 제약이 큰 해결책	가장 좁은 technical spike	성능·보안·마이그레이션 실패 비용이 큼
가격·계약·규제에 닿는 변경	business viability risk 책임자와 정책 확인	되돌리기 어렵거나 고객별 계약이 다름

30분 review는 작은 변경의 위험을 빠르게 노출하는 시간 상자이지, 사용자 연구를 대체하는 숫자 규칙이 아니다. 그 시간 안에는 다음 네 문장만 맞추면 된다.

Problem / opportunity: 대상·제외 segment 중 누구의 어떤 관찰 가능한 마찰을 바꾸는가?
Riskiest assumption: 무엇이 틀리면 해결책을 폐기해야 하는가?
Minimum evidence: 어떤 관찰이면 계속·수정·폐기할 것인가?
UX and measurement: entry·empty·error·success, 도메인·권한·결제 상태, 이벤트·guardrail·privacy 경계는 무엇인가?

이 판단 카드는 기존의 긴 인터뷰 질문 목록이나 운영 절차보다 의사결정에 가깝다. 질문 수가 아니라 답이 다음 선택을 바꿀 수 있는지가 중요하다.

9. 경계와 흔한 오해

“사용자가 원한다고 말했다”는 구매·사용 증거가 아니다

미래 의향 질문은 예의상 긍정과 상상 편향에 취약하다. “이 기능을 쓰겠습니까?”보다 최근 실제 사건, 지금 쓰는 대안, 이미 치른 시간·비용을 묻는 편이 value risk를 더 잘 탐색한다. 그래도 interview는 원인 후보를 만드는 정성 증거이며 모집단의 비율을 확정하지 않는다.

“프로토타입 과업에 성공했다”는 제품 성공이 아니다

사용성 테스트는 “쓸 수 있는가”에 강하지만 “쓸 것인가”와 다르다. 참가자가 지시에 따라 초대를 완료해도 실제 팀원을 초대할 이유가 없을 수 있다. 또한 클릭 프로토타입은 billing 정합성, 이메일 전달률, 동시성, 보안을 검증하지 않는다.

“Discovery 완료”라는 단계문은 dual-track과 맞지 않는다

Delivery가 시작된 뒤에도 실제 데이터가 가설을 뒤집을 수 있다. 반대로 이미 잘 알려진 문제의 작은 개선은 별도 discovery sprint 없이 delivery 안의 짧은 확인으로 충분할 수 있다. 두 트랙의 핵심은 순서가 아니라 학습용 일과 제품 품질용 일을 다른 성공 기준으로 관리하는 데 있다.

산출물이 많아도 증거가 없을 수 있다

journey map, service blueprint, user flow가 모두 있어도 사용자 관찰과 데이터가 없다면 정교한 가설 묶음일 뿐이다. 지도는 팀의 생각을 정렬하는 도구이고, 현실을 자동으로 복사하는 도구가 아니다.

10. 실패 신호로 운영하기

인터뷰 진행 순서를 외우기보다 다음 현상이 보일 때 discovery 루프가 깨졌다고 판단한다.

Discovery와 UX Flow의 실패 신호

problem 문장에 이미 특정 화면·기능·기술이 답으로 들어 있다
가설에 대상, 개입, 결과, 기간, 반증 조건 중 무엇이 빠졌는지 설명하지 못한다
가장 위험한 가정보다 만들기 쉬운 프로토타입부터 선택한다
interview의 미래 의향을 실제 사용 증거처럼 보고한다
usability test 결과로 시장 수요·기술 가능성·사업성을 한꺼번에 통과시킨다
user flow에 error, retry, permission, billing 상태와 돌아갈 경로가 없다
핵심 이벤트가 서버 상태 전이보다 이르게 기록되어 성공을 부풀린다
discovery 산출물이 delivery 팀에 전달되지만 엔지니어는 근거와 폐기 조건을 모른다
조사 횟수는 늘지만 결과가 계속·수정·폐기 결정을 바꾸지 않는다
출시 후 반대 증거가 나와도 이미 delivery 했다는 이유로 가설을 유지한다

실패 신호가 보이면 인터뷰 질문을 더 늘리기보다 현재 결정과 증거의 연결을 복구한다. 어떤 위험을 다루는지, 그 방법이 실제로 답할 수 있는 질문인지, 어떤 결과가 선택을 바꿀지를 다시 적는다.

11. 다음 문서로 이어지는 연결

이 문서가 “무엇을 학습하고 어떤 흐름을 만들 것인가”를 다룬다면, 다음 문서들은 그 흐름을 신뢰 가능한 측정과 출시 판단으로 연결한다.

Product Analytics & Tracking Plan: UX Flow의 상태 전이를 event taxonomy와 tracking plan으로 바꾼다.
Funnel, Cohort & Retention Metrics: 흐름의 이탈과 재방문을 segment와 cohort 차이로 해석한다.
Experimentation & Feature Flags: 가설 효과를 비교하고 delivery와 release를 분리한다.
Product Domain Modeling: UX Flow 뒤의 account, workspace, membership, entitlement 상태를 모델링한다.

추가 학습 키워드

Product discovery
Dual-track development
Continuous discovery
Problem, opportunity, assumption, hypothesis
value risk, usability risk, feasibility risk, business viability risk
User flow, journey map, service blueprint
Prototype, interview, usability test
Activation event
Guardrail metric

참고 소스

Nielsen Norman Group, Discovery Phase: https://www.nngroup.com/articles/discovery-phase/
Nielsen Norman Group, User Journeys vs. User Flows: https://www.nngroup.com/articles/user-journeys-vs-user-flows/
Nielsen Norman Group, Service Blueprints: Definition: https://www.nngroup.com/articles/service-blueprints-definition/
Nielsen Norman Group, User Interviews: How, When, and Why to Conduct Them: https://www.nngroup.com/articles/user-interviews/
Nielsen Norman Group, Usability Testing 101: https://www.nngroup.com/articles/usability-testing-101/
Jeff Patton, Dual Track Development is not Duel Track: https://jpattonassociates.com/dual-track-development/
Product Talk, Continuous Discovery: https://www.producttalk.org/glossary-discovery-continuous-discovery/
Silicon Valley Product Group, The Four Big Risks: https://www.svpg.com/four-big-risks/
PostHog, Product Engineer role: https://posthog.com/careers/product-engineer
Linear, Product Engineer role: https://linear.app/careers/069c4628-88d7-4e4d-b393-c996fc7f3076