[서비스 기획] 프로젝트를 통해 무엇을 얻을 것인가?
대부분의 아이디어는 유효하지 않을 것이라는 진실
PM, PO의 세계에서 바이블로 불린다는 책. 인스파이어드.
기획과 관련된 베스트셀러로 존재하는 여러 책들을 읽었지만 이 책은 더 특별하다.
런칭 후 '사실은 이 기획은 안될 걸 알았다.'며 자조적으로 말하는 동료와 함께 술잔을 기울이며 이유를 고민해봤다면 한 문장, 한 문장 고개를 끄덕이게 하는 책.
인스파이어드의 가슴을 후벼파는 문장들과 사실은 안될 걸 알고도 핸들을 꺾지 못했던 과거 자조적 경험을 바탕으로 더 나은 프로덕트 기획을 위해 리뷰를 남긴다. 나와 같은 경험이 있다면 기회가 될 때 꼭 한 번 읽어보길 바란다.
폭포수(waterfall) 프로세스의 함정
워터폴 프로세스는 '폭포수'처럼 작업이 '위에서 아래로' 떨어져 각 단계에 따라 진행되는 프로세스를 말한다. 그래서 한 단계를 넘어가면 이전 단계로 돌이키기 어렵다.
좋은 조직에서는 워터폴 프로세스도 관리가 용이하다는 장점이 있지만, 아래에서 이야기하는 워터폴 프로세스는 수직적으로 내려오는 의사결정과 컨베이어벨트 같은 프로덕트 생산으로 벌어지는 실패에 관한 것이다.
인스파이어드에서는 폭포수 모델을 사용하면 오로지 매출을 위한 기능이나 이해 관계자들 위주로 제품이 끌려가서 프로덕트팀은 마치 외부 용병처럼 그저 열심히 실행할 뿐이라고 우려한다.
실제로 조직에 속해 일하는 기획자들은 아래의 프로세스를 경험해봤을 것이다.
'이 서비스 만들 사람 구함! 오케이! 너 당첨!'
물론 이 과정에서 '당첨'은 팀원이 가진 능력과 언제나 상관관계가 있지는 않다.
담당자가 가진 능력보다 목표 일정이 더 중요한 경우가 많으니까.
담당자가 "아이디어 출처"가 어디인지 어리둥절한 사이에도 시간은 흘러간다. 틱톡. 틱톡.
디자이너와 개발자를 배정받고 리뷰가 진행되면 '이 기능이 꼭 필요한가요?'라는 질문을 듣게 될테니, 미리 그럴듯한 사유까지 만들기 시작한다.
하지만 이 과정에서 이미 예상될 때가 있다.
'흠... 이대로는 잘 안 될 것 같은데?'
데이터들을 분석하고 시뮬레이션도 해보면서 이 컨셉으로는 목표하는 바를 이룰 수 없다는 판단이 들었을 때 리더를 찾아가 파이팅넘치게 의논하기도 한다.
'팀장님, 일정을 조금 미루더라도 이 기능은 꼭 필요합니다.'
'안돼. 빨리 런칭하고 테스트해야지.'
'이게 핵심기능이라, 이 기능이 없으면 사용성이 너무 떨어져서요.'
'일단, 다음 달에 런칭하고 얘기하자.'
그렇게 일정에 맞춰 MVP 기능을 탑재하지 못한 서비스가 예상한대로 성과가 나오지 않으면 그 기능은 날개를 펴보지 못한 채 서비스에 잔류하기도 한다.
인스파이어드에서는 이러한 프로세스를 통해 지시된 업무의 문제로 2가지를 지적한다.
고객의 문제 해결을 위한 아이디어가 아닌 이해관계자 중심의 아이디어
실무자는 시키는 일만 하는 용병
용병팀 VS 미션팀
업무를 하다 보면 '동기부여'가 상당히 중요하다.
지시된 업무에 대해 구색만 갖춰 일을 한다면 그건 시키는 일만 하는 용병일 뿐.
진짜 문제를 해결하기 위해서는 미션이 무엇인지 정확하게 알고 문제 해결을 위해 담당자들이 진심을 다해 고민하는 미션팀이 되어야 한다.
이를 위해 PO는 함께 협업하는 담당자들이 기획의 비전을 믿고 문제 해결을 위해 최선을 다할 수 있도록 동기부여를 제공할 수 있어야 한다. 용병이 아닌 미션팀의 구성원이라고 느끼게 만드는 것은 PO의 역할이다.
아이디어가 '유효하지 않을 것'이라는 진실
슬프지만 고객들은 서비스의 사소한 개편에는 큰 관심을 보이지 않는다. 기능이 조금 개선됐다고 해서 서비스에 더 많은 돈을 지불하려고 하지 않는다. 새로운 기능이 출시됐다고 해서 즉각적으로 사용해보려고 하지 않는다.
그러나 우린 한 달을 채 기다리지 못하고 작은 기능 개선에도 결과 보고서를 준비하여 성과를 평가받는다. 이미 대부분의 아이디어가 '유효하지 않을 것'이라는 진실을 알고 있음에도.
인스파이어드에서는 제품 로드맵에 있는 최소 절반 이상의 아이디어는 기대했던 효과를 만들어 내지 못한다고 장담했다.
그렇다면 어떻게 유효한 아이디어로 만들 수 있을까?
'돈을 얼마나 벌 수 있을까'에 대한 예측은 금물!
최소 스펙으로 런칭해서 테스트를 해보는 건 좋은 생각이다. 하지만 그 테스트가 '얼마나 매출에 기여할 수 있는 서비스냐'를 판단하기 위함이라면 그건 좋은 생각이 아니다. 현실적으로 매출 극대화에 즉각적 영향을 줄 수 있는 서비스를 매번 배포하는 것은 어렵기 때문이다.
그래서 인스파이어드에서는 ’얼마만큼의 돈을 벌 수 있는가'와 '얼마만큼의 비용이 드는가'에 대해 솔직히 알 수 있는 근거가 없으며 어떤 경우에도 제품 개발의 가장 중요한 교훈 중 하나는 우리가 모르는 것을 알아가는 것이어야 한다고 조언한다.
그러나 새로운 서비스를 통해 테스트하고자 하는 것이 '고객에 대한 이해'를 높이는 것이라면 테스트를 통해 훨씬 더 현실적으로 이득이 되는 데이터와 성과를 얻을 수 있다.
앞서 언급한 것처럼 조직에서 근무하며 지시되지 않은 기획을 시도하기는 쉽지 않다.
지시된 업무를 하는 프로세스 보다 더 중요한 건, 주어진 프로젝트에 대해 PM, PO 스스로 "프로젝트를 통해 얻을 수 있는 것은 무엇인가"에 대해 더 많은 고민을 해보는 것이다.
대부분의 아이디어는 유효하지 않을 것이라는 진실을 받아들이고, 더 이상은 요구한 성과를 내지 못했다고 해서 "이 기획은 안 될 걸 알았다."며 자조하지 말자.
성과를 내지 못할 것이라고 예상했던 이유와 가설, 그리고 그 가설이 증명됨으로써 서비스가 얻을 수 있는 교훈이 무엇일지에 대해 충분히 고민해보고 그 결과를 다음 프로젝트를 위한 자산으로 만들자.
