어제 PM 멤버들이 모여서 PRD(Product requirement document) 작성에 대해서 서로 피드백을 가지는 시간을 가졌다. 프로젝트의 진행, 완료 여부 관계 없이 관련 PRD를 리뷰하면서 의미있는 피드백을 나누었다. 멤버들끼리 문제점 정의, 문서를 읽은 대상자 고려한 도메인 지식의 상세한 정도, 시각화, current state와 desired state를 어떻게 문서화하면 좋을지 의견을 주고 받았다. 그 중에서 내와 유사하게 공통된 문제인식을 가지셨던 멤버가 있었다. 과거에 진행되었던 특정 프로젝트를 같이 돌아보면서 프로젝트 초기 시점에 놓쳤던 중요한 business feasibilty를 어떻게 그 시점에 체크할 수 있을지 이야기했다. 미팅에선 관련해서 구체적인 액션 아이템은 나오지 못했다. 그 뒤 오늘 Lenny's Podcast의 링크드인 글에서 과거 포커 플레이어였고 현재 decision making 관련 코칭을 하는 Annie Duke 인터뷰 글을 읽었다. Annie Duke는 pre-mortem이라는 기법을 소개했다. pre-mortem은 프로젝트 시작 전에 팀이 모여서 프로젝트가 실패하는 상황을 가정하고, 관련 원인과 assumption을 찾아내는 기법이다. 의사결정 관점에서 위험 징후를 사전에 가정해봄으로써 실제 상황에서 방향성을 선회하는 것이 유연해지고, 소위 말하는 매몰비용과 확증 편향이 커지기 전에 포기하기 쉬워진다는 것이다. "Use pre-mortems to set kill criteria. Before starting a project, imagine failure and what early warning signs might have predicted it. Commit in advance to reassess or pivot if you notice those red flags later on. This makes it easier to walk away when sunk costs and overconfidence bias loom large." - Annie Duke 최근에 읽었던 Continuous Discovery Habits에서도 비슷한 개념이 언급이 되었고, 그 내용은 아래와 같다. 아이디어를 중심으로 일을 하는 것은 리스크가 크다. 많은 사람들이 제품 개발 의사결정 과정에서 고객의 요구사항을 듣고, 떠오르는 첫번째 아이디어에 바로 뛰어든다. 몰입 상승 효과(escalation of commitment)에 빠지게 된다. 이 아이디어를 개발해야하나? 좋은 아이디어인가? 결국 해당 아이디어 틀에서 일을 하다보니 소위 몰입 상승 효과(escalation of commitment)라 불리는 인지적 편향에 빠지기 쉽다. 즉, 우리가 아이디어에 더 많이 투자할수록 그 아이디어와 자신을 동일시하게 된다(‘아이디어에 반했다’라고 표현하는 상황). 우리가 아이디어에 반하게 되면, 두 번째로 확증 편향(confirmation bias)에 빠지게 된다. 우리가 사랑한 아이디어가 좋다는 증거를 더 쉽게 받아들이고, 아이디어에 결함이 있음을 제안하는 증거를 놓치게 된다. 보통 일하다보면 특정 아이디어와 솔루션 중심으로 product feasiblity만 체크하고 프로젝트를 진행하는 경우가 많다. 앞서 소개한 pre-mortem을 통해 프로젝트가 실패했다고 가정하고 product feasibilty 외 business 관점에서 여러 assumption을 생성해보고, 나열된 assumption을 비교 및 대조해보는 것만으로 많은 인사이트를 발견할 수 있다.

고객 인터뷰할 때 흔히 빠지기 쉬운 함정은 미리 솔루션 또는 형상을 정해놓고 검증을 하는 경우이다. 보통 이러한 형식으로 진행되는 고객 인터뷰는 미리 정해진 질문 기반으로 본인이 가진 아이디어, 생각을 뒷받침할 고객의 피드백을 수집하는 형태가 다수이다. 고객 인터뷰에서 중요한 것은 기능적 요구사항 같은 것을 얻거나 검증하는 것이 아닌 고객의 unmet needs, problem을 발견하는 것이다. 이를 위해서 고객 인터뷰는 답변 얻는(내가 원하는) 형태가 아닌 고객이 계속 이야기(스토리)를 할 수 있도록 분위기를 만들어야 한다. 고객에게 몇번 무엇을 했는지, 어떤 기능을 이용했는지 여부 등을 물어보는 것은 큰 의미는 없다. 대부분 기억이 명확하지 않고, 왜곡된 경우가 많다. 그러면 고객이 이야기를 하도록 하는 인터뷰는 어떤 형식일까? 예를 들자면 링글 고객을 가정하여, 가장 최근에 링글 수업을 들었을 때 상황을 고객이 이야기하도록 유도하는 것이다. 혹은 더 다양한 맥락을 유도하면 가장 최근에 영어 공부를 했던 경험에 대해서 이야기하도록 하는 것이다. 그렇게 대화를 시작하면 대부분 고객들은 자연스럽게 자신의 경험을 이야기한다. 그리고 고객에 따라 다르지만, 다수는 일부 디테일, 단계를 건너 뛰고 넘어가는 경향이 많다. 이럴경우에 그 디테일에 대해서 질문을 하여 그 주제/경험에 대해서 최대한 많은 이야기가 형성될 수 있도록 한다. 많은 제품 담당자들이 고객 인터뷰가 힘들다고 한다. 고객과 인터뷰를 하면 단답형으로 답변하는 경우가 대부분이라고 한다. 그러한 고객 인터뷰 패턴을 관찰하면 미리 준비한 질문을 기반으로 답변을 유도하는 경우가 다수이다. 만일 충분히 고객의 이야기를 이끄는 인터뷰를 시도했는데 고객이 단답형으로 이야기하거나, 버그나 기능 개선 아이디어 중심으로 이야기한다면 고객에게 너무 많은 부담을 주지 않은 선에서 최선을 다하다가 마무리하면 된다. 즉, 고객 인터뷰를 자주 할 수 있는 구조를 갖추어서.. 개별 인터뷰 하나 하나에 모든 것을 결론내고 검증한다는 생각을 버려야 한다.