첫 번째 PM으로 제품 만들기: 맨땅에서 시작한 이야기

 

아무것도 없는 곳에서 시작한다는 게 어떤 느낌일까요

처음 회사에 첫 번째 프로덕트 매니저로 합류했을 때, 솔직히 막막했어요. 참고할 만한 프로세스도 없고, 정립된 기준도 없고, 심지어 유저 세그먼트 분석 같은 기본 데이터도 없었거든요. 그냥 백지 상태였어요.

그런데 지나고 보니, 이게 오히려 큰 기회였더라구요. 아무도 가지 않은 길을 제가 직접 만들어갈 수 있다는 거니까요. 물론 처음에 그걸 기회라고 느끼기까지는 꽤 시간이 걸렸지만요.

지난 2년 반 동안 제품 조직을 처음부터 만들어오면서 깨달은 게 하나 있어요. 대부분의 프로덕트 매니지먼트 이론이나 프레임워크는 이미 탄탄한 기반이 갖춰진 조직을 전제로 하고 있다는 거예요. OKR도, Jobs-to-be-Done도, RICE 스코어링도 전부 "우리가 이미 어느 정도 알고 있다"는 가정 위에 서 있어요. 진짜 맨땅에서 시작할 때는 그런 전제가 전혀 통하지 않아요. 오늘은 제가 제로부터 제품 조직을 세우면서 배운 진짜 이야기를 나눠볼게요.

---

PM의 시대가 오고 있어요, 그래서 더 복잡해요

요즘 제품 관리 시장이 엄청나게 성장하고 있다는 건 다들 체감하실 거예요. 최근 통계에 의하면 전 세계 제품 정보 관리 시장 규모는 2024년 약 447억 달러 수준에서 2032년까지 연평균 21.1%씩 성장할 것으로 전망된다고 해요. 프로젝트 관리 소프트웨어 시장도 2025년 기준 93억 달러를 넘었고, 2035년까지 약 392억 달러에 이를 것으로 예측되고 있어요. 연평균 성장률이 12.8%니까 꽤 가파르죠.

그만큼 PM이라는 역할에 대한 기대치도 높아지고 있고, 각종 방법론이나 프레임워크도 쏟아지고 있어요. 근데 여기서 함정이 생겨요. 시장이 커질수록, 그리고 PM이라는 직함이 익숙해질수록 사람들은 "당연히 이런 거 알겠지?"라고 전제하거든요. 초기 조직에서 일하는 분들이 가장 많이 겪는 어려움이 바로 여기서 비롯돼요.

---

프레임워크보다 먼저 할 일: 그냥 듣기

저는 처음 회사에 합류한 몇 주 동안은 아무것도 만들지 않았어요. 대신 팀 전체와 1대1 미팅을 했어요. 합의를 만들려는 게 아니라, 내가 아직 보지 못한 것들을 그들이 무엇을 관찰하고 있는지 이해하려는 목적이었어요.

그때 가장 유용했던 질문이 딱 두 가지였는데요. "우리의 가장 큰 문제와 기회가 뭐라고 보세요?" 그리고 "우리가 그 부분에 대한 실제 고객 피드백이나 데이터를 갖고 있나요?" 간단하죠. 근데 이 두 질문이 우리가 추측이 아닌 실제 증거를 기반으로 일하고 있는지를 바로 보여줬어요.

또 하나 제가 실천했던 건 세일즈 콜을 직접 들어보는 거였어요. 화려하진 않지만, 잠재 고객이 "이거 우리 일주일에 20시간은 절약해줄 것 같은데요"라고 말하는 걸 직접 듣는 것만큼 확실한 건 없더라구요. 특히 갱신 콜이 더 유용했어요. 돈이 걸려 있어서 고객들이 가장 솔직하거든요. 불만도, 기대도, 비교도 전부 날것 그대로 나오는 자리예요.

---

프로세스 전에 원칙부터 세워야 하는 이유

이렇게 기본적인 이해가 생기면, 그다음은 핵심 제품 원칙을 세우는 거예요. 프로세스가 아니라 원칙이에요. 이 둘은 달라요. 프로세스는 "어떻게 할까"를 알려주지만, 원칙은 "왜 이 방향인가"를 정해줘요. 정보가 불완전한 상황에서도 빠르게 의사결정을 내릴 수 있는 기준이 되는 거죠.

저희가 세운 원칙 중 하나는 "B2B 소프트웨어라고 해서 디자인과 사용성 기준을 낮추지 말자"였어요. 이 원칙 하나가 정말 많은 제품 결정에 영향을 줬고, 나중에는 경쟁력의 핵심이 됐어요. 기능 우선순위 논쟁이 생길 때도, 리소스 배분 결정을 내릴 때도, 이 원칙이 나침반 역할을 해줬거든요.

또 다른 원칙은 의사결정 자리에서 최대한 "유저"라는 단어를 쓰자는 거였어요. 이건 사실 이전에 함께 일했던 매니저한테 배운 건데요, 회의에서 "유저가 이걸 어떻게 받아들일까?"라는 질문 하나가 논의 방향 자체를 바꿔주더라구요. 말은 사고를 바꾸고, 사고는 제품을 바꿔요.

