제품개발 100% 실패하는 법 #1
타율 1할, 스타트업 실패 전문가의 이렇게 하면 무조건 실패한다.
PM(PO)로서 다양한 제품의 제품을 다양한 구성원들, 제품팀과 함께 개발하고 출시하면서 실패하거나 결과는 좋았지만 제품 팀이 힘들게 된 경험을 공유합니다. 현재 본인이 여기에 해당하거나 제품팀이 이런 상태에 있다고 관찰되신다면 개선을 위해 빠르게 행동을 취하실 것을 추천드립니다.
성장중독자와 함께 성장, 스타트업, 제품에 대해 이야기 하실분!
첫 번째,
PM(PO)가 제품전략을 소화(消化) 하지 못한 상태로 수동적으로 과제들을 처리한다.
공감하지 못하거나, 반대의 의견을 제시하였지만 반영되지 못하였든 실행의 오너십을 가져야 하는 PM(PO)가 상위 제품전략을 자신의 것으로 소화하지 못한다면 당연히 실행도 엉망이 될 수밖에 없습니다.
'이 제품(기능)을 왜 만들어야 되는지 아직도 모르겠는데? 나열된 근거 중에서 공감되는 게 없어..'
'지금 사용자와 제품 stage를 고려했을 때 양적 성장은 무리라고 데이터를 보여 주면서 설득을 했는데 이걸 추진하라니 절대 납득할 수 없어, 날 무시하는 건가?'
실패할 수밖에 없는 이유.
상위 제품전략을 달성하기 위한 구체적인 실행을 기획하는 PM(PO)는 수동적인 상태가 되지 않도록 경계해야 합니다.
: 위의 예시처럼 극단적인 상황이라면 스스로가 납득할 때까지 상위 제품전략을 의사결정한 주체와 토론, 필요하다면 논쟁을 해야 합니다. 그렇게 해서라도 의사결정을 하게 된 배경에 공감하거나, 그 전략의 불확실성을 인정하고 리턴을 극대화하면서 리스크를 최소화할 수 있는 실행 방안을 고민해야 합니다. 수동적인 상태로 실행에 들어가게 되면 제품팀, 협업부서와 킥오프 미팅부터 어려움을 겪게 될 수 있습니다. 스스로가 의심하고 있는 전략을 실행하게 되면 다른 구성원들도 PM(PO)의 말투, 분위기, 표정으로 그 의심을 느끼게 됩니다.
두 번째,
PM(PO)가 개발하고 있는 기능이 어떤 기대효과가 있는지, 왜 지금 개발해야 하는지 이해하기 쉽게 설명하지 못한다.
PM(PO)가 과제에 대해 명확하게 정리가 되지 않은 상태에 있다면 결과가 잘 나오기 어렵습니다. (결과가 잘 나오더라도 그것이 왜 잘 나온 것인지 학습하기 어렵습니다.)
(협업 부서 마케팅 담당 구성원의 질문) '이 기능을 출시하게 되면 현재 안정화되고 있는 회원가입전환율에 영향이 있는데요. 어떤 목적으로 개발을 결정하였나요?'
(PM(PO)) '음.. 가입 후 온보딩을 위한 실험을 하는 건데요. 단기 리텐션에 긍정적인 효과가 있는지 확인하기 위한 과제입니다. 그래서 7 day retention을 높여서 구매에 영향이 있다는 가설을 증명하려는 거죠'
실패할 수밖에 없는 이유.
과제(기능)를 시작하기 전 명확한 정의를 해야 합니다.
: '이 기능이 있으면 좋을 것 같은데', '000 전환율을 높이려면 이 기능이 필요한 것 같아, 다른 곳에도 있잖아' 이 정도의 가정과 직감으로 PM(PO)가 과제를 구체화해서 실행하게 될 경우 결과를 떠나 제품에 다양한 악영향을 끼치게 됩니다. 무엇을 왜 실행해야하는 지 결정하는 PM(PO)는 누구에게나 현재 실행되는 과제의 배경, 기대효과를 쉽게 설명 할 수 있을 만큼 스스로가 잘 정의하고 있어야 합니다.
세 번째,
PM(PO)가 핵심지표가 아닌 변두리지표를 상승시키는 과제에 많은 Cost를 지불한다.
PM(PO)가 정의한 성공의 정의(KPI)가 핵심 지표가 아닌 경우 기대효과가 떨어지는 실행을 하게 됩니다.
콘텐츠의 반응 개수를 늘리면, 신규 콘텐츠 작성 수가 많아질 것이다.
누적 판매 정보를 리스트, 상세 페이에 표시하면, CTA 클릭률이 높아질 것이다.
회원가입 Flow의 UX writing의 Tone을 정리하면, 가입전환율이 높아질 것이다.
실패할 수밖에 없는 이유.
PM(PO)는 지표 간의 관계를 잘 이해하고, KPI를 결정해야 합니다. 그리고 10% 상승이 아니라 200% 상승할 수 있는 가설을 찾기 위해 노력해야 합니다.
: PM(PO)는 과제를 구체화하고, 출시된 기능의 성과를 분석하고, 제품 주요 지표를 모니터링하기 위해 엄청나게 많은 숫자들, 지표들을 보게 됩니다. 숫자들을 많이 보게 되면 경계해야 할 부분은 지표들이 제품, 사용자에게 주는 영향을 간과하게 되는 점입니다. 신규 콘텐츠 작성 수를 높이는 게 목표라면 누가 신규 콘텐츠를 작성하고 있고 누가 작성하지 않는지를 확인하고 작성하지 않는 이유, 가설을 도출해야 문제가 해결이 되고 임팩트가 큰 기대효과를 가진 과제를 정의할 수 있게 됩니다.
네 번째,
PM(PO)가 과제에 대해 첫 설명을 하는 자리에서 개발자와 디자이너가 말이 없고, 멀뚱멀뚱 뻘쭘한 분위기로 미팅이 끝난다.
PM(PO)가 아주 완벽한 스피치를 한 것이라면 모르겠지만 분위기가 싸하게 흘러간다면 문제가 있습니다.
"이번 과제 설명은 여기까지입니다. 혹시 궁금하신 점이나 같이 이야기하고 싶은 점 있으신가요?"
(정적)
'PM(PO)가 시간을 두고 제품팀을 둘러본다.
(정적)
"그럼 여기서 마치겠습니다.'
실패할 수밖에 없는 이유.
PM(PO)와 제품팀은 일을 시키고 주어진 일을 하는 관계가 아닙니다.
: 물론 PM(PO)가 주요 의사결정을 하는데 많은 비중을 차지 하긴 하지만 BOSS처럼 군림하는 위치는 아니라고 저는 생각합니다. 함께 목표를 달성하고 성장하기 위해 노력하는 하나의 팀이자 공동체 구성원이라고 저는 생각합니다. 그렇기 때문에 PM(PO)는 항상 제품팀과 자신의 관계가 현재 어떤 상태에 있는지 인지하고 있을 필요가 있습니다. 제품의 상황과 제품팀의 상태(퍼포먼스, 사기, 팀워크, 신뢰 관계 등)를 염두에 두고 어떤 관계를 형성하고 발전시켜야 할지 고민하고 적극적으로 소통하는 자세가 필요합니다.
다섯 번째,
PM(PO)가 한가하고 자기 자리에 오래 앉아 업무를 하고 있다.
제 경험 상 휴일에 혼자 출근한 것이 아니라면 PM(PO)는 회사에서 한가할 수 없습니다.
(오후 2시부터 6시까지 PM(PO)가 자리에 앉아 아무도 찾아오는 사람 없이 혼자 업무를 진행하고 있다.)
실패할 수밖에 없는 이유.
PM(PO)는 먼저 찾아가서 상태를 확인하고 흐름 관리를 하는 역할입니다.
: 극단적인 예시라 공감이 덜 가실 수도 있지만 위의 주제로 글을 쓰기 위함입니다. PM(PO)는 문제가 있는 상태의 구성원이 찾아와 주길 기다리는 사람이 아니라, 항상 먼저 다가가서 진행 상황을 확인하고, 지금 흐름을 막고 있는 것을 해결하고, 목표달성을 위한 정확한 기능이 개발되고 있는지 점검하고, 제품팀 구성원의 성장을 관찰하는 역할이라고 저는 생각합니다. 이런 역할은 다른 구성원이 할 수도 있지만 제 개인적으로는 PM(PO)가 이 역할을 했을 때 얻는 이익이 더 크다고 생각합니다. 네 번째에 말씀드린 협업 관계와 소통이라는 측면에서도 먼저 찾아가서 소통하고 문제를 함께 해결하려는 자세는 매우 큰 효과가 있습니다. 그리고 제품 개발, 디자인에 대한 이해가 높아지게 되고, 제품팀 구성원들의 지속적인 관찰을 통해 회고, 피드백 시 유용한 내용을 전달할 수 있게 됩니다.
제가 경험했던 다양한 실패의 경험을 공유하는 것을 통해서 다른 분들의 학습 비용이 낮아지거나, 현재 어려운 상황에 처한 Product Manager, Product Owner, CEO 분들이 문제를 해결하는데 도움이 되길 바라며 작성합니다.
경험에 의존한 내용으로 검증된 방법론이나 이론이 아닙니다. 편향된 방향으로 기술된 내용이 일부 포함 될 수 있으며, 이로 인해 불편하시거나 이견이 있으신 분들은 편하게 알려 주시면 저의 성장의 기회로 생각하겠습니다.
