제품팀 5명의 고민 vs 20명의 고민
PM, 디자이너, 모바일 개발자, 웹 개발자, 백엔드 개발자가 같은 공간에서 일을 하는 제품팀으로 시작해서
3개의 스쿼드가 있는 20명의 메이커 집단으로 사이즈가 커진 제품팀을 경험하고 있다.
지금 생각해 보니 5명이서 일하던 제품팀의 PM이 했던 고민과
현재 20명의 동료가 있는 제품팀 PM의 고민은 과장을 좀 보태면 하늘과 땅 차이로 다른 고민을 하고 있다.
예를 들면 이런 것이다.
첫 번째로는 5명이서 일 할 때는 붙이는 기능마다 새로 만드는 기능에다가 파트별로 1명씩 밖에 없기 때문에 자기 자신을 리뷰하고 결정에 대한 책임도 수습도 온전히 자기가 했다. 그래서 지금 내가 잘하고 있는 게 맞는지 고민을 많이 했던 것 같다. 그러다 그냥 고객에게 일단 답을 얻자는 마인드로 정말 2주 만에 이해관계자 커뮤니케이션까지 마쳐서 릴리즈를 했었다.
20명에서 일할 때는 새로 만드는 기능은 간혹 가다가 있고 이미 만들어진 기능의 문제를 발견하여 개선하는 일도 많다. 그리고 릴리즈 준비를 할 때도 파트 별로 코드를 리뷰한다거나 문제가 될 만한 부분이 없는지 내부에서 확인하는 단계가 추가되기도 했다. 처음에는 내가 잘하고 있는 게 맞는지 고민을 했다면 지금은 그 고민은 파트별로 대화하며 해소할 수 있고 내가 만든 제품의 퀄리티나 고객에게 문제 될 건 없는지, 파트별로 피드백을 받다가 릴리즈가 늦어지진 않는지를 피드백 루프를 더 간소화할 수 없는지를 고민하는 것 같다.
두 번째로는 운영 측면이다. 5명인 제품팀에서는 운영팀도 같은 방에 있어 우리가 하는 이야기와 결정을 같이 들어 커뮤니케이션을 따로 할 필요가 없었다. 반대로 고객의 VoC가 바로 들리기 때문에 운영팀에게 따로 물어보지 않아도 제품팀에서 바로 문제를 해결하는 경우도 종종 있었다.
하지만 제품팀이 20명으로 커졌다면 운영팀도 이전보다 사이즈가 커졌다. 이제 운영의 VoC는 따로 정리해서 들어야 하고 제품에서 간단한 기능을 만들어도 운영팀에게 전달할 문서를 따로 만들어야 하고 우리가 만든 기능을 CS 운영할 수 있도록 운영 요구사항도 다 준비가 되어야지 릴리즈가 가능하다. 이전에는 알아서 협업이 일어났다면 이제는 협업을 하기 위해 서로 맞춰줘야 할 게 생겼다.
마지막으로는 우리가 우리의 팀장(CPO 또는 CTO/리더 등의 이름이 있지만 공감 갈 수 있도록 팀장으로 부르겠다)에게 커뮤니케이션하는 방법도 좀 달라졌다. 5명일 때는 사무실에서 같은 모니터를 보며 떠오르는 생각이나 내가 얻은 정보를 모두 설명을 했지만 지금은 우리의 팀장도 중요한 많은 일을 다루기 때문에 피드백을 받는 회의를 잡아야 하고 팀장과의 커뮤니케이션 시간을 효율적으로 쓰기 위해 만들려는 제품의 디자인 프로토타입에 공을 많이 들이고 있다.
이렇게 쭉 쓰면 5명일 때가 더 나아보이기도 하지만 20명이 된 지금은 이전에 시도하지 못했던 사이즈가 큰 기능을 시도할 수 있으며(제품 기술 부채도 같이 해결 가능) 다른 서비스에게는 있지만 우리 제품만 없는 기능을 만드는 단계를 넘어서(여유가 생겼을 수도 있다) 사용자에게 정말 필요한 게 뭔지 우리 제품이 줄 수 있는 value가 뭔지를 고민하는 게 일상이 되었다. 서로의 파트에서 이야기 나눌 수 있는 동료가 있어 에너지 관리와 더 나은 결정을 할 수 있도록 안정감이 생겼고 각자의 경험을 공유하고 회고하는 좋은 문화도 생긴 것 같다.
5명일 때의 고민과 20명일 때의 고민은 다르지만 100명이 됐을 때 고민은 또 달라질 것이다.
그때의 내가 하게 될 고민이 무엇인지 궁금하다.
