PO, PM들의 존재이유를 알려주는 책, 인스파이어드

이 책은 나에게 많은 영감을 준 책이다. 지금 내가 무엇을 잘못하고 있는지, 당장 내가 무엇을 해야할지 아주 직설적으로 알려주는 책이다. 작년에 읽었을 때 너무 인상적이어서 2번 읽었는데..2021년을 회고하는 과정에서 다시 읽어보니 내가 올해에 무엇을 잘못했고 무엇을 간과했으며 내년에 무엇을 해야하는지 명확하게 알 수 있었다.

현재 회사는 성장하는 회사이고 매일 매일 다양한 문제들이 생겨난다. 그러다보니 각 팀에는 급한일이 항상 존재하고 PO인 나는 항상 급한일을 해결하는데 많은 시간을 소비한다. 그러다보면…나도 장기적인 시야를 잃거나 문제의 본질을 보지 못하거나 무의식적으로 외면하기도 한다.

이런 힘겨운 상황에서 다시 한 번 인스파이어드책을 읽음으로써 현재 상황에서 나에게 필요한 시야와 사고의 관점을 다시 회복할 수 있었다.

PM, PO와 같이 Product을 관리하는 입장에서 문제를 정의하고 이를 해결해야 하는 사람들에게는 꼭 필요한 책이다. 혹시 안 읽어봤으면 그냥 읽어보기 바란다.

이번 포스팅에서는 인스파이어드 책에 나온 몇 가지 중요한 포인트들에 대해서 이야기를 해보고자 한다.


제품개발에 대한 핵심개념

이 책은 기존 폭포수 개발방식의 문제점부터 시작한다. 그리고 애자일과 린의 원칙을 설명하며 제품개발의 핵심개념을 정의한다. 여기에서 중요한 것은 애자일과 같은 개발방법론 보다는 제품을 개발한다는 것의 본질적인 의미이다.

일반적으로 제품개발(Product 개발)이라고 하면 기획/디자인/개발 과정을 거쳐 Product이 완성되는 과정을 의미한다. 폭포수개발 방식 뿐만아니라 애자일 개발 방식에서도 기획/디자인/개발 과정은 필요하다. 그런데 인스파이어드 책의 저자 마티 케이건은 제품을 발견하는 과정과 제품을 시장에 전달하는 과정도 제품개발에 속한 과정이라고 정의한다. 제품을 발견한다는 의미는 문제를 정의하는 과정이라고 볼 수 있으며, 제품을 시장에 전달한다는 것은 일반적으로 우리가 흔히 말하는 마케팅의 과정이라고 볼 수 있다. 그런 의미로 볼 때 Product을 개발한다는 것은 영업/마케팅 조직의 비지니스 과정과 분리되어 있지 않다는 것을 의미한다.

제품은 판매와 분리되어 있지 않다. 제품을 만든다는 것은 사용자가 이용하기 편리하게 잘 만드는 것만 포함되지 않는다. 만들어진 제품이 시장에 전달되는 것까지가 제품을 만드는 과정이다.

제품팀은 기능을 구현하는 것이 아니라 문제를 해결한다. 전통적인 제품로드맵은 생산량에 대한 것이다. 강한 팀은 근원적인 문제를 해결한다. 이는 사업적인 성과에 대한 것이다.

인스파이어드 책 내용 중

따라서, 제품 개발과 판매가 하나의 패키지로 움직이려면 개발조직과 영업조직(혹은 비지니스 조직)이 하나의 패키지로 움직여야 한다. 이 두가지를 분리하면 기술조직과 비지니스 조직은 서로 다른 목표를 가지고 분리되어 움직인다. 필수적으로 이 두 조직이 함께 움직여야 기술조직은 기능구현이 아니라 문제를 해결하는 역할을 할 수 있으며 기능구현의 성과를 넘어 비지니스 성과를 낼 수 있다.

사실 나는 이 비슷한 이야기를 아주 오래전부터 들어왔다.(살다보니 망각할 뿐….) 대략..6년전에 작은마케팅 클리닉 이라는 강의를 들은적이 있는데 해당 강의에서도 동일한 이야기를 들었다.

