[번역] 시니어 프로덕트 매니저가 다르게 생각하는 방법

시니어 프로덕트 매니저가 다르게 생각하는 방법

이미지 출처 : 원본 포스트

종종 프로덕트 매니저가 어떻게 더 높은 직급으로 승진할 수 있는지 질문을 받는다. 사실 승진은 보통 복잡한 게임이다.

물론 내 역량과 성과가 중요한 역할을 하지만 매니저가 인재 개발에 얼마나 신경 쓰는지, 동료들의 역량과 경험, 회사 내의 정치적 요소 등 여러 가지 요인이 영향을 미친다.

 

따라서 이 글은 시니어 PM으로 승진하는 방법에 대한 것이 아니라 사고의 수준을 높이고 더 나은 PM이 되는 방법에 대한 것이다.

직책에 상관없이 누구나 시니어 PM처럼 사고할 수 있다.

반대로 시니어 PM 타이틀을 가지고 있다고 해서 모두가 그 타이틀에 걸맞은 역량을 갖춘 것은 아니다.

 

아래의 다이어그램은 문제와 해결 방법에 대해 얼마나 명확하게 이해하고 있는지에 따른 다양한 프로덕트 매니지먼트 방식을 보여준다.

제품 관리 기술을 발전시키기 위해서는 모든 수준의 명확성에서 편안하게 작업할 수 있어야 하며, 각 상황에서 사용할 수 있는 다양한 도구들을 배우는 것이 중요하다.

이미지 출처 : 원본 포스트

문제가 명확한지 어떻게 알 수 있을까? 명확한 문제를 나타내는 몇 가지 지표가 있다.

• 비즈니스와 사용자에게 미치는 영향을 명확하게 설명할 수 있다.
• 문제의 근본 원인을 잘 이해하고 있다.
• 다른 문제들보다 이 문제를 지금 해결해야 하는 이유가 명확하다.

또한 해결책이 명확하다고 할 수 있는 조건은 다음과 같다.

• 이 해결책이 문제를 해결할 수 있다고 확신한다.
• 여러 가지 해결책을 검토한 결과 비용 대비 효율 면에서 이 해결책이 가장 뛰어나다.
• 팀이 해결책을 어떻게 실행할지 알고 있다.

이번 글에서는 다양한 상황에서 사용할 수 있는 도구들을 다루고, 마지막에는 주의해야 할 함정에 대해 이야기할 것이다.

---

기본을 잘 다지기: 탁월한 실행

문제가 이미 잘 정의되었고 해결책이 합의된 경우에는 이것을 훌륭하게 실행하는 것이 중요하다.

이는 주로 주니어 PM의 주 역할이지만 시니어 PM도 이 부분을 마스터해야 하며, 경우에 따라서는 직접 관여를 줄일 수 있다.

이미지 출처 : 원본 포스트

"어떻게 빠르게 배포할 수 있을까?"

여기서 핵심은 백로그를 관리하는 것이다:

티켓을 명확하게 작성하고, 적절한 크기로 나누며, 우선순위를 올바르게 설정하고, 효율적으로 작업이 진행되도록 한다.

이를 위해 스프린트 계획, 리파인먼트, 회고와 같은 팀 활동을 주도하는 것도 포함될 수 있다.

전통적인 스크럼 팀에서는 프로덕트 오너(PO)의 역할이다. 더 성숙한 조직에서는 보통 테크 리드가 이 역할을 맡는다.

만약 훌륭한 테크 리드가 팀에 있다면 걱정할 필요가 없다!

PM으로서 고유의 가치를 더할 수 있는 부분은 다음과 같다:

• 엔지니어들이 작업의 비전과 맥락을 이해하고 비즈니스 목표에 어떻게 기여하는지 이해하도록 돕기
• 작업을 독립적으로 배포할 수 있는 작은 단위로 나누는 것을 지원하기

기능이 복잡할 경우 전체 기능을 배포하는 데 몇 달이 걸릴 수 있다.

만약 기능을 작은 단위로 쪼개면서 사용자에게 여전히 가치를 줄 수 있는 상태로 배포할 수 있다면 큰 성과다.

더 빠르게 배포하면 사용자로부터 더 빨리 피드백을 받을 수 있으며, 즉 잘못된 것을 만드느라 몇 달을 소비하는 위험을 줄일 수 있다.

 

