Landing Over Launching — What Product Managers Can Learn From Space Explorations

[🚀 Launching vs landing: 프로덕트가 우주미아가 되는 것을 방지하자] 🖋️ 큐레이터 평: 요즘 여러 테크 기업에서 화두가 되기 시작한 주제는 제품 launch(이륙) 즉 출시에 그치지 않는 성공적인 landing(착륙)입니다. 제품 출시의 스피드와 실험에 초점을 두다보니 많은 프로덕트 매니저들이 앞다퉈 새로운 제품을 출시하려고 하고, 출시 후 기술적 안정성, 제품의 포지셔닝, lifecycle(생명주기) 등에 소홀해지는 경우가 많습니다. 아마존의 Fire phone, 마이크로소프트의 Edge브라우저, 구글의 Google+ 등의 프로덕트들은 성공적으로 출시되었으나 사용자들의 사랑을 받지 못하여 결국 정리되거나 뒤늦게 전략을 변경한 후 재출시 되었습니다. 물론 제품이 완벽해질 때까지 출시를 늦춰야 된다는 말은 아니며, 다양한 제품과 피쳐를 실험적으로 출시하는 것은 혁신을 장려하는 좋은 방법이라고 생각합니다. 다만 이륙 후에 성공적인 착륙이 어떤 것인지 미리 생각해보면, 출시 후 사용자의 반응과 데이터를 통해 기준을 수정하더라도 제품이 우주미아처럼 떠돌아다니다가 버려지는 것을 방지할 수 있습니다. 📑 본문 요약: 아폴로 11호는 미국의 John F. Kennedy 대통령이 인간을 달에 착륙시킨 후 무사히 지구로 귀환시키겠다는 원대한 계획을 세운 후 약 250억 달러(요즘 물가로 1천5백억 달러)의 비용을 들여 8년 뒤인 1969년 7월 20일에 지구에서 이륙했다. 이 시점까지 8명의 우주인이 생명을 잃었고, 아폴로 11호의 경우에 우주선이 지구에서 폭발하면 핵폭탄 수준의 피해를 줄 수 있었다. 일반적인 소프트웨어였다면 8년이나 준비해온 런칭이었기 때문에 런칭 자체를 축하하기 위해 수개월 동안 축배를 들었을 것이다. 그러나 아폴로 11호 관계자들은 모든 우주 조종사들이 지구에 안전하게 귀환해야 임무가 성공한다는 것을 알고 있었기 때문에 이륙 후 8일 3시간 18분 35초 동안 끊임없이 목표를 이루는데에 집중했다. 그들의 지원으로 우주선은 Saturn V 우주셔틀에서 순조롭게 분리되었고, 달에 성공적으로 착륙했다. 조종사들이 달의 표면을 밟은 후 우주선은 달에서 다시 지구를 향해 이륙했으며, 성공적으로 지구의 궤도에 진입했다. 아폴로 관계자들은 우주선이 안전하게 바다에 착륙했을 때 비로소 임무가 성공적이었다고 발표했다. 모든 제품은 미션과 이뤄야하는 목표가 있다. 제품 런칭은 목표를 이루기 위한 하나의 중요한 수단일뿐이지 그 자체가 목표가 될 수 없다. 제품의 두번째 버전이 첫번째 버전보다 중요하고, 첫번째와 두번째 버전 사이에는 수많은 사항들을 개선해야 한다. 프로덕트 매니저들이 이륙(출시)만 잘 하는 게 아니라 착륙 (제품의 성공)을 잘 하려면 어떤 사항들을 고려해야 하는가? 1. 제품 출시 전에 목표를 명확히 정하고, 내부 이해관계자들과 합의를 한다 2. 출시 자체가 아닌 목표를 이루는 것에 초점을 둔다- 출시 후 제품을 성공적인 궤도에 올리기 위해서 해야 되는 일들을 잊지 않는다 3. 데이터를 수집하고 분석한다 (아폴로 11호가 어디로 향하는지 알 수 없었다면.. 우주 비행 관제 센터는 어떻게 아폴로의 성공여부를 가늠할 수 있었을까?) 4. 축배를 든다 (그러나 적절한 시점에 한다)- 제품 출시 파티를 너무 일찍하면 집중력이 흐트려지고 제품이 잘못될 경우 담당자는 변명하기에 급급해질 수가 있다. 5. 필요시 제품을 정리(sunset)한다- 출시 후 얼마 동안 도전할 것인지, 어떤 경우에 pivot을 할지 생각해보는 게 중요하다. 사용자들이 수준 이하의 제품을 너무 오래동안 사용하는 것보다 못한 게 없다. 가장 중요한 것은 모든 팀원들이 landing이 launching 이상으로 중요하다는 것을 인지하는 것이다.

