실제로 내보낼 수 있는 첫 출시의 범위를 정하는 법

여덟 달이 걸린 첫 버전은 팀이 느려서인 경우가 드뭅니다. 거의 언제나, 처음부터 살아남을 수 없는 범위가 "덜어내기는 비관적으로 보이는" 회의실에서 합의되었기 때문입니다.

범위를 정하는 건 기술이고, 그 대부분은 모두가 아직 낙관적일 때 무엇을 만들지 않을지 정하는 기술입니다.

하나의 루프에서 시작하세요

모든 제품에는 핵심 루프가 있습니다. 사용자가 반복하며 가치를 전달하는 일련의 동작이죠. 사전이라면 검색하고, 읽고, 이해하기. 마켓플레이스라면 등록하고, 발견하고, 거래하기.

자기 루프를 한 문장으로 적으세요. 그런 다음 제안된 모든 기능을 두 더미로 나눕니다. 루프가 성립하는 데 반드시 필요한 것과 나머지 전부.

두 번째 더미는 거의 언제나 예상보다 네다섯 배 크고, 일정이 사라지는 곳이 바로 거기입니다. 그 기능들이 나빠서가 아니라, 어느 것도 하중을 지지 않는데 전부 일정에 들어 있었기 때문입니다.

"MVP"는 더 이상 의미가 없다

이 말은 이제 양립하지 않는 두 가지를 덮습니다. 의도적으로 작지만 한 가지 일은 정말 잘하는 제품, 그리고 넓지만 엉성하게 만든 제품. 대부분의 팀이 실제로 내보내는 건 후자이고, 그것이 실패하는 이유는 사용자가 좁은 제품은 용서해도 고장 난 제품은 용서하지 않기 때문입니다.

더 쓸모 있는 표현은 좁고 완결된입니다. 개수는 적게, 각각은 오류 상태와 빈 상태까지 제대로. 한 가지 일을 끝까지 하는 첫 버전은 두 번째 출시의 자격을 얻습니다. 여덟 가지 일을 60%로 하는 첫 버전은 얻지 못합니다.

덜어낼 것은 범위이지 품질이 아닙니다. 품질을 덜어내면 계획서에서는 보이지 않고 사용자에게는 아주 잘 보입니다.

보통 덜어내도 되는 것

필수처럼 보이지만 거의 언제나 기다릴 수 있는 것들:

• 계정. 그것 없이도 가치가 성립한다면. 가입은 대부분의 퍼널에서 가장 큰 이탈 지점입니다. 먼저 쓰게 하고, 저장할 가치가 있는 상태가 생기면 그때 넣으세요.
• 관리자 화면. 여러분은 사용자가 아닙니다. 데이터베이스 클라이언트나 스크립트로 몇 달은 버팁니다.
• 설정 항목. 설정 하나하나가 구현도 테스트도 필요한 분기입니다. 합리적인 기본값을 고르고, 요청이 오면 토글을 넣으세요.
• 온보딩 흐름. 튜토리얼은 대개 명확하지 않은 화면에 붙인 반창고입니다. 화면을 먼저 고치세요.
• 두 번째 플랫폼. 웹 다음 모바일, 또는 한쪽 모바일 다음 다른 쪽. 동시에 하면 작업량은 두 배가 넘고 피드백 속도는 절반이 됩니다.
• 다국어. 특정 시장이 곧 출시 시장인 경우가 아니라면. 아직 모양이 바뀌는 제품을 번역하는 건 다시 번역한다는 뜻입니다.

덜어내면 안 되는 셋

이것들을 덜어내는 건 속도처럼 보이지만 이자가 높은 빚입니다.

1. 순조롭지 않은 경로

오류 상태, 빈 상태, 로딩 상태, 오프라인. 작업량의 약 5분의 1이고 체감 품질의 대부분입니다. 실패를 우아하게 다루는 제품은 작아도 단단해 보입니다. 문제가 생기면 흰 화면을 띄우는 제품은 순조로운 경로가 아무리 좋아도 고장 나 보입니다.

2. 측정

분석 없이 내보내면 첫 버전은 아무것도 가르쳐 주지 않습니다. 어디가 쓰이는지, 사람들이 어디서 멈추는지, 루프가 닫히는지 알 수 없습니다. 데이터 웨어하우스가 필요한 게 아니라, 핵심 루프가 완료되는지와 어디서 끊기는지를 알면 됩니다.

3. 빠르게 배포할 수 있는 능력

수정 하나 내보내는 데 손으로 하루가 걸린다면 수정을 덜 내보내게 됩니다. 그런데 출시 직후 몇 주가 바로 수정이 가장 중요한 시기입니다. 기본 파이프라인은 이틀 작업이고 첫 두 주에 본전을 뽑습니다.

계층이 아니라 사용자 여정으로 자르세요

가장 흔한 계획 실수는 수평으로 만드는 것입니다. 데이터 모델 전부, 다음 API 전부, 다음 화면 전부. 전부가 동작하기 전에는 아무것도 동작하지 않고, 끝날 때까지 아무것도 배우지 못합니다.

대신 수직으로 자르세요. 얇지만 진짜인 경로 하나를 끝에서 끝까지 만들고, 그다음 넓히세요. 둘째 주면 눌러 볼 수 있는 것이 생깁니다. 그러면 대화가 "제품을 상상하기"에서 "그것에 반응하기"로 바뀌고, 쓸모 있는 피드백은 후자에 있습니다.

현실적인 형태

초점이 잡힌 첫 출시라면 대략:

좁고 완결된 것으로 총 8~16주. 넓은 것을 6주에 하겠다는 계획이라면 틀린 쪽은 추정이 아니라 범위입니다.

덜어낸 것을 적어 두세요

비용이 없으면서 되풀이되는 논쟁을 막는 습관: "v1에 넣지 않음" 목록을 모두가 볼 수 있게 명시적으로, 항목마다 한 줄 이유를 붙여 유지하는 것입니다.

이것은 "깜빡했다"를 "결정했다"로 바꾸고, 같은 기능이 매달 다시 논의되는 걸 막으며, 그대로 v2 백로그가 됩니다. 게다가 맥락이 가장 충분했던 그 논의 순서대로 이미 정렬되어 있죠.

좋은 범위의 검사

질문 둘, 둘 다 "예"여야 합니다.

• 이것만 만들면 누가 쓸까요? 아니라면 하중을 지는 것을 덜어낸 겁니다.
• 지금 있는 시간 안에, 순조롭지 않은 경로까지 포함해 제대로 만들 수 있나요? 아니라면 더 덜어내세요.

대부분의 계획은 두 번째에서 떨어지는데, 10주 차까지 아무도 그 말을 하지 않습니다.