제품개발 100% 실패하는 법 #2
타율 1할, 스타트업 실패 전문가의 이렇게 하면 무조건 실패한다.
이전 글에 이어서 제품개발을 실패하기 위한 너무나 쉬운(?) 방법을 알려드립니다!
성장중독자와 함께 성장, 스타트업, 제품에 대해 이야기하실 분!
여섯 번째,
제품팀의 의사결정 할 수 있는 범위가 지나치게 한정적이어서 컨펌이 필요한 상황이 자주 발생한다.
실행의 주체가 되는 제품팀과 PM(PO)가 의사결정 할 수 있는 범위가 한정적이라면 실행에 병목(bottleneck)이 생기게 되고 주도적인 실행이 아니라 수동적인 실행이 되게 됩니다.
'이번 실험 계획은 000 부서 000님과 논의해서 A/B 테스트 비율을 결정할게요.'
'C00 님이랑 싱크를 맞추고 실험 예산이랑 기획 방향을 확정할 수 있어요.'
'이번 기능 디자인에 대해 000님이 이견이 있으신 것 같아요. 일단 어떤 생각이 있는지 제가 확인해 보고 올게요. 그때까지 클라이언트 개발은 홀드 하시죠.'
실패할 수밖에 없는 이유.
제품전략의 목표 달성을 위한 실행을 위한 제품팀이 주체적으로 실행하고 책임질수록 성장하는 조직, 회사가 될 가능성이 높아집니다.
: 보고를 통해 승인을 받는 절차까지는 아니지만 그렇다고 100% 자율적으로 진행하기 어려운 의사결정 범위를 가진 제품팀이 있습니다. 당연히 제품이 규모가 커지면 다양한 조직이 함께 목표를 위해 노력하기 때문에 '독단적'으로 기능을 개발하거나 제품을 변경할 수는 없습니다. 그렇기 때문에 상위제품전략 - 제품전략을 달성하기 위한 주요 과제들과 목표에 대해 다른 조직과 이해를 같이 할 필요가 있습니다. 그리고 사전에 예측 가능한 영향에 대해 검토가 끝난 이후에는 제품팀의 실행은 집중력과 실행력을 잃지 않도록 최대한의 의사결정 범위와 권한을 보장해 주는 것이 좋다고 저는 생각합니다. (회사의 일하는 문화, 조직의 규모, 구성에 따라 차이가 클 수 있다는 점에 대해서 글을 읽으시는 분도 이해하실 거라 생각하면서 제 생각을 말씀드립니다.)
일곱 번째,
사용자 경험, 가치 전달보다는 개발 품질이나 실행 속도를 위주로 개발의 주요 의사결정이 이루어진다.
제품팀이 담당하고 있는 제품이 PMF를 검증하는 단계가 아니라 그 이후 Growth, Scale Up stage인데 개발 품질이나 빠른 실행 속도를 중시하는 의사결정을 자주 한다면 당장은 아니더라도 서서히 빛을 잃어가는 제품이 될 가능성이 높습니다.
'이번 스프린트 내에 구현하기에 마이크로 인터렉션이 많은데 좀 덜어 낼 수 있을까요?'
'지금 개발되어 있는 구조를 많이 변경해야 하는데요... 꼭 필요한 건가요?'
'메인 시나리오 위주로 일단 출시하고 다음 업데이트를 빨리 나가는 방향으로..'
(목표, 사용자에 대한 이야기 보다 각자의 입장에서 시간 내 일을 마치기 위한 이슈 레이징이 많은 경우)
실패할 수밖에 없는 이유.
모든 제품은 사용자(고객)가 잘 사용하는데 그 목적이 있습니다.
: 기본적으로 제품팀이 제품을 개발하는 목적은 사용자에게 가치를 제공하기 위함이라고 생각합니다. (그것이 눈에 보이지 않는 개발 작업이라도) 만들어 내는 사람인 제품팀이 '만들기' 자체에 매몰(埋沒)되거나 회사나 상위 리더가 더 빨리 만들어 내는 것에만 너무 포커스 할 경우에 제품을 사용하는 '사용자'는 없고 허공에 돌을 던지는 것처럼 공허한 기능만 제품에 덕지덕지 쌓이게 됩니다. 사용자가 그 제품을 삭제하지 않고 계속 사용할 이유를 제품팀은 업데이트를 통해 증명해야 한다고 생각합니다.
여덟 번째,
구린 제품, 기능을 출시한다. (속으로 구리다는 걸 알면서도)
스스로 만들고 있는 기능의 아이디어나 품질이 별로라는 것을 알고 있지만 '관성'에 따라 제품을 개발하고 출시하는 일이 반복된다면 제품의 품질은 점점 떨어지게 됩니다.
'디자인이 좀 별로인 것 같은데.. 디자이너한테 이야기해야 되나'
'이 기능은 나 같으면 안쓸 것 같은데.. 왜 만드는 거지?'
'좀 깔끔하게 동작하게 못하는 건가.. 화면에 들어올 때마다 이미지를 로딩하고 턱턱 끊어지는데'
(개발한 제품을 일할 때 외에는 사용하지 않음)
실패할 수밖에 없는 이유.
이유, 설명이 필요하겠습니까? 솔직하게 이런 경험이 최근에 있나요?
: 일정에 쫓기거나 제품팀의 역량이 부족해서 완성도가 떨어지는 기능이나 제품을 출시할 수 있습니다. 하지만 시간도 있고 역량도 있는데 스스로 생각해도 별로인 기능을 만들어 출시한다면 그 기능을 사용자가 사용하길 기대하는 건.. 부끄러운 일이 아니겠습니까? 자신이 사용하는 제품, 잘 나가는 제품, 유행하는 제품들의 기능이나 품질에 대해서는 기준이 높으면서 스스로가 만드는 제품은 품질의 기준을 낮게 두고 있는 것이 아닌지 냉정하게 돌아볼 필요가 있습니다. 더 좋은 퀄리티를 지향하지 않고 적당히 만들면서도 아무런 생각이 없다면, 그 사람은 그냥 실력이 없는 것입니다.
아홉 번째,
사용자(고객)의 피드백을 무시하거나 듣지 않는다.
부정적인 피드백이 빠르게 개선되지 않는다면 어렵게 모은 사용자가 빛의 속도로 이탈하는 걸 경험할 수 있습니다.
'6건 정도면 일단 다음 달까지 같은 내용이 인입되는지 보고..'
'이 내용은 사용자가 제품을 잘 안 써보고 미스커뮤니케이션이 발생..'
실패할 수밖에 없는 이유.
우리들은 이미 알고 있습니다. 사용자의 피드백, VOC가 중요하다는 것을.
: 하지만 실행 우선순위에서 항상 밀려나고 있다면 사용자의 피드백을 무시하고 있는 것과 마찬가지입니다. 특히 규모가 작은 제품팀에서 유저가 많을 경우에 신규기능개발, 사용자 피드백 반영(VOC 대응) 과제 간에 실행 우선순위를 고민하게 되는 상황이 자주 발생하게 됩니다. 이럴 때는 PM(PO)만 사용자의 피드백을 보는 것이 아니라 제팀 전체가 확인하고 가능하다면 운영까지 해보면서 공감할 수 있도록 하는 방법도 도움이 됩니다. 1명이 피드백을 주었다면 적어도 그 10배 이상의 같은 어려움을 느끼는 사용자가 더 있다고 봐야 합니다.
열 번째,
과제 회고를 충실하게 하지 않는다.
'회고'는 다른 회사에서, 옆 팀에서, 에자일 코치가, PM(PO)가 하자고 해서 하는 '이벤트'가 아닙니다.
'바빠 죽겠는데 또 무슨 회고야.'
'회고라고 가봐도 불평만 하고 분위기만 싸해지는데 이걸 왜 하는 거야.'
'회고하면 뭐 해 변하는 게 없는데, 액션아이템만 뽑고 돌아서면 잊어버리는데'
실패할 수밖에 없는 이유.
그렇더라도 회고가 중요하다고 생각합니다.
: 아무리 의미가 없다고 느끼는 회고라도 하지 않는 것보다는 무조건 제품팀에 도움이 된다고 생각합니다. 회고를 통해 서로에 대한 아쉬움과 불평만 늘어놓다가 끝나더라도 하지 않는 것보다 무조건 좋습니다. 특히 평소에 협업 관련 소통이 자연스럽게 잘 되지 않는 제품팀 일 수록 회고를 적극적으로 해야 합니다. 불편하기 때문에 외면하기 시작하면 감정의 골이 깊어지거나 불필요한 오해가 서로의 신뢰 관계를 무너뜨리게 되는 경우를 종종 경험했습니다. 전문적인 회고 기법이 없어도 "어렵고 힘들었던 점 / 좋았던 점 / 성장 한 점"과 같은 간단한 틀로 의견을 나누기만 해도 공통된 감정이나 이슈들이 한두 가지 정도는 나오게 됩니다. 이것에 대해서 함께 10-20분 정도만 의견을 모아보면 되는 것입니다. 먼 미래에 일을 더 잘하기 위해서 회고를 하는 것이 아니라 내일 일을 더 잘하기 위해서 성장하기 위해서 하는 '회고'를 하시길 바랍니다.
제가 경험했던 다양한 실패의 경험을 공유하는 것을 통해서 다른 분들의 학습 비용이 낮아지거나, 현재 어려운 상황에 처한 Product Manager, Product Owner, CEO 분들이 문제를 해결하는데 도움이 되길 바라며 작성합니다.
경험에 의존한 내용으로 검증된 방법론이나 이론이 아닙니다. 편향된 방향으로 기술된 내용이 일부 포함 될 수 있으며, 이로 인해 불편하시거나 이견이 있으신 분들은 편하게 알려 주시면 저의 성장의 기회로 생각하겠습니다.
성장중독자와 함께 성장, 스타트업, 제품에 대해 이야기하실 분!
