경쟁사 분석은 힌트 이상이 될 수 없습니다.
처음엔 분명 경쟁사 분석과 비교가 도움이 됩니다.
사업적 결정에 보조수단이 되기도 하고,
유저가 어떤 기능에 열광하고 싫어하는지
직관적으로 알 수도 있죠.
하지만, 어느 순간부터는 비교는 목표가 됩니다.
'저 회사가 이 기능이 있으니 우리도 있어야 해'라는 말이 늡니다.
판단의 기준이 '나'가 아니라 '너'가 되는 순간이죠.
왜 필요한지 보단, 무엇이 없는지 '비교'만 남습니다.
전략이 비교로 대체되는 순간이죠.
하나만 기억 해주세요.
비교는 힌트 이상이 될 수 없습니다.
비교를 근거이자 답처럼, 전략처럼 사용한다면
그 의사결정을 보류해보시는건 어떨까요?
다들 MVP란 용어를 알아?
MVP는 ‘최소 기능의 프로덕트’로써 핵심 기능만 넣은 프로덕트를 말해.
근데 이제는 기술이 너무 발전해서,
MVP 대신 MVE란 용어가 유행중이야.
- MVE(Minimum Viable Experience)
최소 경험 제품으로, 기능뿐만 아니라 초기부터 유저 경험을 고려하는 접근법이야.
제품을 사용하는 동안 긍정적 감정을 느끼게 하는거지.
장점으론 높은 사용자 만족도가 있겠지만,
단점으론 초기 개발 비용이 더 많이들어.
실제로 스포티파이는 처음부터
개인화된 추천 알고리즘과 부드러운 사용자 경험을 제공했어.
이제는 IT 프로덕트가 유저 기대가 너무 높아지고 경쟁이 치열해서,
MVE가 더 나은 접근방식으로 평가되고도 있어.
출시하고 싶은 제품 있다면 MVP 같아 MVE 같아?
제가 PM으로 있을때,
지표가 많을수록 똑똑하게 성장할 것 이라는 맹신이 있었습니다.
(*거의 종교 수준으로요)
대시보드는 빽빽했고, 회의는 숫자로 가득했습니다.
근데 이상하게 결론은 문제를 명확히 해결하지 못했고
심지어 느렸습니다.
결국, 모두 지우고 다시 시작하기로 했습니다.
지표를 하나둘씩 줄이니 변화가 생기더라구요.
논쟁은 줄진 않았지만, 판단이 점점 빨라졌죠.
중요한 것은 정보의 양이 아니라 집중의 방향입니다.
(*물론 혹시 모르니, 로우 데이터는 많으면 좋습니다.)
지표를 트래킹 하기전에,
'이 지표가 지금 당장 필요한 것인지'를 꼭 살펴보세요.
쓸모없는 지표는 중립적이지 않습니다.
결정을 미루는 방해물입니다.
최근, 유튜브 알고리즘의 숏박스 채널의 MZ 스타트업 콘텐츠를 띄워주었습니다 :D
스타트업 붐이 일때의 특유의 조직문화를 재밌게 풀어낸 콘텐츠죠.
문득, 20년도 제가 입사했던 한 '스타트업'이 떠오르더라구요.
그 조직은 자율과 유연함을 강조했습니다.
마치 ‘구글’과 ‘스티브잡스’처럼 (심지어 애플 아님) 열린 회의를 지향했고, 누구나 의견을 낼 수 있었습니다.
토스의 혁신, 애플의 디자인… 뭔가를 덕지덕지 붙였던 기억이 납니다.
‘힙’하고 예뻐보였습니다.
조직 분위기는 좋아졌지만, 결정과 일의 진행은 더뎌지기 시작했습니다.
퇴사이후 동료 직원도 그냥 ‘스타트업놀이’하는
회사인것 같아서 뛰쳐나왔다’ 하더라구요
숏박스 콘텐츠를 보니, 그 조직의 문제가 여실히 보입니다.
의견은 많았지만, 누구 하나 결정을 내리려는 사람이 없었습니다.
유연함이 책임을 대체하려 했던 것이죠.
(심지어 기능개발 우선순위 투표하자 했던 모 리더의 말도 생각나네요..)
동료들끼리 ‘권한은 없고 책임만 있다’라 말하지만,
그 때에는 ‘권한만 있고 책임은 없어서’ 조직이 망한 케이스였습니다.
그 이후로 저는 ‘유연하거나 자유로운’ 조직보다
‘명확한 결정’을 먼저 다지는 조직을 선호하는 것 같습니다.
기획에서의 전문성은 무엇일까요?
최근 맡았던 프로젝트가 종료됐습니다.
유저와 소통하며 공감하는 인터렉션이 중요한 프로젝트 였는데요.
서비스 기획과 개발 직무를 함께 병행할수록, 빠르게 상황을 판단하는 힘이 성장했음을 느꼈습니다.
어떤 점이 문제인지도, 어떻게 해결해야 할 지도 그려졌습니다.
하지만 어느 순간부터는 이 익숙함이 판단을 둔하게 만들더라구요.
작업전 '이건 내가 겪었던 기획', '이건 내가 풀었던 문제'라고 생각하며 임했습니다.
그럴 때마다 예상치 못한 문제에 부딪혀 처음부터 다시 재정비하며 서비스를 엮어나가야 했죠.
환경은 비슷해 보여도 맥락과 제약은 다르고
경험은 네비게이션처럼 길을 알려주지 않고, '틀린 길을 줄여주는 오답지'라는걸
그래서 요즘은 이해가 빠를수록 구멍을 찾으려 애씁니다.
내 경험과 지금의 프로젝트가 다른건 무엇인지,
놓치고 있는건 무엇인지,
경험을 과신하고 있진 않은지
어쩌면 기획의 전문성은 속도가 아니라 의심의 깊이가 아닐까요?
주변 서비스 기획자, 개발자들과 이야기할 때
MVP의 대부분은 ‘무엇을 검증할 것인가, ‘어디까지 넣을 것인가’
‘이 다음엔 어떤 기능을 넣을 것인가’를 생각합니다.
반대로, 저의 MVP 스토리를 돌이켜보았을 때 가장 도움이 되었던 것은
‘이 버전이 실패한다면, 우리는 무엇을 알게되는가?’ 였습니다.
성공 시나리오만큼 실패의 시나리오도 세워두어야 한다는 의미이지요.
실패 시나리오가 빠진 MVP는 위험합니다.
최소기능처럼, 학습도 최소인 경우가 많죠.
출시는 했지만, 결과라 말할 수 있는 결과도 못보고 다음을 판단하고 결정해야하는 상태가 옵니다.
그래서 MVP는 기능 단위와 판단 단위를 함께 갖추어야 합니다.
실패 시나리오는 여기서 ‘이 낭떨어지에서 떨어지면 (MVP가 실패했을 때),
어떤 레슨런을 하겠구나’를 세워두고 낙하하자는것이죠.
운이 좋으면 낙하를 시작으로 비행을 하고,
운이 나빠도 큰 배움을 얻어 다음 비행을 준비할 수 있게 되는것입니다.
MVP를 구성하고 계시다면, 기능리스트만큼 실패 시나리오도 깊게 생각해보세요
이 MVP가 실패하면 우리는 무엇을 버리고 무엇을 가져가는가, 각 시나리오에 따라 무엇을 고쳐야 할까
이 질문에 답이 있어야, MVP가 갖춰진것이라고 볼 수 있습니다.