"어떻게 잘 수행할 수 있을까?"

여기서는 테스트와 실험이 중요한 역할을 한다.

엔지니어에게 코드를 요청하기 전에 프로토타입을 활용해 사용성 테스트를 진행할 수 있다.

기능을 점진적으로 배포하거나 최종 버전을 공개하기 전에 A/B 테스트를 진행할 수도 있다.

다양한 테스트와 실험 방법은 공구 상자의 도구와 같다. 각 도구가 어떤 기능을 하는지 이해하고 상황에 맞는 도구를 선택할 수 있어야 한다.

 

— 프로토타입 사용성 테스트

• 목적: 사용자가 솔루션을 사용하는 방법을 알고 있는지 테스트한다.
• 목적 아님: 사용자가 솔루션을 사용하고 싶은지 테스트하는 것은 아니다.

진행 방식: 클릭할 수 있는 프로토타입을 보여주고 솔루션과 관련된 작업을 수행해 보도록 요청한다.

예를 들면 “사진을 업로드하는 방법을 보여주시겠어요?” 라고 묻는다.

 

이때 해야할 일은 조용히 관찰하며 메모하는 것이다.

사용자가 어떤 버튼을 클릭해야 하는지 직관적으로 알고 있는가?

특정 작업을 수행할 때 무슨 일이 일어날지 이해하고 있는가?

텍스트가 그들을 헷갈리게 만들지는 않는가?

 

이 테스트는 소중한 엔지니어링 자원을 낭비하지 않기 위한 빠르고 적은 비용의 방법이다. 

usertesting.com 같은 플랫폼을 사용해 퇴근 전 테스트를 설정하면 다음 날 결과를 확인할 수 있다.

 

아주 작은 스타트업에서는 usertesting.com이 너무 비쌀지도 모른다.

그럴 경우에는 이미 제품에 너무 익숙하지 않은 누군가에게 프로토타입을 테스트할 수 있다.

 

— 기능을 점진적으로 출시

기능을 전체 사용자에게 한 번에 제공하는 대신 점진적으로 배포하는 것이다. 다음과 같은 경우에 유용하다.

1. 기능이 문제를 일으키지 않는지 확인하고 싶을 때: PM으로서 ‘통제 지표(control metrics)’가 무엇인지 이해해야 한다.
   통제 지표란 앱의 충돌 비율이나 고객 불만 건수와 같이 새로운 기능을 출시하면서 피해를 받지 않기 바라는 요소를 말한다.
2. 기능의 영향을 측정하고 싶을 때: 특정 사용자 그룹에게만 기능을 배포함으로써 (반대로 소수의 그룹을 보류해 기능을 제공하지 않음으로써) 기능이 목표하는 지표에 미치는 영향을 확인할 수 있다. 확실한 결과를 위해 사용자는 고르게 분포해야 한다.
   P.S.: 기술적으로는 이 방법도 A/B 테스트에 해당하지만 여기서는 A/B 테스트를 두 가지 이상의 다른 솔루션을 테스트할 때만 사용한다.

피해야 할 때: 사용자가 솔루션을 간절히 기다리고 있고, 출시할 기능이 상황을 더 나쁘게 만들지 않는 경우.

상황이 심각하다면, 기능의 영향을 측정할 수 있는 기회조차 포기해야 한다.

 

— A/B 테스트 수행

A/B 테스트는 말 그대로 솔루션 A와 B를 비교해 어느 쪽이 더 나은 성과를 내는지 확인하는 것이다. 프로토타입을 테스트할 수도 있고, 실제 환경에서 A/B 테스트를 할 수도 있다.

여러 버전을 테스트하는 A/B/C/D 테스트도 가능하며, 각 버전에 다른 구성 요소를 결합할 수도 있다. 이 테스트의 목표는 솔루션의 우승 버전을 식별하는 것이다.

구글이 41가지 파란색을 테스트하여 2억 달러의 수익을 얻은 사례를 들어보았을 것이다. 다만 수 백만 또는 수 십억 사용자가 있는 대형 서비스가 아닌 이상 지나치게 A/B 테스트에 집착할 필요는 없다.

