메이커 팀으로 빠르게 서비스 개발해보기

2/26 EO와 Disquiet에 기고했던 글입니다.

어쩌다 보니 PM 없이 메이커만으로 구성된 팀으로 신사업을 진행하게 되었습니다. 디자이너와 FE, BE 개발자 3명이 1달 반 동안 어디까지 갈 수 있었을까요? 지금부터 그 후기를 공유드리겠습니다.

새로운 시작

2024년 새해의 시작과 함께 새로운 팀과 새로운 프로젝트가 시작되었습니다. 역시 언제나 그렇듯이 예상대로 흘러가는 것은 아무것도 없습니다. 새로운 팀에 함께 하기로 했던 PM 분이 퇴사하게 되면서 저희는 PM 없이 신규사업을 진행할지 선택해야 하는 상황이 되었습니다.

과연 메이커만으로 구성된 팀의 장점과 단점은 무엇일까요?

• 장점: 빠르게 개발할 수 있다. 개발한 실제 결과물을 가지고 피드백을 수집해서 개선해 갈 수 있다. 모든 사람이 기획과 의사결정에 조금 더 깊이 참여하게 된다.

• 단점: 모두의 의견을 듣고 중심을 잡아줄 사람이 없다. 의사결정 과정에서 누군가가 명확하게 결론을 내기가 어렵다. 자신의 전문 영역 밖의 영역들도 같이 고민하고 시간을 투입해야 한다(비즈니스 모델, 마케팅 등).

이러한 장단점을 모두 고려한 결과 저희는 그래도 저희끼리 한 번 갈 수 있는 데까지 가보기로 하였습니다.

한계 파악하기

적은 시간(3개월)과 리소스를 이용해서 하나의 서비스를 만들기 위해 먼저 가능한 범위에 대해 파악해 보았습니다. 우선 아이템 선정과 관련된 제약사항을 먼저 파악해 보았습니다.

• 아이템: 적은 노력으로 큰 파급력을 얻을 수 있는 분야
  • 할 수 있는 아이템: 소셜, 커뮤니티, 유틸, 플랫폼, ...
  • 하기 어려운 아이템: 제조, 유통, 커머스, 협상이 필요한 B2B, ...

역시 원천기술이 필요하거나 물건을 직접 판매하는 등의 아이템은 저희에게 적합하지 않다고 판단하였고, 커뮤니티와 같이 많은 사람이 모이는 곳을 만들고 이 안에서 가설들을 테스트하기로 정하였습니다.

다음으로 구체적인 업무에서의 한계에 대해서 고민해 보았습니다.

• 기획 및 프로젝트 진행 방법: 구성원이 이해하기 어렵지 않으면서도 유연함과 일관성을 가질 수 있는 방법
  • 쉬운 방향: 피드백 루프, MVP, 애자일
  • 어려운 방향: 치밀한 비즈니스 모델 설계, 대규모 waterfall
• 기술: 기술적으로 개발 가능한 분야
  • 개발 가능한 분야: 간단한 웹, 간단한 앱, 커뮤니티, 사진 및 글 업로드
  • 개발이 부적합한 분야: 자체 데이터로 학습이 필요한 AI 관련 아이템, 기술적 난이도가 높은 기능
• 디자인: 적은 노력으로 큰 효과를 낼 수 있는 아이템
  • 효율적인 아이템: 재사용 가능한 디자인, 확장 가능한 디자인
  • 비효율적 아이템: 지속적으로 컨텐츠 추가가 필요한 아이템

이를 종합하여 다음의 목표를 도출하였습니다.

소셜 분야에서 간단한 웹 서비스를 피드백 루프와 MVP 방법론을 이용해서 빠르고 효율적으로 개발한다.

팀 전략 세우기

팀이 앞으로 나가기 위한 전략으로 가장 크게 참고했던 방법은 피드백 루프(Feedback Loop)와 MVP입니다.

피드백 루프