정대용 Google, Product Manager

How To Get Into Product Management (And Thrive) ✨

[프로덕트 매니저가 되는 방법 (+ 잘 하는 방법)] 🖋️ 큐레이터 평: 프로덕트 매니저라는 직무의 정의는 산업 분야와 회사마다 조금씩 다르고 PM이 되는 방법 또한 다양합니다. PM은 적은 권환에도 불구하고 책임져야 하는 게 많고 언제나 팀원들보다 두세 발짝 앞을 내다봐야 하는 힘든 점도 많지만 팀이 합심해서 좋은 결과물을 세상에 내놓으면 모든 스트레스가 풀리고 오히려 아드레날린을 분비시키는 정말 보람이 있는 직업입니다. PM이라는 직업에 관심이 있는 분들에게 가장 중요한 것은 내가 왜 PM이 하고 싶은지 생각해보고, 이런 일을 정말 좋아하고 어느 정도 잘 할 수 있다는 자신감이 있으면 바로 관련 역량을 키우고 그것을 행동으로 증명하기 시작하는 것이라고 생각합니다. PM 역량을 갖추기 위해 사이드 프로젝트로 앱을 출시해보던가 무료 웹사이트를 통해 테스트를 돌려서 가설을 증명해보거나, 사내에 있는 프로덕트와 연관이 있는 프로젝트를 나서서 맡는 등 여러가지 방법이 있습니다. 아래는 AirBnB에서 엔지니어로 근무하다가 초기 PM으로 전향한 Lenny Rachitsky의 글입니다. 다음 기회에 이 글에 깊게 언급되지 않은 being scrappy(적은 리소스로도 창의적으로 문제를 해결하는 능력), discovery(고객 니즈 발굴)와 customer obsession(고객에 대한 집착)에 대해 좋은 글을 공유하도록 하겠습니다. Lenny의 원문이 조금 긴 편이지만 유용한 링크가 많으니 이미 PM을 하시는 분들도 읽어보시면서 현재 어떤 스킬을 더 보완하는 게 좋을지 생각해볼 수 있을 것 같습니다. 📑 본문 요약 <우선 '왜'하고 싶은지, 나에게 PM이 맞는지 생각해보자> 다음 사항들을 통해 성취감을 느끼면 PM을 해라 1. 사람들의 문제를 해소하는 것 (사용자와 팀원들) 2. 비즈니스 성장에 기여하는 것 3. 다양한 사람들과 함께 일하는 것 4. 전략 세우기 5. 무슨 일이 있어도 일을 해내기 6. 권한 없이 팀을 이끌기 7. 많은 내부 관계자들에게 자주 커뮤니케이션을 하는 것 8. 결정 내리기 (큐레이터: 물론 팀원들과 의견을 조율 후에 내리는 결정) 9. 사용자들에게 멋진 경험을 만들어주는 것 10. 세부 사항에 신경을 쓸 줄 알고 언제나 준비가 되어 있는 것 다음 사항들을 통해 성취감을 느끼게 되면 PM이 되지 말아라 1. 사람들이 나에게 언제나 감사함을 표현한다 2. 모든 것을 내 마음대로 하는 것을 좋아한다 3. 혼자 일하고 남들이 건드리지 않는 것을 선호한다 4. 내가 항상 옳다고 생각한다 5. 혼자 디자인하고 개발하는걸 좋아한다 6. 모든 사람들이 나를 좋아하고 나의 결정들을 좋아한다 7. 언제나 고도의 집중력을 발휘할 수 있는 환경 8. 미팅을 싫어한다 9. 이메일 (또는 업무용 챗 프로그램 메세지)을 싫어한다 10. 대인기피증이 있다 물론 위 사항들이 모두 해당되어야 하는 것은 아니지만 대부분의 사항이 해당된다면 다음 내용을 읽어볼 것을 권한다. <'어떻게' PM이 될지 생각해본다: 네 가지 방법> 1. 대기업 내부 직무 이동- 어떤 역량을 보유하고 발휘한 경험이 있어야 하고 상대 PM팀에서 나를 옹호한다 (큐레이터: 스타트업에서도 충분히 가능하지만, 아직 안정적인 성장 단계에 오르지 않은 스타트업은 PM직무를 가르쳐 가며 제품을 개발할 여유가 없을 때도 있습니다. 오히려 아래 3번에 언급된 사람을 고를 여유가 없는 초기 스타트업에 기회가 있을 수도 있습니다) 2. 대기업 공식 PM 프로그램을 통해 쥬니어 피엠으로 입사 (큐레이터: 우리 나라에는 아직 활성화되지 않은 것으로 알고 있습니다. 또한 정말 하고 싶은 직무라면 직급을 낮춰서라도 시작하는 것이 나쁘지 않다고 생각합니다) 3. PM이 급하게 필요한 스타트업에 합류한다- 네트워킹을 통해 파운더나 임원을 잘 알고, 허슬(추진력/끈기)을 보여주고, 기회가 주어질 때 성공적으로 실행할 수 있는 능력을 갖췄을 경우 가능하다. 일을 하면서 빠르게 배울 자세를 가지고 있어야 한다. 4. 창업을 한다- 스타트업 초창기에는 CEO가 피엠 역할을 많이 하고, 기업이 인수될 경우 인수기업 측에서 피엠으로 활동하는 파운더가 많다. <'어떤' 역량을 개발할지 생각해본다: PM의 7 가지 역량> 1. 문제 풀이 능력- 팀이 문제를 풀 수 있도록 가이드? 해주기. 명확한 비전에 기반한 전략 짜기 2. 실행력- 모든 팀원들과 합의한 로드맵 짜기, 주요 일정 지키기, 진행을 방해하는 문제가 생겼을 때 해소하기. 이것은 피엠의 가장 기본적인 업무다. 3. 커뮤니케이션 능력- 시기 적절한 커뮤니케이션을 통해 모든 일이 유기적으로 돌아갈 수 있게 돕는 것 4. 리더십- PM은 권한없이 상당히 많은 책임이 부여된다. 팀원들의 신뢰를 얻고, 결정을 내리되 모든 사람들이 목소리를 낼 수 있게 하고, 무슨 일이 있어도 사기 진작. 5. 데이터에 기반한 결정- 명확한 원칙을 팀원들과 미리 정하고, 정량적 및 정성적 데이터를 활용하여 결정을 내린다 6. 탁월한 제품에 대한 감각을 갖는 것- 좋은 프로덕트가 어떤 것인지에 대해 직감을 기르고, 제품 개발 시에 감각과 과학적 사고의 균형을 유지한다 7. 언제나 준비가 되어 있어야 한다- PM이 무엇이든지 한다고 선언했으면 이를 이행해서 팀원들의 신뢰를 얻어야 한다. 제품 개발 시에 무엇이 잘못될 수 있는지 한 번 쯤 생각해보고 준비한다. 미팅 전에 몇 분 동안이라도 생각을 정리하고 참석한다. <보너스: PM업무를 더욱 잘 하려면..> - 비전을 세운 후 이를 명확하게 설명하고 내부 이해 관계자들의 합의를 얻어낸다 - 비즈니스 감각- 팀과 기업 전반적으로 어떤 기능들을 어떤 순서로 개발하는 게 좋을지, 비즈니스를 성장시키는 요소가 무엇인지 이해 - 진행하고 있는 업무가 고객과 기업에 주는 영향에 대한 집착 - 성장 지향적 자세- 자신과 주변의 모든 사람이 계속 변화하며 실력이 향상될 수 있다고 믿어라