예를 들어 사용자를 유료 고객으로 전환하는 중요한 과정인 ‘획득(acquisition)’과 ‘활성화(activation)’ 과정은 철저하게 개선해야 하지만 이 과정에서의 $$ 효과는 쉽게 측정할 수 있다. 하지만 사용자가 업무를 수행하기 위해 제품을 실제로 사용하는 과정에서는 간단한 A/B 테스트가 적절하다.

---

 

비판적 평가 (그리고 신중한 반론 제기)

이 지점부터 프로덕트 매니저와 디지털 프로젝트 매니저의 차이를 결정짓는 요소라고 할 수 있다.

프로젝트 매니저의 역할은 프로젝트를 성공적으로 전달하는 것이다.

문제는 이미 다른 사람이 정의했고, 해결할 가치가 있다고 판단했으며, 실행할 해결책도 마련했다.

 

해결책을 비판적으로 평가하는 것(“이 문제를 해결하는 더 나은 방법이 있을까?”)과 문제 자체를 평가하는 것(“이 문제가 해결할 가치가 있는가?”)은 프로덕트 매니저의 사고를 한 단계 발전시키는 요소이다. 때로는 이해 관계자에게 "아니오"라고 말하거나 반론을 제기하는 것을 의미할 수도 있다.

 

그리고 어떤 경우에는 인하우스 PM과 에이전시 PM의 차이일 수도 있다. 에이전시는 특정 프로젝트를 실행하기 위해 고용되는 경우가 많다. 만약 에이전시의 PM이 프로젝트가 전혀 필요하지 않다고 결론을 내린다면 에이전시는 그다지 즐거워하지 않을 것이다.

이미지 출처 : 원본 포스트

“이 문제를 해결하는 더 나은 방법이 있을까?”

“더 나은” 해결책을 정의하는 방법은 여러 가지가 있다.

“더 나은 것”은 더 빨리 구축할 수 있거나, 통합 비용이 저렴하거나, 장기적으로 비즈니스에 더 가치가 있거나, 단기 문제를 더 효과적으로 해결할 수 있음을 의미할 수 있다.

프로덕트 매니저로서 문제의 전략적 중요성을 이해하는 것은 중요하며 이를 통해 해결책에 적합한 제약 조건을 설정할 수 있다.

이후 팀원들(엔지니어, 데이터 과학자, 디자이너)의 전문성을 모아 제약 조건을 만족하는 다양한 해결책을 찾아야 한다.

 

— 문제의 전략적 중요성 이해하기

종종 하나의 원칙으로 팀에게 지시하는 PM들을 봐왔다.

이 원칙이 신속성일 수도 있고(“가능한 한 빨리 이걸 내보내야 해”) 최고의 사용자 경험일 수도 있으며(“우리 제품은 세계 최고 수준이어야 해”), 다른 것이 될 수도 있다. 문제는 이들이 모든 문제와 해결책이 동일하지 않다는 점을 인식하지 못할 때 발생한다.

 

프로덕트 매니저로서 다음을 명확히 설명해야 한다.

• 이 작업을 통해 달성하고자 하는 회사의 목표는 무엇인가?
• 해결하려는 사용자 문제는 무엇인가? (그리고 그것이 문제라는 것을 어떻게 아는가?)
• 문제를 해결했는지 어떻게 알 수 있는가? 영향을 미칠 결과 지표는 무엇인가? 측정할 출력 지표는 무엇이고 그것이 결과 지표에 어떻게 영향을 미칠 것인가?

— 팀에 맥락과 제약 조건 제공하기

수 많은 페이지에 달하는 PRD(제품 요구 사항 문서)를 작성하거나 이것을 엔지니어에게 "넘겨주는" 방식은 좋아하지 않는다.

대신 맥락(회사 목표, 사용자 문제, 지표 등)과 제약 조건을 제공해야 한다. 제약 조건은 다음과 같다.

• 자원 (시간과 엔지니어 수)
• 사용자 세그먼트
• 다루거나/다루지 않을 특이 케이스

모든 사람에게 완벽한 무언가를 만드는 것이 항상 목표가 아니라는 것을 기억하자.

예를 들어, 특정 사용자 세그먼트 X를 위한 빠르고 간단한 솔루션을 원하고, 엣지 케이스 Y와 Z는 고려하지 않는다고 말하는 것도 괜찮다.

