1주 1개 실험하는 스쿼드 운영하기

6개월간 스쿼드를 운영하면서, PM으로서 가장 중요하게 생각한 것은 두 가지였습니다.

스쿼드가 (늘어지지 않고) 생동감 있게 운영될 수 있는가?

모든 구성원이 우리의 목표를 정확히 이해하고 몰입할 수 있는가?

이 두 가지를 효과적으로 달성하기 위해 저희가 택했던 방법은 '1주 1개 실험 운영'이었습니다.

실험을 꾸준히 돌린다는 것이 말처럼 쉬운 일은 아니에요. 팀원들이 실험 자체를 부담스럽게 느낄 수도 있고, 단기적으로 의미 있는 성과를 보여주지 않으면 실험이 우선순위에서 밀려날 위험도 큽니다. 그럼에도 불구하고 저희가 실험 중심의 운영을 선택했던 이유와, 이를 실제로 실행하면서 얻은 인사이트를 공유해보려고 합니다.

왜 굳이 '실험'을 선택했을까?

고객을 알아가는 방법 중 항상 실험이 정답은 아닐 수 있습니다. 유저 리서치, 인터뷰, 서베이 등 여러 방법이 많았지만 저희 스쿼드는 '실험'이라는 방법을 택했는데요.

첫 번째, 저희 스쿼드는 빠른 실행이 가능한 조직이었습니다.

저희 팀은 PM, 모바일 개발자, 서버 개발자, 디자이너, 웹개발자로 구성된 팀이었는데요. 모두가 겸직 없이 해당 스쿼드에 100% 몰입할 수 있었던 환경이었어요. 즉 실험을 위해 추가적인 의사결정 단계를 거칠 필요 없이 스쿼드 팀 내에서 바로 실행이 가능했다는 점이 강점이었습니다. 많은 실험과 빠른 반복(iteration)이 가능했고, 이를 통해 짧은 시간 내에 여러 가설을 검증할 수 있었습니다.

두 번째, 사용자도 자신의 문제를 명확하게 알지 못했습니다. 저희는 '용달 서비스'를 제공하는 앱을 운영하고 있었는데, 일반적인 B2C 사용자는 생애 주기에 1~2번 쓸까 말까한 서비스였습니다. 그렇기 때문에 사용자는자신이 어디서 어떻게 어려움을 겪는지조차 인지하지 못하는 경우가 많았습니다. 이러한 상황에서 설문조사나 인터뷰를 통해 정확한 문제를 도출하기는 쉽지 않았어요. 오히려 사용자에게 직접 정답을 물어보기 보단, 운영자의 VOC나 제품 데이터를 기반으로 가설을 설정하고 실험을 통해 데이터를 수집하는 것이 더 효과적이라 판단했습니다..

세 번째, 제품 역사상 처음 개선을 시도했던 OKR이었습니다. 저희 스쿼드의 주요 OKR은 "상담신청을 줄이고 바로결제 비율 늘리기" 였습니다. 하지만 이전에 개선 진행된 적이 없었던 OKR이었기 때문에 이 목표를 달성하기 위해 어떤 방식이 효과적일지 명확한 기준이나 과거 데이터가 부족한 상황이었어요.

따라서 한 번에 큰 개선을 시도하기보다는 작은 실험을 지속적으로 반복하며 빠르게 배워가는 방식을 선택했습니다. 즉, 작은 가설 단위로 빠르게 실험하는 방식을 채택했고, 이를 통해 점진적으로 인사이트를 쌓아가고자 했습니다.

따라서 저희 스쿼드 목표는 '1주 1개 실험하자. 그리고 레슨런을 빠르게 축적하자'가 되었답니다!

의미 있는 실험 찾기: '다음 실험'을 위한 실험

팀원분들과 논의를 하게 될 때면 여러가지 아이디어와 가설들이 쏟아져 나왔는데요. PM으로서 아이디어를 내는 것보다 더 중요한 건 당장 우리가 어떤 실험을 가장 먼저 하는 게 좋을지 뾰족하게 정의하는 것이에요. 처음에는 우선순위를 정하는 것이 어려웠지만 실험을 진행하면 할수록 당장 좋은 숫자를 만드는 것보단 우리가 앞으로 더 나은 결정을 내리도록 '정보'를 얻는 것 또한 중요하다는 것을 알 수 있었어요.

