그걸 꼭 제품으로 검증해야 할까요?

"최소 존속 제품(MVP)은 시장에 약속한 가치를 제공하는 최소한의 제품이다. 그러나 이 정의의 어디에도 이 제품이 실제로 존재해야 한다는 말은 없다." - [린 분석] 中

제품을 만들고, 개선하고, 운영하는 업무를 하다 보면 생각이 자꾸만 제품에만 꽂힌다. 무언가를 개선하기 위해서 제품의 정책을 수정하고, 전략적 성과를 달성하기 위해 새로운 제품을 기획한다. 그리고 어느새 업무가 기계적으로 ‘PRD’ 또는 ‘와이어프레임’을 작성하고 이를 개발팀에 공유하는 식으로 흘러간다.

이는 프로덕트 매니저로 직무를 전환한 뒤, 처음에 가장 혼란을 겪은 부분이기도 했다. 분명 ‘나는 제품 담당자니까, 제품을 통해 고객에 대해 학습해야 하니까, 제품을 통해 고객의 문제를 해결해야 하니까, 좋은 제품을 만들어야 하니까’ 등 생각이 항상 제품으로 귀결되었다.

그러던 어느 날, 여느 날과 같이 기획을 공유하던 스크럼에서 대표님의 피드백을 받았다.

"플래터님, 개발팀이 지금 리소스가 다 할당된 것 같은데, 이런 경우 PM은 뭐를 하면 될까요? 그리고, 그걸 꼭 제품으로 검증해야 할까요?"

‘가설은 꼭 제품을 통해서만 검증해야 하냐?’라니. 순간 머리가 멍했다. 제품 없는 가설 검증이라고? 하다못해 MVP라도 만들어 출시해야 하는 건 아닌가? 필요한 기능만 확실하게 정의한 후 빠르게 구현해서 그 뒤에 반응을 보면 되는 것 아닌가?

그런데, 우리의 목적은 제품을 만드는 것이었나? 애초에 제품팀은 왜 제품을 만드는가?

“그걸 꼭 제품으로 검증해야 할까?

우리의 목적은 제품을 만드는 것이었나?

애초에 제품팀은 왜 제품을 만드는가?”

가설을 검증하는 여러 가지 방법

PM은 고객에 대해 학습하고 이를 제품에 가장 적절하게, 리스크 없이 반영하기 위해 가설을 세우고 이를 검증한다. 제품은 고객에 대해 학습하고, 고객의 문제를 해결하고, 가설을 검증하는 수단이다. 그런데 가설은 꼭 '제품'을 통해서만 검증할 수 있는 걸까? 바꿔 말해 기획하고, 산출물을 정리하여, 디자인과 개발을 거쳐 최종 제품으로 만들어 서버에 배포한 뒤에만 우리는 가설을 검증할 수 있는 걸까?

결론은 '아니오'다.

물론 제품과 서비스의 종류에 따라 어떤 가설들은 최종적으로 제품 혹은 서비스 형태가 나와야만 검증할 수 있다. 정책, 인프라, 부동산과 경제, 의료 등 그 규모가 크고 여파가 큰 산업과 제품, 서비스일수록 더욱 그렇다. 그래서 이러한 영역은 소위 ‘린(Lean)’하거나 ‘애자일(Agile)’ 할 수도 없고, 그래서도 안 된다. 되도록 한 번에 온전하게 성공해야 한다. 그래서 더욱 어렵고, 실패의 리스크도 크다.

그러나 프로덕트 팀으로 볼 때 하는 일의 대부분은 충분히 다른 방안을 검토할 수 있다. 프로덕트 팀이 일하는 궁극적인 목적은 고객에 대해 학습하고 고객에 대한 가설을 검증하기 위함이다. 제품의 개발 또는 개선은 어디까지나 이를 위한 방법의 하나일 뿐이다.

우리가 고객에 대해 학습할 수 있는, 가설을 검증할 방안

1. 지표를 분석하다
2. 설문 또는 인터뷰를 진행해 직접 물어본다
3. 사용자 참여 테스트를 진행한다
4. VOC를 확인한다
5. 제품 외의 도구, 툴을 이용해 실험해본다

바꿔 말해, 제법 많은 경우에 우리는 코드 한 줄 없이도 가설을 검증할 수 있다. 굳이 MVP 형태의 제품을 내놓기 전에, MVP 자체를 만들 필요가 있는지를 검증해볼 수도 있다.

MVP는 린하게, 그리고 리스크를 최소화하기 위한 방안이라고 알려졌다. 그렇지만 MVP마저도 결국에는 불필요한 공수와 리스크를 발생시킬 수 있다. 간단한 설문, 이메일, 실험 등을 통해 검증할 수 있을 것을 굳이 MVP라는 이름으로 제품을 만들었을 수 있다.

“MVP마저도 결국에는 불필요한 공수와 리스크를 발생시킬 수 있다.