이러한 선택을 신중하게 고려하고 타협에 만족하는 경우에 한한다.

(이미지 출처 : 원본 포스트) 과도하게 명세를 작성하는 것은 좋지 않지만, 이를 충분히 이해하고 있어야 한다.

 

— 팀의 전문성을 모아 해결책 도출하기

이제 한 발 물러서서 팀이 빛을 발할 기회를 주어야 할 시간이다.

팀이 독자적으로 사고하고, 기술적 탐구를 하며, 와이어프레임을 만들 시간을 준다. 여전히 가이드라인 제공, 조언, 명확한 설명은 필요하다.

최종적으로 여러 좋은 해결책이 도출되었다면 결정을 내리는 것은 PM의 역할이다.

 

디자인 스프린트는 이 과정을 진행할 수 있는 하나의 방식이다.

다른 방법은 정기 스프린트에 이를 통합하는 방법으로 듀얼 트랙 애자일이라고도 한다.

전자는 팀의 사고 및 작업 방식을 새롭게 해야 하는 큰 프로젝트나 신규 프로젝트에 적합하다.

후자는 팀이 달성해야 할 전달 목표가 있는 경우에 더 간편하고 덜 방해가 된다.

 

“이 문제를 해결할 가치가 있는가?”

회사에서 프로덕트 중심으로 운영되는 정도에 따라, 문제의 해결할 가치에 대해 질문하는 것은 쉽지 않을 수 있다.

프로덕트 요청은 매우 고위의 이해 관계자나 심지어 CEO로부터 올 수도 있으며, PM은 신중히 선택하여 대처해야 한다.

 

Meta에서 자주 쓰는 말처럼 “선의는 가정하고, 능력은 가정하지 않는다”는 입장이라면 모든 프로덕트 아이디어와 요청은 일정 레벨의 가치를 지닙니다. 완전히 쓸모없는 요청은 없겠지만 반론을 제기하기가 더욱 어렵기도 하다.

 

이에 도움이 될 도구들을 소개한다.

 

— 영향력 수치화하기

가장 기본적인 방법이지만 다시 언급할 만하다. 다음 요소들을 고려해 영향을 수치화하고 이를 달러 가치로 변환할 수 있다.

• 도달 범위: 영향을 받는 사용자 수
• 강도: 사용자들이 현재 상태에서 겪는 불편함의 정도
• 사용자 세그먼트: 사용자 세그먼트가 회사에 얼마나 중요한가(도달 범위는 작더라도 이 사용자들이 회사 매출의 절반을 차지할 수 있다)

가능한 한 주관성을 줄이기 위해 명확한 데이터와 수치를 가져와야 한다.

 

— 기능의 진정한 비용 이해하기

기능 구축 비용을 추정하는 일은 비교적 간단하다. 엔지니어로부터 시간을 추정 받아 급여로 곱한다.

그러나 구축 비용 외에도 다른 종류의 비용이 있다는 점을 기억해야 힌다.

• 유지 비용: 일단 기능이 라이브 상태가 되면 이를 유지하고 발생하는 문제를 해결할 책임이 있다.
• 복잡성 비용: 이 기능으로 인해 코드 베이스가 더 복잡해지고, 다른 기능을 구축할 때 추가된 복잡성으로 인해 시간이 더 걸린다. 신규 팀원은 코드 베이스를 이해하는 데 더 많은 시간이 필요하다.
• 개선 비용: 기능이 출시 후 문제를 완벽히 해결할 것이라고 기대할 수 있지만 매우 드믄 경우다. 수정을 통해 설정을 조정하거나 복사본을 변경해야 할 수 있다.
• 조정 비용: 팀은 회의에 참석하고, 이메일을 작성하고, 업데이트를 보고하고, 관련 팀에 사전 통보를 해야 한다.
• 그리고 당연히 기회 비용도 고려해야 한다: 우리가 시간을 어떻게 사용할 수 있었을까? 놓친 기회로 인한 손실은 어느 정도인가?

이미지 출처 : 원본 포스트

 

— 시급성 이해하기

항상 “이 문제가 해결할 가치가 있는가?”만이 중요한 것은 아니다. “왜 지금인가?”라는 질문이 중요할 수 있다.

 

