[경영] 개발 함정을 탈출하라 - 4부 프로덕트 매니지먼트의 4단계

 이전 글

2023.03.22 - [IT 말고/책] - [경영] 개발 함정을 탈출하라 - 3부 프로덕트 전략을 세우는 방법

[경영] 개발 함정을 탈출하라 - 3부 프로덕트 전략을 세우는 방법

4부 프로덕트 매니지먼트 과정

4부에서는 프로덕트 카타를 중심으로 어떻게 프로덕트 매니지먼트를 하는지 설명합니다.

프로덕트 카타

1. 방향을 이해하고 성공지표 설정하기

'프로덕트 지표'는 프로덕트, 나아가 사업 자체의 건전성을 보여준다. 프로덕트의 건전성이 사업 전체의 건전성에 영향을 미치기 때문이다. 측정 기준은 모든 프로덕트 매니저의 생명줄이다. 프로덕트 상태를 계속 주시해야만 언제 어디서 행동을 취해야 할지 알 수 있다.

...(중략) 소위 '허영 지표'를 측정하는 경우가 많다. 린 스타트업에서 제시한 허영 지표 개념은 항상 숫자가 늘어나므로 휘황찬란해 보이는 목표들을 강조한다. 자신의 프로덕트 사용자 수, 하루 페이지 뷰 수, 로그인 횟수들을 자랑하는 것이다. 

말을 이해하기가 쉽지 않은데요. 제 경험에 비추어 보면, 경영진을 제외한 일반 직원들은 목표보다는 당장의 일에 더 집중하는 경향이 있습니다. 따라서 성공 지표의 달성만 보고 일을 할 때가 많습니다. 그런데, 성공 지표가 잘못 설정되어 있다면, 개발함정에 빠져 프로덕트의 목적 달성에 도움이 안 되는 일을 하기 쉽습니다. 그래서 프로덕트의 방향을 이해하고, 성공지표를 설정해야 하며, 이때의 성공지표는 철저히 프로덕트 목표 중심이 되어야 합니다.

책에서는 프로덕트 목표가 무엇인지 철저히 고민하게 도와주는 프로덕트 프레임워크로 해적 지표(Pirate Metrics)와 하트 지표(Heart Metrics)를 설명합니다.

해적 지표

해적 지표(Pirate Metrics)

 해적지표는 그림에서처럼 프로덕트 사용 라이프 사이클을 보여줍니다. 깔때기처럼 위에서 아래로 순차적으로 각 단계를 통과하며 고객이 경험을 이어간다고 합니다.
이 순서는 모든 기업에 동일하지는 않으며, 각자의 프로덕트 흐름에 맞추어 단계를 정할 수 있다고 합니다.

깔때기를 알맞게 사용하면 단계를 통과할 때마다의 전환율을 쉽게 계산할 수 있다. 이 전환율을 참고하면 사람들이 많이 떨어져 나가는 지점을 파악해 잘못된 부분을 고칠 수 있다. 단계별 깔때기 사용자 수를 확인하면 해당 집단을 공략해 다음 단계로 이동시킬 방안도 구상할 수 있다. 여기서 목표는 사람들이 프로덕트에 잔류해 결제하도록 만드는 것이다.

하트 지표
해적 지표는 매우 유명하지만 사용자 만족도가 반영되지 않아서 하트 지표가 고안되었다고 합니다.

하트(HEART) 지표는 행복(Happiness), 참여(Engagement), 채택(Adoption), 유지(Retention), 과제성공(Task Success)으로 이루어지며 특정 프로덕트나 기능을 말할 때 주로 이용된다. 여기서 채택이라는 개념은 해적 지표에서의 활성화와 비슷하다.  프로덕트를 처음 사용하는 사람이 대상이기 때문이다. 유지는 해적지표에서의 유지와 같다. (중략)… 행복은 사용자의 만족도를 나타낸다. 참여는 사용자가 프로덕트를 이용하는 빈도다. 과제 성공은 사용자가 프로덕트에서 수행해야 할 활동의 난이도를 보여준다.

