유용한 MVP 브리프는 디자인을 시작하기 전에 세 가지를 결정합니다. 누구를 위한 제품인지, 첫 버전에서 의도적으로 무엇을 제외할지, 다음 투자를 정당화할 사용자 증거가 무엇인지 정합니다. 그래서 브리프는 문서 작업이 아니라 첫 번째 제품 결정입니다.
창업자는 시장 설명 몇 단락과 기능 목록, 제품의 미래를 말하는 한 문장을 담은 아이디어 설명서를 가져오는 경우가 많습니다. 대화를 시작하기에는 충분하지만 출시하기에는 부족합니다. 제작팀에는 야심을 검증 가능한 선택으로 바꾸는 더 작고 집중된 문서가 필요합니다.
유용한 브리프가 하는 세 가지 일
1. 문제를 겪는 사람을 구체화하기
소기업은 시장이지 첫 사용자가 아닙니다. 좋은 브리프는 그 사람과 상황, 그리고 오늘 사용하는 임시 해결책을 구체적으로 적습니다. 내일 예약을 취소할 병원 관리자가 겪는 문제와 새 예약을 찾는 환자의 문제는 다릅니다. 첫 사용자를 구체화할수록 다음 제품 결정을 내리기 쉬워집니다.
2. 첫 버전의 경계를 정하기
기능 목록은 사람들이 상상한 것을 말하지만 범위의 경계는 실제로 만들 것을 말합니다. 핵심 순환을 한 문장으로 쓰고, 그것을 안정적으로 작동시키는 화면·의미 있는 행동·데이터·성공을 알려 주는 피드백을 적으세요. 나머지는 출시 요구사항이 아니라 이후 후보입니다.
3. 다음 증거를 정의하기
출시 후 지켜보겠다는 말은 학습 계획이 아닙니다. 처음 몇 주에 관찰할 완료된 흐름, 반복 행동, 결제 전환 또는 특정 사용자와의 인터뷰를 정하세요. 복잡할 필요는 없지만 다음 제품 결정을 바꿀 만큼 실제 행동에 가까워야 합니다.
화면을 디자인하기 전에 적을 것
- 첫 사용자: 역할, 상황, 고통스러운 임시 해결책
- 핵심 순환: 가치를 만들고 반복할 수 있는 최소 행동
- 출시 범위: 첫 버전에서 명확히 제외할 내용
- 신뢰 요구사항: 사용자가 행동하기 전에 보고 통제하고 이해해야 할 것
- 다음 검증 지점: 한 차례 더 만들 가치가 있는 행동이나 대화
우리가 사용하는 범위 테스트
제안한 기능을 하나씩 살펴보며 묻습니다. 이 기능이 첫 사용자에게 핵심 순환이 성공할 가능성을 높이는가? 아니라면 첫 버전에서 제외합니다. 가능하다면 보호하는 가설을 쓰고 더 저렴하게 검증할 방법을 찾습니다. 이렇게 하면 유용한 기능이 제품을 영원히 미루는 핑계가 되는 것을 막을 수 있습니다.
브리프의 목표는 만들 수 있는 모든 것을 기록하는 것이 아니라 다음 제작 결정을 한눈에 보이게 하는 것입니다.
— 실무 규칙: a rule we use in product kickoffs
자주 묻는 질문
MVP 브리프는 얼마나 길어야 하나요?
한 번에 읽을 수 있을 만큼 짧고 선택을 내릴 만큼 구체적이어야 합니다. 첫 사용자, 핵심 순환, 출시 범위, 신뢰 요구사항과 다음 검증 지점을 정했다면 보통 한두 페이지면 충분합니다.
완전한 기능 목록을 브리프에 넣어야 하나요?
핵심 순환에 필요한 기능만 넣고 나머지는 이후 아이디어로 분리하세요. 보류 목록은 좋은 아이디어를 보존하면서 출시 요구사항으로 몰래 변하는 것을 막습니다.
목표 사용자가 아직 확실하지 않으면 어떻게 하나요?
가장 유력한 두 후보와 둘을 구분할 증거를 적으세요. 불확실성은 명확하게 드러나면 유용하지만 넓은 범위 속에 숨으면 비용이 커집니다.
디자인 전에 브리프를 완성해야 하나요?
첫 디자인을 이끌 만큼 명확해야 하지만 영원히 고정할 필요는 없습니다. 디자인이 더 나은 질문을 제시할 수 있으므로, 바뀔 때마다 범위와 모으려는 증거를 함께 갱신하세요.