brunch

You can make anything
by writing

C.S.Lewis

by 파담파담 Jun 10. 2023

성공하는 프로덕트를 만들고 싶다면

주니어 PM 성장기 #12

"여러 결과 중에서 확률이 가장 높은 것은 '실패'다."

최근 읽은 '아이디어 불패의 법칙'의 초반에 나오는 문구다.


아마 모든 프로덕트 매니저들은 본인이 만들어 낸 프로덕트가 성공하길 바랄 것이다.

프로덕트를 만들면서도 '이건 성공할 수밖에 없는 아이디어야!'는 생각으로 임하고 있을지 모른다.


나도 약 2달 전 오랜 기간 준비한 프로덕트를 출시하기까지 실패보다는 성공할 가능성이 높다고 생각했다.

시장 가치, VOC 분석만으로 성공 가능성이 높은 프로덕트를 만들기 시작했다고 착각했기 때문이다.


그러나 유저들은 냉정하다.

본인이 사용할만한 가치를 느끼지 못한다면 절대 사용하지 않는다.

프로덕트는 유저들에게 동정의 대상이 아니기 때문이다.


따라서, 내가 부족했던 부분과 그것을 채우기 위해 내가 생각한 방법을 공유하고자 한다.


프로덕트가 성공하기 위해서는 세 가지 질문을 모두 만족해야 한다.

해결해주고자 하는 유저들의 문제가 정말로 문제인가?

유저들이 프로덕트를 사용하면서까지 그 문제를 해결하고 싶어 하는가?

프로덕트가 문제를 해결하기 위해 정말 효율적인가?


내 프로덕트가 위 질문에 어떤 답변을 할 수 있는지 가장 확실하게 아는 방법은 완성된 프로덕트를 실제 유저들에게 공개하는 것이다.

하지만 이 방법은 기회비용이 너무나도 크다.

앞서 말했듯이 프로덕트는 실패할 확률이 가장 높기 때문이다.

따라서, 프로덕트가 출시되기 전에 위 질문에 답변하기 위해서는 질문의 목적에 맞는 사전 검증 방법이 필요하다.


해결해주고자 하는 유저들의 문제가 정말로 문제인가?


위 질문의 목적은 '유저들의 Painpoint를 정확히 파악했는가?'이다.

PM은 유저들이 불편해할 것이라고 예상했는데 실제 유저들은 별로 불편해하지 않을 수 있다.


이 때는 유저들에게 설문조사를 진행하는 것이 가장 효율적이라고 생각한다.

내가 어떤 유저들의 어떤 문제를 해결해주고 싶은지, 그리고 그것이 정말 문제인지 빠르게 파악할 수 있기 때문이다.


설문조사도 아래 질문에 답변하기 위해 목적을 잊지 말아야 한다.

따라서, 설문조사 구성은 아래 내용을 염두에 두고 진행하는 것이 좋다.

고객의 Painpoint와 JTBD를 찾아내고 문제가 정말로 문제인지 설문조사를 통해 파악할 수 있어야 한다.


우리의 핵심 고객은 누구인가? (Who are our core customers?)

그분들의 JTBD은 무엇인가? (What's their JTBD?)

기존에는 어떻게 해결하고 있나? (How do they get the job done?)

고객이 겪는 문제나 페인 포인트는 무엇인가? (What's thier pain point or problem?)


유저들이 프로덕트를 사용하면서까지 그 문제를 해결하고 싶어 하는가?


위 질문의 목적은 '유저들이 겪는 불편함이 해결이 필요한 불편함인가?'이다.

이 때는 유저들에게 '프리토타이핑(Pretotyping)'을 하는 것이 좋다고 생각한다.


프리토타이핑이란 Pretend와 Prototype을 합친 단어로

어느 아이디어가 추구하고 만들 가치가 있는지를 값싸고 빠르게 검증하기 위해 설계하는 것을 말한다. 


프리토타이핑에 대해서는 '아이디어 불패의 법칙'에 잘 설명되어 있으니 궁금하면 읽어보는 것을 추천한다.


책에 나온 예시를 보면 프리토타이핑이 왜 필요한지 알 수 있다.


코인빨래방을 방문하는 사람들은 세탁부터 건조까지 한 번에 진행할 수 있지만 빨래는 여전히 스스로 개어야 한다는 점에 불편함을 느끼고 있다.

실제 고객 인터뷰 등 조사를 해본 결과 과반수 이상의 사람들이 빨래를 개는 것에 귀찮음을 느꼈다.

이 부분에 주목한 발명가는 빨래를 개주는 로봇을 발명하기로 했다.

하지만, 정말 사람들이 그 로봇을 쓸 지에 대해서는 의문이 들었다.

때문에 코인빨래방 한편에 자리를 잡고 본인이 직접 빨래를 개어주는 서비스를 시작했다.

놀랍게도 사람들은 빨래를 개주는 서비스에 관심은 있었지만 실제로 사용하지는 않았다.


즉, 문제가 있긴 하지만 프로덕트를 사용하면서까지 해결하고 싶은 문제는 아니었던 것이다.


프로덕트가 문제를 해결하기 위해 정말 효율적인가?


위 질문의 목적은 '해결책이 쓸만한가?'이다.

앞선 질문에서 모두 '예'라고 답했더라도 유저들이 그 프로덕트를 잘 쓰지 못한다면 성공 가능성은 낮아진다.


만약 토스에서 '간편 송금' 서비스를 시작했지만 '간편 송금'을 하기 위한 과정들, 즉 UX 품질이 낮았다면 성장하기에는 어려웠을 것이다.


이 때는 UT를 진행하는 것이 좋다고 생각한다.

UT란 User Test로 실제 유저들에게 프로덕트를 써보게 한 뒤 얻은 인사이트로 제품을 개선하는 것이다.


내가 만든 프로덕트를 실제로 사용할 타깃 유저들에게 거의 완성된 프로덕트나 프로토타입을 보여주면서 어떤 부분을 더 개선하면 좋을지 파악하는 단계라고 보면 된다.


내용 정리

해결해주고자 하는 유저들의 문제가 정말로 문제인가? -> 설문조사로 검증

유저들이 프로덕트를 사용하면서까지 그 문제를 해결하고 싶어 하는가? -> 프리토타이핑으로 검증

프로덕트가 문제를 해결하기 위해 정말 효율적인가? -> 유저 테스트로 검증

작가의 이전글 신기능은 '수단'일뿐이다.
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari