제품팀, 프로덕트팀, PO, PM, Product Engineer 필독서: 인스파이어드
우리 팀은 온보딩 과정에 독서가 있다. 내가 온보딩할 땐 없었지만
그 목록에 있는 필독서, 마티 케이건의 『인스파이어드』 독후감.
- 들어가며
- 1. 제품은 왜 실패하는가
- 2. 최고의 제품팀은 이렇게 일한다
- 3. 자율적인 팀에 필요한 것: 비전, 전략, 그리고 원칙
- 4. 제품 발견의 가장 중요한 것: 고객이 진짜 원하는가
- 5. 만들기 전에 테스트
- 6. 이해관계자와 함께 가기
- 7. 혁신을 멈추면 사라진다
- 8. 강한 제품 문화란
- 읽고 나서
들어가며
이 책이 하려는 말을 한 문장만 뽑는다면, 초반에 나오는 이 문장인 것 같다.
강한 기술 제품 회사는 끊임없는 제품 혁신이 필요하다.
몇 년 혹은 심지어 수십 년 전에 만들었던 가치와 브랜드를 이용하는 것에만 의존해선 안 된다.
우리 회사에는 제품팀이 존재한다.
제품팀이란 무엇이고, 어떻게 일해야 하는가를 알려 주기 위해 이 책이 필독서가 된 게 아닐까.
최근 잠깐 PO 역할을 맡은 적이 있다.
그때는 ‘내가 뭔가를 모른다’는 것만 막연히 알았는데, 이 책은 그 모르는 것들의 목록을 보여 줬다.
PO가 알아야 할 게 참 많더라.
1. 제품은 왜 실패하는가
본인의 팀은 ‘애자일’한가요?
책은 실패한 제품들이 거치는 과정을 이렇게 묘사한다.
아이디어가 나오고 → 얼마만큼의 매출이나 가치를 만들어 낼지, 얼마만큼의 비용과 시간이 필요한지(비즈니스 케이스)를 산정하고 → 우선순위를 매겨 로드맵에 넣고 → 요구사항, 디자인, 구현, 테스트, 배포.
비즈니스 케이스의 결함에 대해 저자는 다음과 같이 말한다.
현재 시점에서 우리는 이 두 가지 수치에 대한 근거가 전혀 없으며, 솔직히 우리는 알 방법이 없다.
저자는 이 프로세스가 프로젝트 중심적이라고 꼬집는다.
프로젝트는 결과물(output)에 대한 것이고, 제품은 비즈니스 성과(outcome)에 대한 것이다.
기능을 다 만들면 프로젝트는 끝나지만, 그 기능이 아무 성과도 못 냈다면 제품으로서는 실패다.
그리고 가장 큰 문제.
전통적인 폭포수 방식이 여전히 가지고 있는 가장 큰 문제는 위험이 가장 마지막에 발견된다는 것이다.
고객에 대한 검증이 너무 늦게 일어난다는 의미다.
2. 최고의 제품팀은 이렇게 일한다
세 가지 원칙
- 위험은 초기에 대응한다. 고객이 구매할 것인지(가치), 사용하기 쉬운지(사용성), 실현 가능한지(실현 가능성), 사업적으로 유효한지(사업 유효성).
- 제품은 순차적으로 넘기는 게 아니라 함께 협업하며 정의되고 설계된다.
- 기능을 구현하는 것이 아니라 문제를 해결한다.
위 원칙을 읽으며 ‘그럼 문제를 찾는 게 제일 큰 일 아닌가?’ 싶었다.
이 책에서 풀어야 할 문제는 주로 리더가 사업 목표의 형태로 준다(예: “신규 고객 활성화에 30일 걸리던 걸 3시간으로”).
팀의 몫은 그 문제를 어떻게 풀지 찾는 것이고, 그게 자율성의 영역이다.
비즈니스 맥락으로서 제품 비전과 팀의 구체적인 사업 목표는 리더에 의해 제공되지만, 그들이 풀어야 하는 문제를 해결하는 실질적인 방법에 대해서는 언급된 것이 없다.
이것이 팀이 자율성과 유연함을 발휘할 수 있는 대상이다.
다만 “그 문제가 진짜 고객에게 있는 문제인가”를 확인하는 건 팀의 일이다.
그래서 고객 인터뷰의 첫 질문은 “우리가 생각한 문제를 사용자가 가지고 있는 게 맞는지”다.
제품 발견과 제품 실행
이 책이 말하는 제품 혁신에 꼭 필요한 활동은 두 가지다.
만들 제품을 발견하는 것, 그리고 그 제품을 시장에 전달하는 것.
제품 발견은 결국 네 가지 질문에 답하는 과정이다.
- 사용자들이 이 제품을 살 것인가? (또는 사용할 것인가?)
- 사용자가 이 제품을 어떻게 사용하는지 이해할 수 있는가?
- 우리 엔지니어가 이것을 만들어 낼 수 있는가?
- 우리 이해 관계자가 이것을 지지하는가?
제품 실행은 발견에서 “만들 가치가 있다”고 확인된 것을, 실제로 팔고 운영할 수 있는 품질로 만들어 내보내는 일이다.
제품 실행의 목적은 판매하고 비즈니스를 운영할 만한 품질 수준의 기술 제품을 만들고 전달하는 것이다.
프로토타입에서는 신경 쓰지 않아도 됐던 규모, 신뢰성, 결함 허용, 보안, 개인정보보호, 국제화 같은 것들이 여기서 전부 필요해진다.
발견이 무엇을 만들지 정하는 일이라면, 실행은 그걸 구현하고 테스트하고 출시하는 일이다.
3. 자율적인 팀에 필요한 것: 비전, 전략, 그리고 원칙
이 책이 말하는 제품팀은 자율적이다. 문제를 어떻게 풀지는 팀이 스스로 찾는다.
그런데 자율성만 주면 팀마다 제각각 흩어진다.
그래서 팀에 방향을 주는 게 필요하고, 그게 비전, 전략, 그리고 원칙이다.
제품팀은 필요한 사업적 맥락을 알아야 한다.
팀은 회사가 어느 방향으로 향하고 있는지 명확히 이해할 필요가 있다.
그리고 자신의 팀이 더 큰 목적을 위해 어떻게 기여할 수 있을지 잘 알아야 한다.
사업적 맥락의 두 기둥
기술 기업이 팀에 주는 사업적 맥락은 두 가지다.
- 제품 비전과 전략: 전체 조직이 무엇을 달성하려 하는지, 그 비전을 달성하기 위한 계획은 무엇인지에 대한 큰 그림.
- 사업 목표: 각 제품팀에 대한 구체적이고 우선순위가 명확한 목표.
처음엔 ‘사업 목표라면 결국 다 돈 아냐? 돈이 아닌 목표가 있을 수 있나?’ 싶었다.
책의 예시를 다시 보니, 목표는 돈 그 자체보다 돈으로 이어지는 고객 행동에 가까웠다.
“신규 고객 활성화 30일 → 3시간”, “이탈률 낮추기”, “생애 가치 높이기” 같은 것들.
매출은 이런 행동들이 쌓인 후행 지표라서, 팀이 매일 움직일 수 있는 레버로 삼기엔 너무 멀다.
결국 돈으로 수렴하긴 하지만, 팀에 주는 목표는 그 앞 단계의 측정 가능한 성과여야 한다는 것.
제품 비전은 사명과 다르다
제품 비전은 통상적으로 2년에서 5년 정도의 기간에 우리가 만들어 내고자 하는 미래를 나타낸다.
회사의 사명(mission statement)과는 다르다.
사명은 “무엇을 위해 존재하는가”는 말해 주지만, “어떻게 거기까지 갈 것인가”는 말해 주지 않는다.
그 빈자리를 채우는 게 제품 비전이다.
제품 원칙: 이베이 이야기
제품 원칙은 당신이 만들고자 하는 제품의 특성이다.
가장 기억에 남는 건 이베이 사례였다.
이베이 수익의 대부분은 판매자에게서 나왔다.
그런데 판매자들이 이베이를 좋아하는 진짜 이유는 구매자가 많아서였다.
그래서 만들어진 원칙.
구매자와 판매자가 서로 원하는 것 사이에 충돌이 발생하는 경우 우리는 구매자가 필요로 하는 것에 우선을 둔다.
그것이 판매자를 위해 우리가 할 수 있는 가장 중요한 일이기 때문이다.
원칙은 선언이 아니라 충돌했을 때 내린 결정에서 드러난다.
이베이가 “구매자 편”을 원칙으로 삼은 건 그게 결국 판매자에게도, 회사에도 가장 이로웠기 때문이다.
우리의 원칙은 무엇일까.
무엇이 끝내 회사에 이로울 것인가.
이베이의 판매자가 구매자 때문에 남았다면, 우리 서비스에 사람들이 남는 이유는 뭘까.
지금 우리가 잘하는 게 마케팅이라고 해 보자.
마케팅이 첫 구매를 만들어 준다면, 두 번째 구매와 추천은 무엇이 만들어 줄까. 결국 리텐션과 레퍼럴을 신경써야만
제품 전략: 모든 사람을 한 번에 만족시키지 마라
제품이 실패하는 가장 확실한 길은 모든 사람을 한 번에 만족시키려고 노력하는 것이다.
제품 전략은 제품팀이 집중할 수 있도록 목표 시장에 대한 논리적이고 의도적인 순서를 분명히 드러낼 필요가 있다.
혁신을 잃는 10가지 이유 중 하나로 위의 문장이 나온다.
이 문장 말고는 별다른 설명이 없어서, 처음엔 이게 무슨 말인가 했다. 그럼 뭐 한 명만 만족시키면 되나요?
핵심은 ‘한 번에’와 ‘순서’다.
모든 고객을 버리라는 게 아니라, 지금은 어느 시장 하나에 집중하고 거기서 이기면 다음 시장으로 넘어가라는 것.
참조 고객 챕터에 구체적인 예가 나온다.
처음에는 재무 서비스 산업에 대한 6명의 참조 고객을 구성하고, 그다음에 제조 산업에 대한 6명을 구성하는 것과 같은 방법이다.
또는 지역적으로 확장할 수도 있다.
처음 6명은 미국, 그다음은 독일, 브라질 등으로.
전략이란 결국 “이번엔 이것만”을 정하는 일이고, 그 순서를 명시해 두지 않으면 팀은 이 고객 저 고객 요청을 다 받다가 아무에게도 사랑받지 못하는 제품을 만든다.
비전을 세웠다면, 꿈을 팔아라
제품 에반젤리즘은 가이 가와사키가 말한 것처럼 ‘꿈을 파는 것’이다.
사람들이 미래를 상상할 수 있도록 돕고, 그 꿈을 만드는 데 도움을 줄 수 있도록 영감을 불어넣는 것이다.
스타트업 창업자, CEO, 제품 총괄이라면 이게 역할 중 가장 중요한 부분이고, 이걸 못 하면 뛰어난 팀을 꾸리기 어렵다고 한다.
비전은 만드는 것으로 끝나지 않는다. 함께 볼 수 있게 팔아야 한다.
아무도 매력적이라고 느끼지 않고, 따르지 않는 비전은 아무래도 소용이 없으니까.
열정은 전염된다. 누군가 생생히 꿈꾸면, 그 꿈을 함께 꾸고 싶어지기도 한다.
그런 사람과 함께 일할 때는 그런 부분이 참 감사하게 느껴지기도 한다. 선명하고, 잘 변치 않는 비전이 함께라면 더 감사할 것 같아요.
4. 제품 발견의 가장 중요한 것: 고객이 진짜 원하는가
가치 위험
제품 발견 속 네 가지 위험 중 저자가 가장 강조하는 건 가치 위험이다.
고객이 이러한 문제 해결을 원하는 것이 맞는지?
우리가 제안한 솔루션이 현재 가지고 있는 것을 버리고 선택할 만큼 충분히 훌륭한 것인지?
두 번째 질문이 늘 어렵다.
고객은 이미 무언가로 그 문제를 해결하고 있다. 특히 요즘은 자기가 필요한 거 자기가 만들어 쓰는 셀프 커스텀 자급자족 시대이기도 함.
예를 들면 뭐가 있을까. 나는 취미로 춤을 추는데, 예전에는 핸드폰에서 흘러 나오는 음악을 춤추는 나와 함께 영상에 담으려면 별도의 앱이 필요했다. 해당 앱이 유료화가 되었던가, 아님 필요 없어졌나 안 쓴지는 오래 됐다. 현재는 사진 모드에서 원을 꾹 눌러 영상을 찍으면 음악이 담겨서 그렇게 한다. 어떤 친구들은 그냥 음악 틀어놓고 카메라도 켜둔채로 화면 녹화를 하기도 했다.
아무튼 다들 무언가로 해결하고 있는데, 그 무언가를 버리게 할 만큼이어야 한다.
고객이 당신의 제품을 구매하는 동기가 생기려면 당신의 제품을 월등히 나은 것으로 인식해야만 한다.
그리고 대부분의 제품은 완전히 새로운 시장이 아니라, 수요가 이미 존재하는 기존 시장에 들어간다.
그러니 진짜 도전은 “수요가 있는가”보다 “다른 솔루션보다 가치의 관점에서 명백하게 더 나은 걸 만들 수 있는가“다.
물론 그렇다고 수요를 그냥 단정 지어선 안 되고.
참조 고객: 6명
나는 제품팀에게 6명의 참조 고객을 확보하기 전까지는 시장에 제품을 출시하지 말라고 최선을 다해 설득한다.
참조 고객은 실제로 돈을 낸 구매자이면서, 다른 사람에게 이 제품을 얼마나 사랑하는지 이야기할 의사가 있는 사람이다.
- 6명은 사업자(B2B) 기준이다. 통계적으로 유의미해서가 아니라 자신감이 생기는 수준이라서. 소비자 제품이라면 10~50명 정도의 간절한 고객을 찾아 그들이 제품을 사랑할 때까지 함께한다.
- 작은 기능 얘기가 아니다. 새로운 제품/비즈니스를 만들거나 큰 규모의 과제일 때의 이야기.
- 6명이 요청하는 걸 다 넣는 게 아니라, 6명 모두를 만족시키는 하나의 솔루션을 찾아야 한다.
이 프로그램에 참여하는 네다섯 명의 고객을 구하는 데도 큰 어려움을 겪고 있다면, 당신이 그다지 중요하지 않은 문제를 쫓고 있을 가능성이 크다.
간절한 고객이라.
‘간절함’이라는 것 자체가 너무 흔치 않은 것처럼 느껴졌다.
다들 그냥 살아가진 않나? I do
꼭 해결하고 싶어 하는 어떤 문제가 있나?
우리 서비스를 이용하는 사람들은 어떤 문제를 해결하기 위해 간절한가?
간절함은 어떻게 측정할 수 있을까?
당장 떠오르는 답은 해당 문제를 해결하기 위해 여러 곳에 돈을 써 봤다면 그 고객은 간절하다고 할 수 있을 것 같다.
션 엘리스 테스트
제품/시장 궁합(PMF)을 진단하는 가장 보편적인 방법이라고 한다.
최근에 제품을 최소 두세 번 써 본 목표 시장의 사용자에게 묻는다.
“이 제품을 더 이상 사용할 수 없게 되면 어떤 기분일까요?”
① 매우 실망스럽다 ② 다소 실망스럽다 ③ 상관없다 ④ 사용하지 않기 때문에 전혀 관계없다
40% 이상이 ‘매우 실망스럽다’고 하면 PMF를 달성했을 가능성이 충분하다고 본다(소비자 제품 기준).
우리 서비스에 이 질문을 던지면 어떨까.
솔직히 ‘매우 실망’할 고객은 잘 떠오르지 않았다.
오래 함께해 온 고객들의 경우에는 좀 아쉬울 것 같긴 한데, 그들에게도 대체할 곳은 있다고 느껴졌다.
고객 인터뷰는 매주
고객 인터뷰는 최소한 매주 2시간에서 3시간 정도는 진행해야 한다.
인터뷰에서 확인하는 건 세 가지다.
- 우리가 생각했던 문제를 사용자가 가지고 있는 게 맞는지
- 지금은 그 문제를 어떻게 해결하고 있는지
- 현재 솔루션에서 전환시키려면 무엇이 필요한지
저자는 인터뷰가 시간 대비 훌륭한 결과를 계속 만들어 낸다고 하고, 인터뷰 자리를 아이디어 테스트 기회로 쓰는 걸 굉장히 좋아한다고 한다.
고객 인터뷰하니까 플랜핏이 떠오른다.
고객의 소리를 잘 듣는 게 중요하다고 생각하는데, 플랜핏에서는 다양하게도 고객의 소리를 듣는 것 같아 인상 깊었던 적이 있다.
이런 식으로 인터뷰를 신청하는 페이지까지 있었음. 저희도 고객 인터뷰.. 누가 좀 해주세요. 아님 제가?? ??
고객의 의견. 들을래 말래?
책 후반에 제프 베이조스의 말이 인용된다.
“고객은 항상 놀라울 정도로 불만족스러워한다. 그들이 행복하다고 말하고, 사업이 번창할 때도 마찬가지다. 심지어 그들이 잘 모르고 있을 때도 항상 고객은 더 나은 것을 원하며, 당신이 고객을 기쁘게 해 주고자 하는 의지가 그들을 위해 뭔가를 발명하게 할 것이다.”
읽다가 ‘아니 근데 고객으로부터 요구사항을 수집하는 건 나쁜 팀이라며ㅠ’했다.
좋은 제품팀과 나쁜 제품팀을 비교하는 챕터에서 분명 이렇게 말했었다.
좋은 팀은 그들의 비전과 목표, 고객 불편의 관찰, 제품을 사용하면서 고객들이 만들어 낸 분석 데이터, 문제를 해결하기 위해 새로운 기술을 끊임없이 탐색하는 과정을 통해 영감과 제품 아이디어를 얻는다.
나쁜 팀은 영업과 고객으로부터 요구사항을 수집한다.
충돌되는 의견이 아니라고 가정하고 생각해보면, 베이조스 말의 마지막 동사가 ‘발명하게’ 라는 점이 눈에 띈다.
고객이 불만족하다는 건 들어야 하지만, 고객이 말하는 해결책을 받아 적으라는 건 아니다.
고객은 더 나은 걸 원한다는 건 알지만, 그게 뭔지는 모른다.
나쁜 팀은 고객이 말한 기능 목록을 요구사항으로 만들고, 좋은 팀은 그 불만 뒤의 문제를 이해한 다음 고객 대신 해법을 발명한다.
앞에서 본 “6명이 요청하는 걸 다 넣지 말고, 6명 모두를 만족시키는 하나의 솔루션을 찾아라”와 같은 얘기다.
5. 만들기 전에 테스트
최고의 팀들은 한 주에 20개의 실험을 진행한다
최고의 팀들은 한 주에도 여러 가지 제품 아이디어를 실험한다.
10개에서 최대 20개 이상을 진행하기도 한다.
한 주에 20개라니, 비현실적으로 느껴졌다.
뭔가를 한 번 해보려면, 데이터도 좀 봐야 되는 거고, 어떻게 테스트해볼지, 측정은 어떻게 할 건지 이런 것들을 생각해야 하는데.
로드맵도 마감도 없이 발견과 실험에만 시간을 쏟을 수 있다면 가능하겠지만, 우리는 그런 상황이 아니지 않나 싶었다.
저자도 이런 반응을 예상했는지, 바로 뒤에 이렇게 적어 뒀다.
다소 비판적인 시각이 있을 수도 있다.
‘일주일에 15가지 실험을 진행하는 것이 가능하다고?’
어쩌면 내가 생각한 ‘실험’과 저자의 ‘실험’에 갭이 좀 있을 수도 있겠다는 생각을 했다.
제품 발견은 일련의 빠른 실험들의 진행을 포함한다.
그리고 그 실험들을 빠르고 적은 비용으로 진행하기 위해서 실제 제품보다는 프로토타입을 활용한다.
(…) 최소한 제품을 구현하는 데 드는 시간과 노력보다는 작은 규모로 진행되어야 한다.
책에 나온 예로 미루어 보면 피그마 화면 하나를 고객 세 명에게 보여 주는 것, 가짜 문 버튼 하나 다는 것, 쿼리 한 번 돌려서 이 문제를 겪는 사람이 실제로 몇 명인지 세 보는 것, 만들기 전에 몇 명에게만 사람이 손으로 직접 해 주는 것(안내인 테스트) 같은 것들이다.
질문 하나에 답하는 몇 시간짜리 행동이 실험 하나라고 말하는 것. 이라고 이해했음.
이런 식이라면 우리도 주마다 최소 15개의 실험은 하고 있는 것 같다.
다만, 좀 더 해 볼 여지는 있는 것 같다.
더 실험해보자.
일 하나를 시작하기 전에 1시간짜리 실험 하나를 먼저 붙여 보자. 하지만 요즘 코드 비용이 거의 0인데요
가짜 문 테스트
수요를 확인하는 방법 중 가장 재밌었던 건 가짜 문(fake door) 수요 테스트다.
버튼이나 메뉴를 사용자 경험상 있어야 할 정확한 위치에 넣는다.
그런데 누르면 기능이 작동하는 게 아니라, “이런 기능을 연구 중인데 의견 주실래요?”라는 페이지로 보낸다.
연락처를 남길 수 있게 해서.
비슷하게 랜딩 페이지 수요 테스트도 있다.
신규 서비스를 진짜 출시한 것처럼 소개하고, 가입 버튼을 누르면 “아직 연구 중”이라는 페이지를 보여 준다.
이걸로 빠르게 얻는 건 두 가지다.
- 수요에 대한 훌륭한 근거
- 이 기능에 대해 이야기할 준비가 된 사용자 목록
개발 공수 0에 가깝게 수요를 볼 수 있다는 게 꽤 매력적이다.
비슷하게 ‘기능 알림 받기’ 같은 걸 만들었던 적이 있었는데, 그보다도 훨씬 간단하게 테스트해 볼 수 있었다는 걸 깨달았다.
정성적 가치 테스트: 지불 의사
가치를 재는 저자의 선호 방법은 돈을 낼 의사가 있는지 보는 것이다.
돈을 받을 생각이 없는 상황에서도.
그 자리에서 카드를 꺼내는 사용자를 찾는 것이다(실제로 카드 정보를 받진 않는다).
- 비싼 기업용 제품이라면 강제력 없는 구매 의향서에 서명해 달라고 할 수 있다.
- 돈이 아니라 평판으로 지불하게 할 수도 있다. 친구·동료·상사에게 추천할 의향을 0~10점으로 묻거나, SNS 공유를 요청하거나, 추천할 사람의 이메일을 입력해 달라고 하거나. (실제로 저장하진 않지만, 입력할 의사가 있다는 것 자체가 의미 있다.)
확실한 테스트라고 느낀 이유는, 말은 누구나 할 수 있지만 행동으로 옮기기는 쉽지 않기 때문이다.
사실 생각이 있나요?
했을 때 누구라도 아 그럼요~ 할 수 있겠지만 yup! shut up and take my money! 하긴 어려울 테니. 이메일은 거절을 어려워하는 사람들의 경우 그냥 아무 이메일이나 댈 수는 있겠다.
정량적 가치 테스트: 데이터로 확인하기
지불 의사가 말로 확인하는 거라면, 데이터는 실제 행동으로 확인하는 방법이다.
우리는 흔히 사용자 관찰을 통해 뛰어난 아이디어를 얻고, 또한 새로운 기술을 적용하는 것으로부터 뛰어난 아이디어를 얻게 된다.
데이터 자체를 깊이 학습하는 것은 획기적인 제품 아이디어를 이끌어 내는 통찰을 제공해 줄 수 있다.
저자가 꼽는 핵심 분석 정보의 조합은 이렇다.
| 분류 | 예시 |
|---|---|
| 사용자 행동 | 클릭 경로, 참여 행동 |
| 비즈니스 | 활성 사용자, 전환율, 생애 가치, 잔존율 |
| 재무 | 평균 판매 가격, 결제 정보, 주문 완료 소요 시간 |
| 성능 | 로딩 시간, 가동 시간 |
| 운영 비용 | 스토리지, 호스팅 |
| 시장 진출 비용 | 고객 획득 비용, 영업 비용, 캠페인 비용 |
| 감성 | 순추천고객지수(NPS), 고객 만족도, 설문 조사 |
도대체 어떤 데이터를 봐야 하나 싶을 때, 여기부터 시작해도 좋겠다는 생각이 들었다.
데이터가 없으면 빼는 결정도 못 한다는 대목도 공감됐다.
나는 고객에게 영향이 없는 기능들을 제거함으로써 제품을 철저히 단순하게 만드는 것을 추구한다.
하지만 무엇이 사용되고 있고 어떻게 사용되고 있는지 알지 못하는 상태에서 이러한 제거 작업을 하는 과정은 매우 고통스럽다.
데이터가 없다면 경영진은 (정당하게) 결정을 망설이게 된다.
있던 기능을 없애기 위해서는 어떠한 근거가 필요하다.
“그거 누가 쓰고 있으면 어떡해요?”라는 그 질문에 숫자로 답할 수 있어야 지울 수 있다.
사업 유효성 테스트
가치, 사용성, 실현 가능성까지 통과해도 마지막 관문이 있다. 사업 유효성.
처음엔 사업 유효성이라면 법만 안 어기고 비용보다 이득이 크면 되는 거 아닌가 싶었다. ㅎㅎ;;
비용에 회사가 쏟는 온갖 리소스가 들어간다고는 생각했지만, 그 리소스가 이렇게까지 구체적일 줄은 몰랐다.
사업 유효성을 검증한다는 것은 제안하는 솔루션이 비즈니스의 각 영역이 가진 제약 범위 안에 있는가 확인하는 것을 의미한다.
그리고 영향받는 이해관계자들이 검토할 기회가 있었는가도.
- 마케팅: 판매 채널이나 주요 마케팅 프로그램에 영향을 주거나, 브랜드 약속(고객이 회사에 기대하는 범위)을 벗어나면 상의해야 한다.
- 영업: 성공적인 제품은 영업 채널의 강점과 제약을 고려해 설계된다. 검증된 기존 영업 채널을 벗어난다 싶으면, 구현 전에 영업 리더와 마주 앉아 보여 줘라.
- 고객 성공(CS): 하이터치 서비스 모델이라면 CS 담당자는 제품 통찰과 프로토타입 테스트에 특히 큰 도움이 된다.
- 재무: 만들고, 팔고, 운영하는 비용을 감당할 수 있는가.
- 법무: 개인정보보호, 회계 감사, 지적 자산, 경쟁사 이슈.
- 사업 개발: 이면 계약으로 정해진 의무와 제약. 제안이 그 관계에 미치는 영향을 알아야 한다.
6. 이해관계자와 함께 가기
개발자이기 때문인가, PO/PM에게 기대하는 걸 딱 하나만 꼽으라면 여러 사람이 같은 이해와 생각을 공유하고 있게 하는 것이라고 생각한다. Please let everyone be on the same page
그런 의미에서 다음 문장들이 꽤 공감이 갔다.
이해 관계자 관리는 제품 발견의 핵심 중 하나다.
솔루션이 가치 있고, 사용성이 충분하고(고객과 함께), 실현 가능(엔지니어와 함께)한지 확인할 뿐만 아니라 이해 관계자들이 제안한 솔루션을 지원할 것인지도 분명히 확인해야 한다.
많은 기업에서 일부 이해 관계자들은 심지어 제품이 무슨 역할을 하는지를 이해하지 못하고, 일부는 그 역할에 대해 두려움을 느낄 수도 있다.
이러한 상황에 민감하게 대응하라.
시간을 할애하여 제품의 역할, 기술 기반의 제품 회사가 어떻게 운영되는지, 왜 그렇게 해야 하는지에 관해서 설명하라.
7. 혁신을 멈추면 사라진다
어도비: 캐시카우를 건드린다는 것
어도비(요즘 민심이 흉흉하지만)의 레아 힉맨은 연 20억 달러를 버는 데스크톱 패키지 크리에이티브 스위트를 구독형으로 바꾸려 했다.
어도비 전체 매출 40억 달러의 절반이었다.
회사라는 신체의 모든 뼈와 살이 그 매출을 지켜 내기 위해 열심히 동작하고 있다고 보면 된다.
그래서 이 정도 규모의 전환은 회사를 안락한 구역(comfort zone) 밖으로 멀리 밀어붙이는 것을 의미한다.
재무는 매출 감소를 걱정하고, 2년 주기 출시에 익숙한 엔지니어팀은 지속 배포를 걱정하고…
회사 거의 모든 기능을 건드려야 했다.
결과적으로 어도비는 2013년 크리에이티브 클라우드 구독으로 전환을 마쳤다.
읽으면서 캐시카우를 건드리는 것의 무서움에 꽤 공감했다.
comfort zone을 벗어나라는 게 안정적인 캐시카우에 투자를 줄여야 한다고 말하고 싶은 건가?
매출에 대한 확신도 없을 때?
어떻게?
라는 생각이 들었다.
본질적으로 저자가 하고자 하는 말은 캐시카우, 그 자체에 대한 것이 아니라 캐시카우가 회사 전체를 붙잡아 두는 중력에 대한 이야기라고 이해했다.
모두가 지금의 매출을 지키는 데 최적화돼 있어서, 시장이 변해도 몸이 안 움직인다는 것.
캐시카우가 있다고 안주하지 말고, 시장 변화나 신기술 흐름을 놓치지 말라는 거다.
레아 역시 지금의 업그레이드 모델이 장기적으로 고객에게도 회사에도 좋지 않다는 걸 알았기에 밀어붙였다.
is it?
그럼 ‘확신도 없을 때 어떻게?’에 대한 책의 답은 다음과 같다.
확신이 없으니까 전부를 거는 게 아니라, 가짜 문 테스트나 참조 고객 프로그램처럼 싸고 안전하게 확신을 사는 방법(=제품 발견)을 쓰라는 것.
캐시카우는 지키면서, 옆에서 작게 검증하고, 근거가 쌓이면 옮겨 타라.
이 책을 처음 읽었을 때는 너무 추상적이라고 느꼈었다.
“알겠습니다. 그래서 어떻게 해야 하죠?” 싶은 순간들이 대부분이었기 때문.
다시 보니 결국 책이 하는 얘기는 “제품 발견으로 혁신해라” 하나였다.
그리고 그게 ‘어떻게’에 대한 답이었다.
레아도 이런 식으로 혁신했을까 싶어 더 찾아봤다.
레아는 프로토타입을 만들어 핵심 경영진과 꼭 필요한 팀들에게 비전을 설명하고 지지를 얻었다.
한 번 설득하고 끝내지 않고, 매출이 일시적으로 떨어지거나 고객과 내부가 반발할 때마다 사람들을 다독였다.
구독형을 내놓고도 기존 상품을 1년 동안 함께 팔았다.
그리고 1년 뒤, 기존 상품의 마지막을 선언하고 끝내 전부를 걸긴 했다.
실험으로 확신을 모아도, 결국 “이제 바꾸자”고 결정하는 순간은 온다.
실험은 그 결정을 대신해 주지 않는다.
근거를 갖고 결정하게 해 줄 뿐이다.
책에서 혁신에 대해 얘기하는 문장 몇 가지 더.
만일 기업이 혁신을 멈추면, 그 기업은 사라진다.
당장은 아니더라도 기존 솔루션의 최적화에만 몰두하고 혁신을 멈추고 있다면 경쟁사의 먹잇감이 되는 것은 시간문제다.
지속적인 혁신을 위해서는 기존의 비즈니스를 파괴할 수도 있는 위험을 감수하려는 의지가 필수적이다.
우리는 책임감 있는 방식으로 혁신을 수행해야 한다.
책임감이 있다는 의미는 큰 두 가지 운명을 함께 짊어져야 한다는 말이다.
바로 매출과 브랜드를 지켜 내는 것과 직원과 고객을 지켜 내는 것이다.
넷플릭스: 필요는 혁신의 어머니
넷플릭스가 DVD 대여를 구독 모델로 바꿨을 때, 모두가 신작만 찾았다.
신작은 비싸다.
이대로면 파산행이었다.
어떻게든 비싼 타이틀과 저렴한 타이틀을 섞어 보는 고객을 만들어야 했다.
필요는 혁신의 어머니라고 했다.
바로 이 시점에 넷플릭스의 큐(queue), 평가 시스템, 추천 엔진이 모두 시작되었다.
추천 엔진이 “고객에게 좋은 영화를 보여 주자”가 아니라 “구 작품도 보게 만들어야 산다”에서 나왔다는 게 재밌었다.
사업 제약이 오히려 혁신의 출발점이 된 셈.
개선과 혁신은 무엇을 묻느냐의 차이
‘혁신’이라는 단어가 주는 중압감이 있다.
뭐랄까.
스티브잡스 정돈 되어야 혁신은 아닐까.
세상에 없던 것을 내놓아야만 할 것 같다.
세계 최초. 그런 거. 혁신의 아이콘 애플도 폴더블 내니까 조롱 당하니까요
좋은 제품은 문제를 해결하는 제품이라고 생각하고, 그러므로 문제를 찾고 싶기도 했다.
그런데 막상 찾으려고 하면 막막했다.
고객 일탈 행동, 데이터, CS 같은 걸 보면 문제는 보인다.
근데 거기서 나오는 건 대부분 개선이지, 책이 말하는 끊임없는 혁신은 아닌 것 같았다.
책의 고객 일탈 행동 챕터를 다시 보니, 거기 나온 예시는 개선보다 컸다.
수집품 거래 사이트였던 이베이에서 사람들이 자동차를 팔기 시작한 것.
당신이 예상하듯이 안전하게 차를 구매하고 운송하는 것과 표를 사서 하루 잘 쓰고 가치가 없어지는 것 사이에는 매우 중대한 차이가 있다.
이걸 보고 “차 거래를 좀 더 편하게 해 주자”에서 멈추면 개선이다.
“이 사람들은 왜 이렇게 불편한데도 여기서 차를 팔지?”라고 물으면 새로운 시장을 볼 수도 있다.
(이베이는 자동차 파는 사람들을 보고 이베이 모터스를 만들었다.)
같은 신호를 봐도 무엇을 묻느냐에 따라 개선이 되기도, 혁신이 되기도 한다는 걸 깨달았다.
그렇다고 고객만 보면 혁신이 나오느냐 하면, 책은 오히려 반대로 말한다. 절대 제가 개발자라서 가져온 문단이 아닙니다. 절대로요.
어떤 사례에서도 사용자나 고객, 영업을 통해 최선의 솔루션이 나오지 않았다.
사용자들은 나중에 그들이 푹 빠지게 될 제품이 과연 가능한 것인지 전혀 예측하지 못했다.
나는 진심으로 혁신적인 제품 아이디어가 나오는 지속 가능한 최고의 원천은 바로 개발자들이라고 생각한다.
그들은 지금 가능한 것이 무엇인지 알 수 있는 최고의 위치에 있다.
이해할 수 있는 선에서 정리해 보면 이런 것 같다.
- 고객 문제만 보면 → 개선
- 기술만 보면 → 아무도 원하지 않는 장난감
- 고객 문제 × 이제는 가능해진 기술 → 혁신
넷플릭스도 그랬다.
신작에만 수요가 몰려 망할 것 같다는 문제에 추천 기술을 붙였다.
그러니 개발자인 내가 할 수 있는 건, 고객이 오래 당연하게 참아 온 불편을 하나 골라서 “지금 기술이라면 이걸 아예 없앨 수 있지 않나?”라고 묻는 일이 아닐까.
IT 마인드셋 vs 제품 마인드셋
책은 혁신을 잃는 이유 중 하나로 이걸 꼽는다.
IT 마인드셋이 있는 조직에서는 제품팀이 비즈니스가 원하는 일을 지원하기 위해 존재한다.
반대로 제품 마인드셋이 갖춰진 조직에서는 제품팀이 사업의 요구에 맞는 방식으로 회사의 고객을 돕기 위해 존재한다.
미묘한 차이 같지만, 누구를 위해 일하느냐가 다르다.
사내 부서를 위해서인가, 고객을 위해서인가.
부서를 위해 일하면 요청받은 걸 만드는 팀이 되고, 요청은 대부분 개선이다.
혁신이 나올 자리가 없다. !!!
현상 유지의 함정, 그리고 우리의 20% Time
규모가 성장한 기업은 제품팀이 이른바 현상 유지 활동에만 전념할 가능성이 크다.
오류를 수정하고, 비즈니스의 각 영역에 필요한 기능을 만들고, 기술 부채에 대응하는 등의 일이다.
일부는 당연하기도 하고 건강한 현상이지만, 팀이 더 어렵고 큰 문제를 다룰 수 있는 여지를 가지도록 해야 한다.
구글에는 20% 타임이라는게 존재한다.
직원이 정규 업무 시간 중 약 20%(주당 하루 정도)를 상사의 지시나 평가 없이 자신이 주도하는 혁신적인 사이드 프로젝트나 학습에 자율적으로 사용할 수 있도록 허용하는 제도이다.
나도 뭔가 시간이 주어지고, 명분이 있어야만 뭘 할 수 있는 사람으로서 이게 있었으면 좋겠다고 여러 번 주장해 왔다.
그리고 현재는 해당 제도를 회사에서 진행하고 있다. 5% Time 같긴 한데
저자는 이런 핵 데이를 둘로 나눈다.
- 간접적인 핵 데이: 회사 미션과 대략 관련만 있으면 아무 아이디어나 탐색.
- 직접적인 핵 데이: 특정 고객 문제나 사업 목표(예: ‘고객 이탈률 낮추기’)를 주고, 팀을 알아서 꾸려 아무 아이디어나 실행해 본다.
주당 하루도 뭔가를 탐색하고 변화를 만들어 내기엔 충분하지 않은 것 같은데…
나약해지니까 다시 한 번 상기한다.
실험은 꼭 무거울 필요는 없다.
가볍게.
자주.
8. 강한 제품 문화란
저자는 제품 문화를 두 관점으로 본다.
첫 번째 관점은 회사가 고객을 위해 가치 있는 솔루션을 만들어 내기 위해 끊임없는 혁신을 할 수 있느냐는 것이다. 이것이 바로 제품 발견이다.
두 번째 관점은 아무리 훌륭한 아이디어라도 만들 수 없고 고객에게 전달할 수 없는 버전이라면 아무 소용이 없다는 것이다. 이것이 바로 제품 실행이다.
그리고 강력한 혁신 문화의 일곱 가지 모습.
| 문화 | 의미 |
|---|---|
| 실험 | 테스트를 실행할 수 있다고 생각한다. 많이 실패할 것이고, 실패가 허용된다. |
| 열린 자세 | 좋은 아이디어는 어디서든 올 수 있고, 처음부터 확실한 아이디어는 없다. |
| 자율성 | 모든 개인과 팀이 아이디어를 시도할 권한이 있다고 느낀다. |
| 기술 | 진정한 혁신이 새로운 기술, 데이터 분석, 고객으로부터의 영감에서 나온다는 걸 안다. |
| 비즈니스와 고객에 능숙한 팀 | 개발자를 포함한 팀이 비즈니스의 요구·제약과 사용자를 깊이 이해한다. |
| 능력과 다양성 | 서로 다른 능력과 배경이 혁신적인 솔루션을 만든다고 인식한다. |
| 제품 발견 기법 | 아이디어를 빠르고 안전하게(브랜드·매출·고객·동료를 지키며) 시도하는 메커니즘이 있다. |
어떤 경우이건 당신과 팀이 바라는 것은 이러한 혁신과 실행의 관점에 대해 스스로 진단하고, 그러고 나서 팀이나 회사로서 어떤 모습이 되고 싶은지 스스로 물어보거나 무엇이 필요한지 생각해 보는 것이다.
그래서, 우리 팀은 어떤 모습이었으면 좋겠나.
위 표를 우리 팀에 대 보면, 실험/열린 자세/자율성/능력과 다양성 정도는 갖추고 있으나 기술/비즈니스와 고객에 능숙한 팀/제품 발견 기법 등이 부족하진 않나 싶다.
좀 더 새로운 기술과, 데이터와, 고객에 관심을 갖는 팀이 되면 좋겠다.
또 빠르고 안전하게 시도할 수 있는 팀이 되면 좋겠다.
그런 팀이 되려면 어떻게 해야 할까.
그저 말로 권하는 것만으로는 잘 안 되는 것 같다.
안타깝게도, 다들 시간은 없고, 주어진 일을 해내는 데 외에 쓸 수 있는 시간은 내가 만든 것에 에러가 있는지 정도는 아닌가. 일단 저는 그래요.
역시 시간 확보가 중요하다. 제품 발견에 더 시간을 많이 써도 되는 환경을 만들어야겠다.
읽고 나서
아, 그거 뭐였더라 싶으면 내가 쓴 글을 찾아 들어오기도 해서, 기억에 남는 것들은 모조리 기록하다 보니 다소 길어진 것도 같다.
TL;DR 하자면, 이 책에서는 “혁신해라”고 말하고 있습니다.
근데 이제, 실험 많이 해서 가능성을 높이고, 근거를 가지고.
이거 읽으라고 주신 분이 또 CPO님이신데, 읽으면서 느낀 점은 여기서 하라는 거 다 하고 계신다는 거임.
참 실현 잘 되는 사람. 멋진 사람. 존경하는 마음을 살짝 담겠습니다.
여기까지.
안녕!
