MVP를 하는 이유가 최소한의 리소스를 투입한 가설검증인데, 방점은 '가설검증' 인거죠. 많은 곳에서 '최소 기능 제품(Minimum Viable Product, MVP)'을 고민하면서 무조건 작

MVP를 하는 이유가 최소한의 리소스를 투입한 가설검증인데, 방점은 '가설검증' 인거죠. 많은 곳에서 '최소 기능 제품(Minimum Viable Product, MVP)'을 고민하면서 무조건 작게라도 제품을 만들어보고 판단을 해야 한다는 주장이 설득력을 얻곤 합니다. 해당 방식을 검증하는 프로세스와 리소스가 충분하다고 한다면 가능할 수 있으나 어느 서비스도 기획/디자인/개발 리소스가 남아도는 곳은 없을거라 봅니다. 작게시작하고 지속적으로 수정하는 MVP 방식에 동의 합니다. 다만 여기 나와 있는 것 처럼 MVP 하기전에 검증해낼 수 있는 것을 최대한 검증해내는게 효율적인 리소스 투입을 위한 핵심이네요. 가설검증 방법에 추가로 하나 덧붙이면 동종 서비스 또는 이종 서비스의 제품을 분석해보는 것도 도움이 될 듯 합니다. 고객은 항상 우리 제품, 경쟁사 제품만 쓰는게 아니니까요. [내용요약] #1. 우리가 고객에 대해 학습할 수 있는, 가설을 검증할 방안 : 프로덕트 팀이 일하는 궁극적인 목적은 고객에 대해 학습하고 고객에 대한 가설을 검증하기 위함이다. 1.지표를 분석하다 2.설문 또는 인터뷰를 진행해 직접 물어본다 3.사용자 참여 테스트를 진행한다 4.VOC를 확인한다 5.제품 외의 도구, 툴을 이용해 실험해본다 #2. MVP라는 이름의 불필요 리소스와 리스크 : 제품없이도 가설을 검증할 수 있는 경우, 아래의 문제가 발생한다 1.PM이 고작 일정관리자가 된다 - 디자인 및 개발팀의 할당 리소스가 없으면, PM은 기획이 끝난 뒤 제품이 나올 때까지 멀뚱멀뚱 기다리게 된다. 혹은 개발팀의 일정을 보채게 된다 2.속도가 느려진다 - 기획한 걸 디자인-개발을 통해서만 순차적으로 구현, 검증하는 과정은가설 수립과 검증 사이에 불필요한 기간 또는 리드 타임이 발생하면서 해당 과정의 완성을 기다리게 된다 3.제품을 만드는 것 자체가 리스크다 - 왜냐면 대부분의 제품은 실패하니까