책 내용으로는 이해가 가지 않아서 따로 검색해 보았습니다. 하트 지표는 사용자 경험을 측정하는 방법이며, 좀 더 상세하게 보면 아래와 같이 볼 수 있습니다.

- Happiness(만족도): 사용자가 제품 또는 서비스를 사용하면서 느끼는 기쁨과 만족감을 측정합니다. 이는 사용자가 제품을 사용하기를 원하는 이유를 이해하는 데 도움이 됩니다.
- Engagement(참여도): 사용자가 제품 또는 서비스와 상호 작용하는 빈도와 방식을 측정합니다. 이를 통해 사용자가 제품 또는 서비스와 상호 작용하는 방법과 빈도를 파악할 수 있습니다.
- Adoption(채택도): 새로운 사용자들이 제품 또는 서비스를 얼마나 빠르게 채택하는지를 측정합니다. 이는 제품 또는 서비스의 초기 인상을 파악하는 데 도움이 됩니다.
- Retention(유지도): 사용자가 제품 또는 서비스를 사용하면서 유지되는 시간을 측정합니다. 이는 사용자가 제품 또는 서비스에 대해 만족스러움을 느끼고 지속적으로 사용하는 데 중요한 지표입니다.
- Task Success(작업 성공률): 사용자가 제품 또는 서비스에서 수행하는 작업의 성공률을 측정합니다. 이는 제품 또는 서비스의 사용성과 유용성을 평가하는 데 도움이 됩니다.
 

프로덕트 활동은 수익이나 비용, 나아가 사업 결과에 영향을 미쳐 프로덕트 지표가 경영 성과로 연결되는 것이다. 다만, 프로덕트 계획과 옵션을 비롯한 전략의 모든 단계에 지표가 있어야만 프로덕트 개발이 성공적으로 이루어지는지 확인할 수 있다.
어떤 지표를 채택하든 하나가 아닌 여러 지표의 체계를 갖추어 프로덕트에 대한 의사결정을 이끌어야 한다. 집중할 영역이 하나라면 지표도 하나만 채택하기 쉽다..(중략)

이 체계는 문제가 있다. 유지율은 결과가 즉시 나오지 않는 지행 지표라는 점이다. 사용자들이 프로덕트를 계속 사용했는지 확실히 알아보려면 몇 달을 기다려야 하므로 활성화, 행복, 참여와 같은 선행 지표를 함께 측정해야 한다.
선행 지표는 우리가 유지율과 같은 지행 지표 관련 목표를 달성하는 길로 순조롭게 가고 있는지를 알려준다. 유지율에 대한 선행 지표를 정하려면 행복, 프로덕트 사용 등 사용자가 머물게 하는 요소를 정성화하면 된다.

가용데이터를 충분히 확보하려면 그 데이터를 쉽게 측정할 도구들을 도입해야 한다. 지표 플랫폼 채택은 모든 기업이 가장 먼저 해야 할 일 중 하나다. 앰플리튜드, 펜도, 믹스패널, 인터콤, 구글 애널리틱스가 모두 데이터 플랫폼이다...(중략)

성공지표는 하나가 아니라 여러 지표로 체계를 갖추어야 한다는 것과 지행지표와 선행지표를 함께 측정해야 한다는 것이 참 의미 있는 말로 보입니다. 얼마 전에 리뷰한 "NHN 이렇게 한다! 소프트웨어 품질관리"에서도 다양한 선행지표를 측정하는 것이 개발 품질을 올린다는 이야기가 나오는데요. 이런 애자일 방법론과 일맥 상통하는 부분인 것 같습니다. 선행지표로서 리스크를 줄이고, 프로덕트 개발이 제 길을 찾아가는지 알 수 있습니다.
 
프로덕트 개발이 단기간에 끝나는 것이 아닌, 여러 가지 프로젝트와 기능으로 지속적으로 이어져 나가는 이상, 이런 지표를 채택하여 측정하는 것이 필요합니다. 물론, 대부분의 회사들이 당연하게 이런 부분을 측정하기는 하지만, 그것이 프로덕트 품질과 직접적으로 연결이 되는지, 그 의미에 대해 제대로 파악이 되고 있는지는 고민해 보아야 할 문제 같습니다.
 

