디스콰이엇 Pre A 회고: 프로덕트

• 본 기고문은 디스콰이엇 박현솔 리더님의 작성하신 회고 글로 디스콰이엇과 동시 게재됩니다.

• 디스콰이엇 Pre A 회고: 프로덕트 - 1에 이어지는 글입니다.

집중할 수 있는 업무 프로세스

​이전에 창업을 여러번 시도하기도 하고 초기 창업팀에서 일하면서 뼈저리게 깨달은 것이 몇개 있다. 그 중 하나가 팀이 결정을 빠르게 할 수 있는 상태를 만들어 놓는게 정말 중요하다는 점이다.​ 많은 창업팀이 초기에 제품 방향성에 관해서 논쟁하는데 에너지를 많이 소비한다. 보통 흐름이 이렇다.​

유저, 투자자, 업계 동료 등으로부터 우리의 프로덕트에 대해 다양한 채널로 여러 피드백이 들어온다. 무엇이 중요한지 논의해보자고 미팅을 잡고 하나하나 중요도를 따져본다. 이 과정에서 서로 타고난 성향 그리고 배경에 따라 공감하는 부분이 갈리면서 의견차가 생긴다. 의견차가 좁혀지지 않으면 데이터를 보자고 하거나 유저들과 이야기를 나눠보자고 한다. 어떤 데이터를 봐야 되는지 몰라 이것 저것 볼 수 있는건 다 보기 시작하고 유저들에게 무엇을 개발해야 되는지 물어보기 시작한다. 하지만 결국 우리 모두 편향을 갖고 있어 의견차가 쉽게 좁혀지지 않고 결국 이도저도 아닌 결정을 하게 된다. 성과 없이 이런 과정이 반복되면 점점 감정 소모가 심해지고 서로에 대한 신뢰도가 떨어진다.​

위와 같은 경험을 여러번 했다. 이에 대한 나의 해법을 한 문장으로 정리하면 무조건 결정의 속도를 높일 수 있는 방향으로 최적화시키는 것이다.​

초기 창업팀은 모두 PMF라는 목적지를 향해 나아가고 있다. 어떤 길이 최적의 길인지 가보지 않고 알 수는 없다. 이걸 알 수 있다고 착각하는 순간 팀의 속도는 급격히 느려지고 연비가 안좋아진다. 다만 이동 속도를 빠르게 할 수는 있다. 팀의 이동 속도는 결정의 속도이다.​

디스콰이엇 또한 결정의 속도를 빠르게 만들기 위해서 나는 통상 프로덕트 팀들이 하는 것들을 다 빼려 노력했다. 아이디어 회의, 기획, 과도한 유저 인터뷰, 과도한 가설 검증 및 데이터 수집, 실행하고자 하는 것에 대한 팀원의 동의를 얻어야 되는 요소 등을 다 제거했다.

​

제거한 요소들

​

1) 아이디어 회의​

디스콰이엇을 시작할때부터 지금까지 주 1회 스크럼을 하는 것 외에는 회의를 일체 하지 않는다. 스크럼을 할때도 지난주 실행한 것들과 결과, 그리고 이번주 실행할 것들을 공유하는데 시간의 70%를 사용한다.

​

2) 기획​

피그마를 사용해서 디자인 시안을 만들고 개발 팀에 넘기는 프로세스가 없다. 그냥 바로 VSCode를 열어 UI를 코딩하고 UI가 완성되면 프론트와 백을 연결한 후 배포한다.

​

3) 과도한 유저 인터뷰 [1.1]​

유저와 이야기를 나누는 것은 정말 중요하다. 다만 유저 인터뷰의 핵심은 전략에 대한 key insight를 얻기 위해서이지 유저에게 개발해야 될 기능, BM, 방향성 등에 대한 결정을 위임하기 위해서는 아니다. 이를 이해하면 유저 인터뷰를 효율적으로 할 수 있다.

​

4) 과도한 가설 검증 [1.2]​

고객 중심 개발, 린개발, 데이터 기반 의사 결정 등의 개념이 퍼지면서 개발 전에 될거라는 증거를 얻기 위해 MVP/프리토타입 검증과 데이터 수집을 하기 시작했다. 이 개념들 모두 정말 훌륭하고 나또한 많이 활용한다. 다만 이와 같은 프레임워크들의 본질적인 목표를 이해하고 수단이 아닌 목표 달성에 집중할 필요가 있다. 이들 모두 리스크 최소화에 관한 것이며 이또한 결국 속도에 관한 것이다. 가장 빠르게 가장 신뢰도 높은 데이터를 얻는 것이 목표이고 개발전 검증하는 행위는 단지 그 수단 중 하나이다. 개발을 통해 만든 결과물과 가까울수록 데이터의 신뢰도는 높아진다. (데이터 신뢰도 x 검증 수단 개발 속도)를 계산해서 높은 방향으로 해야 된다.

​

5) 과도한 데이터 수집 [1.3]​