벽에 생긴 작은 균열은 지금 당장은 큰 영향을 주지 않지만, 이를 무시하면 나중에 큰 문제로 번질 수 있다.

해결하지 않았을 때 발생할 비용과 지연의 비용을 이해하는 것은 문제의 긴급성과 중요성을 이해하는 데 도움이 된다.

다음과 같은 비유를 들어보자.

• 일부 문제는 불과 같아 즉시 해결하지 않으면 나중에 새로 구축해야 한다.
• 다른 문제는 천장의 누수와 같아 시간이 지나면서 점점 더 악화되다가 결국에는 전체가 무너질 수 있다.
• 또 다른 문제는 물웅덩이처럼, 다소 성가시긴 하지만 모두가 이를 피해 다닌다면 해가 없다.

— 신중한 반론 제기

모든 과정을 거치고 나서 이 문제가 지금 당장은 해결할 가치가 없다고 확신하게 되었다.

반론을 제기하는 것은 일의 필수적인 부분이며, 워런 버핏이 말하길, “성공한 사람과 정말 성공한 사람의 차이는 정말 성공한 사람은 거의 모든 것에 ‘아니오’라고 말하는 것”이라 했다.

 

나의 반론 제기 원칙은 다음과 같다:

• 단도직입적으로 말하라: 그들의 요청을 수행하지 않을 것이라면 빠르고 명확하게 말한다.
• 요청을 신중히 검토했음을 보여라: 이 결론에 도달한 사고 과정을 설명한다.
• 팀이 수행 중인 일을 보여라: 그들이 더 가치 있는 무언가를 구축 중임을 명확하게 설명해야 한다.

— 의견 차이가 있어도 맡은 일에 전념하기

최고위급 의견(HiPPO, Highest Paid Person’s Opinion)이 나오면 그 의견에 동의하지 않더라도 그 작업을 수행해야 하는 경우가 있다. 팀에 불만을 표출하고 싶은 유혹이 들 수도 있다.

 

아마존의 제프 베이조스는 이견을 갖고도 헌신하기(disagree and commit) 개념을 주장했는데 개인적으로 매우 좋아하는 개념이다.

(아직 읽지 않았다면 전체 내용을 읽어보는 것을 추천한다.)

백그라운드에서 이견이 있었을지라도, PM이자 팀 리더로서 리더십과 일치하는 입장을 견지하고 이 작업을 지지해야 한다.

---

전략적 기회 발굴

이제 가장 높은 수준의 불확실성을 다루고 있다. 문제와 해결책이 모두 불분명한 상태이다.

이때는 한 걸음 물러서서 큰 그림을 볼 수 있는 좋은 기회가 될 수 있다.

이미지 출처 : 원본 포스트

 

우리가 주목해야 할 가장 가치 있는 문제는 무엇인가?

이 질문에 답하려면 사용자가 제품을 사용하는 이유와 방식, 그리고 다른 제품으로 이동할 때 고려하는 요소를 깊이 이해해야 한다.

하버드 대학교의 클레이튼 크리스텐슨 교수는 2016년에 이러한 프레임워크를 처음 소개했으며 이후로 가장 신뢰 받는 프로덕트 개발 프레임워크 중 하나가 되었다.

 

— 사용자 ‘할 일(JTBD)’ 이해하기

JTBD의 핵심은 사용자가 제품을 “고용”할 때 이루고자 하는 목표가 무엇인지 이해하는 것이다.

이 답은 일반적으로 표면적으로 드러나는 것보다 깊다.

예를 들어, 당신이 관리하는 제품이 MBA 프로그램이라면, 사람들이 MBA를 하는 이유는 직업 전환, 현재 경력 발전, 창업 준비 등 다양하다.

 

이러한 이유를 더 깊이 파고들 수 있다. 예를 들어, 현재 경력을 발전시키기 위해 MBA를 한다고 답한 사람들의 경우, 그 진짜 의미가 무엇인가? 현재 어떤 점이 그들을 막고 있는가? 자신감이 부족한지, 지식의 격차가 있는지, 아니면 단순히 학위를 통해 자격을 입증하고자 하는 것인가?

 