1. 이미 알고 있는 것은 실험하지 않는다.

실험을 설계하다 보면, 자연스럽게 이미 알고 있는 점에 대해서도 실험을 진행하려는 경우가 생깁니다.

예를 들어, "사용자 A 부분에서 어려움을 겪고 있다"는 사실을 이미 데이터를 통해 알고 있다면, 이를 굳이 다시 검증할 필요가 없겠죠.

이를 방지하기 위해 OKR 기준으로 우리가 알고 있는 점(축적된 레슨)과, 모르기 때문에 확인해야 할 점을 정리했습니다. 이미 정답을 알 것 같은 실험이면 과감히 우선순위를 뒤로 늦추고, 우리가 모르는 것을 알려줄 실험만 남겼어요.

2. '다음 실험'을 위한 실험을 하기

어느 정도 해야 할 실험들이 정리되면, 솔루션별로 디자이너 및 개발자와 협의하여 리소스 및 임팩트 단위로 분류했습니다. 즉, 리소스는 적지만 임팩트가 큰 솔루션을 찾기 위함이었어요.

하지만 여기서 중요한 점이 있습니다. 일반적인 제품 개발에서 '임팩트'는 보통 매출 상승, 전환율 개선 등을 의미하지만, 저희 실험에서의 임팩트는 '유용한 정보를 가장 많이 얻을 수 있는 것!' 입니다.

특히 우리 스쿼드의 OKR은 이전에 시도된 적이 없어 레슨런이 축적되지 않은 부분이었기 때문에, 당장의 제품 성과보다는 모르는 부분을 가장 많이 해소해줄 수 있는 방법을 찾으려고 했어요.

✨ "이 실험을 하면 다음 실험을 위한 레슨런이 될까?"라는 관점을 유지하는 것이 핵심이었습니다.

실험 후, 레슨런은 항상 축적하기

1주 1개 실험을 진행하면서 어떻게 많은 레슨런을 효율적으로 관리할 수 있을까 고민을 하다가, 스쿼드 방에 하나의 작은 실험 플랫폼을 운영했었는데요.

모든 실험 결과(성공, 실패 포함)를 문서화하고, 이를 다음 실험을 설계할 때 반드시 참고하도록 했습니다.

실패한 실험도 절대 그냥 넘어가지 않고, '왜 실패했는지'를 분석하여 레슨으로 남겼습니다.

우리한테 인사이트를 주어서 더 개선할 여지가 있는 실험은 '후속 실험 진행', 그렇지 않은 실험은 깔끔하게 '기각'하는 방식으로 빠른 의사결정을 내렸어요.

이러한 과정을 통해 저희 스쿼드는 모든 일을 할 때마다 실험에서 얻은 레슨을 바탕으로 다음 제품 방향성을 논의할 수 있었고 사용자에 대해서 더 심도 깊은 논의를 할 수 있었어요

마무리

스쿼드 PM으로 일하면서 실험의 중요성을 다시금 실감했습니다. 실험을 중심으로 운영하면 단기적인 성공뿐만 아니라, 팀 전체가 사용자 기반 사고를 자연스럽게 익히고, 실행력 있는 조직 문화가 형성되는 장점이 있었어요.

무엇보다, 실험을 통해 얻은 레슨런이 쌓일수록 우리 팀이 점점 더 근거 있는 선택을 하게 되고, 더 나은 사용자 경험을 설계할 수 있다는 점이 가장 큰 배움이었습니다.
(회의를 할 때 팀원들이 나서서 이전 레슨런을 공유하며 아이디어를 줄 땐 정말 성취감 있기도 했어요...!)

OKR 개선을 처음 시도하는 상황이라면, 실험을 적극적으로 활용하는 것도 방법이 될 수 있습니다! �