이런 원칙들은 프로세스보다 훨씬 확장성이 좋아요. 판단 기준을 제시해주는 거지, 매번 세부 단계를 정해주는 게 아니거든요. 팀이 커지고 의사결정이 분산될수록 이 차이가 엄청나게 커져요.

---

빠르게 실행하고, 더 빠르게 배우기

스타트업의 진짜 장점이 뭐냐고요? 작고 관대한 유저 베이스, 그리고 적은 의사결정자예요. 큰 조직에서는 상상도 못할 속도로 실험하고 배포할 수 있어요.

이전에 큰 조직에서 일할 때는 A/B 테스트 하나 하려면 여러 단계의 매니저와 리더십 검토를 거쳐야 했어요. 지금 회사에서는 제가 직접 기능을 승인하고 배포해요. 처음엔 그 부담이 꽤 컸어요. 근데 이게 반복되다 보니, 실시간으로 제품 직관을 키우고 제 판단을 믿는 법을 배우게 됐어요.

빠르게 움직일수록 한 가지 필수조건이 생기는데요, 바로 극단적인 주인의식과 문서화예요. 구두 합의나 암묵적인 이해는 나중에 혼란만 일으켜요. 기록하세요. 그리고 결과에 대해 책임지세요. 이 습관은 팀 규모가 커질수록 더 가치 있어져요.

---

초기 단계에서 지표는 오히려 오해를 부를 수 있어요

이게 좀 역설적으로 들릴 수도 있는데요, 저는 초기 몇 개월 동안 지표에 집착하지 않았어요. 작은 팀이었고, 매주 수십 명의 고객과 직접 대화했고, 우리가 만드는 것의 가치에 대한 확신이 있었거든요. 데이터는 모니터링했지만, 정성적인 인사이트와 직관에 많이 의존했어요.

제품-시장 적합성을 아직 찾고 있을 때는 지표가 오도할 수 있어요. 낮은 전환율이 제품이 준비 안 된 걸 의미할 수도 있고, 잘못된 고객 세그먼트를 타겟하고 있다는 신호일 수도 있어요. 데이터에 파묻히기보다는 직접 고객과 대화하면 어떤 상황인지 훨씬 명확히 알 수 있어요.

제품이 성숙해지면서 선별적으로 지표를 골라 고객 대화와 리서치를 가이드하면 돼요. 특히 B2B 환경에서는 지표의 의미를 해석하는 맥락이 B2C보다 훨씬 복잡해요. 결국 고객 직관을 개발하고 사용하는 게 더 중요하다는 걸 반복적으로 느꼈어요.

---

작은 팀에서 큰 영향력을 만드는 법

초기 PM이 할 수 있는 가장 강력한 일 중 하나는 고객의 성공 스토리를 내부에 전파하는 거예요. 숫자가 없어도, "이 고객은 우리 제품 덕분에 업무 시간이 절반으로 줄었어요"라는 이야기 한 줄이 팀 전체의 방향을 정렬시켜줘요.

저는 주간 업데이트에 고객 피드백을 반드시 포함시켰어요. 개발팀이 자신들이 만드는 게 실제로 누군가의 일상을 바꾸고 있다는 걸 직접 느끼는 게 얼마나 중요한지 몰라요. 지표 대시보드 열 개보다 고객 한 명의 목소리가 더 큰 동기부여가 되는 경우가 많아요.

또 작은 팀일수록 "PM만의 영역"을 고집하지 않는 게 중요해요. 세일즈가 뭘 듣고 있는지, 개발팀이 어디서 막히는지, 디자이너가 어떤 질문을 받는지 전부 PM의 인풋이 돼야 해요. 제 역할의 경계를 느슨하게 유지하는 게 오히려 더 강력한 제품을 만드는 원동력이 됐어요.

---

오래 지속되는 기반을 만들고 싶다면

제로부터 만들 때는 완벽한 프레임워크나 포괄적인 프로세스가 필요한 게 아니에요. 해결하려는 문제에 대한 명확함, 일관되게 실행하는 규율, 그리고 빠르게 듣고 적응하는 겸손함이 필요해요.

이걸 할 수 있다면, 고객을 기쁘게 하고 회사 성장을 돕는 건 물론, 본인의 커리어 목표도 함께 이룰 수 있어요. 시장을 선도하는 제품이든, 작지만 충실한 서비스든, 시작점은 언제나 같아요. 누군가의 이야기를 진심으로 듣는 것. 그게 전부예요.

---

마무리 요약: 첫 PM으로 살아남는 법은 생각보다 단순해요

프레임워크보다 실제 고객의 목소리를, 프로세스보다 확고한 원칙을, 완벽한 계획보다 빠른 실행과 학습을 선택하세요. 초기에는 지표보다 고객과의 직접 대화가 훨씬 강력한 나침반이 돼요. 그리고 가장 중요한 건 모든 결정을 기록하고, 결과에 책임지며, 겸손하게 배우는 자세예요. 프로젝트 관리 소프트웨어 시장이 2035년까지 연평균 12.8% 이상 성장한다는 전망처럼, PM의 역할은 앞으로 더 중요해져요. 그렇기에 지금 이 기반을 제대로 닦아두는 것이 어떤 투자보다 가치 있어요.