아래 사진을 보면 애플 Mac은 이용자들이 스스로 제품 광고를 하고 있다. Mac은 제작 당시부터 마케팅을 함께 고려하여 상품안에 판매전략도 함께 녹아들어간 것이다. 따라서, 광고없이 상품으로 소통할 수 있는 것이다.

우린 명심해야 한다. 제품개발과 판매는 동시에 일어난다. 결코 분리될 수 없다.

출처 : https://www.slideshare.net/yibong/v-765-3-h20150918


제품발견과 가치테스트

일반적으로, 우리가 사업을 시작하거나 Product을 만들 때는 몇 가지 점검을 한다. 과연 이 비지니스 혹은 Product이 의미있는 성과를 낼 수 있는지를 알아보기 위해서이다. 책의 저자는 아래 4가지를 제시한다.

  • 가치 : 사용자 또는 고객이 이 제품을 사용하거나 구매할 것인가?
  • 사용성 : 사용자가 이 제품의 사용 방법을 이해할 수 있는가?
  • 실현 가능성 : 우리가 이것을 만들 수 있는가?
  • 사업 유효성 : 이 솔루션이 우리의 사업에 유효한가?

나는 보통 ‘실현 가능성’부터 고민을 하고 그 다음 ‘가치’부분을 고민한다. 이 두 가지를 먼저 고민하는 이유는 이 두 가지 중 하나라도 해결이 되지 않으면 다른 부분은 고민할 필요도 없기 때문이다. 그래서 책 부분중에 가치테스트 부분을 관심있게 읽었는데, 이 내용에는 내가 지난 주니어시절에 실수한 그 모든 내용이 들어가 있다.

정성적인 가치 테스트

정성적인 테스트는 무언가를 증명하는 것이 아니다. 그것은 정량적인 테스트의 목적이다. 정성적인 테스트는 빠른 학습과 통찰에 관한 것이다.

책 내용 중

나는 주니어시절 정성적인 테스트를 통해 내가 세운 가설을 검증하고 싶었던 적이 있었다. 그래서 내 가설에 맞는 내용의 인터뷰가 나오면 기분이 좋았다. 그런데 이것은 정말 심각한 모순이다. 인터뷰란 가설을 세우기 위해 학습을 하는 과정이기 때문이다. 정량적인 테스트(데이터 기반 의사결정)가 중요하다고 강조하는 사회 분위기 속에 휩쓸리면 이런 생각의 오류를 범하게 된다.

정량적인 가치 테스트 기법

  • 정성적인 테스트가 빠르게 학습하고 커다란 통찰을 얻는 것에 관한 것이라면, 정량적인 기법은 근거를 수집하는 것이다.
  • 새로운 기능을 추가하고자 한다면, 그 기능의 사용에 대한 최소한의 기본적인 분석정보를 심어 두어야 하나다. 그렇지 않으면 그 기능이 기대한 만큼 사용되는지를 나중에 확인하기 어렵다.

정량적 테스트의 중요성은 이미 다 알고 있다. 그래서 많은 기업들이 데이터를 활용하고자 방대한 양의 사용자 데이터를 쌓는다. 그런데 정량적인 테스트만을 강조해서 생각하다보면…….아래와 같은 시나리오의 실수를 저지르게 된다. 내 주변에도 이런 실수를 하는 분들이 정말 많다.

  • 목표는 없지만 데이터는 중요하므로…일단, 데이터를 쌓으려고 한다. 그런데 데이터를 쌓으려고 보니(예를들면, 사용자 로그 등) 생각보다 많은 노력이 들어가고 여러 엔지니어의 도움이 필요하다. 그러다보니 데이터 쌓는 것에 스스로 매몰된다. 목표는 없지만 데이터 쌓는 것에는 집착하는 사람이 되어간다.
  • 사용자 행동에 대한 학습이 되지 않은 상태에서 가설을 세우고 검증하려고 한다. 학습이 되지 않았으니 당연히 가설도 논리적이지 않다.

정성적인 가치 테스트와 정량적인 가치 테스트도 분리될 수 없다.

