🎇 [초기 스타트업이 실험할 때 고려해야 할 5가지] 이 글, 어떤 사람들이 참고하면 좋을까요? - 경영진의 강력한 직관으로 series A단계까지 도달했으나, 이제는 데이터도 활용하면서 의사결

🎇 [초기 스타트업이 실험할 때 고려해야 할 5가지] 이 글, 어떤 사람들이 참고하면 좋을까요? - 경영진의 강력한 직관으로 series A단계까지 도달했으나, 이제는 데이터도 활용하면서 의사결정을 할 필요가 있다고 느낀 경영진, PM - 아직까진 확장보다는 ‘생존’이라는 키워드가 더 중요한 스타트업이지만, (요즘 핫하다는)실험을 통한 제품 개선을 시도해보고 싶은 경영진, PM 1. 우선순위를 정할 마땅한 프레임워크가 없을 때는 ICE 프레임워크를 쓰자. 2. 고객에 대한 배움을 얻을 수 있는 실험부터 하자. ICE 점수를 메긴 가설 목록이 만들어졌지만 상위 가설들의 점수가 비슷비슷해서 고민이신가요? 그렇다면 저는 그 중에서 ‘고객에 대한 배움을 얻을 수 있는 실험’을 가장 먼저 할 것을 추천드립니다. ‘고객에 대한 배움을 얻을 수 있는 실험과 거리가 먼 실험’은 다음과 같은 실험들입니다. - FOMO 적용 : 재고 얼마 안 남았다는 표시 노출, 곧 판매 마감된다는 표시 노출 등 - Social proof 적용 : 고객 후기를 상위에 노출, N명이 보고 있다는 표시 노출 등 - 버튼 색깔 바꾸기 등등 인간의 인지 편향을 활용한 실험들 이런 실험은 초기 스타트업이 하기에는 시간이 아깝습니다(어쩌면 실험을 안하고 그냥 적용하는게 나을지도 모릅니다). 통계적 유의성을 확보한 실험을 하려면 최소 2주는 필요할 텐데, 2주 후에 얻은 결론이 ‘우리 고객들은 재고가 얼마 안 남았다는 표시를 보면 더 많이 구매하더라’ 뿐이라면 얼마나 아쉽겠어요. 너무 일반적인 상식을 활용한 실험은 초반에는 지양하는 것이 좋습니다. 대신 고객 퍼소나에 기반하여 우리 고객만의 특유의 상황, 특유의 심리를 근거로 한 실험을 해보시길 권장드립니다. 실험 결과에 따라 설정한 퍼소나에 대한 확신이 생기거나, 지금 설정된 퍼소나가 어쩌면 잘못 설정되어 있을 수 있다는 배움을 얻을 수 있으실 겁니다. 3. '뭘 더 줄일 수 있을까' 를 3번 되묻자. 처음 실험을 세팅할 때 가장 많이 하는 실수 중 하나가 오버 스펙의 실험을 준비하는 것입니다. 실험은 기능 배포가 아닙니다. 실험은 기능 배포의 근거를 쌓기 위해 하는 것입니다. 따라서 근거를 많이 쌓고 싶으시다면 실험은 최대한 ‘싸게, 자주, 많이, 일찍’ 하는 것이 좋습니다. 4. '가설의 근거'를 위한 UT와 인터뷰 사용자 경험 컨설팅, 연구 집단인 닐슨 노먼 그룹에 따르면, 약 5명의 사용자를 가지고 사용성 테스트(UT)를 했을 때 대략 85% 수준의 사용성 문제를 발견할 수 있다고 합니다. (참고 - Why you only need to test with 5 users) 그런데 저는 닐슨 노먼 그룹의 UX전문가들처럼 정교하게 UT를 설계하고 진행할 자신이 없습니다. 그러다보니, 제가 진행한 UT에서 발견한 개선 인사이트를 곧바로 제품 개선의 근거로 활용하는 것을 경계하는 편입니다. 하지만 ‘가설의 근거’로 활용하는 것은 전혀 경계할 필요가 없죠. 전통적인 사용성 테스트는, 그 결과로 나온 개선안을 제품에 바로 반영하는 것을 목적으로 하기 때문에 테스트 설계가 정교하고 철저해야 하고, 그만큼 시간과 비용이 많이 들여야 합니다. 하지만 UT에서 얻은 근거를 ‘가설의 근거’로만 활용한다면, 더 이상 UT에 과하게 시간과 비용을 쓸 필요가 없습니다. 즉, 실험을 통해서 가설을 검증하고, 그 검증한 결과를 제품 개선의 근거로 쓰는 사이클을 구축할 수만 있다면, 이제부터 중요한 일을 가설을 빠르게, 싸게, 많이 수집하는 것입니다. 보통 크리티컬한 문제는 지인 몇 명한테만 UT를 해봐도 금방 드러납니다. 고객 인터뷰도 가설의 근거를 수집하는 용도라면 괜히 철저히 리쿠르팅하지 말고 지인 중에 잠재 고객과 가까운 사람이 있으면 그 사람을 빨리 인터뷰해보는게 낫습니다. 그리고 그렇게 얻은 인사이트를 가설의 근거로 활용해서 최대한 빠르게 실험해보세요. 5. 실패해도 좋다. 하지만 배움은 꼭 얻어야 한다. 실험은 win or lose가 아니라 win or learn 이어야 합니다. 조직에 실험 결과를 공유할 때는 꼭 성과와 배움을 함께 공유합시다.