PM 포트폴리오, 만든 기능보다 먼저 선택한 이유를 보여주세요

기획한 화면과 출시 기능은 많은데, 내가 어떤 판단을 했는지 설명하기 어렵나요? 서비스 기획자·PM·PO 포트폴리오에 기능 목록을 더 넣기 전에 ‘무엇과 비교해서 이 일을 먼저 했는가’를 보여주는 기록 하나를 붙여보세요.

완성 화면 앞에 당시의 선택지를 놓아요

출시된 기능만 보면 다른 대안이 있었는지 알 수 없습니다. 같은 목표를 놓고 검토한 후보와 제약을 함께 적어야 선택 이유가 드러나요. 뒤늦게 떠올린 좋은 대안은 ‘당시 검토안’이 아니라 ‘회고 중 발견한 대안’으로 구분합니다.

우선순위 점수는 답이 아니라 설명의 시작

Atlassian의 제품 관리 지침은 프레임워크로 논의를 구조화하되, 점수의 이유와 팀이 가진 정보를 함께 보도록 안내합니다. 우선순위도 학습에 따라 다시 검토합니다. 따라서 포트폴리오에 점수표를 넣는다면 어떤 기준과 자료로 채웠는지 설명하세요. 근거 없는 점수를 만든 뒤 객관적인 분석 결과처럼 보이게 할 필요는 없습니다.

한 장으로 쓰는 결정 기록

아래는 폴리오쉽이 제안하는 작성 양식입니다.

• 목표·시점: 누구의 어떤 문제를, 언제까지 다루려 했나?
• 후보: 실제 비교한 선택지는 무엇이며 범위가 비슷했나?
• 기준: 기대 효과·투입 노력·선행 작업을 어떤 근거로 판단했나?
• 불확실성: 확인된 사실과 추정은 무엇이고 누가 검토했나?
• 선택·보류: 먼저 한 일과 미룬 일, 그 대가를 어떻게 설명했나?
• 내 역할: 자료 정리·제안·조율·최종 결정 중 무엇을 맡았나?
• 재검토: 어떤 정보가 생기면 순서나 범위를 바꾸기로 했나?

예약 서비스로 비교하는 가상 예시

목표를 ‘예약 취소 뒤 다음 행동을 이해하기 쉽게 하기’로 정했다고 가정해볼게요. 후보 A는 취소 안내 문구 정리, 후보 B는 직접 예약을 변경하는 기능입니다. 실제 서비스의 사례나 성과가 아닌 사고 연습입니다.

A는 안내를 다룰 수 있지만 변경 자체의 불편은 남습니다. B는 변경 과정을 다루지만 예약 가능 시간 확인 등 추가 설계가 필요할 수 있어요. A의 작은 문구 수정과 B의 전체 기능을 단순한 점수 하나로 비교하기 전에, 각각 어디까지 만드는지 범위부터 적어보세요.

B의 구현 노력이 아직 확인되지 않았다면 ‘높음’으로 확정하지 말고 확인할 질문으로 남깁니다. 이후 조사나 기술 검토에서 전제가 달라지면 선택도 바뀔 수 있어요. 이 예시에서 어느 후보가 정답인지는 정해져 있지 않습니다.

높은 점수인데도 미뤘다면 그 이유를 써요

선행 작업이 끝나지 않았거나, 효과 추정의 근거가 약했거나, 별도로 반드시 처리해야 할 과제가 있었다면 그 제약을 설명합니다. 결론에 맞추려고 과거 점수를 고치지 말고 ‘당시 판단’과 ‘이후 알게 된 사실’을 나누세요. 팀의 결정을 혼자 내린 것처럼 쓰지 않는 것도 중요합니다.

제출 전 확인할 세 가지

□ 선택한 안뿐 아니라 보류한 안의 장점과 남은 문제도 적었나요?

□ 예상 효과와 출시 후 실제 관측 결과가 구분되나요?

□ 내부 로드맵·고객 정보 없이 공개 가능한 판단 과정만 담았나요?

오늘은 대표 프로젝트 하나에서 ‘왜 이것부터 했나요?’라는 질문에 세 문장으로 답해보세요. 목표, 비교한 대안, 선택을 바꿀 조건이 들어가면 기능 목록에 없던 판단을 설명할 수 있습니다.

출처 및 편집

폴리오쉽 에디터 · 공식 에디토리얼

Atlassian · Prioritizing ideas ↗