2. 문제 탐구

사용자 조사, 관찰, 설문, 고객 의견은 우리가 사용자의 관점에서 문제를 탐구하는 데 활용할 수 있는 도구들이다. 이때 사용자 조사를 '사용성 테스트’와 헷갈리지 말자. 사용성 테스트는 프로토타입이나 웹사이트를 보여주면서 사람들이 행동을 완수해보게 함으로써 그들이 기능을 쉽게 다루고 이용하는지 보는 것이지 그 기능이 실제로 문제를 해결해 주는지 확인하는 연구는 아니다. 이것을 '평가형' 연구라고 부른다.

반면, 문제 기반 사용자 조사는 '생성적 연구'다. 이런 연구는 해결하려는 문제를 찾아내는 것이 목적이다. 그러려면 고객이 겪는 문제의 근원을 파헤치고 그를 둘러싼 전후 상황을 이해해야 한다. 마케틀리도 이런 연구를 했다. 그들은 고객을 찾아가 관찰하고 그들에게 질문을 던졌다. "강의를 완성하는 과정에서 어떤 문제로 가장 곤란하셨나요? 어떤 점이 힘드셨나요? 문제 기반 연구에서는 무엇이 불만인지 파악하고 문제의 근본 원인을 알아내야 한다. 고객이 겪는 문제의 전후 상황을 이해하면 그 문제의 해결 방안을 더 정확히 구상할 수 있다.

그렇지 못하면 추측만 난무한다. 여기서 쉽게 빠질 수 있는 개발 함정은 근본 원인을 찾기도 전에 문제 해결에 뛰어드는 것이다. 우리는 문제가 무엇인지도 모르는 상태에서 그 문제를 해결하려고 덤비곤 한다. 우리 뇌는 해결 방안 찾기를 좋아하지만 일할 때 그런 태도는 위험하다. 문제의 근원을 이해하지 못하면 절대 자신의 의도에 맞춰 정확한 해결 방안을 도출해 낼 수 없다. 의도대로 움직이지 못하니 운 좋게 올바른 해결 방안이 얻어걸리길 바랄 수밖에 없는 것이다. 문제의 뿌리를 이해하는 것이 어렵기는 해도 더 효율적이고 효과적이고 성공적인 방식이다.

이런 사고방식을 장착했을 때 저지르기 쉬운 실수를 꼽자면 기능 부족이 문제라고 넘겨짚는 것이다...(중략)

문제 해결 방안을 생각하다 보면 아이디어 구상에만 집착하기 쉽다...(중략)

프로덕트 매니저의 가장 중요한 업무가 문제를 탐구하는 것이 아닐까 싶습니다. 문제를 제대로 찾아내기만 하면, 그에 대한 해답은 누군가가 낼 것이라고 생각합니다. 문제를 제대로 찾아내지 않은 상태로 기능 개발을 하고, 그 기능이 개발되면 문제가 해결될 것이라고 생각했지만, 실제로는 아무 도움이 되지 않았던 적이 수없이 많았습니다. 제대로 된 성과 평가 없이 무엇인가 하는 것 자체로 평가하는 조직에서 이런 문제가 많이 발생합니다. 

 3. 해결책 탐구

기업들은 '배우기 위한 개발'과 '이익을 얻기 위한 개발을 혼동할 때가 많다. 실험은 항상 배우기 위한 개발이다. 실험을 하면 고객을 더 잘 이해하고 어떤 문제 해결이 가치 있는 일인지 증명할 수 있다. 실험은 장기간 진행되도록 설계하면 안 된다. 실험은 원래 가설이 맞는지 틀리는지 증명하기 위한 것이고 소프트웨어를 개발할 때는 이런 실험을 최대한 신속히 진행해야 한다. 그래서 결국에는 개발했던 것을 전부 폐기처분하고, 성공한 경우에는 지속 가능하고 확장 가능한 방식을 구상해야 한다.

