스타트업이 추구하면 안되는 '완벽한 미완성'

프로덕트 오너(이하 PO)로 일을 하면 자연스럽게 마주하게 되는 이해관계자들과의 커뮤니케이션과 설득의 과정 속에 놓인다. 더 많은 혹은 더 우리가 가야할 방향에 맞는 길로 다가서기 위해 어쩔 수 없는 어려운 선택을 하고 결정을 할 수 밖에 없기 때문에 항상 반발에 마주하게 된다. 이 과정 속에서 항상 염두해야만 하는 위험한 주장에는 어떤 것들이 있을까?

 

나는 불편한데? - 일반화

사용자들에게 푸시 메세지를 보낼 방법이 Firebase의 콘솔에서 밖에 할 수 없었던 모바일 제품을 맡았다. Firebase는 그 자체만으로도 훌륭한 서비스임에는 틀림 없지만, 이런 써드파티 서비스의 증가는 오퍼레이터들의 혼란을 가중 시키고 업무 난이도를 높이는 단점도 분명히 존재한다. 사실 이것보다 더 큰 문제는 Firebase는 우리의 유저 정보를 그대로 들고 다니지 않고, Topic을 하나씩 지정해주지 않으면 그룹을 나누어 특정 사용자들에게만 푸시를 보낼 수 없다는 점이다. 

 

이 문제는 제법 아쉬울 때가 많았는데 아무래도 DA(Data Analyst)의 역할도 병행하고 있다보니 오퍼레이터나 마케터에게 적절한 프로모션 타깃을 알려주어도 이용자에게 다가갈 방법이 없었다. 기본적인 인구통계조차 반영할 수 없이 전체에게 보내는 푸시메세지라니 지금 생각해도 비참하다. 임시 방편으로 연결된 채널톡을 활용하여 사용자들에게 접근했지만 이것도 점점 세그먼트가 다양해질 수록 의존하기 어려워졌다. 백로그에 남겨놓았던 문제이지만 제품이 활성화 되기 위해 꼭 필요한 상식적인 기능이라고 생각했기 때문에 우선순위를 높이고 기존의 Firebase에 붙여서 바로 푸시를 보낼 수 있도록 했다. 

 

이 백로그만 언급하고 이야기 나눌 때는 사용자별로 그룹을 만들 수 있어야 하며, 해당 그룹 또는 개인 별로 푸시 메세지를 생성하여 발송할 수 있어야 한다는 단순한 요구사항이었고, 이 외의 부수적인 혹은 잠재적인 니즈는 스프린트 이후에 점검하며 붙여나가기로 했다. 2주 정도의 구현 기간이 끝나고 어드민 페이지(Django admin)에 붙여서 오퍼레이터 및 마케터에게 전달되었다.

 

막상 두어달이 지나자 내가 원하는 게 빠졌다며 당연한 기능이 왜 없냐는 항의가 있었다. 확인해보니 그룹에게 재발송, 여러 그룹에게 복합적으로 발송하는 등의 기능들이 빠졌다는 것이었다. 나 역시 필요할 수 있는 기능이라고 생각했고 지금부터 또 기능을 업데이트 하면 된다고 생각했는데 당사자는 '지금' 없으니 답답하다는 듯 여기저기 짜증 섞인 자신의 의사를 표현하고 다녔다. 그의 논리는 간단했다.

 

"내가 사용자인데 내 이야기를 듣지 않았다."

 

여기서 중요한 건 오퍼레이터와 마케터 등 푸시 메세지를 활용할 내부 사용자의 수가 20명에 가까웠고, 꼭 필요한 기능과 나중에 구현할 기능을 나누는 과정 속에서도 언급된 적 없었던 기능이다. 사후고찰을 통해 발견된 잠재적 수요가 당연히 제공되어야 할 핵심 기능으로 순식간에 돌변한 것이다. 

 

