모든 실무를 해보면서 배운점
CEO는 3가지를 해야된다고 한다. 비전에 대해서 이야기하고 사람을 채용하고 자금을 운영해야 된다고 한다.[1] 한마디로 회사 경영을 해야된다.
맞는 말이지만 이는 PMF를 찾은 이후의 회사들에 해당되는 이야기다. 경영은 PMF를 찾은 이후, 즉 마케팅, 영업, 인건비에 돈을 썼을때 어느 정도 성장할지 예측이 가능한 일정한 unit economics가 생긴 이후 가능하다. 반대로 PMF 찾기 전의 회사들은 상황이 다르다. PMF를 찾기전 대표는 PMF를 찾는 것에 집중해야 된다. 예외인 경우도 있지만 보통 PMF를 찾는 과정에서는 채용과 과한 자금이 오히려 방해가 되는 경우가 많다.
이때는 빠르게 다양한 실험을 할 수 있는 상태를 유지해야 된다. 그래서 창업자와 공동창업자 및 초기 창업팀원들 모두 오로지 PMF를 찾기 위해 90%의 시간을 실무에 쓴다. B2B일 경우 CEO는 영업 팀장이 되어 모든 영업에 관여하고 B2C일 경우 CEO는 제품 팀장이 되어 제품 개발에 관여를 하게 된다.
위의 논리가 맞다고 생각해 디스콰이엇은 최소한의 인력을 유지했고 그러기 위해 나를 포함한 창업멤버들 모두 실무에 90%의 시간을 써오고 있다. 나같은 경우에는 채용, 투자유치, 지원사업, 창업하는 과정에서 발생하는 다양한 회계/법무 부터 해서 사업 개발, 디자인, PM, 프론트 개발 등 모든 일을 직접 다 했다. 이렇게 직접 모든 부분의 실무를 다해보니 배우게 된 것이 있다.
각 팀원들의 입장을 모두 이해할 수 있다는 점이다. 흔히 영업, PM, 디자이너, 개발자 사이에는 미묘한 긴장 관계가 존재한다. 고객과 가장 접점이 많은 영업팀은 고객과 만나면서 다양한 요구사항을 듣게되고 그러면서 제품에 어떤 기능만 추가되면 영업이 잘 될 것 같은데라는 생각이 들게 된다. 그래서 제품 팀에 신규 기능 개발을 재촉하게 된다.
PM은 전체적인 회사의 방향성을 고려하면서 제품 전략을 고민하고 요구 사항을 제품 로드맵에 반영한다. 그리고 디자이너와 개발자가 제한된 시간 안에 기능을 개발해 고객에게 전달할 수 있도록 전략과 로드맵을 정리하여 전달한다. 제품의 성공을 리드하는 PM 입장에서는 빠른 주기로 가설 검증하는 것이 중요하다. 그렇다 보니 디자이너와 개발자가 퀄리티에 신경 쓰기보다는 일단 반응을 볼 수 있도록 빠르게 만들어 배포하길 원한다.
디자이너와 개발자는 어느 정도 장인정신을 갖고 있다. 디자이너는 좀 더 시간을 들여서 더 멋진 UX와 그리고 픽셀 단위까지 완벽한 UI를 만들고 싶어하고 개발자는 깔끔한 코드를 짜고 싶어한다. 그리고 창작하는 과정에서 디자인과 코드에 감정 투자를 많이 하게 된다. 장인 정신을 발휘할 시간적 여유 그리고 감정 투자된 창작물이 버려지지 않고 많은 유저들이 사용하길 원하는 마음으로 인해 명확한 제품 전략과 로드맵 그리고 전략에 대한 논리를 PM에게 요구하게 된다.
이렇게 직접 모든 실무를 다해보니 이런 미묘한 긴장 관계의 본질은 각자 업무를 수행하는 과정에서 내적으로 얻는 즐거움이 조금씩 다르기 때문이라는 것을 깨달았다. 언제 도파민을 얻는지가 각자 다르다. 영업은 리드가 고객으로 전환 되었을때 쾌감을 얻는다. PM은 프로젝트가 계획대로 진행될때 쾌감을 얻는다. 디자이너는 만족스러운 디자인이 나왔을때 쾌감을 얻는다. 개발자는 코드가 잘 작동할때 쾌감을 얻는다.
물론 역할의 구분 없이 자신이 관여한 제품이 많은 사람들로부터 이용되고 소속한 회사가 성장하면서 주변 사람들 혹은 사회로부터 인정을 받고 경제적인 보상이 늘어나면 이는 모두에게 쾌감으로 이어진다. 하지만 이는 모두 외적인 보상이며 실제 업무 과정에서 얻는 내적인 쾌감은 차이가 있다.
이를 이해하지 못한 상태에서 일을 하면 서로 견제하는 관계로 이어지게 되고 이게 악화되면 불신과 불화로 이어지게 된다. 특히 팀 혹은 프로젝트를 이끄는 위치에 있는 대표나 PM은 이런 매커니즘을 잘 이해하고 팀원들에게 현재 집중하고자 하는 것과 전략을 지속적으로 명확히 해주면서 우선순위를 잘 판단할 수 있도록 도와줘야 되고 각 팀원의 업무로부터 얻는 쾌감에 대한 기대치 관리를 잘해야 된다.
📌 요즘 어떻게 하면 좋은 제품 팀을 만들 수 있을지 계속 고민하고 있습니다. 디자이너, PM, 마케터, 개발자들이 어떤 팀에서 일하고 싶어하는지 어떤 내적 동기 혹은 외적 동기를 갖고 있는지 배우고 있습니다. 이에 대해서 의견을 주실 수 있는 분과 커피챗을 하고 있으니 연락주세요!
📌 디스콰이엇에서 프론트엔드 개발자와 벡엔드 개발자를 찾고 있습니다. 관심있는 분들은 저에게 커피챗 주세요!
참고 자료
[1] Fred Wilson의 CEO가 해야되는 3가지: https://avc.com/2010/08/what-a-ceo-does/
댓글
로그인 후 댓글을 남길 수 있습니다.
감사합니다! 이번 글에서 한 발자국 더 높은 계단을 넘은 기분이 나네요..!! PM으로 일하면서 정말 냉정하게 각 부서의 역할과 특징을 이해하는 분들이 얼마나 많으실까요...(개인적으로는 대부분의 PM은 그저 일정에 맞춰 화면을 기획하는 역할에 머물러 있다고 생각됩니다..) 이러한 이해 속에서 운영되는 팀의 퍼포먼스와 운영조직의 변화가 너무 나도 궁금합니다..
도움이 되었다니 기쁘네요 :) 앞으로도 종종 PM에 대한 글을 올려보도록 할게요 ㅎㅎ
PM이야 말로.. 없어선 안될 너무나 중요한 존재라는걸! 생각하게 됩니다. 글 내용과 같은 가치관을 갖고있는 PM과 함께 해보고싶네요..
저는 스타트업 PM으로 일하고 있습니다. 스타트업 특성상 디자이너와 개발진으로 구성된 완전한 팀이 없고, 디자이너와 개발진 모두 아웃소싱입니다. 대표는 자꾸 산출물만 요구하는 상황이고 주요 업무는 모두 아웃소싱이라 소통이 어려운데 어떤 식으로 해결해야 할까요? 결국 제가 컨트롤을 할 수 있는게 없다 보니 결과물은 자꾸 딜레이되고.. 이걸 협업툴로 해결할 수 있을까요? 하나씩 기능별로 나누어 작업하는게 최선일까요? 질문이 다소 broad 하네요.
• Communication cost: 어떻게든 이 비용을 줄이는 것이 PM의 중요한 역할 중 하나인 것 같습니다. 이를 잘하기 위해서는 Mission > Strategy > Product Strategy > Product Roadmap > Project Brief를 잘 정리한 문서를 만들고 팀원들에게 주기적으로 이 문서를 기반으로 체크하는게 중요한 것 같습니다. 특히 기능 딜레이나 communication cost는 Project brief를 할때 우리의 전략, 집중해야 될 점, 판단 기준(guiding principle) 등을 잘 정하지 않으면 정말 쉽게 비싸지는 요소들인 것 같아요. • 기능 딜레이: 기능이 딜레이 되는 이유는 다양하게 있을 수 있어 그 원인이 뭔지에 따라 대처 방법이 다를 것 같아요. 일반적으로 개발에는 항상 미리 예상치 못하는 불확실성이 존재해 정확한 일정을 산출하는 것이 쉽지 않은 것 같아요. 이를 해결하는 2가지 방법이 있는데 첫번째는 시간을 정하면 그에 맞게 개발 범위를 최대한 역추산 후 개발 퀄리티에 상관 없이 무조건 배포하는 방향으로 하는 것이고 두번째는 Shape up이라는 방식으로 개발 사이클을 좀 더 느슨하게 가져가면서 자세한 기능 결정을 개발자에게 온전히 맞겨 Communication cost를 낮추는 방식이 있는 것 같습니다. Shape up에 관해서는 릴레잇의 블로그 링크를 참고해보세요: https://www.relate.kr/blog/shape-up-relate/ • 툴: 저희는 노션 그리고 Linear라는 툴을 사용하는데 개발 스코프를 짜고 백로그 정리하고 Issue tracking하는데 도움이 많이 되는 것 같습니다. • 위에 적은 내용들은 사실 아웃소싱 구조로 실행하기에는 어려움이 많은 것 같아요. 그리고 대표님께서 직접 제품 개발 혹은 세일즈에 관여하지 않으면 지속적으로 대표님과 PM 사이의 답답함이 존재할거라 생각합니다. 그래서 최소 1달이라도 대표님께서 제품 개발에 관여를 해보는 것을 추천합니다.
상세한 답변 감사합니다! 추천해 주신 책과 도구 한 번 살펴보도록 하겠습니다. 그리고 Communication Cost의 관점에서는 생각해보지 못했는데 정말 중요한 부분이라고 생각되네요. 개발이 너무 딜레이 되서 Shape up 방식으로 제안해서 진행했는데, 결국 대표님이 다 갈아 엎는 상황이 발생.. 개발자들의 반발도 있었구요. Shape up 방식은 어느 정도 상호간에 신뢰와 업무 스타일에 대한 동의도 있어야 하는거 같네요.
잘 읽었습니다 개발을 할 줄 알다보니 장인정신에 시간과 에너지를 너무 많이 빼앗기고 있어서 반성중이에요. 반성하고 있다는 말만 어느새 2년 째 하고 있는 것 같네요. 펀딩 받으면 런웨이가 생기니까 좀 더 발등에 불이 떨어지려나 싶기도 하고 PMF 찾는데 고객 인터뷰해서 문제 정의하고 problem-solution fit 찾고 해야하는데 자꾸 개발만 하게 되네요..
PMF 어려운 것 같아요 ㅠㅠ 화이팅입니다!
정말요...다 하다보니 뭐 하나라도 성과가 나면 좋지만, 뭐 하나라도 실패하면 기분이 어쩔수없이 다운되는 것 같습니다. 그래서 인간다운 기계? 기계 같은 인간이 되는 게 좋겠다 싶은 요즘입니다~!
😂
좋은 글 감사합니다. 저는 아직 경험도 지식도 부족하고 용기만 있어 대책없이 일을 수행해보다보니 부족함을 많이 느끼고 해결책을 찾아 공부하다보니 이 글까지 읽게되었습니다. 홀로 서기를 시작하는 프리랜서로서 저에 대한 pmf찾는 일이 더 중요하다는 것을 알게 되었네요 여러 직무, 직업, 사업, 창업, 예술분야까지도 모두 통하는 중요한 이야기인 것 같습니다. 큰 사업체에서의 역할 구분과 방향, 그리고 단계에 알게되어 너무 좋고 더 자세한 정보와 이야기를 기다리겠습니다.