제품 결정 기록: 가설, 지표, 되돌릴 조건을 함께 남기는 법

어느 제품 팀이 반년 전에 가입 단계를 다섯에서 셋으로 줄였다고 해 봅시다. 지금 누군가 묻습니다. “그때 왜 줄였죠? 그래서 좋아졌나요?” 회의록에는 “가입 단계 축소 결정”이라는 한 줄만 남아 있습니다. 무엇을 기대하고 정했는지, 무엇이 달라지면 성공인지, 누가 언제 확인하기로 했는지는 어디에도 없습니다. 결정은 남았는데 배움은 남지 않았습니다.

제품 결정은 대부분 “이렇게 하면 사용자가 이렇게 움직일 것이다”라는 가설입니다. 이 글에서는 결정을 내릴 때 가설, 확인할 지표, 되돌릴 조건을 함께 적어 두고, 때가 되면 닫는 방법을 정리합니다.

제품 결정은 무엇이 다른가

일정이나 범위, 담당을 정하는 프로젝트 결정은 내린 뒤 그대로 실행하는 것이 대부분입니다. “출시일을 다음 달 첫 주로 한다”고 정하면 그대로 실행하면 됩니다. 기록할 것은 무엇을 왜 정했는가입니다.

제품 결정은 내린 순간에 시작됩니다. “가입 단계를 줄이면 가입을 마치는 사람이 늘 것이다”는 출시하고 사용자가 움직여 봐야 맞았는지 알 수 있습니다. 두 가지가 다릅니다.

• 불확실합니다. 결정하는 시점에는 결과를 모릅니다. 아무리 조사를 해도 사용자가 실제로 어떻게 움직일지는 내놓아 봐야 압니다.
• 배움이 목적에 들어 있습니다. 틀린 결정도 왜 틀렸는지 알면 다음 결정의 재료가 됩니다. 맞았는지 틀렸는지 확인하지 않은 결정은 맞았더라도 남는 것이 없습니다.

그래서 제품 결정의 기록에는 “무엇을 정했나”에 더해 “무엇을 믿고 정했나”, “무엇을 보면 알 수 있나”, “언제 물러서나”가 들어가야 합니다. 결과가 나온 뒤에 적으면 이미 아는 결과에 맞춰 기억이 바뀝니다. 결정하는 날 적는 것이 핵심입니다.

결정 기록의 여섯 칸

표는 가로로 밀어서 볼 수 있습니다.

실제로 써 보면 기준값과 되돌릴 조건이 비어 있기 쉽습니다. 기준값 없이 “가입 완료율 개선”이라고만 적으면 조금만 올라도 성공이라고 말하게 됩니다. 되돌릴 조건은 좋아지길 바라는 숫자가 아니라 그 변경 때문에 나빠질 수 있는 숫자로 정합니다. 한쪽을 올리려는 변경은 흔히 다른 쪽을 건드리기 때문입니다.

예시 두 개

아래는 지어낸 예약 서비스의 예이고, 숫자도 설명을 위해 지어낸 것입니다.

예시 1: 가입 단계 줄이기

표는 가로로 밀어서 볼 수 있습니다.

예시 2: 알림 기본값 바꾸기

표는 가로로 밀어서 볼 수 있습니다.

두 번째 예시의 “숫자 근거는 없음”처럼 근거가 약하면 약하다고 적습니다. 약한 근거로 정한 것이 잘못은 아닙니다. 약했다는 것을 나중에 알 수 없는 것이 문제입니다.

확인할 때가 오면: 셋 중 하나로 닫기

확인할 때가 되면 기록을 열어 셋 중 하나로 닫습니다.

• 맞음: 기준값을 채웠고 되돌릴 조건에 걸리지 않았습니다. 결과 숫자와 함께, 가설의 “왜냐하면”도 맞았는지 한 줄 적습니다. 숫자는 올랐는데 이유가 달랐던 경우가 있습니다.
• 틀림: 기준값에 못 미쳤거나, 기준값은 채웠지만 되돌릴 조건에 걸렸습니다. 되돌릴지 그대로 둘지 정하고, 가설의 어느 부분이 틀렸다고 보는지 적습니다. 이 한 줄이 다음 결정의 재료입니다.
• 모름: 숫자가 애매하거나, 같은 때 다른 변경이 함께 나가 무엇 때문인지 가릴 수 없습니다. 숫자가 결정 뒤에 움직였다고 해서 결정 때문에 움직인 것은 아닙니다. 모름도 정직한 결과입니다. 왜 알 수 없었는지 적고, 더 볼지 그만 볼지 정합니다.