이러한 깊은 이유를 이해하는 것은 사용자의 요구를 더 잘 충족할 수 있도록 제품을 개선할 수 있는 기회를 발굴하게 할 수 있다.

 

— 사용자의 전환 요인 이해하기

사용자가 제품을 사용하기로 결정할 때 그들은 전에 사용하던 것으로부터 전환한다.

심지어 이전에 특정 ‘제품’을 사용하지 않았더라도 적용된다 ㅡ‘아무것도 하지 않는 것’도 대안이 된다.

 

전환 결정에는 네 가지 힘이 작용한다.

• 밀어내는 요인: 현재 솔루션의 불만과 문제점
• 끌어당기는 요인: 새로운 솔루션의 장점 또는 혜택
• 불안감: 새로운 솔루션에 대한 우려와 걱정
• 관성: 기존 솔루션에 대한 편안함과 익숙함

PM으로서 사용자의 전환 요인을 파악해 전환 장벽을 능동적으로 낮추는 것이 중요하다.

MBA 예시를 통해 네 가지 요인을 살펴보자.

(이미지 출처 : 원본 포스트) 예시: 파트타임 MBA를 선택하는 데 영향을 미치는 네 가지 요인

 

제품의 미래 대비는 어떻게 할 수 있을까?

제품 개선은 현재의 영역에만 국한되지 않는다. 급진적인 혁신은 대개 외부에서 시작하며 점진적 개선으로는 도달하기 어렵다.

 

— 제품의 경쟁 환경 이해하기

이전 섹션에서 논의한 것처럼, 제품의 경쟁자는 단순히 겉으로 드러나는 것들만이 아니다.

X 대학의 MBA 프로그램은 Y 및 Z 대학과 경쟁할 뿐만 아니라, 부트캠프, 온라인 강좌, 팟캐스트, 임원 코칭, 심지어 넷플릭스와도 경쟁하고 있다.

이러한 대안들을 매핑하고 제품과 비교할 때 고객의 니즈를 또 다른 축으로 삼아 각 제품이 그 니즈를 얼마나 충족시키는지 평가할 수 있다. 아래에 예시가 있다.

이미지 출처 : 원본 포스트

P.S.: 여기에 더해 다음과 같은 보완 작업을 수행하는 것도 유용하다:

(1) 사용자 세그먼트 매핑 — 각 세그먼트는 다른 요구를 가지고 있으며, 모든 세그먼트가 동일한 비즈니스 가치를 가지는 것은 아니다,

(2) 니즈를 위생 요인, 성능 요인, 만족 요인으로 분류 — 카노 모델로 알려져 있다. 이 글이 이미 길어지고 있으니 생략한다.

 

이제 MBA 프로그램의 프로덕트 매니저로서 기존 MBA를 대체할 완전히 새로운 제품을 구상한다고 가정한다.

고객의 니즈 맵을 활용해 현재 사용 가능한 솔루션이 충족하지 못하는 니즈를 찾아내고 강력한 가치를 제안하는 새로운 프로그램을 만들어낼 수 있다.

 

— 제품의 가치 사슬 확장 기회 식별하기

제품을 위협하는 요소는 단순히 경쟁자나 새로운 진입자만이 아니다.

마이클 포터가 5가지 경쟁 요인 분석에서 설명한 바와 같이 다른 여러 요인이 작용할 수 있다.

그의 프레임워크는 고객과 공급업체의 협상력을 인식하는 것에 관한 것이다. 공급업체가 가격을 올려도 다른 선택지가 없다면 곤란하다.

고객이 쉽게 다른 곳으로 갈아타거나 가격을 낮출 수 있다면 문제일 것이다.

 

제품의 장기적인 성공 가능성을 높이고자 한다면 당신의 협상력을 높여 고객과 공급업체의 협상력을 낮추는 것이 필요하다.

포터의 이론은 일리가 있지만, 이러한 접근은 한쪽이 손해를 보는 파워 게임을 시사하는 느낌이다.

나는 이것을 다른 방식으로 생각하는 것을 선호한다. “어떻게 하면 제품의 가치 사슬을 확장할 수 있을까?”

 

Shopify를 예시로 들어보자. Shopify는 온라인 스토어 빌더로 시작했다.

