오늘 한 일
어제는 ChatGPT를 구독했고, 오늘은 Claude를 구독했다.
Claude Code도 빠르게 살펴보면서 공식 quickstart 문서를 확인했다.
- Claude Code quickstart: https://code.claude.com/docs/ko/quickstart
오늘 PM 강의에서는 목표 수립과 문제 정의에 대해 배웠다.
특히 기억에 남은 내용은 이것이었다.
PM의 첫 번째 단계는 목표 수립이다.
프로덕트 비전 → OKR → KPI는 상위 목표에서 하위 지표로 이어져야 한다.
오늘 배운 내용을 내 이전 회사 경험과 연결해보니, 왜 당시 개발자로서 답답함을 느꼈는지 조금 더 명확하게 이해할 수 있었다.
1. PM의 첫 번째 단계는 목표 수립이다
PM의 일은 기능을 정하는 것에서 시작하지 않는다.
가장 먼저 해야 할 일은 우리가 무엇을 달성하려고 하는지 목표를 정의하는 것이다.
목표는 위에서 아래로 연결되어야 한다.
프로덕트 비전 → OKR → KPI
프로덕트 비전은 제품이 장기적으로 어디로 가야 하는지를 보여준다.
OKR은 그 비전을 달성하기 위한 일정 기간의 목표와 핵심 결과다.
KPI는 실제로 목표가 잘 달성되고 있는지 확인하기 위한 지표다.
이 흐름이 없으면 팀은 열심히 일해도 같은 방향으로 움직이기 어렵다.
2. 이전 회사에서 느꼈던 답답함
이전 회사에서는 상위 목표가 충분히 공유되지 않았던 경험이 있다.
그 결과 개발자로서 “왜 이 기능을 만드는지” 모른 채 구현에만 집중해야 했다.
예를 들어 이런 흐름이 있었다.
DAU, MAU가 감소했다.
그러니 매달 새로운 기능을 개발하자.
개발자 입장에서는 자연스럽게 이런 질문이 생겼다.
- 왜 매달 야근을 하면서 이 기능을 만들어야 하지?
- 우리의 제품 비전은 무엇이지?
- 이 기능이 그 비전과 어떻게 연결되지?
- DAU, MAU가 증가하면 정말 문제가 해결되는 걸까?
- 어느 정도 증가해야 목표를 달성했다고 볼 수 있을까?
그때는 이 질문들이 막연한 답답함처럼 느껴졌다.
하지만 오늘 강의를 듣고 나니, 이 답답함의 이유가 보였다.
상위 목표와 지표가 명확히 연결되지 않았기 때문에, 기능 개발이 문제 해결이 아니라 단기적인 대응처럼 느껴졌던 것이다.
강의에서 들은 문장처럼, 비전 없는 문제 해결은 단기적인 임시 방편이 될 수 있다.
3. PM이었다면 어떻게 했을까
만약 내가 PM이었다면 최소한 팀 레벨에서라도 이번 분기에 우리가 무엇을 달성해야 하는지 정의하고 공유했어야 한다고 생각한다.
예를 들어 단순히 “기능을 많이 만들자”가 아니라 다음과 같이 정리했어야 한다.
이번 분기의 목표는 유저가 앱에 더 오래 머물 이유를 만드는 것이다.
그다음 이 목표를 지표로 연결해야 한다.
- 평균 체류시간
- 재방문율
- 주요 콘텐츠 소비율
- 커뮤니티 참여율
- 인앱 결제 전환율
이렇게 목표와 지표가 연결되어야 팀원들도 “왜 이 기능을 만드는지” 이해할 수 있다.
기능은 목표를 달성하기 위한 수단이지, 그 자체가 목표가 되어서는 안 된다.
4. 문제 정의에는 상위 목표가 필요하다
오늘 공부하면서 또 하나 크게 느낀 점은, 문제 정의를 하려면 먼저 상위 목표가 있어야 한다는 것이다.
문제란 단순히 불편한 현상이 아니다.
문제는 목표 달성을 방해하는 것이다.
따라서 목표가 없으면 무엇이 문제인지도 명확히 말하기 어렵다.
예를 들어 “유저가 앱에 오래 머물지 않는다”는 현상이 있다고 해도, 우리 목표가 체류시간 증가인지, 결제 전환 증가인지, 커뮤니티 활성화인지에 따라 문제 정의가 달라진다.
그래서 PM은 문제를 정의하기 전에 먼저 물어야 한다.
우리는 무엇을 달성하려고 하는가?
지금 발견한 현상은 그 목표를 어떻게 방해하는가?
5. 문제 정의할 때는 현상, 영향, 원인을 구분해야 한다
오늘 배운 내용 중 가장 실무적으로 와닿았던 것은 문제 정의에서 현상, 영향, 원인을 구분해야 한다는 점이었다.
이전 회사 경험에 대입해보면 다음과 같다.
목표
유저가 앱에 더 오래 머물도록 한다.
현상
유저가 앱에 오래 머물지 못하고 금방 이탈한다.
영향
사용자 관점에서는 앱 안에서 할 게 없다고 느끼고, 다른 게임이나 서비스로 이탈할 수 있다.
비즈니스 관점에서는 체류시간이 감소하고, 인앱 결제 기회가 줄어들며, 결과적으로 매출 하락으로 이어질 수 있다.
원인
앱 내에서 유저가 지속적으로 즐길 콘텐츠가 부족했다.
앱의 핵심 기능 중 하나였던 커뮤니티는 KLPGA 경기가 있을 때만 활성화되었다. KLPGA 경기는 1년 중 약 9개월 정도 열리고, 그중에서도 주로 목요일부터 일요일 사이에 진행된다.
즉 비시즌이나 경기가 없는 평일에는 유저가 앱에 들어올 이유가 충분하지 않았다.
이렇게 구분하니 문제가 훨씬 선명해졌다.
유저가 앱에 오래 머물지 않는다.
에서 끝나는 것이 아니라,
경기 일정에 의존적인 콘텐츠 구조 때문에, 비시즌과 경기 없는 평일에 유저가 앱에 방문할 이유가 부족하다.
까지 내려갈 수 있었다.
이 정도로 원인이 선명해지면 가설도 자연스럽게 이어진다.
만약 비시즌에도 유저가 소비할 수 있는 콘텐츠를 제공한다면, 앱 체류시간과 재방문율이 증가할 것이다.
이 흐름이 강의에서 배운 “만약 ~하면, ~할 것이다” 형태의 가설 수립과 연결된다.
6. 해결방안을 미리 정해두고 문제를 정의하면 안 된다
문제를 정의하기 전에 해결방안을 먼저 정해두면, 진짜 원인을 놓칠 수 있다.
예를 들어 사용자가 “텍스트가 작아서 읽기 어렵다”고 말한다고 해서 바로 글씨를 키우는 것이 정답은 아닐 수 있다.
먼저 확인해야 할 질문이 있다.
- 이 불편을 느끼는 사용자는 누구인가?
- 시니어 사용자에게만 발생하는가, 전체 사용자에게 발생하는가?
- 어떤 텍스트에서 문제가 발생하는가?
- 해당 텍스트는 중요한 의사결정에 필요한 정보인가?
- 정말 글씨 크기 문제인가, 아니면 색상 대비나 위치 문제인가?
즉 PM은 사용자의 말을 그대로 해결방안으로 바꾸는 사람이 아니라, 그 말 뒤에 있는 원인을 파악해야 한다.
이전 회사 경험에서도 비슷한 일이 있었다.
아이템 구매율이 감소했다.
그러니 새로운 아이템 패키지를 팔자.
하지만 이 접근은 원인을 확인하기 전에 해결방안을 먼저 정한 것이다.
구매율이 감소한 이유는 가격 때문일 수도 있고, 아이템 매력도가 낮아서일 수도 있고, 노출 위치가 문제일 수도 있고, 유저가 이미 충분히 보유하고 있어서일 수도 있다.
원인을 확인하지 않고 새 패키지만 추가하면, 문제는 해결되지 않을 가능성이 크다.
7. 개발자의 디버깅 사고와 PM의 문제 정의는 닮아 있다
오늘 흥미로웠던 점은, 개발자의 디버깅 사고방식과 PM의 문제 정의 방식이 본질적으로 닮아 있다는 점이었다.
개발자는 버그가 발생했을 때 바로 코드를 고치기보다 먼저 묻는다.
왜 이 버그가 발생했지?
어느 지점에서 값이 잘못 들어갔지?
재현 조건은 무엇이지?
근본 원인은 무엇이지?
PM도 마찬가지다.
왜 이 문제가 발생했지?
어떤 사용자에게 발생하지?
어떤 목표를 방해하지?
표면 현상 아래의 원인은 무엇이지?
개발자는 코드의 문제를 디버깅하고, PM은 사용자 경험과 비즈니스 문제를 디버깅한다.
이렇게 생각하니 개발자로서의 경험이 PM 전환에 도움이 될 수 있다는 확신이 조금 생겼다.
오늘의 한 줄
비전 없는 문제 해결은 단기적인 임시 방편이 될 수 있다.
PM은 기능을 만들기 전에 우리가 무엇을 달성하려는지, 지금 문제가 그 목표를 어떻게 방해하는지부터 정의해야 한다.
⸻
앞으로 적용할 것
앞으로 PM 과제나 프로젝트를 할 때는 바로 해결방안으로 들어가지 않고, 아래 순서로 먼저 정리해보고 싶다.
- 이 제품의 비전은 무엇인가?
- 이번 기간의 목표는 무엇인가?
- 이 목표를 확인할 KPI는 무엇인가?
- 현재 보이는 현상은 무엇인가?
- 이 현상이 사용자와 비즈니스에 어떤 영향을 주는가?
- 원인은 무엇인가?
- 이 원인을 바탕으로 어떤 가설을 세울 수 있는가?
이 순서를 지키면 “기능을 많이 만드는 PM”이 아니라, 목표와 문제를 연결해 더 나은 판단을 하는 PM에 가까워질 수 있을 것 같다.