무엇이든지 한 가지 생각에 너무 집중하면 다른 한 쪽의 가치를 망각할 수 있다. 내 생각에는 정량적인 가치 테스트와 정성적인 가치 테스트는 서로 분리될 수 없다. 가설은 관찰을 통한 학습에서 나오기 때문이다.

논문을 작성할 때도 가설은 각종 문헌연구를 통해 합리적인 근거로 도출된다. 기존 논문들에 대한 학습과정을 통해 가설의 타당성을 확보하지 못하면 유의미한 통계가 나와도 해당 연구는 아무런 의미가 없다. 그냥 통계가 그렇게 나온 것일 뿐이다.

그래서 현재 재직중인 회사에서 나는 A/B 테스트 전에 되도록이면 Hotjar를 통해 사용자 이용행태를 먼저 관찰한다. Hotjar는 사용자가 Product을 이용하는 과정을 동영상으로 녹화해주기 때문에 새로운 문제를 발견할 수 있고 문제 현상에 대한 원인을 파악하여 가설을 세울 수 있다. 물론, 녹화영상을 봐야하기 때문에 많은 시간이 소요된다.(아래 이미지 참고)

https://www.hotjar.com


좋은 제품팀 VS 나쁜 제품팀

아래 내용은 인스파이어드 책에 나온 좋은 제품팀과 나쁜 제품팀의 차이를 알려주는 일부 내용이다. 몇 가지 더 있는데 우리가 자주 실수할 것 같은 5가지로 간추렸다. 이 부분을 통해 내가 속한 제품팀이 좋은 제품팀인지 나쁜 제품팀인지를 구분할 필요는 없을 것 같다. 각자 개인이 공감하는 부분이 있다면 그 부분을 하나씩 개선해 나가면 되기 때문이다. 공감되지 않는 부분이 있다면 일부러 개선할 필요도 없다. 다만, 스스로 객관화를 하여 판단할 필요는 있을 것 같다.

  • 좋은 팀은 그들의 핵심 이해 관계자들을 이해하고 있으며, 그들이 겪고 있는 제약사항을 잘 알고 있다. 이를 통해 사용자와 고객에게만 효과적인 솔루션이 아닌 비즈니스 제약 조건 속에서도 유효한 솔루션을 찾아내는데 최선을 다한다. 나쁜 팀은 이해 관계자로부터 요구사항을 수집한다.
  • 좋은 팀은 그들의 엔지니어가 매일 제품 발견을 위한 프로토타입을 만들어 볼 수 있는 시간이 있는지 확인한다. 그래서 더 나은 제품을 만드는 방법에 대한 그들의 생각을 실행해 볼 수 있다. 나쁜 팀은 스프린트 미팅에서 엔지니어에게 프로토타입을 보여 주고 추정을 하려고 한다.
  • 좋은 팀은 최종 사용자 및 고객과 매주 직접 만난다. 그리고 최신 아이디어에 대한 고객들의 반응을 확인한다. 나쁜 팀은 그들 자신이 고객이라고 생각한다.
  • 좋은 팀은 그들이 기대했던 아이디어들이 결국 고객에게 효과가 없을 수도 있다는 것과 심지어 검증된 아이디어조차도 희망하는 성과가 나오는 수준이 되려면 여러 번의 이터레이션이 필요하다는 것을 잘 알고 있다. 나쁜 팀은 그저 로드맵에 있는 것들을 만들면서 품질을 만족하고 일정을 준수하는 것에 만족한다.
  • 좋은 팀은 비즈니스 성과에 유의미한 영향을 만들어 냈을 때 서로 축하한다. 나쁜 팀은 마침내 뭔가를 출시했을 때 서로 축하한다.

