이번 제품을 만들면서 처음엔 3개월간 기획-와이어프레임-프로토타입-MVP(?) 비스무리한걸 만들때까지는 사측의 요구로 혼자 진행했었다. 물론 이걸 위한 펀딩은 없었으며, 그저 토이프로젝트로써 진행을 했다. 음, 뭐 돈도 안주는데 뭘 그리 열심히 하냐 라고 물어볼 순 있겠지만, 이러한 경험들이 모여서 나중에는 더 좋은 제품과 더 멋진 커리어를 쌓을 수 있는 것이라고 기대했기 때문이다.
하지만, 제품의 필요성에 대해서 통계적으로 접근을 한다음에 제품의 필수 요소들 (이건 나중에 이야기를 하자) 그리고 제품을 엉성하게 나마 만들어서 임원진들에게 시연하고 나온 후에 해당 프로젝트는 정식 프로젝트로써 사내에서 승인을 받게 되었다. 이때 당시 나에게 할당이 된 협업 관계의 직원은 2명.
프로젝트를 해내는데 ... 2명? 이라고 생각할 순 있지만 기업의 규모 뿐만아니라 차기 프로젝트가 여러개가 진행되는 상황에서 내가 맡은 진단기기는 후순위였기 때문에 많은 인원을 할당할 수 없었다. 그렇다고 이걸 못하겠다고 포기하는것은 내가 원하는 목표와도 맞지 않았기 때문에 나는 나 나름대로 이걸 수행해보고자 하였다.
근데 그거 아는가? 혼자서 하는 것은 나름의 생각을 정리해서 나의 우선 순서대로 일을 하면 되지만 누군가와 협업을 한다는 것 그리고 누군가들에게 지시를 내리고 이끌어 간다고 하는 것은 생각보다 많은 고뇌가 필요로 한다. 누군가에게는 어떤 식으로 요청을 할 것이며, 누군가의 아이디어를 받아 들일 것인가 말것인가. 만약 받아들인다면 어떻게 반영을 하여 기존 계획의 수정을 할 것이며, 거절 한다면 어떻게 거절을 함으로써 해당 업무를하는 사람이 '공격받았다'라고 느끼지 않게 할 것인가.
지금부터 나의 실패 그리고 성공담을 한번 적어보려고 한다.
들어가면서
자랑스럽게도 이번에 세계진단기기 박람회 MEDICA 2023에서 내가 기획했던 제품이 결국 세상에 나오게 되었다. 어떻게 보면 정식 데뷔를 하였다. 아쉽게도 이번에 나는 개인적인 사정으로 인하여 참석하지는 못하였으나, 우리 팀원들이 현장에서 열심히 홍보를 해준덕분에 나름의 호평을 받았다는 이야기를 전해들었다. 나의 사정을 이해해주고 현장에서 열심히 설명해준 팀원들에게 감사의 뜻을 전한다.
MVP에서 우선순위란?
처음 MVP라는 것을 만들어야 한다고 주장을 했을때 다들 오해했던 것이 있었다. 그것은 바로
만들고자 하는 기능을 모두 구현해서 보여주어야 한다.
참으로 지금 생각하면 어처구니가 없었다. 어떻게 보면 MVP에 대한 정의조차 제대로 내리지 않은 상태에서 제품을 만들어야 겠다고 말하는 것과 같은 논리이다. 이렇게 기능적인 면을 추구하고자 하다보니 엔지니어링 인원은 기능의 완벽 구현을 위해서 종일 밤낮을 고생해야 했다. 물론 레거시 코드를 사용하여 이전의 코드를 가져오는 것이 많았으나, 새롭게 추가된 기능의 경우에는 해당 기능을 만들기 위해서 받쳐주는 추가적인 기능들이 필요하게 되는 바람에 날마다 스프린트를 해야하는 상황이 펼쳐지게 되었다.
지쳐가는 엔지니어링 인원을 보면서, MVP를 만든다는 것의 진짜 목적을 다시 한번 되새기는 시간을 가져보았다.
MVP는 핵심가치를 전달하고자 하는 것이 우선시 되어야 하는 제품이며, 이 제품의 가치를 제공하는 것에는 기능이라는 토대 위에 신뢰성이라는 사용성 그리고 사용자 중심의 경험 그 다음 디자인이 접목이 되어야 하는 것이였다.
그러나 우리는 일단 기능을 무조건 완성해서 임원들에게 보여주고 현재 상황을 모니터링 할 수 있게 해야한다는 것에 치우쳐서 필수라고 생각했던 모든 기능들을 모두 집어 넣고자 하였다. 이러다 보니 너무나도 과도하게 모든 기능들이 필수적이라는 일반화된 가치를 제안하고 있었다. 이를 막아야하는 것이 기획을 하고 프로덕트를 매니지먼트 하는 나의 역할이였다.
위의 그림에 나의 잘못된 점이 여실히 드리나고 있는데 나는 계속해서 기능을 만들어 달라고 요청을 하고 있었다. 오히려 최종 프로덕션 단계에서 가치를 제안하고자 할때는 편의성과 디자인 그리고 신뢰성등에 바탕을 두어서 제품에 대한 기대치를 끌어올렸어야 하는건데, 이 점은 나의 첫번째 패착이였다. 그러다 보니 결국 MVP를 6개월만에 만들어 내겠다는 나의 욕심은 팀원들의 지친 얼굴로 여실히 나타났다.
또한 실패할 것이라고 생각했던 프로젝트가 조금씩 진척 사항을 보이고 있으니 이에 대해서 첨언을하고 싶어하는 주변의 요구 또한 많았다. 그러다보니, 결국 MVP라는 단계를 뛰어넘고 우리는 완벽하게 작동하는 완성본을 만들기 위해서 몇날 며칠을 계속해서 회의하고 뒤집고 했던 것이다. 기록을 남겨서 다른 사람들이 공통된 생각을 해야한다는 것 때문에 많은사람들이 회의에 들어오도록 했지만 이 점이 결국 화살이 되어서 우리의 프로젝트가 점점 추가적인 기능을 넣기 위한 수단으로써 변모하고 있었다.
이제 실제적으로 어떠한 기능을 우선적으로 넣고 고객들의 중요 순위를 어떻게 다시금 반영할 수 있을지 정리해야 하는 순간이 오게 되었다.
모스코(MoSCoW) 우선순위 정하기
우리의 제품의 경우에는 그렇게 복잡한 형태의 앱은 아니였다. 기능은 아무래도 중요하게 사람의 혈장으로 특정 바이오마커의 농도를 측정하는 기기였지만 그렇다고 해서 기능 자체가 엄청난 고도의 계산을 요구하거나 연관이 되어서 나타나거나 그런것은 아니였다. 그렇다 보니, 우리는 모스코라고 하는 어느 정도 간결한 프로덕트를 위한 우선순위 지정 방법을 사용하였다.
모스코라는 것 외에도 워킹스켈레톤, 라이스, 카노 등 과 같은 우선순위 설정 방법들이 있으니 나중에 한번 다뤄보도록 하겠다.
여튼 모스코는 MVP처럼 필수 기능을 보여주기 위한 서비스에 적합하며, 출시 예정중인 제품에도 사용이 가능하다. 그리고 사용의 용이성에 초점을 맞추다 보니까. 간편하게 필수 기능을 생각해보기엔 좋다.
자 그럼 각 알파벳 별로 다시 한번 설명을 해주자면 다음과 같다.
- M: (Must have) 프로젝트의 승패를 쥐고 있는 필수적인 기능이다.
- S: (Should have) Must 보다는 단계가 낮지만 가치를 더하는데 있어 필요한 기능이다.
- C: (Could have) 생략을 한다고 해도 큰 영향을 미치지는 않는다.
- W (Will not have) 현재 바로 진행하지 않아도 문제는 없다.
감이 오는가? 정량적인 방법이라고는 할 수 없지만 나름의 "정의"를 통해서 제품의 기능 우선순위를 나열하여 프로젝트의 속도를 높일 수 있는 방식이다. 나의 경우 해당 제품에 대해서 구분을 해본 결과
M에 해당하는 것은 '속도'와 '편의성'에 가장 중요한 부분을 차지하고 있는 두가지 기능이 선택이 되었다. 업계 누구라도 따라올 수없는 알고리즘의 독특함을 사용한 최고의 속도 그리고 처음 사용하는 누구라도 쉽게 사용할 수 있는 '스토리 텔링'의 편의성.
그리고 그 외의 C나 W에는 자동 리포트 생성 기능이라던가 아니면 제품 보호 기능 또는 '있으면 좋을 법한' 최신식 기능 들이였다. 최신식 기능들이라고 하면 꼭 있으면 좋을 것 같지만, 제품을 사용하는 사람들이 의료전문가들에 집중이 되어 있는 만큼 사람들이 우선순위로 설정하고 있는 기능은 C나 W에 속하지 않을 터였다.
이를 통해, 깊은 계산이라던가 시간이 걸릴 것 없이 쉽게 우선 순위를 재설정할 수 있었으며, 팀원들에게도 곧바로 공유를 하여 팀 리소스에 맞는 우선순위 설정이 가능하게 되었다. 다만, 문제가 있었다면 모두가 필수 기능이라는 것에 동의를 하지 않는 부분도 있긴 있었다. 물론 내가 여기서 리드를 하고 있는 입장에서 결정하여 통보하는 식으로 진행을 할 수도 있었지만, 엔지니어의 입장에서 또 디자이너의 입장에서 생각하는 주요점들이 있었다.
이와 같은 점들에 대해서는 시간이 걸리더라도 각자의 입장에 대해서 '충분히' 이야기를 듣고 설득력 있는 이야기인지 확인해보았다. 이것만큼 중요한 것도 없을것이다. 그 누구라도 소외받지 않도록 할려면 '대화'와 '공유'가 필요하다. 특이 팀으로 움질일때는 더욱 그렇다. 그렇기에 이야기를 들어보고 괜찮은 기능이라고 생각이 든다면 W 범주에 넣어두어 '추후에 반영하되 잊지는 않겠다'라는 식으로 정리를 해두었다. 아무래도 1년이라는 제한적인 시간 동안 3명의 팀이 함께 움직여야 하다 보니 릴리스 시간에 대한 중요도 때문에 많은 기능을 할애할 수가 없었던 점이 컸다.
다른 우선순위 설정법은 생각해보지 않았나?
아 물론 했다. 라이스 (RICE: reach impact confidence and effort) 운선순위 설정법을 생각 했으나, 기능을 사용하기 위한 영향도 라던가 팀이 소요한 시간등에 대한 수치를 객관적으로 수집할 수 없었기 때문에 결국 객관적이지 않은 단순 추정치로 전락해버릴 가능성이 높았다.
왜냐하면, 아직 객관적인 수치로써 사용자의 활동이라던가 마케팅을 분석한다는 등의 계산법이 정립이 되지 않았다 보니, 이에 대한 자료를 제공해줄 수 없는 환경이였다. 그렇기 때문에 해당 방식은 내가 진행하는 프로젝트와는 맞지 않았다.
자 이렇게 할일을 다시 정했다.
'모두가 동일한 가치'를 공유해야 한다는 생각을 '모두가 동일한 시간을 보냄으로써 생각을 동일하게 한다고 받아들여' 결국 우리 팀이 1달이라는 시간을 허비하는 결과를 낳게 되었다. 이를 극복하기 위에 MoSCoW 방식으로 우선순위를 정했으니 다시 스프린트를 위한 시간을 가지면 되는 것이였다.
하지만 일을 그렇게 또 쉽게 흘러가지 않았으니.
나도 모르는 사이에 우리 팀은 '편향'이라는 수렁텅이로 빠져들어가고 있었다. 이번엔 외부적인 문제가 아닌 내부적인 문제가 발생해버린 것이다. 나는 이걸 어떻게 극복해야할지 필사적인 방법을 찾아야했다.
조심해야할 편향에 대해서 다음에 한번 알아보도록하자.
'PM과 UIUX 이야기' 카테고리의 다른 글
| PMF (Product Market Fit)은 어떻게 파악했습니까? (1) | 2023.11.22 |
|---|---|
| 프로덕트 매니저의 역할 4가지로 구분해보자. (0) | 2023.11.21 |
| 진단기기 시장에서 경쟁자분석 어떻게 했어요? (0) | 2023.11.17 |
| 진단기기 시장조사는 어떻게 했는지 더 알려줘요 (시장수치 접근법) (1) | 2023.11.16 |
| 진단기기 시장 조사는 어떻게 했어요? (시장확인) (1) | 2023.11.15 |