당신의 로드맵은 지금 '변명'인가요, '판단'인가요?

• 로드맵이 아쉽게 끝나는 건 괜찮아요. 그 아쉬움을 설명하는 언어가 다음 분기를 결정합니다.

• 계획대로 안 된 회고 자료를 쓸 때, 늘 나오는 단골 문장들이 있습니다. "이해관계자 요청 때문에", "개발이 지연돼서", "비즈니스 우선순위가 변경되어서". 다 맞는 말이지만, 이 언어에만 머물면 다음 분기에도 똑같은 변명을 반복하게 됩니다.

외부 귀인 (External Attribution)
실패나 문제의 원인을 외부 요인에서 찾는 심리적 경향. 반대는 내부 귀인으로, "내 판단이 틀렸다"는 방향입니다. 본문에서 계속 등장하는 그 찜찜한 감각이 바로 외부 귀인과 내부 귀인 사이 어딘가에 걸려있는 거예요.

계획 오류 (Planning Fallacy)
심리학자 대니얼 카너먼이 정의한 인지 편향. 미래 계획을 세울 때 소요 시간과 리소스를 낙관적으로 과소 추정하는 경향을 말합니다. 개인의 실수가 아니라 인간이 계획을 세울 때 구조적으로 갖는 편향이에요.

Output vs. Outcome
Output은 만들어낸 것(기능, 페이지, 배포 횟수), Outcome은 그 결과로 실제로 바뀐 것(사용자 행동, 비즈니스 지표)이에요. 우선순위 변경을 설명할 때 Output 기준으로 말하면 "못 만들었다"가 되고, Outcome 기준으로 말하면 "더 큰 임팩트를 선택했다"가 됩니다. 같은 결정이 완전히 다르게 읽혀요.

회고 자료에서 매번 반복되는 그 문장들

분기 회고 자료를 열면 어김없이 등장하는 문장들이 있어요.

"이해관계자 요청으로 우선순위가 변경되었습니다."

"개발 일정이 예상보다 지연되었습니다."

"비즈니스 우선순위 변경으로 방향을 조정하였습니다."

틀린 말이 하나도 없고, 실제로 그랬을 거예요. 근데 이 문장들을 쓰고 나면 왜 항상 찜찜할까요?

그 찜찜함의 정체는 외부 귀인이에요. 원인을 외부에서 찾는 순간, 나는 설명을 마친 것처럼 느끼지만 실제로는 아무것도 배우지 못한 채 다음 분기로 넘어가게 됩니다.

오해하지 않으셨으면 해요. 대부분의 로드맵은 잘 돌아가요. 이 이야기는 분기 전체가 실패했다는 게 아니라, 아쉽게 마무리된 그 한두 개의 프로젝트를 어떻게 설명하느냐에 대한 이야기입니다.

우선순위 변경은 사실 자연스러운 일이에요

비즈니스 우선순위가 바뀌는 건 이상한 게 아니에요. 시장 상황, 경영진 판단, 고객 피드백, 경쟁사 움직임에 따라 분기 중간에 얼마든지 바뀔 수 있고, 오히려 그 변화에 기민하게 반응하는 게 PM의 역할이죠.

진짜 질문은 이거예요. 그 변경이 왜 타당했는지 설명할 수 있나요?

두 PM의 이야기를 비교해보면 확 와닿으실 겁니다.

타 부서 요청으로 A 기능 배포가 무산되었습니다.
→ A보다 B의 비즈니스 임팩트가 더 크다고 판단하여 리소스를 전환하였습니다.

개발팀 일정 지연으로 런치 일정이 밀렸습니다.
→ 초기 계획 때 지나치게 낙관적으로 추정했습니다. 다음 분기에는 x%의 버퍼를 고려하겠습니다.

경영진의 지시로 로드맵이 전면 수정되었습니다.
→ 비즈니스 방향성 변화 신호를 바탕으로 가설을 업데이트하여 로드맵에 반영하였습니다.

전자는 외부에서 일어난 일의 피해자가 된 느낌이지만, 후자는 PM의 주도적인 판단과 결정이 들어간 언어입니다. 이 판단의 기준이 명확히 쌓여야 다음 분기 계획을 더 잘 세울 수 있습니다.

