인스파이어드

인스파이어드에서 가장 인상깊었던 문구는 다음과 같다.

 

1. 위험은 마지막보다 초기에 대응한다.

뛰어난 팀은 어떤 것에 대한 구현을 결정하기 이전에 4가지 위험을 먼저 발견하고 대응한다.

• 가치 위험(value risk): 고객이 과연 이 제품을 구매할 것인가?
• 사용성 위험(usability risk): 사용자가 이 제품의 사용 방법을 쉽게 이해할 수 있는가?
• 실현 가능성 위험(feasibility risk): 우리 엔지니어가 보유한 시간/역량/기술로 필요한 것들을 만들어 낼 수 있는가?
• 사업 유효성 위험(business viability risk): 이 솔루션이 영업/마케팅/재무/법무 등 우리 사업의 다양한 측면을 고려했을 때 제대로 효과를 발휘할 수 있는가?

 

2. 제품은 순차적인 방식보다 함께 협업하며 정의되고 설계된다.

훌륭한 팀은 제품 관리자, 디자이너, 엔지니어가 함께 붙어서 활발히 의견을 주고받으며, 고객이 사랑하고 비즈니스 성과를 이룰 수 있는 기술 중심의 솔루션을 만들어 낸다.

 

3. 끝으로, 기능을 구현하는 것이 아니라 문제를 해결한다.

전통적인 제품 로드맵은 생산량에 대한 것이다. 강한 팀은 단순히 솔루션을 구현하는 것을 넘어 근원적인 사업 성과를 해결한다.

 

그동안 사이드프로젝트를 하면서 디자이너로써 PM이 결정한 사항에 대해 가장 빠르고 사용하기 쉬운 안을 만들어내기 위해 노력해왔다. 디자인을 하면서 이렇게 하면 진짜 성공할까?라는 의문이 들었지만 그건 PM의 몫이라고 미뤄두며 협업을 진행했는데, 이러한 나의 태도는 큰 실수였다. 나는 정작 위의 3가지 문구와 정반대되는 태도로 사이드프로젝트에 임했던 것이다.

 

1. 우선 프로덕트를 value, usability, feasibility, viability 4가지 측면에서 바라볼 시야를 갖추지 못했다.

2. 이러한 리스크에 대해 매주 2~3번의 회의를 하며 언급하긴 했지만, 디자이너로써 usability를 제외하고 관여하지 않았다.

3. 또한 usability를 구현할 때, '문제'가 아닌 '기능'에 최적화된 안을 내는 데 시간을 쏟았다.

 

우리 제품은 AI 캐릭터와의 대화가 지루하다는 사용자의 Engagement 문제로부터 시작되었다. 대화 데이터를 살펴보니 유저들은 AI 질문에 단순히 답하기만 했고, 반복적인 대화만 하고 있었다. 기존 시장의 제품들은 AI 캐릭터의 프로필을 탐색 페이지에 두고 있었기에, 그래서 캐릭터의 피드를 탐색 페이지에 배치하면 대화 소재를 더 많이 제공할 수 있다는 가설을 세웠다.

그리고 실험 결과는 리텐션을 기준으로 세웠다. 초반에 직접 컨택하는 방식에서 후반에는 SNS로 고객을 모집하다보니 public한 유저가 유입되며 리텐션이 더 하락했고, 사용자의 use case인 "성적인 대화"가 우리가 설계한 경험과 맞지 않았다. 결국 우리는 AI 캐릭터 시장에는 성적인 대화가 유저에게 가장 가치있는 기능이고, 우리의 방법은 가치가 없다는 것으로 결론지었다.

 

어떤 점이 잘못되었을까?

다시 생각해보면 첫 실험에서 16.7%나 일주일동안 우리 서비스를 이용해주었다. 푸쉬알림을 보낼 수 없고, 앱이 아니었기 때문에 DM링크를 찾아서 들어와야 하는 제약이 있는데도 말이다. 이정도 리텐션을 달성하지 못했기 때문에 우리 프로덕트는 가치가 없어!라는 결론을 내리기 전에, 왜 16.7%나 되는 고객이 일주일 동안 우리 서비스를 이용했을지 생각해보지 않았다.

 

또한 "우리 서비스를 가치있다고 생각한 유저들은 어떤 특성을 가졌는가?"에 대한 물음을 하지 못했다. 이러한 기능을 많이 사용하는 유저들은 어떤 특성이 있었는지, 초반에 직접 컨택한 유저들과 후반의 public 유저들이 보인 다른 성향에 대해 분석을 하며 새로운 인사이트를 발견했다면, 성적인 대화를 주로 원하는 유저들과 다른 세그먼트를 발견할 수 있었을 것이다.

 

데이터를 확인할 때에도 유저들이 많이 사용하는 캐릭터와 기능을 특징으로 다음 이터레이션을 계획했다. 왜 이런 캐릭터를 많이 선택했고, 그것을 선택함으로써 유저의 어떤 문제를 해결할 수 있었는지에 대한 생각은 하지 않았다. 데이터를 해석하는 프레임워크가 잘못되었고 그저 대중성 높은, 많이 선택되는 기능 중심의 이터레이션이 계속되었던 것이다.

 

앞으로 내가 PM으로 실험을 진행한다면?

만약 초기의 pmf를 찾아야 하는 실험을 하게 된다면 다음 3가지는 확실히 할 것이다.

1) 우선 어느 정도 이상의 리텐션을 기록했다면, 우리가 제공하고자 하는 가치 때문에 유저가 이용하는 것인지, 아니면 다른 가치를 그들이 발견했기 때문에 이용하는 것인지 '가치'에 대한 부분을 확실히 짚고 넘어갈 것이다.

2) 어떤 유저가 우리 서비스에서 가치를 느끼는지, 우리가 가장 문제를 잘 해결해줄 수 있었던 '핵심 유저'를 찾을 것이다. 초반에는 어떤 유저가 핵심 유저인지 모르기 때문에 실험에 따라 핵심 유저에 가까워질 수도 멀어질 수도 있지만 꾸준히 이들의 세그먼트를 나누려고 시도해 볼 것이다.

3) 니즈 기반으로 솔루션을 디벨롭해나갈 것이다. 어떤 기능에 대해 사용자가 긍정적인 반응을 보인다면, 기능 자체를 똑같이 디벨롭하는 것이 아니라 그 기능이 충족하는 사용자의 니즈가 무엇인지 문제의 단계로 다시 해체하고 여러가지 안을 계획해볼 것이다.