소규모 사업자는 브랜드와 스토어 테마를 설정하고 상품을 추가하면 15분 만에 온라인 스토어를 개설할 수 있다.

초기 목표 고객은 이미 사업과 판매할 물건을 가지고 있으면서 온라인 존재감을 필요로 하는 사람들이었다.

이후 Shopify는 또 다른 기회를 발견했다. 아직 무엇을 판매할지 모르는 창업 준비자들을 위한 시장이다.

Shopify는 도매 시장과 드롭쉬핑 서비스를 추가했다.

(이미지 출처 : 원본 포스트) 온라인 스토어 관리의 간소화된 가치 사슬

온라인 스토어 관리의 다음 단계는 주문을 처리하여 고객에게 배송하는 것이다.

Shopify는 이를 위한 자체 물류 네트워크도 제공하면서 영역을 확장했다.

 

Shopify는 고객이 다른 서비스로 갈아타기 어렵게 하면서 새로 진입하는 경쟁자가 고객을 뺏어가기 어렵도록 만들었다.

이는 Shopify뿐 아니라 고객에게도 이득이다.

 

적용할 점: 고객이 JTBD를 달성하기 위해 거치는 과정을 매핑한다. 고객이 제품을 사용하기 전후의 과정에서 지원하여 당신의 가치를 확장할 방법이 있는가?

---

모든 내용을 하나로

길고 긴 글을 읽어주셔서 감사하다. 이 글에서 한 가지 핵심만 가져간다면 바로 이것이다:

모든 상황에서 항상 효과적인 단 하나의 도구는 없다.

프로덕트 매니지먼트 기술을 향상하기 위해 1) 사용할 수 있는 도구의 수를 늘리고, 2) 각 도구를 언제 사용할지 아는 것이 중요하다.

(이미지 출처 : 원본 포스트) 긴 글 요약 : 이 글에 나온 도구들이 모든 것을 망라한 것은 아니다.

 

끝으로 짧은 메모를 덧붙이고자 한다. 빠지면 안 되는 두 가지 함정이 있다.

1. 문제와 해결책을 지나치게 의심하는 것: 더 스마트해 보이기 위해, 혹은 시니어 프로덕트 매니저처럼 보이기 위해 가장 고급스러운 도구를 사용할 필요는 없다. 생각하는 비용이 구축하는 비용보다 높다면 그냥 만들고 출시하는 것이다. 시장이 답을 알려줄 것이다.
2. 문제와 해결책을 거의 의심하지 않는 것: 이는 보통 신입 PM(다른 사람이 이미 문제와 해결책을 명확히 했다고 생각함)이나 오래된 PM(회사와 사용자, 도메인에 너무 익숙해져 당연하게 여김)에게서 나타나는 버그다. 참고로 “신입”과 “오래된”은 나이가 아니라 회사에서의 근속 연수를 의미한다.

문제나 해결책에 대한 명확성에 확신이 없다면, 한 가지 팁이 있다. 글로 써 보는 것이다.

보도 자료, 고객 감사 편지, 혹은 문제와 해결책을 설명하는 간단한 서술문 형태로 작성할 수 있다.

---

👋 안녕하세요, 저는 데비입니다. 제품 운영자로 12년 이상 제품을 개발해 왔습니다. 현재 Zero Gravity의 최고 프로덕트 책임자(CPO)로 일하고 있으며, 이전에는 Shopify와 Meta에서 근무했습니다. 저는 프로덕트 제작을 처음 원칙으로 되돌리는 것, 즉 사용자와 비즈니스에 가치를 전달하는 것을 목표로 한 제품 구축에 대해 이야기합니다. 그 가치가 긍정적인 사회적 또는 환경적 영향을 미친다면 더욱 좋겠죠. 트렌드를 앞서가고 싶으신가요? 제 뉴스레터를 구독하셔서 인사이트를 받아 보세요!

---

🔗 게시글의 원본 링크는 다음과 같습니다.

https://medium.com/@debbiewidjaja/how-senior-product-managers-think-differently-c5d8cd0cb52c

How senior product managers think differently

 

🍀 한국어로 읽기 편하게 일부 의역한 부분도 있지만, 오탈자나 잘못된 번역이 있다면 댓글로 알려주시면 감사하겠습니다.