피드백 루프는 Build -> Measure -> Learn 과정을 반복하면서 초기 아이디어를 검증해가는 방법으로 저희가 지켜야 할 큰 틀이라고 생각했습니다. 먼저 최초 아이디어를 빠르게 웹으로 만들어서 출시하고(Build), 수집된 결과(Measure)를 통해 앞으로 만들 기능에 대한 힌트를 얻는(Learn) 방식으로 프로젝트를 진행하였습니다. 이러한 루프를 3개월 안에 최소 2회 완주할 수 있도록 목표를 설정하였습니다.

참고 - niceideas.ch: The Search for Product-Market Fit

MVP

다음으로 참고했던 방법론은 MVP(Minimum Viable Product)입니다. MVP란 용어는 이미 많은 곳에서 자주 사용되고 있지만 모호한 의미로 사용되는 경우가 많은 것 같습니다. 저희 팀은 이번 기회에 MVP의 M과 V가 무엇을 의미하는지 집중해 보기로 하였습니다.

• Minimum: 제품이 가져야 하는 최소한의 기능. 이를 지키지 못하면 사용할 수 없는 조악한 결과물이 됩니다.
• Viable: 제품의 생존 능력. 너무 약하면 생존하지 못하며 너무 과하면 규모만 크고 효율이 떨어지는 제품이 됩니다.

참고 - niceideas.ch: The Search for Product-Market Fit

결론적으로 저희는 MVP를 M과 V 사이의 외줄 타기로 정의했습니다. 또한 MVP는 아래 그림처럼 바퀴만 만들고 끝나거나 최종 결과물과 완전 다른 제품을 만드는 것이 아니라는 점도 팀 안에서 확실하게 인식을 맞추고 시작하였습니다.

Fred Voorhorst - Expressive Product Design

아이템 선정하기

사실 가장 고통스러운 과정은 바로 아이템을 선정 과정이었습니다. 만약 시장 분석 전문가가 팀에 함께했다면 현재 한국이나 미국에서 가장 유망한 아이템을 분석해서 빠르게 카피하는 방식으로 접근하는 것이 성공 확률을 가장 높일 방법일 것입니다. 그러나 저희는 그렇게 트렌드에 대한 레이더를 체계적으로 가동하기 어렵다고 판단했습니다. 따라서 저희 주변을 기준으로 필요할 만한 것들을 생각해 보았습니다.

• 실제 내 삶에 도움이 되면서 (Feasibility)
• 친구들과 같이 사용이 가능한 (Desirability)
• 오래 남을 아이템 (Viability)

About Product/Market Fit — what I’ve learned about the goal, the process and the nuance

먼저 며칠 동안 계속해서 브레인스토밍을 진행하였고,

위 과정을 통해 키워드 3개를 도출하게 되었습니다.

• 일정
• 그룹
• 사진

이를 조합하여 설정한 첫 번째 아이템은 다음과 같습니다.

• 아이템: 친구들과 함께 사용하는 카카오톡 그룹 채팅방을 하나의 서비스로 만들어서 일정과 사진을 공유하는 서비스를 만들어 보자
• 문제:
  • 카카오톡은 그룹만을 위해 만들어진 것은 아니므로 여러 가지 불편한 점들이 있다.
  • 시간이 지나면 단톡방의 사진이 사라진다.
  • 일정 투표 시에 응답 현황 등이 보여 눈치가 보인다.
  • 채팅 내역이 많아지거나 사진과 뒤섞이면 이전 내용을 찾기 어렵다.
• 해결방안:
  • 그룹 일정 관리와 사진 저장에 특화된 서비스를 만들자
  • 사진을 영원히 남길 수 있도록 한다.
  • 일정에 특화된 다양한 기능을 제공한다.
  • 기존 채팅 방식과 다른 캘린더 피드 등을 제공한다.
    그러나 처음부터 완전한 제품을 만들어 테스트하기는 어려울 것으로 보였습니다. 따라서 3개의 키워드 중에서 일정 부분만 웹을 통해 간단히 테스트해 보기로 합니다.

