지표 체크인을 포함한 릴리스 회고 진행하기

출시는 12일이 아니라 12주에 걸쳐 성숙한다

대부분의 출시 회고는 2주 안에 이뤄집니다. 그때는 데이터가 얇고 팀의 감정적 투자도 아직 강합니다. Amplitude의 지표 연구와 The Pragmatic Engineer의 출시 후 분석 글은 모두, 정말 보고 싶은 신호인 6주 차 리텐션, 12주 차 수익화, 누적 참여도는 첫 2주 안에는 보이지 않는다고 말합니다. 2주, 6주, 12주의 세 번 체크인은 서로 다른 신호를 맞는 시점에 포착하게 합니다.

지표 체크인을 포함한 릴리스 회고 진행하기 프롬프트가 작동하는 방식

이 프롬프트는 2주, 6주, 12주에 세 번의 회고를 배치합니다. 처음에는 활성화 중심 질문, 중간에는 참여도, 마지막에는 지표가 충분히 익은 뒤 비즈니스 임팩트를 다룹니다. "원래 메모의 어떤 가설이 틀렸는가"라는 출력은 학습을 명시적으로 기록하게 만듭니다. 잘못된 가설을 인정하지 않는 출시는 다음 팀을 위한 축적된 지혜를 남기지 못합니다.

사용 시점

• 의미 있는 기능이 1~4주 전에 출시되었습니다.
• 출시 모멘텀은 높지만 성숙한 회고가 아직 잡혀 있지 않습니다.
• 이전 출시가 후속 점검 없이 성공으로 선언되었지만 실제로는 아니었습니다.
• 새 PM이 팀에 합류하며 최근 출시의 구조화된 인수인계가 필요합니다.
• 이사회가 출시 결과 데이터를 요구하는데 아무도 집계하지 못했습니다.

흔한 함정

• 2주짜리 단일 회고. 2주 데이터는 대부분의 실제 신호를 보기엔 너무 얇습니다. 잘못된 결론에 도달하게 됩니다.
• 메모 인수인계 없음. 팀은 다음 일로 넘어가고, 기억은 희미해지고, 다음 팀은 같은 교훈을 다시 배웁니다. 12주 메모를 남기세요.
• 활성화만 측정. 활성화 회고만으로는 리텐션을 놓칩니다. 참여도 회고만으로는 수익화를 놓칩니다. 세 번 모두 필요합니다.

출처

• Amplitude Blog — Amplitude
• The North Star Framework — Amplitude
• The Pragmatic Engineer — Gergely Orosz
• Sprint Retrospectives — Atlassian