오늘의 핵심 배움
오늘 배운 내용은 크게 네 가지였다.
- 모든 기획은 How가 아니라 Why에서 시작해야 한다.
- PM의 의사결정은 직관이 아니라 데이터와 비즈니스 임팩트로 설명되어야 한다.
- 커뮤니케이션은 좋은 말솜씨가 아니라, 주장과 근거를 연결해 동료를 납득시키는 과정이다.
- 좋은 프로젝트는 킥오프와 회고를 통해 시작과 끝을 시스템으로 관리해야 한다.
오늘의 수업을 들으면서 PM에게 중요한 것은 단순히 기획서를 잘 쓰는 능력이 아니라, 문제의 원인을 찾고, 판단 기준을 세우고, 팀이 같은 방향으로 움직이도록 만드는 능력이라는 생각이 들었다.
⸻
1. 모든 기획의 시작은 How가 아니라 Why다
기획을 할 때 가장 먼저 물어야 하는 것은 “어떻게 만들 것인가?”가 아니라 “왜 이 일을 해야 하는가?”다.
Why가 먼저 정리되지 않으면, What과 How는 쉽게 흔들린다.
겉으로 보이는 현상만 보고 바로 해결책을 정하면, 실제 문제를 해결하지 못할 가능성이 높다.
예를 들어 일정이 지연되고 있을 때 단순히 “팀의 속도가 느리다”고 판단하면 해결책도 “더 빨리 하자” 정도에 머무를 수 있다. 하지만 한 단계 더 들어가서 “왜 느린가?”를 묻다 보면, 실제 원인은 자료 미비나 의사결정 지연, 지원 부족일 수 있다.
즉 PM은 표면적인 현상에서 멈추지 않고, 근본 원인을 찾는 질문을 계속해야 한다.
내가 이해한 것
기획의 시작은 해결책을 빨리 내는 것이 아니라, 왜 이 문제를 풀어야 하는지 충분히 납득하는 것이다.
Why가 분명해야 결과물의 방향도 흔들리지 않는다.
⸻
2. 직관이 아니라 데이터와 비즈니스 임팩트로 의사결정하기
PM에게 주어진 문제와 데이터는 그 자체로 정답이 아니다.
중요한 것은 데이터를 맥락 안에서 해석하는 것이다.
예를 들어 앱스토어의 별점 1점짜리 리뷰는 단순한 불만 모음이 아니다. 이를 “실시간 정보 오류”, “위젯 기능 요청”, “사용성 불편”처럼 분류하고 정량화하면, 실제 사용자 니즈를 파악하는 중요한 단서가 된다.
또한 프레임워크를 사용할 때도 주의가 필요하다.
AARRR처럼 유명한 프레임워크를 쓴다고 해서 자동으로 좋은 분석이 되는 것은 아니다. 우리 서비스 맥락에 맞는 지표인지, 그 지표가 실제 문제를 설명하는지 확인해야 한다.
우선순위를 정할 때도 마찬가지다.
예를 들어 앱 크래시와 결제 에러가 동시에 발생했다면, 결제 에러도 중요하지만 앱 크래시는 모든 유저의 진입 자체를 막기 때문에 더 큰 비즈니스 임팩트를 가진다. 따라서 먼저 해결해야 할 문제는 앱 크래시다.
내가 이해한 것
PM의 판단은 “느낌상 이게 더 중요해 보여서”가 아니라, 사용자 영향 범위와 비즈니스 임팩트로 설명되어야 한다.
데이터는 숫자를 보여주는 도구가 아니라, 더 나은 판단을 하기 위한 근거다.
⸻
3. 논리와 공감으로 이끌어내는 커뮤니케이션
PM은 정답이 없는 상황에서 최선의 선택을 하고, 그 선택을 동료들이 납득할 수 있도록 설명해야 한다.
이때 중요한 것은 주장과 근거를 분리하는 것이다.
예를 들어 “UX를 개선해야 합니다”는 주장이다.
이 주장이 설득력을 가지려면 “최근 사용자 피드백의 45%가 어렵다고 응답했습니다”와 같은 근거가 함께 있어야 한다.
또한 커뮤니케이션은 논리만으로 끝나지 않는다.
마케팅팀은 빠른 출시를 원하고, 개발팀은 더 많은 개발 시간이 필요할 수 있다. 이때 PM은 어느 한쪽의 입장만 선택하는 것이 아니라, 각 팀의 관점을 이해하고 현실적인 타협점을 찾아야 한다.
예를 들어 초기 버전은 핵심 기능 위주로 먼저 출시하고, 추가 기능은 후속 버전에 반영하는 식으로 조율할 수 있다.
갈등 상황에서는 감정적으로 대응하기보다, 사실 관계와 목표를 기준으로 논의를 다시 정렬하는 것이 중요하다.
내가 이해한 것
PM의 커뮤니케이션은 단순히 말을 잘하는 것이 아니다.
근거로 설득하고, 상대의 관점을 이해하며, 팀이 움직일 수 있는 합의점을 만드는 것이다.
⸻
4. 프로젝트의 시작과 끝을 시스템으로 관리하기
좋은 기획은 문서를 잘 쓰는 것에서 끝나지 않는다.
프로젝트의 시작과 끝을 어떻게 관리하는지도 중요하다.
- 킥오프
킥오프에서는 프로젝트의 목표, 범위, 마일스톤, 역할을 명확히 공유해야 한다.
특히 In/Out 범위를 정하는 것이 중요하다.
무엇을 이번 프로젝트에서 다루고, 무엇은 다루지 않을지 정하지 않으면 중간에 범위가 계속 넓어질 수 있다.
킥오프가 잘 되어야 팀원과 이해관계자의 기대치가 맞춰지고, 일정 지연이나 혼선을 줄일 수 있다.
- 회고
프로젝트가 끝난 뒤에는 회고가 필요하다.
회고는 누군가를 비난하거나 자책하기 위한 시간이 아니다.
KPT나 4Ls 같은 회고 방식을 활용해 잘한 점, 아쉬운 점, 다음에 시도할 점을 정리하고, 구체적인 액션 아이템으로 연결해야 한다.
예를 들어 “일정이 늦어졌다”에서 끝나는 것이 아니라,
“다음 스프린트 플래닝 때 예상 공수를 더 구체적으로 산정하자”처럼 다음 행동으로 이어져야 한다.
내가 이해한 것
프로젝트를 잘한다는 것은 시작 전에 기대치를 맞추고, 끝난 뒤에는 배움을 남기는 것이다.
즉 PM은 프로젝트의 생애주기를 관리하는 사람이다.
⸻
오늘의 한 줄
PM은 좋은 아이디어를 내는 사람이라기보다, 왜 이 문제를 풀어야 하는지 정의하고, 데이터로 판단하며, 팀이 같은 방향으로 움직이도록 만드는 사람이다.
⸻
앞으로 적용할 것
앞으로 과제나 프로젝트를 할 때는 아래 네 가지를 꼭 확인하고 싶다.
오늘 배운 내용은 기획 문서를 작성할 때뿐 아니라, 팀 프로젝트를 운영할 때도 계속 적용해야 할 기본기라고 느꼈다.