첫 번째 루프

서비스 만들기 (Build)

사실 메이커로 구성된 팀이 가장 신나는 시점이 바로 만드는(Build) 단계라고 생각합니다. 디자이너가 전체 서비스 구조를 설계하는 과정에서 API를 설계해야 하는 백엔드 개발자와 함께 논의하고, 최종 시안이 나오기 전에 프론트엔드 개발자는 먼저 스타일을 제외한 컴포넌트 개발을 진행해두는 식으로 빠르고 유연하게 작업하였습니다. 만약 PM이 있었다면 모든 과정을 조율해 주었겠지만, 저희는 그런 사치를 누릴 수 없었기에 앉은 자리에서 서로가 완벽하게 이해될 때까지 빠르게 의사소통하였습니다.

긴밀하게 서로 한자리에 모여 개발하면서 추가되면 좋을 것 같은 기능을 자유롭게 제안하였고 이를 통해 제품을 더욱 구체화할 수 있었습니다. 또한 서로 우려되는 부분을 미리 체크해 주기도 하면서 각 담당자가 체크하기 어려운 빈틈을 메꿔주기도 하였습니다.

이러한 과정을 거쳐 처음으로 만든 결과물은 바로 OURR(Our Record)입니다.

2주 동안의 작업 결과 일정을 만들고 초대장을 생성해서 친구들에게 참석 여부를 확인하는 서비스를 개발하였고 참여 인증샷도 남길 수 있도록 하였습니다. 마케팅 관련해선 먼저 사용자 인터뷰 대상자들을 모집하였고 서비스에 대해 알려드린 뒤 주변 사람들에게도 일정을 공유하도록 유도하였습니다.

그렇다면 결과는 어땠을까요?

1주일 데이터 종합 결과 (Measure)

• (SignUp) 총 207명이 서비스에 접속하였으며
  • 이 중에서 106명이 로그인 창을 열었고
    • 다시 이 중에서 60명이 가입에 성공하였습니다.
• (Activation) 가입한 사람의
  • 58.6%는 일정 참석 여부에 응답하였습니다.
  • 41.4%는 일정 캘린더 추가 버튼을 클릭하였습니다.
  • 34.5%는 초대장을 만들었고 같은 비율로 이를 공유하였습니다.
  • 8.62%만 인증샷을 실제로 업로드 하였습니다.
• (Event) 생성된 일정은 총 62개로 1명 당 약 1개 일정이 생성되었으며
  • 이에 대한 참석 여부 응답은 177건 발생하였습니다.
    • 참석 138건, 모름 23건, 거절 16건.
• (Retention) 가입 이후에 다시 돌아온 사람은
  • 다음날 4.35% 였습니다.
  • 그다음 날은 2.33% 였습니다.

첫 루프의 결과로 판단할 수 있는 것은 무엇이었을까요?

데이터를 통해 알 수 있었던 점 (Learn)

데이터를 통해 다음 인사이트를 얻을 수 있었습니다.

• 회원가입 방식에 따라 사용자가 이탈하는 비율이 엄청나게 달라질 수 있다는 것을 확인하였습니다.
  • 초반에 알림 문자 발송을 위해 전화번호 가입 방식만 지원하였으나 절반 이상이 이탈하였습니다.
  • 카카오 로그인을 추가한 이후 이탈 유저가 훨씬 감소하였습니다.
• 일정을 만들고 공유로 이어지는 부분에 대한 설계 및 측정이 부족하였습니다.
  • 일정을 만들고 공유를 통해 다시 다음 가입자를 모집해야 서비스가 자연스럽게 확장될 수 있었습니다.
  • 생각보다 일정 생성 이후 공유하기 버튼을 클릭하는 경우가 적어서 critical path에 대한 점검을 하게 되었습니다.
  • 정확한 데이터 측정을 위해 초대코드를 함께 보내도록 수정이 필요하다는 것을 알게 되었습니다.