(중략)... 그 대신 해결 방안 실험을 더 많이 활용한다. 해결 방안 실험은 기업의 학습 속도를 높이 도록 설계되었다. 여기서 우리는 결실을 맺기 위해 기능을 개발하는 것이 아니라 학습하기 위해 실험한다. 안정적이고 탄탄하고 확장 가능한 프로덕트를 만드는 것이 아니다. 실험을 시작하는 시점에는 무엇이 최적의 해결방안일지 모를 때가 많다. 그것이 바로 프로덕트 카타를 하는 이유다. 프로덕트 카타는 학습 기반을 다져주는 훌륭한 도구다. 항상 '다음에 배워 야 할 것은 무엇인가?"라는 질문을 한다. 그 덕분에 우리는 방향을 잃지 않고 올바른 유형의 실험을 구상할 수 있다.

해결책을 탐구하기 위해 실험을 제안하고 있습니다. 여기서는 실험은 배우기 위한 것이며, 이익을 얻기 위한 것은 아니라고 선을 긋고 있는데요. 현실적으로는 실험에도 비용이 들고(그것이 직접적이든, 기회비용이든) 비용이 들어간 활동에 아무 이익이 없다는 것을 경영진이 이해해 줄지는 조금 의문입니다. 애초에 경영진이 이런 실험을 지시하는 상황이라면 모르겠지만요. 
그래도 아래에서 설명하는 실험은, 잘하면.. 큰 비용 없이 실험이 가능할 것 같기도 합니다.

학습을 위한 실험 방법은 다양하다. 지금부터는 해결 방안 실험의 3가지 방식인 '대행', '오즈의 마법사', '콘셉트 실험'을 각각 간단히 설명하겠다. 이 3가지는 오래 지속되는 해결 방안을 도출할 수 있는 구조가 아니므로 고객들에게 공개하는 범위를 한정해야 한다. 어떤 실험을 하든 끝내는 방법, 즉 '마무리 짓는 법'을 생각하는 것이 중요하다. 고객 대상 실험에서는 기대치를 설정해야 그들을 만족시키고 실험의 실패 위험을 줄일 수 있다. 고객을 대상으로 실험하는 이유, 진행 방식과 종료 시기, 다음 단계 계획을 설명하자. 실험을 성공으로 이끄는 열쇠는 의사소통이다.

대행
마케틀리가 강사들을 상대로 진행했던 실험을 '대행' 실험이라고 한다. 대행 실험은 최종 결과물을 수동으로 만들어 고객에게 제공하는 방식으로, 실제로 적용할 수 있는 방안은 전혀 아니다. 고객들은 기업이 결과물을 자 동으로 생성하지 않고 직접 만들고 있다는 것을 안다. 나는 코드를 짤 필요 가 없고 빠르게 시작할 수 있는 이 방식을 좋아한다. 고객들과 긴밀히 협력하므로 의견을 많이 받을 수 있고 촘촘한 학습고리가 생긴다.
대행 실험은 특히 B2B 기업이 관심을 가질 만하다. 많은 기업이 이런 식으로 출발하기 때문이다. 즉, 고객사의 일을 대신해 주다가 나중에 자동화하는 것이다...(중략)

대행 실험은 매우 강력한 도구가 될 수 있다. 단, 노동집약적 방식이어서 규모를 확대할 수 없다는 점에 주의하자...(중략)... 해결 방안을 확장해 더 많은 사람을 상대할 수 있는지 알아보는 단계가 되면 다른 유형의 실험을 해야 한다.

오즈의 마법사
더 넓은 사용자층의 의견을 받기 위해 내가 제안하는 방식은 '오즈의 마법 사다. 대행 실험과 달리 오즈의 마법사 실험은 실제로 완성되어 출시된 프로덕트처럼 보이고 느껴진다. 화면 뒤에서 모든 일이 수동으로 이루어진다 는 사실을 고객은 모른다. 오즈의 마법사에서처럼 누군가가 모든 것을 조종하고 있다.

