실제 비용과 가치 검증은 프로덕트 릴리즈 이후 발생
<프로덕트 리더십>을 읽고 생각 정리하기
지난 글에 이어 <프로덕트 리더십>의 6장 '스타트업 조직' 중에서 '고객 이해하기'를 소화하며 쓴 지식 기록입니다.
실제 비용은 고객에게 프로덕트를 출하한 이후 발생한다
저 역시 고생 끝에 깨달은 값비싼 경험인데 저자기 짧은 단락에 담은 듯한 표현입니다.
"기능에 필요한 실제 비용은 디자인, 엔지니어링, 필요한 모든 기능이 포함된 프로덕트만이 아니다"라고 마이크 브라운은 경고한다. "실제 비용은 개발이 완료된 후 생산 단계에서 발생한다. 프로덕트가 생산되고 나서 개선이 필요한 무언가를 해결해야 하기 때문이다. 생산 단계 이후의 모든 기능은 비용으로 고려돼야 한다. 사실 실제 비용은 고객에게 프로덕트를 출하한 이후 발생한다." 브라운은 어떤 의사 결정을 내리기 전에 필요한 정보와 데이터에 좀 더 많은 시간을 투자해야 한다고 주장한다.
이를 이해한다면 릴리즈(고객에게 출하하기)를 빨리 하는 방법을 찾아야 합니다. 다시 말해 결정할 항목을 나눠야 할 수 있습니다. 다양한 요소를 고려하여 한번에 릴리즈 하지 말고, 결정을 하기 위한 단계적 릴리즈를 해야 할 수도 있습니다. MVP(Miminum Viable Product)라는 개념이 이를 표현하는 말이라 할 수 있습니다.
Published Interface 개념
아래 내용을 보니 오래전에 읽은 글이 생각났습니다.
IEEE는 멤버 데이터를 기반으로 소프트웨어 배포 후 소프트웨어 문제를 해결하는 것은 개발 시작 전 해결하는 것보다 100배의 비용이 든다고 증명한다.
대학원 다니던 시절에 마틴 파울러의 블리키를 번역한 일이 있었는데, 그때 기억인 듯합니다.
핵심 문장을 보니 그가 IEEE에 칼럼을 써서 주장했다는 기록이 있네요.
In my column for IEEE Software I argued that the distinction between published and public is actually more important than that between public and private.
골자는 공개 수준을 말하는 public과 달리 published는 발행 후의 상호작용을 의미하여 파급효과가 매우 크다는 뜻입니다. 마치 파동처럼 영향도가 퍼져 나가고 나비 효과란 말처럼 예상 못한 파문을 일으키기도 하죠. 내가 배포한 API를 사용하는 프로그램 그리고 그 프로그램을 수정하는 개발자들이 늘어날수록 복잡한 이해관계가 생겨납니다. 이해관계는 비단 돈만을 의미하지 않습니다. 고치기 싫은 감정이나 가족과 해외여행을 다녀와야 하는 계획 등을 포함하죠.
프로토타이핑과 프리토타이핑
힘든 교훈이라는 문구에 마음이 갑니다.
브라운은 힘든 교훈을 얻게 되면서 이제는 모든 새로운 계획에 대해 프로토타이핑을 추진하는 것을 주장한다.
<아이디어 불패의 법칙>에서는 처음에는 프로토타이핑도 하지 말라고 합니다. 그러면서 그보다 더 비용을 줄일 수 있는 대안을 제시하죠.
다음 내용은 <아이디어 불패의 법칙>에서 말하는 실패로 가는 경로를 떠오르게 합니다.
범위를 줄이지 않으며 실험하지 않는다. 단순히 첫 번째 버전을 빌드하고 실행한다. 그리고 프로덕트의 성공을 측정하지 않는다. 코딩을 하기 전 팀이 프로덕트에 대한 많은 질문에 대답하는 논리적인 단계별 접근법이 빠져 있다.
사용자가 왜 내가 고안한 기능을 써야 하는가?
경영을 한 이후에 투자자에게 설명하는 일을 겪으면서 다음 문장에 대한 무게감이 확실히 달라졌습니다.
사용자가 과거 습관을 극복할 만큼 충분한 가치를 제공해야 한다. 사용자는 사용 중인 프로덕트 또는 솔루션을 바꾸려면 비용이 발생하므로 솔루션이 단순히 좋기만 해서는 안 된다. 솔루션 전환에 필요한 노력보다 더 많은 가치를 가져야 한다.
아래 저의 경험에서 '현타'라 표현한 구간을 지날 때에 인용한 문단의 마지막 문장의 무거움을 깨달은 듯도 합니다.
여기서 전환비용을 어떻게 바라볼 것인가에 대한 잣대가 사업을 어떻게 보느냐의 잣대가 된다고도 할 수 있습니다. 흔히 전환율을 올리기 위해 '마케팅을 태운다'라고 접근하는 분들이 많습니다. 저도 그 방법 자체를 부정하지는 않았는데, 지금 보니 사회적 통념(혹은 Best Practices)을 자기 잣대 없이 수용하는 경향으로 볼 수도 있을 듯합니다.
여기서 자기 잣대를 가지려면 어떻게 해야 할까요? 왜 사용자 입장에서 전환 비용을 감당할 만한 분명한 혜택이 있어야 합니다. 소개나 유인에 그치는 일회적인 전환이 아니라 계속 쓰고 사용자로 머물 수 있는 혜택이 잣대가 될 수 있어야 한다는 생각을 하게 되네요.
이에 대한 책의 조언은 이렇습니다.
귀는 두 개고 입은 하나다. 더 많이 듣는 데 집중하자.
의식적으로 듣는 시간을 갖는 것이 모든 것을 잘하게 하는 기술이다.
가능한 한 가장 마지막에 말하겠다는 마음으로 시작한다.
"더 자세히 말씀해 주시겠습니까?" 하고 묻는다.
"어떻게 동작하는지 보여줄 수 있나요?"라고 응답하자.
사람들이 말을 끝내면 들은 내용을 다시 질문해서 확인한다.
<듣기의 말들>을 읽으면서 경청이 얼마나 어려운지 실감했는데, 프로덕트의 가치를 높이기 위해서도 필수적인 일이었다는 사실을 깨달으니 잠시 겸손함이 피어납니다.
지난 <프로덕트 리더십>을 읽고 생각 정리하기
11. 프로덕트는 팀 스포츠다
14. 프로덕트 리더 채용하기
