Case: 신기술 기반의 핵심 기능 개발
● 국내 상위권 패션 커머스 기업에서 AI 기반 '가상 피팅룸' 기능을 도입하기로 결정
● PM 2인, AI/ML 엔지니어 10인, 3D 디자이너 5인, 백엔드 개발자 8인을 6개월에 걸쳐 신규 채용 및 전환
● 3개월간 핵심 기술(AI 모델) 연구 및 프로토타이핑 진행
● 이후 7개월간 모든 리소스를 투입하여 기능 구현 및 데이터 학습에 매달림
결과; 10개월의 투입 결과 - C-level(경영진) 시연에서 혹평 후 프로젝트 무기한 보류
→ 어떻게 된 일일까? 왜 이런 결과가 나왔을까?
국내 상위권 패션 커머스에서 야심 차게 준비한 '가상 피팅룸' 기능은 10개월간의 개발 기간에도 불구하고 끝내 빛을 보지 못했다 그 이유는 무엇일까? 기존 고객들이 '더 정확한 사이즈 실측 정보', '다양한 모델의 착용샷'을 원한다는 VOC(고객의 소리)가 많았음에도, 'AI 가상 피팅룸'을 도입하면 멋지겠지? 라는 1차원적 사고를 바탕으로 시장 검증이 안된체 급격한 결정을 했기 때문이다.
이 과정에서 시장 검증이 안된체로 피드백 없이 10개월동안 개발은 진행되었다, 결국은 어떤가? 그 10개월은 수포로 돌아갔다. 물론 급격한 업데이트가 나쁜 것 만은 아니지만 그 만한 risk가 따르기에 실패할 확률도 높기 마련이다. 실현 가능한 아이템인지 분석하고, 점진적 개발을 통해 시장 검증을 확증해야한다.
PM은 의사소통을 통해 각 자원(리소스)들을 효과적으로 연결하고 조율해야 한다. 하지만 그렇다고해서 모두의 의견을 다 수용해선 안된다. 사공이 많으면 배가 산으로 가기 마련이다. 개발자는 제품의 기술과 안전성을, 디자이너는 사용자 경험을, 마케팅팀은 성장을 각 중점으로 삼는다.
PM은 이 모든 것을 동시에 우선순위로 둔다는 것은 어렵고 방향성을 잃을 수 도있기 때문에, 모두의 의견을 듣고 수용하되 어떤 것이 우선순위이고 의논하며, 중간 다리 역할을 하여 팀의 의사결정 중 의사소통 속에서 무엇이 우선순위인지 놓치지 않고 소통해야 팀 전체가 성장(develop)할 수 있다고 생각한다.
사례에서 처럼 무작정 기능을 추가해 만드는 것이 아닌, 기존 고객들의 핵심 요구(사이즈 정보, 착용샷)를 먼저 해결하고, 최소한의 기능을 갖춘 MVP(Minimum Viable Product)로 시장 검증을 하고 팀의 개발 방향성과 우선순위가 무엇인지 개발동안 피드백도 적극 수용하며 점진적으로 개발을 했어야했다.
개발자는 안전성을, 디자이너는 사용자 경험을, 마케팅팀은 성장을 중요하게 생각한다, 각 구성원들은 자기가 우선시하는 것들이 중요하다고 생각한다. PM이 의견을 모두 수용하며 각자의 관점에서 생각하면 모든 것이 중요해 보일 수 있다, 하지만 제품에게 있어서 모든게 우선시 되는 개발은 갈피를 못잡고, 방향성을 쉽게 잃진 않을까라고 생각이 든다.
우선순위를 정해야하는 이유는 개발에 있어서 종종 팀은 중요한 결정을 하게되는 면에도 있다.. 기술적 한계이든, 방향성이든, 제품의 특징이든, 고객 맞춤이든, 되돌릴 수 있는 결정(2-way door)과 되돌릴 수 없는 결정(1-way door)을 맞닿뜨리게 된다. 우선순위를 정해서 제품의 성장을 더 성숙하게 도모하기 위함이고, 나아가 제품이 성장하면서 동시에 유지되기위해서이다.
되돌릴 수 있는 결정(2-way door)은 언제든 되돌릴 수 있기에 나중에 문제가 생기면 되돌려 risk를 비교적 최소화할수 있는 반면에 되돌릴 수 없는 결정(1-way door)은 risk가 있는 중요한 결정 판단에 해야한다. 그렇기에 2-way보다 더욱 신중하게 결정을 해야할 필요가 있다.
각 분야의 최고의 전문가들이 모여서 협업을 해도 '우선순위'에 대한 '의사결정'이 잘못 되면 모든 일은 수포가 된다. 그렇기에 PM은 매순간 매번 올바른 우선순위 결정에 오너십을 갖는다. 압도적인 결과값을 내기위해서 끊임없이 고민해야한다는 것이다.
그러면 어떻게 해야할까? 어떻게 해야 최적의 우선순위를 결정할 수 있을까?
PM은 앞서 말했던 것처럼 조율자이다. 결정 자체를 PM이 혼자 하지 않고, 결정의 방향성을 설득하고 정렬하는 것이다. 물론 의사결정을 할때 중요한 역할을 하긴 하지만 이상적인 미션팀이라면 혼자 결정을 하진 않는다. 각 팀의 업무 우선순위를 명확히 설정하도록 한다. 서로 알수있도록 정리가 되어야 팀 개발에 있어서 무엇이 우선순위인지 각 팀원들이 알수있다.
동시에 PM은 데이터와 시장 또는 고객 피드백을 분석함으로 팀원들에게 왜 이 우선순위가 중요한지가 팀원들이 납들할수있도록 설명하고 "이 결정이 우리 팀 방향 전체 목표에 어떻게 기여하는가?"를 지속적으로 팀원들과 같이 탐구함으로 같이 우선순위를 결정할 수 있다.
그 우선순위 결정 과정에 있어서도 확신 보다 가능성에 더 초점을 두어야 시도와 꾸준한 검증으로 조금 더 높은 가능성이 있는 방향으로 움직이게 된다. "옳고 그름의 의사결정이 아니라 목적을 달성하기에 더 높은 '가능성'을 지닌 방향으로 우선순위를 선정해야 한다"
하지만 모든 결정이 좋은 영향만을 미치진 않는다. 위험과 결과의 수준을 고려할수있는 의사결정들을 구분할줄 알아야하고, 중요한거라 생각되는 결정들은 이해관계자들과의 의견을 충분히 나누고 어떻게 결정할 것인지 합의하여 실행 계획을 짜야한다.
따라서 PM은 혼자 결정하진 않는다. 모든 결정을 (혼자) 내려서도 안된다. 각 분야 전문성이 짙은 팀원들에게 의사결정을 위임해야한다고 생각한다. 기술적 결정은 기술 책임자에게, 사용자 경험 관련 결정은 프로덕트 디자이너에게, 비즈니스 실용성 관련 결정은 PM과 이해관계자들이 결정을 함으로 효율적이면서도 협업적인 면이 돋보인다고 생각한다.
좋은 의사결정은 합의, 투표, 독재 방식이 아니라 협업을 통해 이루어진다.
의사결정중에서도 의견이 맞지 않은 경우도 간혹 발생한다.잘못된게 아니기 때문에 의견 충돌은 당연히 발생할 수 있다. 의견 충돌에 있어서 해결하는 방법이 중요하다. PM은 데이터와 검증된 것들을 활용해 객관성을 확보해 결론을 도출해 설득해야한다. 하지만 그렇다고 해서 PM은 독단적으로 결정해서도 상위 경영진에게 그 의사결정권을 떠넘겨서도 안된다.
이 과정에서 다양한 협업툴을 사용해 의사결정 과정과 근거를 투명하게 공유하면 더욱 효율적이면서도 협업에도 도움이 된다. 때론 중요한 결정을 해야할때면, 팀원들에게 서술형 보고서를 작성해보는 것도 좋은 생각이다.
반대 의견이 있음에도 결정이 내려지면 팀원은 그 결정을 따르고 실행해야하지만, 팀원은 찜찜한 마음으로 맡은 바 일을 하기는 어려울 것이다. 따라서 PM은 자기가 이 결정을 내린것에 대해 논리적으로 설명해주고, 객관적인 데이터와 검증된 것들로 설명할수있도록 최선을 다해야 한다.
프로젝트의 잠재적 가치를 분석하며, 프로젝트 개발의 우선순위를 정하는 RICE 프레임워크가 있다.
도달 범위(Reach), 먼저 일정기준을 잡고 영향을 받는 사용자 술르 기준으로 한다. 영향력(Impact)은 프로젝트가 가져올 변화를 단기적, 및 장기적 결과를 고려하여 점수를 매긴다. 다음 신뢰도(Confidence), 프로젝트의 예측 수치(도달 범위, 영향력)에 대한 확신의 정도를 나타낸다, 그리고 노력(Effort)은 프로젝트를 완료하는데 필요한 리소스, 시간, 인력을 평가한다.
높은 영향력을 가지면서도 적은 노력이 필요한 프로젝트가 더 높은 점수를 받게된다.
물론 RICE모델을 무조건 신용해서는 안된다고 생각한다, 하나의 방법론일 뿐이다. 점수계산이 중요한 것이 아니라 팀이 무엇을 우선적으로 고려해야 하는지에 도움을 주고, 숫자만이 답이 아니라는 것을 알려주며 논리적으로 사고할수있도록 돕기 위해 존재하는 프레임워크이다.
협업을 하다보면 우리는 문서가 중요하다는 것을 알수 있다. 우리의 뇌는 모든 것을 기억할수가 없다. 가끔 깜빡하기도 하며 잊어버리기도 한다. 정보들을 문서에 저장해 사고를 정리할 수 있고, 같은 설명을 여러번 하지 않아도 되는 번거로움도 줄어들며 동일한 정보를 팀원이 공유받을수 있다. 그리고 어떤 맥락에서 어떤 결정이 내려졌는지도 기록할수있기에 실무자에겐 참 편리하고도 친절하다.
또 시대가 고도화가 됨에 따라 KMS이 만들어졌고, 이를 통해 조직 내 지식, 또는 정보를 생성 공유 저장 및 활용하는 것이 편하고 효율적이도록 변하였다. 이는 효율적으로 정보를 찾고 의사결정과 업무 생산성을 향상할수있도록 돕는다. workspace은 단순 일하는 공간이 아닌, 지속적으로 업데이트되는 정보활용과 의사결정의 질(quality)을 높일수 있는 도구다. 협업에서의 관점이 강하다고 생각한다.
그럼 모든 구성원이 모든 정보를 알고 있어야할까? 내 생각은 '아니다'. 그렇다면 꼭 공유되어야 할 내용은 무엇일까?
첫째 고객 인사이트, 팀원들은 알고있어야한다. 모든 의사 결정은 고객 가치를 만드는 것에서 부터 출발한다는 것을. 고객 인터뷰, 설문조사 고객 행동분석, 데이터 분석 등을 통해 제품을 사용하는 고객의 주요 Pain point(불편함), Needs(필요), Behavior(행동)를 지속적으로 문서화하여 공유해야하고, 이는 기술 개발 및 우선순위 설정에 큰 도움을 줄 수있다. 단순하게 데이터와 지표 피드백 모음집이 아닌 제품 인사이트의 '맥락'을 문서로 남기는 것이 중요하다.
둘째 비즈니스 지표, 매출,고객 수,전환율,이탈률 등 핵심 지표를 정리하여 문서화할 필요가 있고, 단순 숫자가 아닌 이 지표가 정확히 어떤 의미를 나타내며 각 의사결정에 어떻게 연결되는지 맥락을 포함해야 회사내 모든 구성원들이 회사가 어느 방향으로 제품을 개발하고 있는지 알수있게 된다.
셋째 프로젝트 진행 상황, 각 기능의 개발 단계(기획-디자인-개발-QA-배포) 명확하게 문서화하되, 불필요한 노이즈같은 정보, 커뮤니케이션은 줄이고 주요 의사결정들이 왜 어떻게 어떤 내려졌는지도 함께 정리하고, 단순 개발 프로세스, 일정 공유가 아닌 변경 사항, risk 요소 까지 포함하여 지속적으로 업데이트하여 모든 구성원이 프로젝트 진행상황을 쉽게 파악할 수 있도록 해야하고 이는 좋은 협업으로 이뤄질 수 있다.
이 과정들은 협업툴로 정리할 수 있다. 고도화됨에 따라 업무 효율에 있어 협업툴들이 많이 발전되어왔다. 하지만 너무 많은 협업도구는 오히려 업무 생산성을 저해할 수 있다는 것을 고려해야 한다. 정보 체계 = 인지 체계 라는 공식을 생각해야한다. 그렇다고 해서 협업툴을 통해 문서를 아예 남기지 않으면 오히려 문제가 발생할 수있다. 공유되어야할 핵심 지식이 개인에게만 남겨 불균형이 생기거나, 동일한 실수를 반복하거나, 불필요한 회의를 계속 해야할 수도 있다.
조직의 지식체계를 관리하는 것 역시 PM의 역할이다.
한번 문서를 남길때 어떤 문서를 남겨야하는지도 효율적으로 생각해봐야한다. 한번 기록하면 여러 번 활용할 수 있는가? 시간이 지나도 여전히 가치가 있는 정보인가? 여러 사람이 참고할 가능성이 높은가? 문서들이 내가(우리가) 일하는 방식을 보여주고 있는가? 의사결정에 필요한 주요 지식들이 눈에 잘 들어오는가? 실무에 자주 쓰는 정보들이 접근하기 편하게 되어있는가? 오랜 기간 자주 사용해온 정보들이 잘 정리되어 있는가?
협업을 효율적으로 할수있도록, 협업을 잘할수 있도록,이 모든 행위의 결과가 제품의 가치를 올릴수있도록 끊임없이 PM으로서 탐구해야한다.