바로 자포스가 오즈의 마법사 방법으로 서비스를 시작했다. 창립자 닉 스윈먼은 사람들이 인터넷에서 신발을 정말 살지 보고 싶어 워드프레스에서 간단한 웹사이트를 만들었다. 방문자들은 인터넷으로 신발을 보고 살 수 있었지만 그 뒤에 있는 사람은 닉 혼자였다...(중략)... 주문이 들어오면 그가 나가서 처리했다. 그는 그런 방식으로 사이트 전체를 구축하지 않고도 온라인으로 신발을 사려는 수요가 있다는 것을 확인했다. 이것이 오즈의 마법사다.

오즈의 마법사를 A/B 테스트와 같은 기술과 결합하는 방법도 있다. A/B 테스트는 새 아이디어가 반영된 페이지로 일부 방문자를 보내놓고 현재 상태의 페이지와 비교해 지표에 변화가 있는지 알아보는 것이다. 

콘셉트 실험
'콘셉트 실험'은 고객과 직접 접촉하는 소통에 더 중점을 둔 해결 방안 실험 방법이다. 사용자에게 시연해 보이거나 콘셉트를 보여줘 반응을 측정하는 것이다...(중략)... 최대한 빠르고 간단한 방법으로 문제 해결 아이디어를 제시해 메시지를 전달하는 것이 핵심이다.

가설을 확실히 실험하기 위해 평가적 실험을 하고 싶다면 고객에게 콘셉트 인터뷰를 할 때 확고한 통과 · 탈락 기준을 세워두어야 한다. 

이런 실험들이 상당히 흥미가 가는데요. 저는 회사에서 빌링시스템을 맡고 있습니다. 지금은 우리 회사 상품에 대한 요금을 계산하고 청구서를 내보내고 있지만, 언젠가는 SaaS형으로 우리 회사 상품 외에 타사의 상품에 대한 요금계산과 청구서 발송을 하는 서비스를 만들고 싶은데요.
 
대기업은 자체 빌링시스템을 구축하겠지만, 소규모 업체나 스타트업 등은 자신들의 주된 상품 외의 부수적인 업무는 잘 모르기 때문이죠. 다만, 이런 서비스가 얼마나 시장에 니즈가 있는지 모르기 때문에, 실험을 거쳐서 고객들의 니즈를 확인하고, 사업화하는 것이 올바른 방향이겠습니다. 특히 오즈의 마법사 방법처럼, 최종적으로 고객은 발송되는 청구서만 보고, 실제로는 수작업으로 데이터 편성해 준다던지.. 하는 방식이 좋겠네요. 
 
그리고, 늘 어떤 방법이든, 항상 정답은 아니며, 상황에 따라 실험을 하거나, 실험을 하지 않을 수도 있으며, 위에 나오지 않은 방법을 시도할 수도 있습니다. 상황에 따라 적절한 실험을 하는 것이 중요하겠습니다. 

4. 해결방안 개발과 최적화

프로덕트 비전 진화

북극성 문서는 팀과 회사 전체가 시각화할 수 있는 방식으로 프로덕트를 설명한다. 해결하기 위해 노력 중인 문제, 제안하는 해결 방안, 성공에 영향을 미치는 해결요인, 프로덕트가 도출할 결과를 모두 기록한다. 

북극성 문서는 광범위한 대상에게 맥락을 알려주기 좋으며 시간이 흐르고 프로덕트를 더 알아가면서 계속 발전시켜야 한다. 이 문서는 시행 계획이 아니라는 것을 명심하자. 여기에는 프로덕트를 어떻게 개발하겠다는 내용이 들어가지 않는다. 그것은 스토리 매핑으로 확인한다.

스토리 매핑은 팀들이 업무를 분류하고 목표를 중심으로 정렬하도록 도와준다.

...(중략)  스토리 매핑을 효과적으로 활용하려면 출발점은 항상 큰 그림, 즉 북극성이어야 한다. 그렇지 않으면 의지할 기반이 없어 개발 함정에 빠지고 만다. 