위 내용중 ‘좋은 팀은 비즈니스 성과로 서로를 축하하고 나쁜 팀은 뭔가를 출시했을 때 축하한다’는 내용에서 스스로 정말 많은 생각을 했다. 뭔가를 출시한다는 그 자체도 상황에 따라서는 굉장히 어렵고 힘든 일이다. 과정이 힘들었다는 것은 그 과정에 참여한 사람들이 고생을 했다는 의미이고 그 과정을 견뎌낸 참여자들은 마땅히 축하를 받을 자격이 있다. 그런데 참여자들이 고생하여 그에 대한 보상을 받는 것과 그런 상황이 존재하는 팀의 문제는 별개이다. 즉, 고통을 견뎌내는 참여자들이 많다고 해서 그 팀이 훌륭한 팀이라고는 말할 수는 없는 것이다. 그 팀을 책 내용의 기준으로 말하자면 고통을 견뎌낸 좋은 팀원들이 많은 팀일 뿐이다. 좋은 팀원이 많다고 해서 좋은 팀이 되는 것은 아니다. 좋은 성과를 내는 팀이 좋은 팀인 것이다. 따라서, 성과를 기준으로 좋은 팀을 만드려면 성과의 질부터 달라야 한다. 우리같은 PO/PM이 존재하는 이유는 좋은 Product으로 좋은 성과를 내는 것 아니던가!

더 다양한 이야기를 듣고 싶으시다면 이메일 구독을 해주세요.

카카오톡 채널로도 소식을 접하실 수 있어요

http://pf.kakao.com/_lxaMxbb


PO, PM이라면...그냥 사서 읽어도 되는 책!

PO, PM이라면...그냥 사서 읽어도 되는 책!
9 10 0 1
더 이상 선배에게 '기획자에게 좋은 책 뭐 있나요?'라고 묻지 마세요. 이거 읽으시면 됩니다. 만약 읽었어도 또 읽으세요. 손해보지 않아요~
더 이상 선배에게 '기획자에게 좋은 책 뭐 있나요?'라고 묻지 마세요. 이거 읽으시면 됩니다. 만약 읽었어도 또 읽으세요. 손해보지 않아요~
9/10
Total Score
14 Shares:
답글 남기기

이메일 주소는 공개되지 않습니다. 필수 항목은 *(으)로 표시합니다

You May Also Like
Read More

기획자와 스토아철학

기획자로서 일을 하다보면 생각보다 많은 부분에서 우울할 때가 있다. 그 우울함이 심해지면 '나는 과연 필요한 존재가 맞는가?'라는 생각까지 들곤 한다. 문제는 이런 경험을 자주 할수록 자존감이 낮아진다는 것이다. 내가 겪어온 경험을 토대로 이 문제를 어떻게 극복했는지 이야기하고자 한다.
Read More

내 리더가 회사를 떠났다.

어떤 한 사람이 있다. 그 사람을 보면서 나는 이런 생각을 했다. "저 분의 인성과 역량을 닮고 싶다. 내 아들이 커서 어른이 된다면 나의 모습보다는 저 분의 모습을 닮았으면 좋겠다." 그 분은 내가 현재 재직중인 회사의 CTO이자 나의 리더였다. 아이러니하게도 그 분과 나는 전혀 다른 성격의 소유자이고 업무 스타일도 많이 달랐다. 하지만 난 정말로 그분을 닮고 싶었다.
Read More

주니어 기획자의 성장과 커리어에 대한 조언

도메인에 대한 이해가 높으면 문제를 제대로 정의할 수 있고 문제를 제대로 정의하면 합리적인 가설을 세워서 효과적인 데이터 분석을 할 수 있다. 데이터 분석을 통해 새로운 도메인 지식이 쌓인다. 이 과정을 반복하면, 기획역량은 자연스럽게 성장한다.
2021년 회고
Read More

2021년 회고(Product Owner, 가족, 성장)

회사에는 동료와 일이 있다. 가정에는 아내와 애들, 육아업무가 있다. 그러나 그 어디에도 나는 없었다. 원래 나 본연의 내가 존재할 수 있는 시간과 장소는 없었다. 단지, 의무로서의 나만 존재했다. 언뜻 생각해보면 참 서글프기도 하지만 잘 생각해보면 꼭 그렇지도 않다. 현재 나의 상황, 역할, 가족, 일.....그 모든 것이 결국은 나를 구성한다. 원래 나 본연의 나는 처음부터 없는 것인지도 모르겠다.
Read More

FE 개발자와 SEO 적용하기

SEO 작업을 통해 검색결과 첫 페이지의 상위 5위 안에 드는 것이 중요하다. 이번 포스팅에서는 내가 담당하고 있는 Product의 FE 개발자와 SEO를 적용하면서 알게된 사항들을 공유하고자 한다.