정대용 Google, Product Manager

The Slack Social Network

[Slack 소셜 네트워크와 경제적 해자(moat) 🏰] 🖋️ Slack을 몇 년 전에 처음 접했을 때 채널을 이용하여 주제별로 대화를 나누고 중요한 협업 기록을 남길 수 있어서 간편하다고 생각했습니다. 그리고 Amplitude라는 데이터 분석 툴을 사용하다가 문제가 생겼을 때 슬랙으로 기술 지원을 받았는데, 일반적인 서포트 챗과 달리 상대 쪽 전문가와 정보를 공유하며 같이 문제를 해결할 수 있다는 점이 인상적이었습니다. 지난 달에 Slack Connect가 공식적으로 출시되면서 Slack의 경제적 해자(moat)에 대해 생각 해보게 되었습니다. 경제적 해자는 브랜드, 기술력, 데이터, 규모의 경제, 네트워크 효과 (인스타그램/페이스북처럼 사용자가 많아질수록 플랫폼의 가치가 증가하는 효과), 협업사 네트워크 등 여러가지 예를 들 수 있습니다 (그러나 불법적인 독점을 의미하지는 않습니다). 초기기업이 경쟁력을 유지하며 크게 도약하려면 경제적 해자(moat)를 확보하는 것이 상당히 중요하다고 생각합니다. 웨렌 버핏도 투자를 결정할 때 기업이 앞으로 얼마나 성장할지 보다 기업의 경쟁력이 얼마나 지속가능한지, 얼마나 넓고 깊은 경제적 해자가 있는지에 초점을 둡니다. 📑 Summary: 슬랙은 4년 전 쯤에 마이크로소프트의 Teams 출시가 발표되었을 때 마이크르소프트를 향한 '충고'를 뉴욕타임즈 전면 광고를 통해 전달했다. 기능 자체보다 열린 플랫폼과 제품과 미션에 대한 진심 어린 사랑을 가져야 한다는 내용이었다. 그러나 2년이 지난 후에 Teams의 DAU가 슬랙을 추월했고, 최근에는 Teams가 320만 DAU(코로나가 전세계적으로 퍼지기 이전 시점인 3월 기준), 슬랙은 120만 DAU(작년 10월 기준)를 기록했다. 마이크로스프트의 경우 파트너 네트워크와 제품 간의 통합이 상당히 넓은 해자다. 규모가 큰 기업 고객은 마이크로소프트와 마찬가지로 슬랙도 영업팀을 통해 직접 상대할 수 있으나, 이런 큰 기업 외에도 수천 개의 중소기업들이 있다. 이들은 외부 협업사에 의존하여 기술 인프라를 구축하는 경우가 많은데, 마이크로소프트는 이런 협업사들에게 제품 교육을 제공하고 Azure와 Office 365 구독료의 일부를 공유해서 고객들에게 Teams를 포함한 마이코로소프트 위주의 솔루션을 추천하도록 장려한다. 슬랙의 경쟁력은 뛰어난 협업용 채팅 기능으로 시장을 선점했다는 것과 여러 기업을 연결시키는 Connect다. Slack Connect을 이용하면 슬랙의 공유 채널을 통해 다양한 기업의 전문가들과 효율적으로 협업을 하거나 정보를 공유할 수 있다. 또한 어설프게 고객사의 모든 툴들과 완벽하게 통합하기보다는 협업을 채팅 중심으로 접근하며 각 기업의 내부 시스템과 지나치게 깊게 연동되지 않기 때문에 다른 기업과 수평적으로 연결할 수 있다. 마이크로소프트가 '클라우드의 OS'를 만든 반면 슬랙은 '기업용 소셜 네트워크'를 만들었다. 즉 마이크로소프트는 보유하고 있는 다양한 솔루션을 통해 고객의 시스템을 수직적으로 접근했으나 슬랙은 챗을 통해 수평적으로 여러 기업들을 접근한 것이다. 💡Food for thought: 여러 기업들이 애용하는 마이크로소프트와 슬랙은 나름의 강력한 경제적 해자를 가지고 있습니다. 지금 맡고 있는 제품은 어떤 해자를 가지고 있나요? 남들이 모방하기 힘든 경쟁력을 갖추기 위해 어떤 노력을 하고 있나요? 이는 장기적으로 성공하기 위해 꼭 한 번 짚어 볼 만한 내용이라고 생각합니다.