북극성 문서로 프로덕트 비전을 구성원들이 모두 이해하도록 하고, 스토리 매핑으로 구체적인 계획을 세워서 실행하라고 합니다. 그래야 개발함정에 빠지지 않는다고 합니다. 그리고 북극성 문서는 계속 발전시켜야 한다는 내용입니다. 
어찌 보면 뻔한 내용인 것 같은데, 우리 회사는 이런 걸 하는 것 같지가 않으니, 뻔한 게 아닌 거 같기도 하네요.

업무 우선순위 정하기

...(중략) 지연비용은 달성하려는 결과에 시간이 미치는 영향을 보여주는 수치 값이다. 이 값에는 긴급성과 가치가 결합되어 있으므로 그 영향을 측정하면 무슨 일을 먼저 해야 할지 순서를 정할 수 있다. 

프로덕트의 첫 번째 버전을 개발해 출시할 예정이라면 확보 가능한 가치의 양, 출시 범위, 세상에 내보내는 데 드는 시간 사이의 균형을 고려해야 한다...(중략)

이 상황에서 우리는 각 기능이나 기능 요소를 긴급성과 가치 측면에서 논의해야 한다. 긴급성이 높다는 것은 고객에게 그 기능을 제공하기 전까지 매 순간 목표를 달성할 기회가 사라지고 있다는 뜻이다. 

지연비용을 더 알고 싶다면 블랙 스완 파밍(https://blackswanfarming.com/ 사이트에 들어가 적용방법을 알아보자.

지연비용의 질적평가 방법

지연비용을 계산할 때 출시 범위를 너무 넓히면 프로덕트 개발기간이 길어져 시기를 놓칠 수 있고, 너무 좁히면 프로덕트 수준이 낮아지므로 적정한 범위를 찾아야 한다는 내용입니다. 그리고, 위의 표를 이용해 무엇을 먼저 할지 결정을 합니다.

완료의 진짜 정의
특정 기능 개발과 반복 과정을 완료했다고 볼 수 있는 시점은 목표가 달성된 순간뿐이다.
기능의 첫 번째 버전을 내놓은 다음 사용자들의 반응을 측정하지 않고 다음으로 넘어가는 경우가 종종 있다. 

일은 마케틀리처럼 해야 한다. 출시 전에 성공 기준을 세워 놓고 그 기준에 도달할 때까지 지표를 측정하고 반복 시행하는 것이다...(중략)... 기능을 출시했는데 목표가 달성되지 않으면 기꺼이 전 단계로 돌아가 다른 것을 시도할 수 있어야 한다. 

프로덕트 출시의 성공기준이 있으면 프로덕트 카타를 적용해 지금까지 우리가 밟아온 과정을 반복할 수 있다. 성공 기준과 방향을 정하고 목표 달성을 가로막는 문제를 알고 실험을 통해 체계적으로 그 문제들을 헤쳐나간다. 

새 기능을 개발할 때나 기존 기능을 최적화할 때나 과정은 같다. 새 프로덕트가 아니라 작은  기능을 개발한다면 문제 탐구 기간을 줄일 수 있다. 해결 방안 실험도 마케틀리에서처럼 긴 과정을 거칠 필요가 없을 수도 있지만 어떤 상황에서든 반드시 문제를 진단하고 해결방안을 파악하려고 노력해야 한다. 

이것이 의도에 따라 프로덕트를 개발하고 개발 함정에서 탈출하는 방법이다.

최종적으로 정리하면, 프로덕트 카타를 중심으로 전략 창조 및 배치 후에 프로덕트 매니지먼트가 실행됩니다.중요한 것은 처음 정한 목표가 달성되지 않았다면, 기꺼이 가장 앞으로 돌아가 다른 것을 시도해야 한다는 것입니다.

5부에 계속..

2023.03.25 - [IT 말고/책 리뷰] - [경영] 개발 함정을 탈출하라 -5부 프로덕트 중심 조직

[경영] 개발 함정을 탈출하라 -5부 프로덕트 중심 조직