요즘 고민들 중 하나는 IT 회사에서 PM 업무를 가장 효과적으로 수행하기 위해 제품의 기술적 디테일을 어느 깊이까지 이해해야 하는지, 적절한 균형점은 어디에 있는지에 대한 것이다. 3개월 전, PM으로서 팀 내 중복 업무를 최소화하기 위해 "how"에 대한 고민을 줄이고 "why"와 "what"에 더 많은 시간을 쓰고자 한다는 취지의 글을 쓴 적이 있다. 그러나 요즘엔 다시 "how"에 대한 이해가 충분하지 않다면 과연 PM으로서 다른 function들의 존중을 얻고 매일 최적의 의사결정을 내릴 수 있을지에 대한 의문이 커지고 있다. 스스로의 말을 번복하는 것처럼 느껴져 이 글을 쓰는 것이 망설여지기도 했지만, 몇달전부터 나는 다시 개발자 분들과 함께 "how"의 영역까지 깊이 파고들어 진지하게 고민하고 있다. 그렇지 않고서 효과적인 PM 역할을 수행하는 것이 가능한지 스스로에게 묻게 된다.
물론 PM으로서 최우선 순위의 업무는 여전히 "무엇을 왜" 만들어야 하는지에 대한 방향성을 정립하는 일이라고 생각한다. 그래서 포커스는 항상 비즈니스의 성공과 고객의 만족도에 있어야 하고 이 영역에서도 나는 아직 충분히 성장할 여지가 많다. 최근에 기획하고 런칭한 몇몇 기능들을 회고해보면, 가슴에 손을 얹고 생각했을 때 정말 정말 필요했던 기능이었는지, 고객들과 한 번 더 한 레벨 더 깊이 이야기해볼 수는 없었는지, 혹은 비즈니스 임팩트를 더 엄격하게 검증했어야 했던 것은 아닌지에 대한 아쉬움이 남기도 한다 (너무 낙관적이었던 경우들이 많다).
그럼에도 불구하고 이 와중에 꽤 많은 시간을 "how"에 대한 고민에까지도 할애하고 있는 이유는, 그래야 외부적으로 무엇을 약속할 수 있고 내부적으로 어디까지 책임질 수 있는지가 명확해지기 때문이다. 첫 직장에서 조직의 시니어 디렉터가 늘 강조하던 원칙이 하나 있었는데, 다소 진부하게 들릴 수는 있지만 “always underpromise and overdeliver”였다. 그 대상이 서비스를 사용하는 엔드유저이든, 함께 일하는 내부 스테이크홀더이든 상관없이 이 원칙을 오랫동안 지속적으로 지켜나간다면 성공의 가능성은 자연스럽게 우상향한다는 취지였다. 반대로 한두번이라도 "overpromise and underdeliver"를 한다면 신뢰 자산을 잃는 것은 순식간이라고 하셨다.
그리고 무엇을, 그리고 어디까지 약속할 수 있는지를 판단하려면 필연적으로 제품이 만들어지는 공정 전반을 꽤 깊이 이해해야 한다고 요즘 느낀다. 모든 업무의 공정 방향성을 개발 조직에 전적으로 위임만 해버리면, 결과 산출물의 퀄리티가 어느 범위에서 형성될지, 업무 타임라인을 어떻게 산정해야 할지, 나아가 "mis/under-delivery"를 유발할 수 있는 리스크들에 대한 감각이 흐려질 수밖에 없다. 이는 결국 “overpromise and underdeliver”로 이어질 위험을 크게 키우며, 이런 일이 반복되면 개인이든 팀이든, 혹은 제품이든 관계없이 신뢰라는 자산을 조금씩 서서히 잃게 된다고 생각한다.
경험이 더 쌓이면 이런 고민들이 자연스럽게 해결될지도 모르고, 경험치가 더 많은 노련한 선배들에겐 훨씬 더 효율적인 노하우가 이미 있을지도 모르겠다. 하지만 적어도 지금 내 앞에 놓인 일들을 제대로 해내기 위해서는, 시간을 더 들여 제품 공정에 대한 이해도를 깊이는 수밖에 없다고 느낀다. 짜투리 시간을 내서 기술 문서를 읽고, 데이터를 보고, 코드를 뜯어보고 아키텍쳐링도 고민해보고, 이것이 과연 장기적으로 확장 가능하고 지속 가능한 방식인지는 아직 스스로도 확신이 없다. 그럼에도 불구하고, 현재 내 역량 수준에서 지금 맡은 역할과 책임을 다하기 위해서는 선택할 수 밖에 없는 방향이라고 느낀다.