변명의 질이 다음 계획의 질을 결정해요

회고가 단순히 "왜 안 됐나"를 정리하는 문서로 끝날 때, 다음 분기 로드맵은 거의 비슷하게 짜입니다. 같은 리스크를 다시 안고, 3달 뒤에 똑같은 변명을 하겠죠.

반면 회고에서 이런 질문이 추가되면 달라져요.

• 우선순위를 변경했다면: 그 변경의 기준이 무엇이었나요? 다음 분기에도 같은 상황이 오면 같은 기준으로 판단할 수 있나요?

• 개발 일정이 밀렸다면: 구조적으로 지나치게 희망회로를 돌린 것은 아닌가요? 다음 분기 추정에는 어떻게 보완할 수 있나요?

• 이해관계자의 요청이 갑자기 등장했다면: 그 요청이 나올 것을 미리 예측하거나 커뮤니케이션으로 조율할 수는 없었나요?

이 질문들은 자책이 아닙니다. 아쉬운 결과를 다음 분기의 더 나은 판단으로 전환하는 작업이에요.

아쉬움을 성공으로 재해석하는 방법

우선순위 변경으로 중단된 프로젝트가 꼭 실패는 아니에요. 더 큰 비즈니스 임팩트를 위해 의식적으로 내린 결정이라면, 그건 오히려 좋은 판단일 수 있어요.

여기서 Output과 Outcome의 언어가 중요해져요. "A 기능을 못 만들었다"(Output 기준)가 아니라 "A보다 B가 이 시점에 더 높은 Outcome을 만들 수 있다고 판단했다"로 설명할 수 있을 때, 변경은 변명이 아니라 선택이 됩니다.

그 판단을 다음 분기 로드맵에 명시적으로 녹여보세요. 예를 들어 이런 방식으로요.

"지난 분기 A는 B로 우선순위가 조정됐습니다. B는 [비즈니스 임팩트 기준]에서 더 높은 Outcome이 예상됐고, 실제로 [결과]로 이어졌습니다. A는 3분기에 다시 검토합니다."

이렇게 쓰면 중단된 프로젝트가 미완성이 아니라 의도된 선택이 됩니다. 팀도, 이해관계자도 로드맵을 단순한 계획서가 아니라 PM의 판단이 담긴 '가설 기반 로드맵'으로 신뢰하게 됩니다.

상반기 회고를 마무리하고 있다면, 아쉬웠던 프로젝트 하나를 골라 이 질문을 추가해보세요.

"이 변경은 어떤 판단 근거로 이루어졌나요? 그리고 그게 3분기 계획에 어떻게 반영되어 있나요?"

이 두 줄만 추가해도 회고는 단순한 결과 정리에서 다음 분기를 위한 판단 기록으로 바뀝니다.

여기까지 읽으면 "현실적으로 빠르게 움직이는 조직에서 매번 이걸 어떻게 다 문서화하나요?", "안 그래도 남 탓 하기 바쁜 문화인데 이런 걸 쓰면 내 무덤 파는 거 아닌가요?"라는 생각이 드실 수 있습니다.

맞습니다. 심리적 안정감이 없는 조직에서는 이런 언어가 오히려 독이 될 수 있죠.

이 글에서 말하는 건 전사 공유용 문서에 반성문을 쓰라는 게 아닙니다. 보고서에는 원래대로 방어적으로 쓰시더라도, 'PM 본인의 비밀 노트'에는 진짜 솔직한 복기를 하셔야 한다는 의미입니다. 내 눈으로 신호를 놓친 건 없는지, 내 판단 기준은 무엇이었는지 스스로에게 솔직해지는 것부터 시작해 보세요.

로드맵은 원래 늘 아쉬움을 남깁니다. 그 아쉬움을 어떤 언어로 해석하느냐가 3분기 계획의 진짜 출발점입니다.

당신의 로드맵은 지금 변명으로 마무리되고 있나요, 아니면 다음 판단의 재료가 되고 있나요.