간단한 설문, 이메일, 실험 등을 통해 검증할 수 있었을 것을

굳이 MVP라는 이름으로 제품을 만들었다면 말이다.”

MVP라는 이름의 불필요 리소스와 리스크

만약 제품 없이도 가설을 검증할 수 있는 경우, 굳이 제품의 기획, 구현, 배포를 하게 되면 아래의 문제들이 생긴다.

1. 디자인 및 개발팀의 할당 리소스가 없으면, PM은 기획이 끝난 뒤 제품이 나올 때까지 멀뚱멀뚱 기다리게 된다. 혹은 개발팀의 일정을 보채게 된다. 이 경우 PM은 고작해야 일정 관리자밖에 되지 않는다.
    
2. 기획한 걸 디자인-개발을 통해서만 순차적으로 구현, 검증하는 과정은 전형적인 ‘워터폴(waterfall)’이다. 가설 수립과 검증 사이에 불필요한 기간 또는 리드 타임이 발생한다. 더 먼저, 빨리 할 수 있는 걸 굳이 기다리게 된다.
    
3. 제품을 만드는 것 자체가 리소스고 리스크다. 왜냐면 대부분의 제품은 실패하니까.

물론 앞서 말했듯이 어떤 도메인의 서비스들은 제품의 형태로만 가설 검증이 가능한 것들도 있다. 그러나 IT 제품의 PM으로 우리가 검증하고 싶은 것 중 일부는 분명 제품을 개발하지 않고도 할 수 있다.

가령, 멤버십 서비스에서 고객의 재구매를 촉진하기 위해 멤버십 만료 예정자를 대상으로 안내 또는 할인권을 제공하는 아이디어/기획안을 내놓았다고 가정해보자. 그러면 이 경우 팀은 두 가지 방법을 택할 수 있다.

가설

월 단위 멤버십 서비스 이용자로서, 멤버십 만료 이전에 만료 사실에 대해 인지하고 할인권을 제공받을 수 있다면, 멤버십에 대한 가격 부담감이 줄어들어 연장 구매할 것이다.

실험 방안 A

만료 예정자를 대상으로 자동으로 안내 및 할인권을 제공하는 푸시와 로직을 기획, 디자인, 개발하여 배포한다.

실험 방안 B

안내 또는 할인권을 제공하면 정말로 재구매하는지 이메일이나 문자를 통해 실험해보고, 검증된 경우 그 결과를 제품으로 배포한다.

위의 가설을 검증하기 위한 방안 A와 B 중 어떤 방안이 더 효율적인가? 어떤 방안이 더 애자일하고, 더 리스크가 적은가? 적어도 이 경우라면, 제품을 거치지 않고도 간단한 이메일, 문자 솔루션만으로 PM 혼자 해볼 수 있는 실험 방안 B가 훨씬 효율적이고, 애자일하며, 리스크가 적지 않은가?

물론 "뭘 고민해요? 알람 제공 정도면 우리 팀은 반나절이면 되는데? 이미 있는데?" 싶은 팀도 있겠지만 어디까지나 위는 예시일 뿐이다.

또한 위 예시의 경우 최종 제품화를 결정, 기획하기에 아래의 내용들을 검증할 수도 있다.

1. Trigger: 무엇을 제공하면 재구매할까? 만료 안내만 해줘도 멤버십을 연장하진 않을까? 혹은 할인권을 제공해야 할까? 할인권을 제공한다면 얼마를 제공해줘야 할까? 조금 더 저렴하게 유도할 순 없을까?
2. Where: 어떤 경로가 가장 잘 노출 및 도달되는가?
3. When: (서비스 사용 주기, 이용 패턴을 고려하여) 며칠 전에 안내해야 가장 연장률이 높을까?
4. How: 어떤 톤 앤 매너, 텍스트로 안내하면 가장 효과적인가?

물론 이 역시도 팀의 리소스와 역량에 따라 제품 반영 후에 제품 내에서 수정할 수도 있다. 어디까지나 예시일 뿐이다. 다만 기획, 디자인, 개발에 더 큰 공수가 필요한 제품이었다면, 제품 개발 후 실험하기보다는, 위의 요소들을 실험해본 뒤 최종본을 제품에 반영하는 게 더 빠르고 안전한 방안이다.

제품은 생각하지 마!

자, 정말로 제품을 통해 검증해야 하는 게 아니라면, 으레 제품부터 생각하진 말자. 우리의 목적은 제품을 만드는 게 아니라, 고객에 대해 학습하고 가설을 검증하여 그 결과로써 좋은 제품을 만들어 제공하는 것이지, 제품 공장을 돌리는 게 아니다. 고객과 핵심 가치 VP에 대한 가설이 맞는지 확인하고, 그것이 검증되면 이를 더 빠르고 효율적으로 제공하기 위해 제품화를 고민하는 게 낫다.