• 생각보다 인증샷 올리기 기능을 잘 이해하지 못한 사용자들이 많았습니다.
  • 실제로 사진을 업로드 한 사용자는 10%도 되지 않았습니다.
  • 자연스러운 흐름에 따라 특정 행동이 발생하도록 기능을 설계해야 한다는 점을 확인하였습니다.

지금까지의 데이터 결과를 보면 생각보다 적극적인 행동이 발생하진 않은 것으로 보입니다. 이탈 비율도 높고 공유도 많이 발생하지 않았으며 서비스를 다음 날 다시 방문하지도 않았기 때문입니다. 그렇다면 이제 서비스를 버리고 처음부터 다시 시작해야 할까요? 아니면 여기서 다시 문제점을 찾고 보완하기 위한 가설을 세우고 앞으로 나아가야 할까요?

저희 팀은 일단 현재 상태에 대한 가설을 만들어 보기로 하였습니다.

1. 만약 일정 기능 자체는 사용자에게 중요하지 않다면?
   a. 이미 구글 캘린더나 카카오 일정 등을 편하게 잘 이용하고 있어서 별도의 서비스를 사용할 니즈가 없다.
   b. 그렇다면 일정 관련된 기능은 아무리 잘 만들어도 사용하지 않을 것이다. → 아이데이션으로 돌아가기
2. 만약 일정 관련해서 아직 발견하지 못한 다른 니즈가 있다면?
   a. 사실 일정을 고르고 초대하고 조율하는 부분을 더 편하게 하고 싶다.
   b. 그렇다면 기능을 보완해서 조금 더 필요한 기능을 찾는다면 많이 사용될 것이다. → 기능 개발로 돌아가기
3. 만약 현재 상태의 기능도 충분히 원하는 사용자들이 있지만 아직 그들에게 도달하지 못했다면?
   a. 만약 이런 서비스가 있다는 것을 알고 있다면 충분히 사용해 볼 만 하다.
   b. 그렇다면 서비스를 알리는 채널을 늘리고 더 멀리 퍼뜨리면 많이 사용할 것이다. → 현재 상태에서 마케팅 보완하기

위 가설 중에서 한 가지를 선택하기로 하였고 가설을 토대로 얼마나 다시 시작할지를 결정하기로 합니다. 이제 여기까지가 첫 루프의 Build-Measure-Learn의 결론입니다. 역시 한 번에 대박이 나는 경우는 없었습니다. 비록 좋은 결과가 나오지는 않았을지 몰라도 앞으로의 방향을 결정할 수 있는 단서는 찾았다고 생각합니다. 다음 루프에선 배운 내용을 반영해서 더 나은 제품이 만들어질 것입니다.

결론

지금까지 팀이 한 번의 루프를 완료하기까지 겪었던 일들을 적어보았습니다. 여기까지 오는 것도 힘들지만 이 과정을 무한 반복한다고 생각하면 막막하게 느껴질 수도 있을 것 같습니다. 그러나 이러한 경험을 통해 팀은 짧은 주기로 현재의 문제점을 계속 확인하고 학습하는 방법을 배울 수 있었습니다. 또한 이 모든 과정이 1달 반 안에 완료되었다고 생각하면 긍정적이라고 생각합니다. 주어진 3달을 모두 아이데이션(Build)만 하다가 끝날 수도 있었기 때문입니다.

만약 누군가가 기획 전문가 없이 새로운 서비스를 만들어야 한다면 일단 빨리 만들고 이를 통해 측정해 보시기를 추천해 드리고 싶습니다. 직접 측정한 데이터를 얻을 수 있다면 앞으로 나아갈 방향에 대한 확실한 단서를 얻을 수 있을 것입니다.

References

niceideas.ch: The Search for Product-Market Fit
About Product/Market Fit — what I’ve learned about the goal, the process and the nuance
알렉스 오스터왈더, 『밸류 프로포지션 디자인』, 아르고나인미디어그룹(2016)