인터널 서비스를 운영하는 팀이라면 언제든 겪어봤을 법한 이야기이다. 사실 이 극단적인 케이스가 아니더라도 자주 접한다. 애초에 요구사항을 파악하며 필수적이지 않으니 조금 뒤에 하자는 PO의 의견에도 아쉬움을 표하며 그래도 지금 해달라는 경우가 수없이 많다. 이유가 객관적이거나 스토리의 목적에 부합하지 않는 경우도 많다. 결국 '내'가 필요하기 때문이다. 

 

"필요한 것 동의해요. 하지만 저희에게 주어진 시간과 자원을 고려하면 일단 여기까지 하고 그 다음에 말씀하신 것도 해보면 어떨까요?"

 

아니면 어떻게 할래? - 책임론

 

사실 가장 답이 쉬운데 이런 경험이 적은 사람에게는 압박감을 주는 질문이 있다. 보통 PO는 자신의 가설을 기준으로 시험할 스토리를 정하게 되는데 이 과정에서 본인의 의견과 다르다거나 실패경험이 많아서 신뢰도가 없는 경우 나오는 질문이다.

 

"너의 가설이 틀리면 어떻게 할래?"

 

우리가 이 실험을 해보는 이유는 해보고 실패하더라도 실패하는 길이라는 것을 빨리 아는 게 더 중요하기 때문에 사실 이 상황에서는 대답이 어렵진 않다. 근데 이 과정에서 더 주목해야 하는 것은 저 질문의 배경에 어떤 맥락이 있냐에 달려있다. 나에 대한 신뢰가 없어서 일 수도 있지만, 전반적으로 리더들에 대한 경험적인 요소가 작용하는 경우도 있고, 너무 많은 실패만 경험했을 수도 있다. 근데 이유가 어떤 것이든 결국 성공 경험만이 해결할 수 있는 문제인 경우가 대부분이다. 그래서 PO는 가장 단기간에 작은 성공이라도 경험할 수 있는 스토리부터 설득해 나가는 것이 중요하다. 

 

"우리 서로 믿어보자! 우린 결국 성공하는 길로 갈 거야"

 

이거 그래서 그런거 아니야? - 논점 바꾸기

 

스토리를 구성하며 가장 중요한 것은 스토리의 제목이나 가설이다. 실험의 설계나 구성 자체가 해당 가설을 검증하기 위해 진행되고 있다. 그리고 모든 가설에는 약간은 중요도가 낮은 몇가지의 전제 또는 질문이 붙는다. 근데 실험이 시작되고 시간이 길어지면 점점 얼라인이 맞지 않는 경험을 하게 된다. 그럼 점점 실제 실험을 실행하는 것보다 다른 내용들에 집착하게 되는 경우가 발생하는데, 이게 바로 시간이 흐를 수록 우리의 확신이 줄어드는 이유이기도 하다.

 

예를 들어 NPS 측정을 해보는 과정에서 점수가 낮은 이유를 응답이 아닌 질문 자체에서 찾는다거나 하는 것이 대표적이다. 이 실험에서 우리는 높은 점수를 받을 수 있는 질문을 찾는 것이 목표가 아니라, 현재의 상태를 파악하고 부족한게 무엇인지 알아내는 것이 목표라는 것을 명심해야 한다. 점수 자체에 포커스를 맞추고 질문을 다시 수정하는 일이 생기면 결국 제품이 좋아지는게 아니라 우리가 측정한 결과값만 좋아지는 보여주기식 업무가 진행될 수 밖에 없다.

 

"우리가 이 실험에서 알아내고 배워야 하는 것은 ㅇㅇ이니까 계속 해볼게요!"

 

 

이 모든 과정에서 우리가 가장 두려워하는 것은 완벽하지 않아서 불만족스러울 때일 것이다. 하지만 완벽함의 기준은 매우 주관적이다. 우리가 보내는 시간 속에서 우리가 만드는 무엇도 완벽할 수 없다. 완벽을 추구하려고 할 때 미완성의 상태는 지속되고, 미완성된 제품은 비즈니스가 될 수 없고 발전할 수도 없으며 만족도 불만족도 할 수 없다.

 

경험조차 할 수 없는 것은 불만족스럽지 않은 것이기도 하지만, 그렇다고 이 상태가 만족스럽다는 절대 아니다.