정대용 Google, Product Manager

Wrongfully Accused by an Algorithm

[AI 편향(bias): 알고리즘으로 인해 잘못 고소 당했다고요?] 🖋️ 우리가 일상적으로 사용하는 서비스들에서 AI의 역할이 점점 커지고 있다. 소비자들은 비디오 스트리밍 서비스가 자동으로 추천하는 개인취향에 맞는 비디오를 보고, 구글 어시스턴트, 아마존 알렉사 등 보이스 어시스턴트를 사용하여 음악을 틀거나 조명의 밝기를 조절한다. 현재 맡은 제품도 AI를 사용하는데, 언제나 training data의 질과 알고리즘의 bias (편향)에 주의를 기울이고 철저히 테스트를 해야하며, 결과를 활용할 때 항상 신뢰수준과 한계점들에 대한 충분한 이해가 필요하다는걸 느낀다. 📑 미국에서 경찰의 인종차별과 폭력으로 인해 불만이 고조되고 있는 가운데 기술력이 떨어지는 안면 인식 소프트웨어와 경찰의 미숙한 사용으로 인한 첫 공식적인 피해 사례가 보도됐다. 작년 말에 미시간 주 디트로이트의 흑인 남성이 집 앞에서 체포되었는데, 경찰이 몇 달 전에 한 시계 가게 CCTV영상에 잡힌 절도범의 이미지와 약 5천만 장의 사진을 비교하여 찾은 사람이었다. 문제는 미시간 주 경찰은 DataWorks Plus라는 기업의 안면 인식 소프트웨어를 사용하는데, 이 기업은 기존에 범인 사진 관리 소프트웨어를 만들다가 외주를 통해 안면 인식 기능을 추가했다. 이들은 시스템의 정확도와 편향을 제대로 측정하지 않고, 수동으로만 검사를 해왔다. 또한 미시간 주가 사용하는 알고리즘은 연방기관의 테스트에서 흑인과 동양인 얼굴의 안면인식 성공률이 백인의 얼굴에 비해 10~100배나 낮은 것으로 측정되었다. 이 사건의 경우, 알고리즘은 몇 명의 용의자 사진과 이에 대한 신뢰도를 제공했고, 검사자는 디트로이트 경찰에게 이 결과를 ‘수사 단서 리포트’를 통해 제공했다. 딜로이트 경찰은 휴대폰 위치 추적, 목격자 증언 등 다른 증거를 충분히 확보하지 않은 상태에서 6명의 사진을 가게 점원에게 보여준 후 그가 지목한 사람에게 바로 체포 영장을 발부했다. 심문 과정 중에 경찰관은 범인 사진이 체포된 윌리엄 씨의 얼굴과 다르다는 것을 발견했지만, 윌리엄 씨는 체포 후 30시간이 지나서야 보석으로 석방되었다. 🖋️ 이처럼 AI 기술을 적용 시 충분히 검증된 알고리즘을 사용하고, AI가 제공하는 결과값을 제대로 이해하고 올바르게 사용하는 프로세스를 수립하는 것이 중요하다는 것을 알 수 있다.

