『인스파이어드』 라는 책에는 이런 문구가 나옵니다.
"우리는 아이디어 대부분이 소용없을 것이라는 마음가짐을 가지고 제품 발견에 접근해야 한다."
- 인스파이어드 p190
"당신이 위대한 제품을 발견하기 원한다면 실제 사용자와 고객을 대상으로 더 일찍 더 자주 당신의 아이디어를 보여주는 것이 중요하다."
- 인스파이어드 p186-187
뇌피셜을 멈추고 테스트로 검증한다
우리는 제품을 기획하고 만드는 동안 수 많은 의견과 아이디어를 제시합니다.
유저들이 겪는 문제점을 해결하기 위해
"이 제품이 필요할거야~ 저 기능이 효과가 좋을거야~" 라는 식의 가정을 세우기도 하죠.
하지만 제품/기능을 선보였을 때 실제 결과는 우리의 생각과는 전혀 다른 양상을 보일 때가 많습니다.
그러므로 우리는 서로의 의견이 맞네 틀리네 하는 '뇌피셜 전쟁' 을 길게 할 필요가 없습니다.
가설을 세우고 실제 테스트를 통해 결과를 검증 해보면 되는 것이죠.
가설은 틀릴 수 있다
가설은 말 그대로 가설입니다.
당연히도 우리의 기대 결과와 다른 결과가 나올 수 있습니다.
그렇기 때문에 하나의 가설에 기타 부가 기능들과 예외사항/우려사항에 대한 추가 기능들을 만드는 것은 리스크가 높습니다.
그 가설이 틀렸을 경우, 낭비하는 시간과 비용들을 점차 증가하기 때문이죠.
그러므로 아직 가설에 불과한 '뇌피셜'에 확신을 가지고 '완벽한' 제품을 만들려고 해서는 안됩니다.
-뇌피셜 파티의 예시-
...
내 생각에는 유저들은 A가 문제니까 A1 기능 만들고 A2, A3, A4 기능도 붙이면 더 좋아할 것 같아.
근데 A5, A6 도 우려되니까 이런 예외사항들도 만들어두자~
...
사용자들에게 이게 필요할테니까 여기서 다 해결할 수 있는 플랫폼을 만들자
가능한 한 최소한으로 검증하자
하나의 가설에 너무 많은 시간과 리소스를 투입하는 것을 피하기 위해
우리는 항상 최소한의 검증 방법을 고민해야 합니다.
심지어 기능과 제품의 구현 없이 검증하는 경우도 있습니다.
결국 최종 목적은 '우리가 의도한 방향이 유저에게 핵심가치 전달을(문제 해결을) 하는가' 라는 가설을 검증하는 것이니까요.
여기서 주의해야할 점은 '최소한의 검증' 이 반드시 '최소한의 기능' 을 뜻하는 것은 아니라는 것입니다.
단순히 기능 스펙을 줄이는 것이 '최소한의 검증' 이 아니라
그 가설을 확인할 수 있도록 유저에게 제공하는 '최소한의 경험' 이라는 표현이 더 적합하다고 보입니다.
혹시 지금 이런 가설과 검증 없이 그냥 괜찮다고 생각하는 기능들을 추가하고 있지는 않으신가요?
최소한의 검증으로 여러분들의 기획과 가설들을 테스트해보세요.
가설 > 검증 > 학습
이 반복을 통해 제품을 만들어간다면 생각하는 것 이상의 효과를 느낄 수 있습니다!
-210414 JWC
