PM을 맡고 4주차... 큰 고민과 시련에 빠졌다.
참신한 아이디어로 시작한 프로덕트가 더 이상 참신해 보이지 않았고, 이게 사용자의 문제를 해결해줄 것 같지 않았다.
사실 팀원들은 큰 걱정이 없었을 수도 있다. 그러나 나는 알 수 없었다.
기존에 있던 서비스도 아니고, 이제 막 1차 MVP를 수립하고, 인프라를 구축하던 시점이니 의견을 구하고 싶다는 생각이 들었다.
개인적인 나의 성향상 과몰입이 심한 사람인데, 문득 "사진을 SNS에 올리기 전, 고민되는 사진을 투표하는 어플리케이션"이라는 주제가 정말 사용자들의 문제를 해결해 주는 어플리케이션인가? 라는 의문이 맴돌았다.
내가 이프로젝트를 하면서 가장 진지하고 심도있게 빠졌던 시기 같다.
그래서 나는 혼자 기획에서의 문제와 가설 그리고 검증이라는 것에 대해서 공부해보고, 우리 서비스에 대입하여 생각해보는 과정을 거쳤다.
문제란 무엇일까?
보통 문제는 현상으로 나타난다. 우리의 경우에는 SNS에 사진 올리기전에 어떤 사진을 올릴지 고민된다. 라는 현상을 발견했다. 근데 우리는 이 현상을 문제로 정의하는 오류를 범했다.
현상은 문제가 아니다. 내 나름의 문제와 현상의 차이를 정의 헀다.
문제는 위와같은 물음에 Yes라는 답이 나와야 기획단에서 정의 하는 문제인 것이다.
사용자는 생각보다 더 냉정하고 게으르기 때문에 조금의 불편함은 감수하고 산다. 그렇기 때문에 '중요한 문제'가 아니면 관성에 의해 살던 대로 살 가능성이 크다.
그렇다면 우리는 우리가 발견한 이 현상을 어떻게 문제로 정의할 것이냐? 라는 큰 숙제에 직면한 것이다.
문제를 추론해가는 과정에서 추상적인 생각 지양, 비판적인 사고, 가치제공에 대한 의식 등이 필요하다. 나는 이런 상황에서 아무리 머리를 굴려봐도 뾰족한 수가 나오진 않았다. 그래서 나름대로의 문제정의와 가설과 검증방법에 대한 내용을 정리하여 팀원들과 의논하는 시간을 가졌다.
팀원들은 어떻게 생각하고 있었을까?
팀원들의 생각
우리는 사용자가 느끼고 있는 '불편함'을 찾지는 않았다.
우리는 사용자의 '욕구'를 충족시켜줄 현상을 찾았다.
그 현상은 SNS에 가장 잘 나온 사진을 올리고 싶었다는 것.
그럼 우리는 그 작은 현상이라도 투표를 통해 이 욕구를 충족시켜줄 문제를 정의하면 된다.
나는 이 이야기속에서 큰 깨달음을 얻었다. 어떻게 6주짜리 프로덕트에서 이 세상에 없어서 해결할 가치가 있으며, 사용자들이 적극적으로 해결책을 찾고, 시간과 돈까지 쓰는 문제를 우리가 정의할 수 있을까? 그건 불가능하다.
그 덕에 다시 초심으로 돌아와 '작은 문제라도 해결하자' 라는 생각이 들었다. 이후, 사용자에게 피드백 받아 또 다시 문제를 세우고 가설을 검증하며 다시 사용자에게 피드백 받는 과정을 거치기로 마음 먹었다. 이 과정을 이터레이션 이라고 하는데 이 과정속에서 우리 서비스가 사용자의 문제를 해결해줄 수 있도록 구체화되고 확장될 것이라고 생각한다.
이후, 나는 우리 프로덕트의 문제를 다음과 같이 정의 했다.
사용자들은 SNS에 사진을 올리기전에 선택의 어려움을 겪으며, 이과정에서 혼자만의 고민과 불필요한 에너지를 소비한다
👉 투표를 통해 빠르게 결정을 내릴 수 있다.
사용자들은 SNS에 사진을 올리고 긍정적인 반응을 얻고자 하지만, 어떤 사진이 더 좋은 반응을 얻을지 예측하기 어렵다.
👉 어떤 사진이 인기있을지 투표를 통해 예측해볼 수 있다.
이 두가지 문제는 사용자들의 행동과 심리를 미루어 짐작해, 해결할 만한 문제로 구체화 해본 것이다.
그렇다면 이 문제에 대한 가설을 세우고 검증하는 과정을 거쳐 서비스의 핵심 줄기를 만들어야한다.
이전에는 정량적 리서치를 통해 위 문제들에 대한 해결 니즈를 확인한 상태였다. 이후에 또 다른 💡 검증 결과를 토대로 계속 이터레이션 과정을 거치며 사용자에게 선택받는 프로덕트로 발전시켜봐야 하는것이 숙제.