정대용 Google, Product Manager

I’m Sorry, But Those Are Vanity Metrics

[죄송하지만, 그것은 ‘허영 지표’네요] 🖋️ 주변에 외부에서 투자를 받고 파트너십을 맺거나 인재를 채용하기 위해 기업의 가치를 표면적으로만 나타내는 지표들을 사용하는 경우가 많다. 그러나 이런 지표들은 고객에게 실질적으로 제공하는 가치와 기업 또는 제품의 성장을 측정하기에는 부족하며, 때로는 팀원들을 혼란시킬 수 있다. 그래서 적어도 기업 내에서는 비즈니스 분야와 고객의 특성에 맞는 명확한 지표를 설정하고 측정해야 기업을 목표한 방향으로 이끌어 나갈 수 있다. 📑 작년에 구글에 26억 달러에 인수된 데이터분석 플랫폼 Looker의 파운더 및 전 CTO인 Lloyd Tabb은 vanity metric (허영지표)의 문제점과 clarity metric (명확한 운영 지표)의 중요성을 강조한다. 그는 vanity metric을 누적다운로드 수와 같이 보기에 좋은 표면적인 지표로 정의하고 clarity metric은 기업의 성장을 이끄는 숨은 요소인 실질적인 운영 지표로 정의하며, 각 지표의 용도를 착각하지 않을 것을 권한다. 그는 지표를 잘못 설정한 채용 관련 스타트업의 사례를 공유하는데, 이 스타트업은 3천만 DAU(Daily Active User: 일별 사용자 수)를 기록하고 5천만 달러의 투자를 받았지만 DAU만을 쫓다가 2년 내에 실패했다. Tabb은 아래 글에 서비스, 광고, 소프트웨어, 이커머스 기업들의 vanity 및 clarity 지표를 비교하며 고객의 행동을 예측하는 대리지표(proxy)를 찾는 방법을 공유한다.

정대용 Google, Product Manager

The Phases Product Teams Go Through, From Product/Market Fit to Hypergrowth

