우당탕탕 일잘러로 거듭나기
담당하는 프로덕트의 어느 단계에 위치하는지, 어떤 산업군인지에 따라 기대하는 임팩트는 달라질 수 있다. 그럼에도 불구하고, PM에게 핵심적으로 요구되는 역할은 동일한 것 같다고 생각한다.
오늘은 여러 차례 시행착오를 통해 배워온, 일을 '잘'하기 위한 한 끗에 대해 정리해 보았다.
복잡한 문제도 단순하게
PM이 다루는 문제는 결코 단순하지 않다. 하나의 지표라도 그 이면에는 수많은 의사 결정과 시장의 변화, 예측할 수 없는 변수들이 얽혀 있다.
이 가운데 ‘진짜 문제’가 무엇인지를 찾고 단순화하는 것이 PM의 역할이라 생각한다. 해결하고자 하는 문제가 복잡한 상태로 존재한다면, 솔루션이 여러 방향으로 분산되기 쉽고 난이도 또한 높아진다. 동시에 아래와 같은 문제들이 발생하기 쉽다.
1) 가설을 명확히 설정하기 어렵다.
: 하나의 문제가 존재하는 상태가 아니기에, 어쩌면 당연한 일이다.
2) 팀원들을 설득하기 어렵다.
: 문제와 가설 간의 논리성이 떨어지기 쉽기에, 해석의 방향성이 분산되고 설득이 어렵다.
3) 문제 해결 이후의 임팩트가 불분명하다.
: 해결하고자 하는 문제가 명확하지 않은 상태이기에, 어떤 임팩트가 있을지를 상상하기 어렵다.
위와 같은 문제들을 해소하지 못한 상태라면, 프로젝트가 마무리된 후에도 찜찜한 마음이 들기 마련이다.
하나의 문제처럼 느껴지더라도 세분화하여 펼쳐보고, 비약이 존재하지 않는지에 대해 점검해야 한다.
진짜 불편함을 발견하기
PM에게 가장 중요한 역량 중 하나는 문제 정의다. 하지만, 프로젝트를 진행하다 보면 무의식적으로 솔루션을 먼저 정해두고 이에 맞춰 문제를 정의하는 실수를 범하기 쉽다.
'신규 기능을 추가하면 사용자들이 좋아하지 않을까?', '이렇게 개선한다면 더 편리해지지 않을까?' 같은 공급자의 시선에서 비롯된 생각들.
이처럼 답을 정해둔 상태로 문제를 찾게 되는 경우, 사용자가 겪고 있는 핵심 문제를 놓치기 쉽고, 솔루션을 정당화하기 위한 표면적인 문제에 집중하기 쉽다.
하지만 PM은 문제를 찾아내는 사람임을 늘 기억해야 한다. 사용자의 경험을 관찰하고, 데이터 이면의 이야기를 듣고, 다양한 가설에 대한 검증이 선행되어야 한다.
“어떤 문제를 해결할까?”가 아니라, “사용자는 지금 무엇이 불편할까?”에 집중하는 일. 단순하게 느껴지지만 가장 어려운 일이다. 하지만 확실한 문제를 발견한 순간, 이후의 방향성이 명확해지고 프로덕트의 성장도 자연스럽게 따라온다는 것을 실감한다.
PM의 의사결정에서 가장 중요한 기준 중 하나는 "어느 정도의 임팩트를 낼 수 있는가?"이다.
제한된 리소스와 정해진 일정 속에서 가장 임팩트 있는 솔루션을 찾아야 하기에, 한 번에 여러 가지 문제를 해결하고 싶어지는 것은 어쩌면 당연한 욕심일지 모른다. 위에서 언급한 것처럼, 단순화되기 전의 복잡한 문제를 마주하고 있는 상황이라면 더더욱.
하지만 모든 문제를 동시에 해결할수록, 가장 중요한 단 하나의 문제조차 제대로 풀지 못하는 상황에 빠지기 쉽다. 최소한의 단위로 문제와 솔루션을 설정하는 것이 특히 중요한 이유다.
여러 실험이 동시다발적으로 진행되거나, 문제가 명료하게 정의되지 않은 상태에서 프로젝트가 진행되는 경우 결과 해석이 어려울 뿐만 아니라, 혼재된 인사이트로 인해 이후의 액션을 수립하는 데에도 혼란이 컸다.
여러 시행착오를 통해, 최소한의 문제를 정의하고 차근차근 풀어내는 것이 장기적으로 더 큰 임팩트를 내는 방법임을 깨달았다.
단계적으로 나아간다는 것은 어쩌면, 태스크 간의 우선순위를 명확하게 인지하고 있으며 현재 프로덕트에 필요한 것을 알고 있다는 의미가 아닐까 싶기도 하다.
상황이 아닌 토픽을 제시하기
PM은 결코 혼자서 프로덕트를 만들어 갈 수 없다.
디자이너와 함께 플로우를 설계하고, 개발자와 함께 이를 구현하고 마케터와 함께 제품을 판매해야 한다. 따라서 모두가 동일하게 문제를 인지할 수 있도록, 간결하고 명확하게 소통하는 것이 특히 중요하다.
1. 특정 전환율이 n%까지 내려갔네요
: 그래서 뭐?
2. 전환율이 n%까지 내려갔네요. ~한 상황이라, ~를 시도해 보면 좋을 것 같습니다.
: 오. ~한 관점에서도 고민해 볼 법한 부분인 것 같은데, 피드백드려야지.
명확한 소통이란 상대방이 "이 사람이 하고 싶은 말이 뭐지?"라는 생각을 하지 않도록 하는 것이다. 이를 방지하기 위해, 나의 해석을 기반으로 하나의 아젠다를 제시해 보자. 단순히 특정 문제 상황이나 지표를 전달하는 데 그치지 않고, 그 상황에 대한 분석과 솔루션을 함께 제안하는 커뮤니케이션은 더 임팩트 있는 솔루션으로 발전하기도 쉽다.
읽기 편한 형태로 전달하기
여러 사람이 동시에 메시지를 올리는 슬랙 채널을 보다 보면, 수신자를 배려한 커뮤니케이션 방식이 무엇인지를 체감할 수 있다. 동료들의 뛰어난 커뮤니케이션을 보며, 내가 배운 점들을 정리해 보면 아래와 같다.
- 전달자의 사고 과정이 자연스럽게 인지되도록
- 문제 상황과 액션 아이템이 명확히 구분되도록
- 나의 제안 사항과 요청 사항이 명확히 인지되도록
더불어, 프로덕트를 함께 만들어가는 스쿼드에게 안정감을 주는 것이 매우 중요하다는 점을 매번 깨닫는다. 성과나 노고에 대한 감사를 전하는 일 뿐만 아니라, 함께 일을 만들어가는 과정에 있다는 것을 실감할 수 있도록 하는 것 또한 누군가에게는 안정감을 주는 중요한 요소가 될지 모른다.
PM으로서 가장 어렵다고 느끼는 부분은 사용자와 비즈니스 모두를 만족시키는 일이다. 결국 프로덕트의 존재 이유는 사용자의 불편을 해결하기 위한 것이지만, 비즈니스의 성공에도 서포트해야 한다는 것. 두 가지 니즈를 스마트하게 해결하는 방법에 대한 고민을 가장 많이 하는 요즘이다.
하나의 태스크, 프로젝트, 프로덕트. 그리고 비즈니스까지. 생각의 범위가 넓어진다는 것은 어쩌면 성장의 반증이 아닐까 - 하는 생각으로 글을 마무리한다.