제품 출시
출시는 발표가 아니다. 발표는 가장 싼 부분이며, 전체로 오해되기 가장 쉬운 부분이다. 이것이 바로 기능이 언론에는 보도되지만 채택되지 않는 이유다.
출시 전에 등급을 설정하라
모든 것이 동일한 대우를 받을 필요는 없으며, 모든 것을 메이저(major)로 처리하면 팀과 청중의 관심이 소진된다.
- Tier 1 — 제품에 대한 이야기를 바꾸거나 새로운 세그먼트를 연다. 전체 모션: 포지셔닝 작업, 언론, 영업 지원, 고객 커뮤니케이션, 캠페인.
- Tier 2 — 기존 고객에게 의미 있는 변화이나 새로운 이야기는 아니다. 제품 내 발표, 문서, 관련 계정에 대한 알림, 영업 브리핑.
- Tier 3 — 개선. 릴리스 노트 외에는 없다.
작업을 시작하기 전에 등급을 합의하고, 그것을 구축한 사람이 Tier 1 쪽으로 끌리는 경향을 예상하라. 등급 이상으로 쓰이는 노력은 다른 곳(보통 다음 출시)에서 빼온 것이다.
발표 전에 내부 준비 순서를 정하라
순서가 중요하며, 자주 뒤집힌다. 지원팀과 영업팀이 발표를 통해 알게 된 다음, 출시 주간 내내 제대로 브리핑받지 못한 질문에 답변하느라 시간을 낭비한다.
외부에 나가기 전에: 문서가 존재하고, 지원팀이 주요 질문에 답할 수 있으며, 영업팀이 누구를 위한 것인지와 누구를 위한 것이 아닌지 알고, 가격 및 패키징이 결정되고 구성되어 있으며, 먼저 시도할 계정에서 작동하는지 확인하라.
팀 외부의 누군가가 처음부터 그 기능을 사용해 보게 하라. 팀은 더 이상 최초 실행 경험을 볼 수 없으며, 그 경험이 다른 모든 사람이 받는 경험이다.
누구를 위한 것인지 결정하고, 누구를 위한 것이 아닌지 말하라
모든 사람을 대상으로 한 출시는 아무에게도 닿지 않는다. 세그먼트, 해결하는 문제, 그리고 그들에게 무엇이 바뀌는지 이름을 붙이고 — 누가 아직 사용하지 말아야 하는지 명시적으로 말하라. 그렇지 않으면 영업팀이 묻는 사람에게 모두 팔 것이고, 최초 고객은 가장 적합하지 않은 고객이 될 것이다.
이유 있는 날짜를 선택하고, 날짜보다 기준을 지켜라
출시 날짜는 이벤트, 분기, 또는 약속에 의해 설정된다. 무엇이 정해지든, 출시에 필요한 기준(품질 기준, 문서, 지원 준비 상태)을 기록하고 그것들을 진짜 게이트(gate)로 취급하라.
지원 준비 전에 출시하는 것은 일주일을 아끼는 가장 비싼 방법이다. 그 비용은 그 기능에 가장 관심 있는 고객에게 나쁜 첫인상으로 남는다.
출시 당일뿐 아니라 이후도 계획하라
대부분의 출시 계획은 출시일에 끝나지만, 실제 작업은 그때부터 시작된다. 후속 작업을 일정에 넣어라: 첫 번째 물결을 놓친 사람들을 위한 두 번째 물결, 시도하지 않은 사용자를 위한 제품 내 프롬프트, 적합한 계정에 대한 아웃리치, 지원팀에 도착하는 질문 확인.
첫 번째 지원 티켓을 주의 깊게 관찰하라. 그것들은 출시가 무엇을 잘못했는지에 대한 가장 빠른 신호이며, 대시보드가 움직이기도 전에 도착한다.
채택을 측정하고, 발표를 측정하지 마라
도달률, 노출수, 언론 보도는 발표를 측정한다. 중요한 것은 의도된 사람들이 그 기능을 사용하는지, 그리고 로드맵이 주장한 대로 작동하는지 여부다.
출시 전에 숫자를 결정하라 — 어떤 계정 중 몇 개가, 무엇을 하고, 언제까지. 사후에 선정된 참여 지표로 평가된 출시는 항상 성공이며, 아무것도 가르쳐주지 않는다.
절대 하지 말아야 할 것
- 지원팀과 영업팀이 명백한 질문에 답할 수 있기 전에 외부에 발표하지 마라.
- 팀이 자랑스러워서 Tier 3 변경사항에 Tier 1 모션을 실행하지 마라.
- 모든 사람에게 출시하는 것이 영향을 줄이는 것처럼 느껴진다고 해서 청중을 좁히지 마라.
- 목표가 채택이었을 때 출시 성공을 도달률로 보고하지 마라.