[기업의 스테이지에 따른 프로덕트 팀 구성 방법] 🖋️ Credit Karma는 미국에서 신용카드, 대출 등 상당 수의 금융 상품을 가입할 때 필요한 credit score(신용도)를 모바일 앱으로 손쉽게, 공짜로 조회하고 개인 정보에 맞게 추천된 금융 상품 가입 시 다양한 금전적 혜택을 받을 수 있는 서비스로 선풍적인 인기를 끌은 핀테크 스타트업이다. 월 사용자수는 2020년 2월 기준 미국인구의 10%가 넘는 숫자인 370만명이 넘었고 올초에 Intuit에 약 70억달러에 인수되었다. 📑 Credit Karma 전 CPO Nikhyl Singhal은 과거에 여러 스타트업을 창업했는데, 그 중 하나는 망했고 나머지 두 개는 IBM과 구글이 인수됐다. 스타트업이 인수되면서 구글에 입사하여 화상통화앱인 Hangouts를 출시했다. 그는 다양한 스케일의 기업에서 근무한 경험을 바탕으로 스타트업의 '비장의 무기'인 프로덕트 팀을 스테이지에 따라 구성하는 노하우를 공유한다. 첫번째 단계는 “drunken walk”다 (큐레이터: 술에 취한 사람처럼 일직선으로 걷지 못하는 모습을 형상화한 듯). 이 단계에서는 프로덕트 매니저의 주요 업무는 파운더(창업자)의 비전을 효과적으로 실행하는 프로젝트 관리다. 빠르게 실험을 돌리고 펀딩자금이 고갈되기 전까지 product-market fit을 찾을 수 있도록 파운더를 돕는 역할을 해야 한다. 두번째 단계는 product-market fit 단계다. 이 단계에는 product-market fit을 어느 정도 찾은 후 성공할 가능성이 보이는 기회들에 집중하여 프로덕트와 비즈니스를 키우는 단계로, 실행에 집중하고 어느 정도의 프로세스를 도입하기 시작한다. 이 단계에서 파운더는 주요 직책의 리더들을 섭외하고 회사를 키우느라 더 이상 프로덕트의 세부적인 사항에 신경을 쓸 겨를이 없다. 이 때 조금 더 큰 조직에서 효율적인 프로세스를 경험했을 뿐만 아니라 직접 프로세스와 프로덕트를 꾸준히 개선한 경험이 있는 PM(프로덕트 매니저)이 필요하다. 세번째 단계는 hyper growth(초고속) 성장 단계다. 현재 제품을 scaling하는 동시에 혁신에 투자해야 하며, 이 때부터 프로덕트 매니지먼트가 진정으로 전략적인 역할을 하게 된다. 프로덕트 팀의 역할은 조금 더 장기적인 로드맵을 제시하고 장기 비전을 여러 분기에 거쳐 실행하는 것이다. 제품의 세부적인 디테일에 대한 파운더의 영향력이 적어지고 팀이 자체적으로 돌아가야 하는데, 프로세스가 부족하면 방향성을 잡고 중요한 것에 집중하기가 어렵다. Nikhyl도 이 단계에 CPO로 Credit Karma에 합류했다. 이 단계에는 PM이 zero to one(무에서 유를 창조한) 경험이 없으면 지금까지 프로세스 없이 기업을 빠르게 키운 파운더와 코드가 맞지 않을 수가 있고 큰 조직에서 활동한 경험이 부족하면 사내의 다양한 이해관계자와의 협업과 동시 다발적으로 진행되는 프로젝트로 어려움을 느낄 수 있다. Nikhyl은 이 시기에 프로덕트 리더에 대한 기대치를 높이고 가능하면 외부인보다는 기존 PM들이 이 기대치에 맞게 성장할 수 있는 기회를 제공하는 것을 추천한다. 또한 다양한 유저를 위한 프로덕트를 만들기 위해서는 팀 구성원의 다양성을 추구해야 한다. 채용을 최대한 편견없이 하고 내부적으로 서로 다른 점과 의견들을 쉽게 공유할 수 있는 분위기를 형성해야 한다. 🖋️ Nikhyl의 글처럼 프로덕트 팀의 역할은 기업과 프로덕트의 성장에 맞춰 진화해야 한다. 프로덕트 팀을 구성하는 정확한 공식은 없지만, 파운더는 제품 전략과 로드맵에 대한 권한을 점점 프로덕트 팀에게 위임하지 않으면 프로덕트가 충분히 성장하지 못하고 결국 유능한 인재들을 잃을 수 있다.

정대용 Google, Product Manager