고객 문제에 집중하여 우선순위를 선정하기
<프로덕트 리더십>을 읽고 생각 정리하기
이 글은 지난 글에 이어 <프로덕트 리더십>의 3장 '훌륭한 프로덕트 리더' 중에서 92~94쪽에 등장하는 '전략에서 로드맵으로 전환'을 소화하며 느낀 내용을 씁니다.
고객 문제에 대한 주제 집중하기
지난 글에 연이어 로드맵에 대한 오해를 줄이기 위한 설명이기도 합니다.
로드맵은 전략 문서이기 때문에 일련의 기능이나 솔루션이 아니라 초점을 맞춰 해결해야 하는 고객 문제에 관한 테마다. 로드맵을 테마로 전환하는 것은 엄청나게 강력하다.
비유적으로 생각하면(독자님이 프로그래머라면) 객체 지향 프로그래밍 언어에서 인터페이스만으로 구성해야 로드맵이 힘을 얻는다는 말이 될 수 있습니다. 또 다른 식으로는 사용자 스토리 혹은 도메인 스토리로 표현해야 한다는 사용자 지향성을 말한다고 볼 수도 있습니다.
비유와 다른 점이 있다면 '테마'란 표현입니다.
테마는 고객을 위해 프로덕트 팀이 할 수 있는 가장 중요한 것을 한 번에 알게 한다. 고객 문제에 우선순위를 두기 위해서는 문제를 먼저 이해하는 것이 필요하다.
고객만의 용어를 써야 한다고 말할 수 있습니다. 마치 제가 좋아하는 Ubiquitous Language의 필요성을 달리 표현한 것이라고 볼 수도 있습니다. 10여 년 전에 스크럼에서 쓰던 말인 Epic 같은 분류(묶음) 단위가 떠오르기도 합니다.
공급자 관점에서 벗어나 생각하기
아래 문장과 연관해서는 근래 저에게 벌어졌던 두 가지 일들을 떠올려 생각을 만들어 주었습니다.
베이스캠프Basecamp의 프로덕트 매니저 라이언 싱어Ryan Singer는 "우리는 좋은 아이디어가 있다고 자주 생각한다. 하지만 그 아이디어는 대부분 공급 관점에서 시작한다"라고 말한다. "우리는 개발하고 싶은 것을 개발하기 위한 이유를 찾는다.
하나는 베이스캠프가 일으킨 생각입니다. 아름다운 가게와 일할 때 그곳이 베이스캠프를 쓰고 있어 Ruby 언어가 뜨던 시절 듣다 잊었던 이름을 떠올렸습니다. 그리고 이전 CTO 님이 찾은 방법론 참조 모델 Shape Up의 개발사도 베이스캠프였습니다.
그리고 지인인 호성 님과 프로그램 재사용에 대해서 이야기할 때 그가 화이트보드에 써 가며 말했던 제공자 관점에서 생각하는 재사용의 한계에 대한 대화가 떠올랐습니다.
그리고 공급 관점에서만 생각하는 함정 혹은 우물에서 벗어나기 위한 비결을 말합니다.
프로덕트를 더 깊이 발전시키기 위한 진정한 방법은 한걸음 뒤로 물러나 수요 측면을 생각하고 질문하는 것이다. 이 아이디어가 지금이 적절한 때인가? 왜 이것이 중요한가? 지금 무엇이 문제인가?
우리 회사에서도 ART를 차용해서 만든 B*ART가 이런 방법의 구현체입니다.
우선순위 선정을 위한 원칙
저는 현재 CEO이면서 동시에 프로덕트 매니저이기에 양쪽 입장에서 아래 문장을 살폈습니다.
우선순위를 선정하는 시작점으로 기능에 대한 CEO의 직관적인 반응을 삼는 것은 좋지 않다.
먼저 프로덕트 매니저 관점에서는 '폭포수(?)'는 좋은 결과를 절대로 내지 못한다는 믿음을 재확인하는 것이었습니다. 다음으로 CEO 관점에서는 저의 권한 남용 혹은 충동적 개입을 막을 장치에 대한 부분입니다. 저는 위임을 강조하고 실행의 동력이 저에게 출발하는 일은 길게 가지 않는다고 확실하게 믿습니다. 그래서, 동기 부여가 필요한 사람은 리더로 세울 수 없다는 사실도 분명하게 알고 있죠.
하지만, 프로세스로 만들어 일상의 루틴이 되지 않으면 사람인 이상 실수하거나 방과 할 수 있습니다. 그래서 두레이에서 OKR을 적용하면서 목표나 핵심결과(KR)를 기록한 업무와 실행 업무를 구분합니다. 제가 이런 일을 필요하다고 업무를 배정하는 일과 이를 담당자가 수락하여 스스로 책임을 받아들이는 일 사이에 여지를 둔 '느슨한 결합' 응용입니다. 느슨한 결합은 빠르게 재구성할 수 있는 힘을 주는데, 중요한 일인데 담당자가 이를 탐탁지 않게 여기면 다른 담당자나 외부 파트너를 결합시켜 조직을 꾸릴 수 있기 때문입니다.
저자는 우선순위를 위한 해법으로 '핵심 프로덕트 관리 원칙 렌즈'를 제시합니다. 렌즈는 간단한 세 가지 항목으로 구성됩니다.
가치
사용 가능성
실행 가능성
다음 B*ART에서는 저희도 이를 활용해 보고 싶습니다.
