PM이 결정(decision)을 하는 방법
PM에게 요구되는 것 중 하나는 '결정을 잘 내리는 것'이다.
하지만 모든 결정을 똑같은 방식으로 내릴 수는 없다.
내가 PM 일을 하면서 느낀 건, 결정에는 세 가지 종류가 있다는 것이다.
빠른 결정
함께 하는 결정
시점을 늦추는 결정
상황마다 어떤 결정을 해야 할지를 구분하는 것, 그게 진짜 '결정을 잘한다'는 의미가 아닐까 생각한다.
1. 빠른 결정: 속도가 필요할 때
가끔은 아무리 토론해도 결론이 나지 않는 순간이 온다. 특히 개발자와 디자이너 사이에서 교통정리가 안 될 때, 결국 나를 찾아오는 경우가 많았다.
"어떻게 할까요?"
"둘 다 가능할 것 같은데, 방향을 정해 주세요."
그럴 땐 빠르게 결정하려고 한다.
긴 논의로 모두가 에너지를 잃기 전에, PM이 먼저 에너지를 내고 방향을 잡는다. 속도를 잃는 것보다, 작은 시행착오가 훨씬 낫기 때문이다.
빠른 결정은 실수할 수도 있다. 하지만 대부분은 실수를 빠르게 고칠 수 있다. 회의가 길어지는 것보다는 훨씬 좋은 결과를 만든다.
2. 함께 하는 결정 : 긴 호흡의 일을 진행할 때
반면, 시간이 걸리더라도 함께 만드는 게 좋은 결정도 있다. 예를 들어 새로운 데이터 모델을 설계하거나, 백엔드와 클라이언트 간 처리 방식을 정할 때. 이런 결정은 단순히 PM이 답을 내려선 안 된다.
개발자, 디자이너, 때로는 운영팀까지 함께 고민해야 한다.
내가 경험한 건, 결정을 함께 내린 사람은 콘텍스트를 훨씬 오래 기억한다는 점이다.
PM이 바빠서 자리에 없더라도, 개발자나 디자이너가 다른 사람에게 "이건 우리가 이래서 이렇게 만든 거야"라고 대신 설명해 줄 수 있다.
3. 시점을 늦추는 결정: 더 좋은 순간을 기다리기
때로는, 지금 당장 결정을 내리는 것보다 조금 더 나은 순간을 기다리는 것이 더 좋은 선택일 때가 있다.
특히 눈에 보이지 않는 문제를 놓고 개발자들이 설루션을 요청할 때 자주 마주친다.
그럴 때 나는 종종 이렇게 제안한다.
"일단 구현하고, 이 문제는 제품이 돌아가는 걸 보고 다시 결정하시죠."
이건 단순히 결정을 '미루는 것'이 아니다. '지금'이라는 불확실한 순간에 억지로 답을 내기보다는, 좀 더 명확한 조건이 갖춰졌을 때 결정하자는 협상이다.
막연한 추측으로 내린 결정은 나중에 제품이 돌아가면서 무력해질 때가 많다.
실제로 구현을 해보면, 우리가 심각하게 고민했던 부분이 사실은 아예 고민할 필요가 없었던 문제였던 경우가 많았다.
PM이 결정을 하는 방법은 여러 가지가 있지만,
결정 그 자체보다, 언제 빠르게 결정해야 할지 알고, 언제 함께 만드는 결정을 해야 할지 구분하고, 언제 시점을 늦추는 것이 더 좋은지 판단하는 것이라고 생각한다.