데이터를 보는 것 또한 간단해야 된다. PMF를 찾아가는 단계에서 데이터는 현재 전략이 먹히는지를 보여주지 해결책이 무엇인지 알려주지는 않는다. 최적화가 중요한 성장 단계에서는 좀 더 체계적으로 다양한 데이터를 봐야하지만 PMF를 찾아가는 초기 단계에서는 다양한 데이터를 보는게 독이 된다. 다양한 데이터를 보다보면 다 중요해보이기 시작하고 노이즈가 생기면서 결정의 속도가 늦어진다. 디스콰이엇은 컨텐츠 생산수, MAU, 리텐션을 주로 보고 나머지 가입 전환율, 사이트 체류 시간, 유저 플로우별 churn rate등은 디스콰이엇이 현재 어떤 상태인지 감을 익힐 정도로만 본다.

​

6) 실행하고자 하는 것에 대한 팀원의 동의​

돌이킬 수 없는 결정과 돌이킬 수 있는 결정이 있다.[2] 예를 들면 핵심 인력 채용, 지분 배분, 투자 유치시 계약 조건, 회사의 브랜드 이미지나 재정 상태에 크게 영향을 미치는 결정 등은 돌이킬 수 없는 결정들이다. 그 외 대부분은 돌이킬 수 있는 결정들이다. 프로덕트 팀이 나아가고자 하는 큰 방향성과 현재 집중하고 있는 전략에 맞다면 실행하고자 하는 것에 대한 타당성을 서로에게 체크를 받고 진행하기 보다는 일단 진행한 후 에러가 있으면 개선해나가는 방식이 훨씬 효율적이다. 디스콰이엇 또한 많은 것을 테스트해보고 있다. 그 테스트가 적합한지 디테일하게 서로 체크를 해주지는 않는다. 어차피 해보지 않고는 모른다는 태도로 일을 한다. 그렇다고 아예 서로 방치하지는 않는다. 다만 디테일한 내용을 체크하기 보다는 좀 더 효과적으로 일을 하는 팁들을 교류한다.

​

회고

위와 같이 업무를 진행하면서 몇가지 느낀 점이 있다. 결정속도가 빠르다는 점외에 발견한 좋은 점은 팀이 모두 각자 하는 일을 재미있어하고 오너쉽이 생긴다는 점이다. 일이 재미있으니 보통 직장인들이 출근할때 갖는 스트레스가 없고 팀원들간의 결속력이 좋아진다.

또 다른 배운점은 팀의 목적지가 어디이고 이를 향해 현재 잘 나아가고 있는지 주기적으로 체크를 해주는 사람이 필요하다는 점이다. 일을 하다보면 목적지가 어디인지, 현재 우리의 우선순위가 무엇인지 흐려지는 순간이 온다. 이런 순간에 누군가가 다시 리마인드를 해주지 않으면 어느 순간 혼란이 오기시작하고 이렇게 팀의 엔트로피가 높아진 상태가 되면 외부로부터 얻는 피드백에 쉽게 휘둘리면서 임팩트 있는 일이 무엇인지 판단하는 것이 어렵게 된다.

현재 디스콰이엇에서는 내가 리마인드 해주는 역할을 하고 있지만 나 또한 제품 개발, 발표, 행정 업무, 외부 요청 응답 등에 휘둘리면서 이 역할을 잘 소화해내지 못했던 것 같다. 나 자신과 팀원들이 외부 자극에 수동적으로 반응하는 형태가 아닌 전략에 맞게 의식적으로 리소스를 집중하는 형태로 일할 수 있도록 잘 관리해야 되는 것 같다.

Foot notes

[1] 보통 스타트업의 생존 확률은 10%라고 한다. 프로덕트 개발이 어려운 이유는 PMF를 찾아가는 과정이 본질적으로 아트의 영역이기 때문이다. 명확한 답이 있지 않으며 핵심 결정들은 직관에 의존해야 된다. 다만 더 빠르게 정답을 찾게 도와줄 도구들이 있으며 이들을 적절히 활용해 직관을 기르고 궁극적으로 더 빠른 시간 안에 정답을 찾을 확률을 높일 수 있는 것 같다. 그러기 위해서는 유저 인터뷰, 데이터 수집, 가설 검증 등의 도구들의 본질적인 목표가 무엇인지 알아야 된다.

• 유저 인터뷰: 전략적 Key Insight를 얻기 위해서이다. 여기서 Key Insight란 보통 유저가 문제를 해결하기 위해 사용하고 있는 현재 해결책의 문제를 이야기한다.

• 데이터 수집: 내 전략이 잘 워킹하고 있는지 파악하기 위함이다. 혹은 성장 단계라면 프로덕트를 최적화를 위함이다.

• 가설 검증: 최소한의 리소스로 가장 신뢰도 높은 데이터를 얻기 위함이다. 데이터 신뢰도 x 검증 수단 개발 속도를 계산해서 검증 수단을 평가해야 된다.

  
  

[2] Jeff Bezos는 이를 one-way door과 two-way door에 비유하면서 이를 잘 구분하면 조직이 커짐에도 불구하고 빠른 속도를 유지할 수 있다고 이야기를 한다. https://shit.management/one-way-and-two-way-door-decisions/

• Written by 박현솔 (원문​)

• Edited by 레아

​