런치 플랜

기능을 켰는데 아무 일도 일어나지 않는 출시가 있습니다. 코드는 예정대로 올라갔고 동작도 잘 하는데, 그 사실을 아는 사람이 만든 팀뿐이라 첫 주 사용자가 30명에서 멈춥니다. 몇 달을 들여 만든 것이 조용히 묻히는 셈입니다.

반대로 어긋나서 망가지는 경우도 흔합니다. 안내 메일이 기능이 켜지기 세 시간 전에 나가 링크를 누른 사람들이 빈 화면을 봅니다. 영업이 고객에게 다음 주 공개라고 말한 날 아침에 이미 공개돼 있기도 합니다. 각 팀이 자기 일정만 들고 움직이면 이런 일이 분기마다 반복됩니다.

두 경우 모두 원인은 같습니다. 출시는 한 팀의 일이 아닌데 그 시점을 한 장에 모아 둔 문서가 없었던 것입니다. 만드는 쪽은 배포 날짜를, 마케팅은 콘텐츠 일정을, 영업은 고객 미팅을 각자 들고 있었습니다. 런치 플랜은 그 흩어진 시점을 하나의 시간 축 위에 얹어, 무엇이 먼저 나가고 무엇이 뒤따르는지를 미리 정해 둡니다.

한 장짜리 문서에 날짜와 담당자가 붙은 항목이 줄줄이 들어갑니다. 여섯 묶음이 기본입니다.

1. 기준 시각. 공개일과 시간을 한 줄로 못 박습니다. 나머지 모든 항목의 날짜가 이 시각을 기준으로 잡히므로 여기가 흔들리면 문서 전체가 무의미해집니다.
2. 할 말. 이번 출시를 어떤 문장으로 알릴지 정합니다. 한 줄 요약과 세 가지 핵심 가치가 메시징 문서에서 내려옵니다. 메시징은 제품을 설명하는 핵심 문구를 체계로 정리해 둔 문서입니다. 여기서 새로 지어내지 않고 가져다 쓰는 것이 원칙입니다.
3. 내보낼 것과 날짜. 블로그 글, 안내 메일, 소개 페이지, 제품 안 공지, 보도자료, 웨비나가 각각 언제 나가는지 적습니다. 순서가 중요합니다. 제품이 켜진 다음에 메일이 나가야 하고, 소개 페이지는 메일보다 먼저 살아 있어야 합니다.
4. 사전 안내 대상. 공개 전에 따로 알릴 사람들입니다. 베타로 써 본 고객, 계약 규모가 큰 고객, 파트너, 기자가 여기 들어갑니다. 큰 고객이 공지 메일로 처음 소식을 듣게 두면 담당 영업이 곤란해집니다.
5. 내부 준비. 영업이 쓸 자료를 넘기는 세일즈 인에이블먼트와 응대 팀을 학습시키는 내부 인에이블먼트가 공개일 며칠 전에 끝나 있어야 합니다.
6. 판정. 무엇을 보고 잘됐다고 할지 미리 적습니다. 첫 2주 안에 유료 팀의 30퍼센트가 한 번이라도 켜 보기, 소개 페이지 방문 5000건 같은 식으로 숫자와 기한을 붙입니다.

준비가 끝났는지를 확인하는 목록은 런치 체크리스트가 따로 맡습니다. 체크리스트가 됐는지 안 됐는지를 묻는다면 런치 플랜은 언제 누가 내보내는지를 정합니다. 둘을 한 문서에 섞으면 준비 항목에 밀려 날짜가 흐려집니다.

쓰는 사람은 제품 마케터이고, 그 자리가 없는 팀에서는 프로덕트 매니저나 그로스 담당자가 맡습니다. 항목을 혼자 채우지는 않습니다. 블로그 글은 콘텐츠 담당이, 제품 안 공지는 개발이, 고객 미팅 일정은 영업이 채웁니다. 소유자가 하는 일은 날짜들이 서로 맞물리는지 확인하고, 하나가 밀렸을 때 뒤따르는 것들을 같이 옮기는 것입니다.

읽는 쪽은 마케팅과 영업과 고객 응대와 개발입니다. 각자 자기 줄만 보면 되도록 쓰는 것이 좋습니다. 공개일을 0일로 두고 앞뒤로 날짜를 세는 형태가 흔합니다. 14일 전에 사전 안내 대상을 확정하고, 7일 전에 영업 자료를 넘기고, 당일 아침에 기능을 켜고 오후에 메일을 보내고, 7일 뒤에 숫자를 확인하는 식입니다.

한 번 쓰고 덮어 두는 문서가 아닙니다. 공개 전까지 매주 한 번씩 열어 밀린 줄을 옮깁니다. 기준 시각이 일주일 밀리면 나머지 열다섯 줄이 전부 따라 밀리는데, 그 조정을 아무도 하지 않으면 메일만 원래 날짜에 나갑니다.

"런치 플랜에 웨비나 날짜가 아직 안 잡혀 있는데 누가 정하나요?"

문서의 빈 줄을 채울 담당자를 찾는 말입니다.

"공개일이 일주일 밀렸으니 런치 플랜 전체를 뒤로 당겨 주세요."

기준 시각이 바뀌었으니 딸린 날짜를 모두 조정하자는 요청입니다.

"이번 건은 사전 안내 대상에 엔터프라이즈 고객 12곳 넣었습니다."

공개 전에 따로 연락할 계정을 확정했다는 보고입니다.

페이지덱이 문서 이력 기능을 내놓을 때 현우가 이 문서를 맡았습니다. 공개일을 화요일 오전 10시로 잡고, 2주 전에 베타로 써 본 30개 팀과 규모가 큰 고객 12곳을 사전 안내 대상으로 확정했습니다. 1주 전에 수아에게 영업 자료와 가격 설명을 넘기고, 공개 당일에는 제품 안 공지를 먼저 띄운 다음 오후 2시에 안내 메일을 보냈습니다.

메일을 아침이 아니라 오후로 미룬 이유가 있습니다. 오전에 기능이 켜지고 나서 두 시간 동안 이상이 없는지 보고, 문제가 있으면 메일을 세우려던 것입니다. 실제로 지난 분기에는 그 두 시간 사이에 오류가 발견돼 메일을 하루 미뤘습니다. 3주 뒤 고객 사례 한 편이 나가는 일정까지 같은 문서에 들어 있었습니다.

공개 날짜를 정하는 문서로 읽는 경우가 가장 많습니다. 첫 줄이 날짜라서 그렇게 보입니다. 날짜는 나머지 열다섯 줄을 걸어 두는 못일 뿐이고, 실제 내용은 그 못에 무엇을 어떤 순서로 거는지입니다. 날짜만 정하고 나머지를 비워 두면 공개 당일에 고객 문의가 들어오는데 응대 팀이 그 기능을 처음 듣는 상황이 그대로 재현됩니다.

공개일로 끝나는 계획이라고 보는 것도 흔합니다. 출시라는 말 자체가 한 시점을 가리키니 자연스러운 오해입니다. 그런데 사람들이 새 기능을 알아차리는 데는 시간이 걸려서, 첫날 한 번 알린 것으로는 대부분이 모르고 지나갑니다. 그래서 공개 후 2주에서 4주를 계획 안에 넣습니다. 2주 뒤 후속 콘텐츠, 3주 뒤 고객 사례, 4주 뒤 숫자 점검이 들어가야 합니다. 이 구간을 비워 두면 출시 당일에만 반짝 오른 숫자가 셋째 주에 원래대로 돌아옵니다.