로드맵 전환 과정에서 모호함 다루기
<프로덕트 리더십>을 읽고 생각 정리하기
이 글은 지난 글에 이어 <프로덕트 리더십>의 3장 '훌륭한 프로덕트 리더' 중에서 95~97쪽에 등장하는 '전략에서 로드맵으로 전환'을 소화하며 느낀 내용을 씁니다.
자존심은 버리고 모르는 정보 관리하기
애매모호한 것을 못 견디는 사람들이 많습니다.
애매모호함을 수용하고 기능에 관해 고객만큼 이해하는 것이다. 대부분의 프로덕트 리더는 가설 형태로 기능에 대해 이야기하고 테스트를 통해 그 가설을 신속하게 검증하는 데 많은 시간과 노력을 기울였다. 가설 위주로 생각하면 개인의 의견이 결과에서 제거된다.
<나는 애자일이 싫다>는 그런 부류의 경영자와 일할 때 겪은 경험에 바탕을 둔 글입니다. 반면에 모호함을 그대로 두고도 계획을 세우고 일을 할 수 있습니다. 저는 10여 년 전에 강규영 님과 함께 일하면서 그런 모범을 어깨너머로 배운 듯도 합니다. 그리고 최근 Kent Beck이 쓴 글에는 이를 굉장히 정교하게 다룬 문장이 나오는데 깊은 사유가 필요해 읽다 말았기에 아쉽게도 다룰 수가 없네요.
한편, 다음 문장은 여러 가지 생각을 만들어주는 문장입니다.
베팅이 틀릴 경우 기분이 나쁠 수는 있겠지만 베팅은 단지 베팅일 뿐입니다. 베팅을 사용하면 아이디어를 만들고 공유하는 분위기를 밝게 해 준다.
가장 먼저는 자존심을 중시하면 새로운 것을 배우기 힘들다는 사실을 주니어 개발자 때 배웠던 일이 떠오릅니다. 그리고 TDD를 익힐 때 반드시 실패(Fail)부터 맛보며 자존심을 버리고 시간을 벌었던 고행의 기간이 떠오릅니다. 하물며 경영자는 내 시간이 아니라 돈을 법니다. 자존심을 내세우면 돈을 잃고, 다른 사람들의 직장까지 잃게 만들 수 있죠.
그리고 포커를 즐기지 못하는 저에게 생소하지만 베팅이란 어딘지 모르게 게임이론과 연관성이 있어 보입니다.
작은 베팅과 큰 베팅
먼저 작은 베팅에 대한 책 내용 중에서 인상적인 부분입니다.
기존의 성숙한 프로덕트를 최적화할 때 데이터를 가설에 대입하는 가장 좋은 방법은 a/b 테스트나 다변량 테스트를 사용해 베팅 테스트를 시작하는 것이다. 이 데이터 기반의 접근법은 새로운 행동 유도가 필요할 때 실제 사용자와 고객의 행동을 보여줌으로 모든 변수나 편견에서 멀어지게 한다.
<코호트란 무엇인가?>편과 <린 분석>에서 배웠던 개념과 기법을 떠올리게 합니다.
다음은 큰 베팅에 대한 내용입니다.
우리는 학습에 초점을 맞추고 가장 위험한 가정을 테스트하는 데 중점을 둔다. RAT Riskiest Assumption Test가 명확하다. 가장 큰 미지의 영역을 테스트하는 데 필요한 것 이외의 것을 만들 필요가 없다. 완벽한 코드나 디자인을 기대하지 말아야 한다. 테스트가 프로덕트가 되지는 않는다.
여러 면에서 영감을 주는 글입니다. 꼭 필요한 것은 만들기 전에 반드시 먼저 테스트하라는 교훈은 2020년 책으로 배운 최고의 교훈이었다고 할 수 있습니다. 인용문의 RAT 개념은 이를 떠올리게 합니다.
또한, 테스트와 프로덕트를 혼동하지 않아야 한다는 점 역시 중요한 부분이라 생각합니다. 프리토타입은 투자 가치에 대한 평기일 뿐 제품 개발 자체는 아니니까요.
모호함에 대한 시간 투자
특정 날짜는 왜 중요할까요?
우리가 인터뷰했던 프로덕트 리더들은 일률적으로 로드맵에 타임라인을 표시하는 것을 피했지만, 로드맵은 시간 경과에 초점을 두고 있는 문서이기 때문에 의미 전달을 위해서라도 특정 날짜는 중요하다.
책을 다시 읽어 보면서 아래 문장에서 그 답을 찾습니다.
로드맵을 작성하는 것은 궁극적으로 증가하는 기간을 관리하기 위해 활동을 계획하는 것이다.
목표에 헌신하게 하고, 꼭 필요한 결과(Key Results)에 초점을 맞춘다는 점에서는 OKR과 유사하게 느껴집니다.
수년을 꿈꾸고, 몇 개월을 계획하고, 몇 주를 평가하고, 매일 릴리스하라
꿈꾸는 시간과 계획과 평가가 강조되는 인상을 받는 이유를 다음 문장에서 찾을 수 있습니다.
생각의 폭을 넓히는 것은 노력을 가장 짧은 시간 프레임으로 좁히는 것이다.
생각의 폭을 넓힌다는 것은 선택지를 늘린다는 의미가 아닐까 생각됩니다.
로드맵을 명확하게 자주 전달하지 못하면 효과가 떨어진다.
통제력(controllability)과 옵션의 힘을 활용하기
한편 최근에 읽은 Kent Beck의 글 <Abstract vs. Concrete Parameters>에서도 모호함을 다루는 일이 언급됩니다. 현재의 기능을 만족하면서 동시에 미래의 변화를 대비해야 하는 소프트웨어 설계의 어려움은 경영의 어려움과 일맥상통하는 면이 있습니다. Kent Beck[1]의 글에서 그는 어떤 경우는 추상적인 매개변수(모호함을 포함하여 구체화하는 일)가 통제력 확보에 유리하고 어떤 경우는 구체적인 매개변수가 유리한 모순에 대해 설명합니다.
마지막에는 이들 사이의 균형을 도식화해서 설명합니다.
Kent Beck의 글은 프로그래밍과 자동화된 테스트에 배경 지식을 포함하기 때문에 독자님들께 쉽게 설명할 엄두가 나지 않습니다. 다만, 저는 HBR에서도 종종 언급된 '옵션의 힘'처럼 선택 가능성을 늘리기 위한 의사결정 방법이 다양한 분야에서 격변하는 현실에 대한 대응책으로 등장한다는 점을 포착했다는 사실을 알리고자 이 내용을 덧붙입니다.
덧붙이느라 본문과 매끄럽지 못한 감이 있는데요. 아주 간단히 말하면, 로드맵에 날짜를 고정한 타임라인을 피하는 이유와 결국 실행 시점에서는 틀리더라도 날짜를 정해야 하는 이유가 모두 통제력 유지를 위한 ‘옵션의 힘’을 노리는 일로 볼 수도 있다는 주장입니다.
주석
[1] 이를 위해 Kent Beck은 테스트 주도로 소프트웨어를 구성해 나가는 전략을 TDD라는 이름으로 발표하고 오랫동안 이를 활용하고 전파하고 있죠.
