David.Cheon
UIpac
David.Cheon
전체 방문자
오늘
어제
  • UIpac (648)
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (65)
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (34)
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352)
      • Weekly Curation (251)
      • Performing Arts (17)
      • Collection (6)
      • Books (0)
      • Life (78)

블로그 메뉴

  • 홈
  • 방명록

공지사항

인기 글

Tags

  • Curation
  • 웨어러블
  • trend
  • UI
  • 사이트
  • UX
  • 분석
  • 인공지능
  • daumkakao
  • 애플리케이션
  • 사물인터넷
  • 모바일
  • 디자인참고
  • Gartner
  • 기획참고
  • 세계 게임시장 규모
  • 유니티
  • 벤치마킹
  • 기획
  • 큐레이션
  • 반응형웹
  • 2015
  • 트랜드
  • 동향
  • 디자인
  • 가트너
  • 2014
  • Mreport
  • 트렌드
  • 다음카카오

최근 댓글

최근 글

방명록

Uipac
David.Cheon

UIpac

Planning · PM/프로젝트 · PM

린스타트업 방법론 우리 팀에 적용해보기

2020. 8. 8. 00:17

에릭 리스의 [린 스타트업]을 처음 읽은 건 몇 년 전이었는데, 그때는 "그냥 스타트업 성공담 모음집이구나" 정도로 넘겼습니다.
그런데 올해 저희 팀이 신규 서비스 하나를 새로 기획하게 되면서, 이 책의 방법론을 실제로 적용해볼 기회가 생겼어요.
이론으로만 알던 것과 실제로 팀에 적용해보는 건 완전히 다른 경험이었습니다.

 

린스타트업의 핵심은 "만들기-측정-학습(Build-Measure-Learn)" 루프를 빠르게 돌리는 것입니다.
그런데 첫 단계인 MVP(최소기능제품)를 정의하는 것부터 팀 내에서 의견이 갈렸어요.
개발팀은 "핵심 기능 하나만 완벽하게 만들자"고 했고, 저는 "여러 기능을 다 얕게라도 넣어서 전체 흐름을 보여주자"는 입장이었습니다.
결국 저희가 검증하고 싶은 가설이 뭔지부터 다시 정리했어요.
"사용자가 이 서비스에 돈을 낼 것인가"를 검증하고 싶었던 거였는데, 그렇다면 굳이 여러 기능을 다 넣을 필요가 없었습니다.
결제 직전까지 가는 흐름 하나만 최소한으로 만들어서 테스트하는 걸로 방향을 좁혔습니다.

 

린스타트업을 팀에 적용하면서 제일 유용했던 실천은 "가설을 문장으로 명시해두는 것"이었습니다.
"우리는 [어떤 사용자]가 [어떤 문제] 때문에 불편함을 겪고 있고, [이 기능]이 있으면 [이런 행동]을 할 것이라고 믿는다"라는 형식으로 매 실험마다 문장을 써놨어요.
처음엔 이게 좀 형식적인 요식행위 같았습니다.
그런데 실제로 실험 결과가 애매하게 나왔을 때, 이 문장이 있으면 "그래서 가설이 맞았나 틀렸나"를 명확하게 판단할 수 있더라고요.
가설 문장 없이 실험했던 초기에는 결과가 나와도 "음, 그럭저럭 괜찮은 듯"이라는 애매한 결론으로 끝나는 경우가 많았습니다.

 

이 부분은 저희가 크게 실패했다가 배운 내용입니다.
초기 실험 하나에서 지표를 미리 정해두지 않고 실험을 진행했는데, 결과가 나오고 나서 "이 숫자면 성공이라고 볼 수 있지 않을까요"라는 식으로 사후에 기준을 맞춰버린 적이 있었어요.
객관적으로 보면 명백한 실패였는데, 팀 내에서 이미 투자한 시간과 노력이 아까워서 억지로 긍정적인 해석을 만들어낸 거였습니다.
이 일을 겪은 뒤로는 실험을 시작하기 전에 "성공 기준 숫자"를 반드시 문서에 박아두고, 실험이 끝난 뒤에는 그 숫자를 절대 수정하지 않는다는 규칙을 세웠습니다.

 

MVP 테스트 결과, 저희가 처음 생각했던 방향은 결국 피벗하게 됐습니다.
원래는 개인 사용자를 대상으로 구독형 서비스를 생각했는데, 실험 데이터를 보니 오히려 소규모 팀 단위 사용자들의 반응이 훨씬 좋았어요.
개인 사용자 전환율은 2% 남짓이었는데, 팀 단위로 초대해서 쓰는 흐름을 넣었더니 팀 하나가 들어오면 평균 4~5명이 같이 가입하는 패턴이 보였습니다.
이 데이터를 보고 나서 팀 전체가 크게 흔들렸어요.
반년 가까이 준비했던 개인용 구독 모델을 접어야 하는 상황이었으니까요.
그런데 데이터가 이렇게 명확하게 다른 방향을 가리키는데 원래 계획을 고집하는 게 더 위험하다고 판단했고, 팀 단위 온보딩 흐름으로 방향을 틀었습니다.

 

린스타트업을 실제로 돌리면서 가장 크게 바뀐 건 팀의 분위기였습니다.
예전엔 "이번 프로젝트는 반드시 성공해야 한다"는 압박이 컸는데, 지금은 "이번 실험에서 뭘 배웠는가"를 더 중요하게 보는 분위기가 자리 잡았어요.
물론 이게 하루아침에 된 건 아닙니다.
초반에는 실험이 실패로 나오면 팀원들이 위축되는 게 눈에 보였고, 저도 "이번에도 실패면 어쩌지"라는 걱정을 안고 회의에 들어간 적이 많았습니다.
그런데 매 실험 결과를 "실패"가 아니라 "가설 검증 결과"라는 언어로 바꿔서 공유하기 시작하면서, 팀 분위기가 조금씩 달라지더라고요.

 

린스타트업 방법론을 책으로 읽을 때는 "당연한 이야기 아닌가"라고 생각했는데, 실제로 팀에 적용해보니 그 당연한 걸 지키는 게 훨씬 어렵다는 걸 알게 됐습니다.
특히 사후에 기준을 끼워맞추고 싶은 유혹을 참는 게 생각보다 힘들었어요.


이번 신규 서비스는 아직 완성 단계는 아니지만, 최소한 방향이 틀렸을 때 빨리 알아차릴 수 있는 팀이 됐다는 것만으로도 이 방법론을 도입한 값어치는 충분했다고 생각합니다.

저작자표시 비영리 변경금지 (새창열림)

'Planning · PM > 프로젝트 · PM' 카테고리의 다른 글

MVP를 정의하는 기준, 실패에서 배운 것  (0) 2020.09.13
서비스 개선 프로세스, 진단-가설-검증  (0) 2020.08.12
요구사항 우선순위 정하는 법 (RICE, MoSCoW)  (0) 2020.08.04
서비스 정책 문서, 왜 자꾸 누락되나  (0) 2020.07.26
디자이너·개발자와 협업할 때 기획자의 역할  (0) 2020.07.19

    티스토리툴바