닫을 때 지킬 것은 하나입니다. 기준값을 결과에 맞춰 고치지 않습니다. 결과를 알고 나면 자기 판단이 맞았다는 쪽의 숫자부터 눈에 들어옵니다. 확증 편향입니다. 58%가 나왔는데 “사실 55%면 충분했다”고 고치면 기록은 쓸모를 잃습니다. 기준이 잘못됐다고 생각하면 그 생각을 닫을 때 「알게 된 것」에 적습니다.

팀이 기록을 읽게 만드는 법

쓰기만 하고 읽지 않는 기록은 오래가지 못합니다.

• 지표를 보는 자리 가까이에 둡니다. 대시보드나 출시 기록에서 바로 열리게 이어 두면, 숫자를 보다가 그 숫자를 움직이려던 결정을 함께 읽게 됩니다.
• 확인할 때를 달력에 올립니다. 기록을 쓰는 날 확인할 사람의 달력에 일정을 넣습니다. 기억에 맡기면 확인하지 않게 됩니다.
• 정기 회의에서 닫습니다. 격주나 월간 제품 회의의 첫 순서를 “이번에 확인할 때가 온 결정”으로 둡니다. 5분이면 됩니다.
• 새 결정을 쓸 때 옛 기록을 찾아봅니다. 서식 맨 위에 “비슷한 결정이 전에 있었나” 한 줄을 두면, 같은 가설을 두 번 시험하는 일이 줄어듭니다.
• 틀림을 탓하지 않습니다. 틀림으로 닫은 사람이 불이익을 받으면 다음부터는 솔직하게 닫기 어려워집니다.

문구 하나를 고치는 일까지 여섯 칸을 채우면 기록이 짐이 됩니다. 사용자 행동이 달라지길 기대하고 내리는 결정, 되돌리는 데 품이 드는 결정부터 시작합니다.

바로 쓰는 서식 한 장

제품 결정 기록 번호:          쓴 날:
비슷한 결정이 전에 있었나:

결정(한 문장):
믿은 가설(이렇게 하면 누가 어떻게 움직일 것이다, 왜냐하면):
근거가 된 관찰(없으면 없음):
확인할 지표:          지금 값:          기준값:
확인할 때:
되돌릴 조건(지켜야 할 숫자와 선):
정한 사람:          확인할 사람:

닫은 날:          결과: 맞음 / 틀림 / 모름
결과 숫자:
알게 된 것(한두 줄):
다음에 할 일:

• 결과를 보기 전에 기준값을 적었습니다
• 되돌릴 조건을 좋아지길 바라는 숫자와 다른 숫자로 정했습니다
• 확인할 때를 확인할 사람의 달력에 올렸습니다
• 확인할 때가 오면 맞음, 틀림, 모름 가운데 하나로 닫았습니다
• 닫으면서 기준값을 고치지 않았습니다
• 알게 된 것을 한두 줄로 적었습니다

제품 결정 기록은 결정을 잘했다는 증거를 남기는 문서가 아닙니다. 무엇을 믿었는지 적어 두고, 그 믿음이 맞았는지 확인하는 문서입니다. 여섯 칸을 결정하는 날 채워 두면, 반년 뒤의 질문에 기억이 아니라 기록으로 답할 수 있습니다.

참고

• PMBOK® 지침서 8판 한국어판, 2.1.6.7.1 측정의 함정. 확증 편향, 상관관계와 인과관계를 가려 읽는다는 생각과 용어만 따랐습니다. 문장은 옮기지 않았습니다.
• PMI와 PMBOK은 Project Management Institute의 등록 상표입니다.
• 그 밖에는 참고 자료 없이 직접 썼습니다. 가설을 세우고 확인하는 생각, 되돌릴 조건으로 지켜야 할 숫자를 따로 두는 생각(실험 분야에서 흔히 가드레일 지표라고 부름)은 널리 알려진 일반 개념으로 서술했습니다. 본문의 예약 서비스와 숫자는 설명을 위해 지어낸 예입니다.
• 가설을 세우는 방법은 이 블로그의 「문제 정의와 가설 검증」 글을 함께 보세요.