문제와 가설을 제대로 정의하는 PM의 노하우

두루뭉술한 아이디어, 어떻게 뾰족하게 만들까?

제가 PM으로서 처음 담당한 프로덕트는 이른바 '욕망의 집합체'였습니다. 무엇을 검증하고 싶은지, 어떻게 검증할 것인지, 검증이 완료된 후 어떻게 확장할지 명확하지 않은 채 기능만 가득했거든요. 아이디어는 가득했지만 문제와 가설의 정의가 불분명했고, 그 아이디어를 검증하기 위해 정말로 필요한 것이 무엇인지 몰랐던 탓이었죠. 

그래서 이 아티클을 준비했습니다. 이 글은 실현해 보고 싶은 아이디어는 많지만 아이디어를 검증하는 구체적인 방법을 몰라서 막막한 주니어, 그중에서도 이제 막 서비스 기획이나 프로젝트 및 프로덕트 매니징에 발을 들인 주니어라면 큰 도움이 될 거예요. 

문제와 가설을 정의하는 게 익숙하지 않으면 두루뭉술한 아이디어와 기능만 많아지기 마련입니다. 그래서 이번 아티클에서는 문제와 가설을 명료하게 정의하고 이를 활용하는 방법을 다룹니다. 그와 함께 제가 그동안 겪었던 여러 가지 시행착오들도 공유해 드릴게요. 

문제와 가설, 명료하게 작성하는 법

이 글을 읽는 분들에게 '문제 정의'나 '가설'이라는 말이 낯설진 않을 것 같습니다. 유명한 창업 스토리나 <린 스타트업> 등을 통해 '제품을 통해 고객의 문제를 해결한다', 'MVP를 통해 시장과 고객에 대한 가설을 검증한다'와 같은 이야기를 접할 수 있으니까요.

난생처음 제품의 MVP나 그로스 실험을 설계한다고 생각해 보죠. 그럼 우리는 지금 이 기획이 훗날 위대한 성공의 첫 시작이기를 기대하면서 다음과 같이 문제를 정의하고 가설을 적을 겁니다. 

(고객들은 현재 OO한 문제를 경험하고 있다. 따라서) OO하면 OO할 것이다. 

그런데 동료 디자이너와 개발자는 어딘가 부족하거나 과하다고 얘기합니다. 그래서 뭔가 빠트렸나 싶어 열심히 수정해요. 하지만 사수나 대표님의 반응도 크게 다르지 않습니다. 정확히 무엇이 문제고, 무엇을 검증하겠다는 건지가 모호하다는 평을 듣죠. 

그렇다면 대체 문제와 가설을 어떻게 정의해야 좋을까요? 여기에는 크게 4가지 방법이 존재합니다. 

1) 문제와 해결 방안을 분리해서 생각하기

문제와 가설을 제대로 정의하기 위한 첫 번째 단계는 해결하려는 문제(problem-to-solve)와 해결 방안(how-to-solve)을 분리해서 생각하는 것입니다. 즉, 문제를 '정의'하는 단계에서부터 해결책을 떠올릴 필요는 없다는 뜻입니다.