11.22 수 ( p.1 ~ p.44 )
프로덕트 성공을 위해 고려해야 하는 점은 단계별로 다르다
프로덕트가 어떤 단계에 놓이는지에 따라서 풀어야 하는 질문도 달라진다. 경험하지 못한 자는 생각할 수 없다. 10 → 100 단계를 해낸 사람은 0 → 1 단계에 대해 알지 못하며, 반대로 0 → 1 단계만 한 사람은 10 → 100 단계를 알지 못한다. 이 모든 단계를 경험한 PO가 되고 싶다.
•
0 → 1 단계 : PMF를 찾았는가?
•
1 → 10 단계 : BM을 찾았는가?
•
10 → 100 단계 : 스케일업을 어떻게 할 것인가?
11.23 목 ( p.44 ~ p.60 )
이 책에서 이야기하는 프로덕트란 대체로 광의의 프로덕트를 말한다. 즉 PM은 사업(=프로덕트)의 성공에 대한 책임을 진다.
단어의 정의에 따라 관점이 달라진다. 프로덕트의 정의를 “개발 부서가 만드는 산출물”로 정의한다면, 개발적 관점으로 접근하게 된다. 하지만 프로덕트를 “사용자에게 가치를 제공하는 수단”으로 정의한다면, 개발을 넘어서 CS, 세일즈, 마케팅 등 더 넓은 차원에서 접근이 가능해진다.
책을 읽으며, 프로덕트에 대한 나만의 정의를 내렸다. 내가 정의한 프로덕트란 “미션을 달성하기 위해 고객에게 가치를 전달해 수익을 발생시키는 수단”이다. 고객 가치만 추구하면 프로덕트는 생존할 수 없고, 수익만 추구하면 프로덕트는 사랑 받을 수 없다. 설령, 이 둘을 모두 충족한다고 해도, 프로덕트가 나를 설레게 만들지 못하면 안 된다. 이 정의를 잊지말고, 항상 되새김질하자.
11.24 금 ( p.60 ~ p.80 )
대강의 장기 계획을 세우는 것은 물론 중요하지만 아무리 계획을 세운다 한들 그 전제인 가설이 뒤집히면 계획은 의미를 잃기 때문이다.
PM의 역량 중엔 ‘버릴 수 있는 용기’가 있지 않을까? PM은 다양한 가설을 설정하고, 이 가설을 검증하는 싸이클을 반복하며 프로덕트의 성장 방향을 찾는다. 하나의 가설을 검증한 후, 배운 바를 바탕으로 새로운 가설을 설정해 다시 검증한다. 마치 탑을 천천히 쌓듯이 각 가설들은 차근차근 이어진다. PM은 가설들이 연속적으로 이어지고, 차근차근 검증할수록 프로덕트의 성장 방향이 명확해지길 원한다.
하지만, 현실은 우리의 바램과 다르게 흐른다. 연속적인 가설들을 검증한 결과, 이 모든 가설이 잘못됐거나 혹은, 큰 임팩트로 이어지지 않음을 깨닫게 된다. 이 순간 PM은 그 동안 해온 모든 것들 버리고, 완전히 새로운 시작을 해야 한다. 하지만 버리는 것은 두렵고 무섭기에 주저하게 되고, 결국 의미 없는 가설에 계속 매달리게 된다. 그 동안의 노력이 아쉽지만, 이를 과감히 버릴 수 있어야 한다. 그래야 팀의 리소스를 의미 없게 낭비하지 않고, 더 올바른 방향을 향해 사용할 수 있다.
11.28 화 ( p.80 ~ p.91 )
프로덕트 세계관을 설정할 때는 추상화 수준에 유의해야 한다. … 많은 사용자에게 널리 영향력을 행사하려면 어느 정도는 크게 세계관의 규모를 확보해야 한다 … 프로덕트 세계관이 너무 구체적이면, 지금 진행 중인 것과 방향이 다른 새로운 프로덕트를 모색하기가 매우 어려워져 사업을 포기하는 일도 생긴다..
책에서는 프로덕트의 기획 순서를 “핵심”, “기획 의도”, “구상”과 “실현” 순이라고 말하며, 앞 단계는 뒷 단계의 의사결정에 영향을 준다고 말한다. 예를 들어, 프로덕트에서 어떤 기능을 기획할 때, 프로덕트의 세계관(=미션과 비전)에 얼라인 되는지를 가장 먼저 고민해야 한다.
돌이켜보면 내가 기능을 기획한 과정에 프로덕트의 세계관은 큰 요소가 아니였다. 관찰한 현상에서 문제를 정의하고, 이를 해결하기 위한 기능을 기획했는데, 여기서 발견한 문제가 프로덕트의 세계관과 얼마나 관련 있는지 고민하지 않았다. 문제의 중요도는 프로덕트의 세계관을 기준으로 둬야 함을 잊지 말자
11.29 수 ( p.91 ~ p.102)
프로덕트 미션과 비전을 충족하는 가치는 무엇이며 그 가치에 공감하는 사용자는 누구인지를 잘 검토해야 한다
작중에서 고객의 니즈와 페인포인트의 정의를 “과업”에 기반한다. 이는 사람의 생각이 특정한 행동을 하면서 발생하기 때문이다. 본질을 보고 싶다면, 본질을 유추할 수 있는 증거를 놓치지 말자
11.30 목 ( p.102 ~ p.120 )
”사용자“를 주어로 하는 관점, 그리고 “비전”을 주어로 사고하는 관점 양쪽 모두가 중요하다.
프로덕트가 가져야 하는 필수 조건은 2가지다. 사용자의 니즈를 충족하는 것과, 프로덕트의 미션과 비전을 이루는 것. 둘 중 어느 한 쪽만 있어도 안 되며, 이 둘은 서로를 상호 보완하며 나아가야 한다.
다만, 현실에서 프로덕트의 세계관과 사용자의 니즈에 충돌이 일어나는 순간이 필수적으로 발생한다. 딜레마 앞에서 우리의 선택지는 사용자를 제외하거나, 이 둘을 어떻게든 조율하거나 혹은, 프로덕트의 세계관을 재정립해야 한다.
과거에는 프로덕트의 미션과 비전은 절대적이며 모든 의사결정은 이 기준을 따라야 한다고 생각했다. 그러다보니, 프로덕트의 세계관과 사용자가 양립하기 어려운 순간에 처할 때, 엄청난 스트레스를 받았다. 미션과 비전을 따르는 것도 좋되, 이를 수정할 가능성도 열어둬야 한다.
12.01 금 ( p.120 ~ p.146 )
출시까지의 마일스톤을 정해진 기일, 예산, 품질을 만족하면서 진행하는 것이 PM의 책무다.
프로덕트 빌드 기간 동안 PM이 온 신경을 쏟아야 하는 3가지 요소는 기일, 예산과 품질이다. PM에겐 ”정해진 기간 동안 얼만큼의 예산을 들여, 얼만큼의 퀄리티를 지닌 결과물을 만들 것인가?”라는 질문에 답해야 하는 의무가 있다. 목표한 기일을 지키지 못하면 의미가 없고, 기일을 지켰다고 한들 예산이 과도하거나 혹은 품질이 낮아도 의미가 없다.
기일, 예산과 품질을 위해 팀이 하나의 방향으로 나아가야만 한다. 팀원 개개인이 서로 다른 그림을 그리면, 업무의 순서가 서로 맞지 않아 병목이 생겨 기일을 맞추기 어렵고, 불가피한 조정 비용이 발생하며, 각자의 업무 결과물이 달라서 높은 품질을 이뤄낼 수 없다.
PM이 주구장창 작성하는 로드맵, 비즈니스 캔버스, 린 캔버스는 팀원들이 같은 그림을 갖게 만드는 수단이자 팀의 기반과도 같다. 지금 당장 처리해야 하는 업무가 있어서 이를 작성하는 걸 등한시 하는 것은 기초 공사 없이 건물을 쌓는 꼴이 된다
12.04 월 ( p.146 ~ p.176 )
NSM은 ‘프로덕트의 핵심이 되는 가치가 사용자에게 전달되고 있는지 알 수 있는 단 하나의 지표’라고 정의할 수 있다.
작중에서 NSM(북극성 지표)는 5가지 조건을 충족해야 한다고 말하며, 이 조건은 (1) 사용자 수, (2) 핵심 가치, (3) 수익으로 구성된다. 예를 들어, NSM을 수익만 고려해 설정한다면, 프로덕트의 핵심 가치를 향상시키는 걸 뒷전으로 둘 수 있다. 반대로, 핵심 가치만 고려한다면, 프로덕트의 지속성을 잊게 된다.
앞선 3가지 구성 요소는 각각 고객, 프로덕트, 기업과 직접적으로 연관됐다. “고객이 많은지 대변하는 지표인가?” “프로덕트의 핵심 가치를 대변하는 지표인거?” “기업의 수익을 대변하는 지표인가?” NSM을 선택하기 위해 사용자를, 프로덕트를, 기업을 모두 중심으로 보는 관점이 필요하다.
12.05 화 ( p.176 ~ p.190 )
프로덕트가 완성되고 나서 지불 용의 가격을 결정하는 건 너무 늦다. 무엇을 만들지 어느 정도 윤곽이 잡힌 단계에서 프로덕트 가치를 바탕으로 가격 산출에 대한 검토를 시작해야 한다.
프로덕트의 가치와 가격은 선후 관계가 아닌, 상호 관계를 맺고 있다. 예를 들어, 결제를 하기 전에 고객은 프로덕트의 가치를 예측해 가격의 타당성을 검토한다. 동시에, 가격이 너무 낮으면, 프로덕트의 가치에 의구심을 갖는다. 전자는 가치가 가격에, 후자는 가격이 가치에 영향을 주는 케이스다. 결국, 프로덕트의 가격은 어떠한 가치를 제공할지 결정한 시점부터 함께 고민을 해야 한다.
가격은 프로덕트의 가치의 정량적 수치라고 볼 수 있다. 다만, 가치의 가격 변환 과정은 명쾌하지 않다. 예를 들어, “고객의 송금을 쉽게 만든다”라는 가치는 얼만큼의 가격으로 변환시킬 수 있을까? 이에 대한 해답으로 작중에서 판페스텐도르프법(a.k.a PSM법)을 소개한다. PSM법은 고객에게 4가지 분기점을 물어보고, 이를 활용해 지불 용의 가격 구간을 알아내는 방식이다. 고객에게 “너무 저렴해서 오히려 불안하다고 느껴지는 가격”, “비교적 저렴한 가격”, “비교적 비싼 가격”, “너무 비싸서 절대 안 살 가격”를 물어보고, 각 대치점의 분기점을 아래 그래프처럼 비교해 지불 용의 가격 구간을 알아내는 방식이다.
12.07 목 ( p.190 ~ p.212 )
PM 의사결정 권한 범위와 더불어 무엇을 누구와 상담해 결정할지를 사전에 명확히 해두기 바란다.
프로덕트 기획부터 출시까지 많은 이해관계자가 존재하며, PM은 모든 이해관계자와 소통해야 한다. 이들과 소통을 등한시 여길 경우, 관계자가 정보를 얼라인하지 못해 예기치 못한 이슈가 발생할 수 있다. DACI 기법은 이해관계자를 4가지 기준으로 분류한다. 상황에 맞는 프레임워크는 사고의 효율성을 높여주는 걸 잊지 말자
•
추진자(Driver) : 업무를 중심에서 리드하는 자
•
승인자(Approver) :업무를 최종 승인하는 자
•
기여자(Contributor) : 업무를 함께 하는 자
•
보고대상자(Infomred) : 업무 정보를 참고해야 하는자
12.11 월 ( p.212 ~ p.229 )
이 사실은 심리적 안정감 고취의 양면성을 보여준다. 조직에서 심리적 안정감이 높아지면 업무 과실 은폐 등의 문제는 확실히 줄어든다. 그러나 온정주의가 나타날 가능성도 배제할 수 없다.
PM은 프로덕트를 성공시켜야 하는 과업을 지닌다. 프로덕트는 PM 혼자만이 아닌, 팀 전체의 결과물이다. 그리고 팀의 결과물이 좋게 만드려면, 팀의 올바른 업무 문화와 분위기가 잡혀야 한다. 토양이 좋을수록, 자라나는 식물도 좋아진다.
올바른 업무 문화가 자리 잡히도록, PM은 “심리적 안정감”과 “책임 의식”이 공존하는 환경을 만들어야 한다. 심리적 안정감이 느껴질수록, 팀원은 자신의 의견과 생각을 공유하는 데 부담을 느끼지 않는다. 이때, 책임 의식이 존재하지 않는다면, 자신이 공유한 의견과 생각의 무게 중심은 없어진다. 즉, 단순히 이야기만 많이 하는 탁상공론 분위기가 자리 잡힌다.
12.14 목 ( p.229 ~ p.257 )
프로덕트를 개발할 준비를 마쳤다면 이제부는 PM은 적극적으로 이끌어가는 대신 프로덕트 팀에게 공을 넘겨야 한다. 그 후 PM은 적절한 시점에 필요한 의사결정을 담당한다. 그후 PM은 적절한 시점에 필요한 의사결정을 담당한다.
PM은 팀원 모두가 동일한 그림을 생각하도록 만들어야 하는 책무가 있다. 이 책무는 팀원, 각자가 동일한 그림을 전제로 자유로운 의사결정을 내려 주체적인 행동을 할 수 있는 환경을 만들기 위함이다. 프로덕트를 잘 만드는 사람은 PM이 아니라, 개발자나 디자이너다. PM은 “어떤 프로덕트가 필요한가?”를 답할 수 있지만, “필요한 프로덕트를 어떻게 만들어야 하는가?”를 잘 답할 순 없다. 오히려 후자의 질문은 개발자나 디자이너가 더 옳은 판단을 내릴 수 있기에, PM은 팀원들이 주체적인 판단을 내릴 수 있는 환경을 만들어야 한다.
12.26 화 ( p.257 ~ p.280 )
선각 수용자가 ‘가치의 새로움’에 주목하는 데 반해, 곧 이어 설명할 전기 다수 사용자는 ‘가치의 실익‘을 추구한다.
출시한 서비스에 대한 사용자 반응이 좋다고 안도하면 안 된다. 사용자가 출시하지 얼마 안 된 서비스를 선택하는 이유는 ‘가치의 실익’이 아닌, ‘가치의 새로움’에 있다. 즉, 초기 사용자는 새로운 서비스를 사용하는 것, 그 자체에 흥미를 느낀다. 이들을 바탕으로 가치를 검증했다고 말하는 행위는 위험하다
