프로덕트 매니저 포지션 지원자에게 내가 언제나 요구하는 생각의 구조가 있는데, 바로 문제(아이디어) - 가설 - 실행 - 측정(-및 개선)의 프레임워크이다.
스크리닝 인터뷰에서 이 프레임워크를 활용하여 자신의 생각을 말하거나, 과제 전형에서 사용한다면, 내용을 떠나 최소 10점의 가산점은 준다.
린스타트업, 승려와 수수께끼, 캐즘, 심지어는 레이달리오의 원칙에까지 소개되는이 프레임워크는, 내가 아는 한제품의 성공 가능성을 높일 수 있는 거의 유일한 방법이다.
간혹 '프레임워크는 생각을제한한다'라는 말장난으로 이런 의견을 비판하는 경우가 있기는 하나, 그 제한되지 않은 생각으로 만들어진 아이디어 또한 검증의 대상이기 때문에 달라질 바는 없고,가설과 측정 없이 만들어낸성과는 소 뒷걸음질 치다 잡은 생쥐라고 생각하기 때문에 딱히 의미 있는 견해라고는 생각하지 않는다.
아이디어는 불완전하다. 그것이 불꽃같은 인사이트에서나왔던, 업계 저명인사로부터 받아 든 제언이던 검증하기 전까지는 완전하지 않다.
모든 창업자와 사업개발담당자, 프로덕트 매니저(오너)는 자신의 생각에 대한 자부심을 일단 내려놓고 그것이 가설일 뿐임을 인정해야 한다. 사실로 확인된 것과 그렇지 않은 것은 냉정하게 구분할 수 있어야 한다.
특히 자원이 한정된 스타트업은 경제적 측면에서라도 이런 시각을 견지하는 것이 굉장히 중요한데, 제품 혹은 비즈니스 모델의 단위를 잘게 쪼개어 개별적으로 검증하는 것은 자원의 낭비를 물리적으로 제한하기 때문이다.(린스타트업 및 비즈니스 모델과 연결되는 내용이다. 다음에 자세히.)
여기서 가설을 검증하기 위한 도구로서의 제품을 MVP(minimal viable product)라 한다. (기회가 된다면, 이 또한 다음에.)
문제란 일반적으로 시장이나 제품에서 발생한, 고객 입장에서 겪게 되는 불편함이다. 간혹 공급자 입장의 문제를 논하는 경우가 있는데, 문제를 겪는 공급자가 우리의 고객이 아니고서는 문제를 잘못 정의한 것이다.
(작업이 내부 프로세스를 개선하는 것이라면 틀리진 않겠다)
잘 정의된 문제는 타겟을 명확하게 정의하며, 타겟이 행동에 나설 만큼 충분히 크리티컬 하며, 의미 있는 가설을 도출하게 한다.
가령 다음과 같다. '20XX년부터, 서울 시내 모든 유치원은 CCTV를 설치하지 않으면 영업을 할 수 없다.
가설은 무엇인가? 타겟의 문제를 해결해주리라 생각하는 가정이다. 잘 정의된 가설은 문제에서 도출되며, 입증 / 기각을 판가름할 수 있는 정량적 기준이 있고, 행동으로 연결할 수 있다.
가령 다음과 같다. '1/10 수준의 가격으로 CCTV를 보급한다면 서울 시내 유치원의 OO%는 우리의 제품을 도입할 것이다'
이제 가설을 입증할 수 있는 구체적인 실행방법이 필요하다.
이 예시에서는 다음의 방법이 적절할 것 같다.
'최소 5년 이상된 폐스마트폰을 활용하여 1/10 가격의 고해상도 CCTV 솔루션을 만든다'
마지막으로 측정과 개선이 남았다.
측정과 개선에서 중요한 것은 우리가 이 가설로부터 KPI를 도출할 수 있는가 이다.
이 예시에서는 '서울 시내 우리 솔루션을 도입한 유치원의 비율' 정도가 되겠다.
만약 가설에서 세워놓은 기준을 달성했다면 이 가설이 입증되었다고 본다.
놀랍게도 동시에 고객이 날카롭게 정의 되었고, 솔루션을 '팔아' 보면서 나름대로 노하우도 생겼을 것이다. 다음 단계 수행에 있어 소중한 발판이 될 것이다.
그렇지 않다면 가설이 기각되었다고 보고, 어떤 부분을 수정할지를 살펴본다.
문제와 가설, 수행 방법을 명확하게 정의했다면 가정이 실제가 아닌 지점도 찾기가 수월할 것이다. 이 또한 굉장히 소중한 우리 팀 만의 노하우가 된다.
이러한 철학은 제품의 작은 기능에서 비즈니스 모델 자체에 이르기까지 모든 범위에서 적용 가능하다.
기능이나 비즈니스 모델에 가정이 반복될수록 성공가능성은 기하급수적으로 낮아진다. (산술적으로 그렇다.)
반대로, 철저한 검증으로 가정을 하나씩 사실로 만들어간다면 성공가능성은 기하급수적으로 높아진다.
