포닥스 프로젝트 리뷰(1) 새로운 서비스를 위한 고객 문제 정의

  이제는 마치 대학원에서 코스웍(Coursework)을 끝내고 졸업 논문을 쓰는 것처럼 프로젝트로 지금까지 배운 내용들을 적용해서 기존에 없는 새로운 서비스를 만드는 작업을 하고 있다. 디자인 프로세스의 4단계 중 지금은 초기 단계인 Discover와 Define이 끝났고 어느 정도 고객의 문제 정의가 끝난 상태이다. 

  왜 모든 프로젝트가 끝나고 후기를 쓰는 것이 아니라 중간에 쓰냐?
배운 것을 적용하면서 경험했던 생각과 어려운 점들을 바로 바로 정리하면서 다시 한번 스스로 인사이트를 얻기 위해서이다. 

  다행히도 이번 프로젝트는 평소에 생각했던 연구자들과 관련된 서비스를 기획해 볼 수 있었다. 같이 하는 프로젝트 파트너도 연구자 시장을 잘 이해하고 있었고 직접 개인 프로젝트로 관련 서비스를 기획하고 있었다. 

---

(1) 팀 빌딩과 방향성

  프로젝트를 시작하고 팀 빌딩을 위해 파트너와 함께 프로젝트를 어떤식으로 해야 하는지 고민하는 것은 그리 오래 걸리지 않았다. 앞서 이야기했지만 우리는 학과는 다르지만 연구자였고, 각자 연구자를 위한 프로젝트를 진행 중에 있었기 때문이다. 이 둘의 프로젝트를 적절히 버무려 프로젝트의 초기 방향성을 잡기로 하였다.   

  이 단계에서 가장 큰 문제점은 우리의 생각을 하나로 정리를 하는 것이었다. 거의 브레인스토밍 하듯이 서비스를 기획하는데 필요한 요소들과 하부 요인들을 던졌고 이들을 카테고리로 정리하여 한 문장으로 정리를 하는 것이 어려웠다. 이 단계에서 우리가 설정한 문제는 '연구자는 강의를 할 곳이 마땅치 않아 강의 실적을 쌓기 어렵다'라는 것이었다. 그래서 '연구자를 위한 온라인 강의 플랫폼'을 구상해 보자는 식으로 방향성을 잡았다. 하지만 설정한 잠재 고객의 문제와 프로젝트의 방향성을 곰곰이 생각해 보니 '이게 굳이 IT서비스여야 하나?'라는 생각이 들었다. 또한 PM으로서의 IT 프로덕트 기획이 아닌 일반적인 창업 아이템으로서의 기획으로 바뀐 느낌이었다. 

  무언가 이상함을 느낀 우리는 더 나은 방향성을 찾기 위해 2시간을 넘게 이야기를 하다 우선은 '연구자를 돕는 서비스' 라는 궁극적인 방향성을 설정하고 UX 리서치를 통해 설정한 가설과 고객의 문제를 확인해 보기로 했다.

  이러한 작업들은 이래 Discover(발견)의 단계에서 나올 수 있는 실수(?) 혹은 문제점일 수 있는 것 같다. 물론 고객의 문제를 찾는 것이 우선 되어야 하지만 기본적인 방향성이 있어야 어떤 자료  조사나 데이터를 모을 수 있을 것이다. 하지만 이 방향성을 잡는데 필요한 데이터나 자료가 없는 상황에서 맨땅에 헤딩하듯이 경험과 뇌피셜(?)에만 의존하다 보니 어떤 것을 우선순위로 잡아야 하는지 기준이 잡히지 않았던 것 같다. 이런 의미에서 PM으로서 서비스의 궁극적 방향성을 잡는 것이 중요하다는 생각이 들었다. 또한 이렇게 세운 가설을 검증하는 UX 리서치를 하는 것도 꼭 필요한 단계라는 것을 알게 되었다.

  개인적으로는 프로젝트의 여러가지 요소들을 고려하여 궁극적으로 나가야 할 큰 그림을 보거나 그리는 것을 좋아한다. 어떤 일에 빠지면 대부분은 세세한 것을 신경 쓰다 원래 하려던 것이 무엇이었는지 잃어버리는 경우가 많이 있다. 그렇기 때문에 누군가가 이 방향성을 붙잡고 계속해서 확인하며 나가야 할 것이다. 이러한 작업을 PM이 해야 하는 것이며 개인적으로는 이 부분에서 나의 강점을 살릴 수 있는 영역이라고 생각한다.

 

(2) UX 리서치 후 피벗

  위의 문제점에도 불구하고 개인적으로는 연구자에 대한 시장과 연구자들의 생리를 잘 알기 때문에 초기에 세웠던 가설, 혹은 방향성에 대한 어느 정도 자신이 있었다. 그래서 UX리서치를 통해 이 가설이 실제로 잠재 고객(연구자)들이 가진 문제인지를 파악하려고 하였다. 재미있는 점은 이 과정에서 초기에 세웠던 가설이 철저하게 부정되었다는 점이다. 

  초기에 세운 연구자들이 가진 문제는 '강의에 대한 열정이 있지만 강의 실적을 쌓을 수 있는 곳이 없기 때문에 강의를 할 수 있는 서비스를 쓸 것이다.'라는 가설을 세웠지만, 실제적으로 연구자들에게 연구를 하는 중 가장 필요한 부분은 '재정적 지원'이라는 점을 발견하게 되었다.

  이 과정을 통해 왜 스타트업이 이런 UX리서치에 진심인지를 알 수 있게 되었다. 내가 잘 안다고 생각한 잠재 고객의 문제와 실제 잠재 고객의 문제는 너무나 달랐다. 처음부터 고객이 가진 문제를 특정할 수 있다면 좋겠지만 사실상 시장은 복잡하고 고객들은 너무나 가변적이기 때문에 서비스의 피벗 혹은 정확한 서비스 방향을 찾아가기 위해서는 UX 리서치가 정말 필요하다는 것을 느꼈다. 많은 수를 대상으로 하는 UX리서치를UX 리서치를 할 수 있으면 좋겠지만, 어떤 인사이트나 혹은 개선점을 찾기 위해서는 작게라도 UX 리서치를 해야겠다는 생각을 하게 되었다. 비록 적은 수의 고객이더라도 그들이 가진 실제적인 문제를 듣는 것에서부터 시작해야 진정한 고객 중심적 접근이 될 수 있을 것이다. 

  이후 설문조사로 UX 2차 리서치를 하여 조금 더 넓혀 대상을 확대하여 초기에 세운 가설이 틀렸다는 것을 다시 한 번 확인하고 '연구자들은 구직을 할 때 정보의 부제로 인하여 어려움을 겪고 있기 때문에 채용  기관을 추천해주는 서비스가 있다면 문제를 해결하기 위해 사용할 것이다.'는 새로운 가설을 세우게 되었다.

  이 가설을 확인하기 위해 UX리서치 3차로 6명의 새로운 연구자들에게 인터뷰를 진행하였는데, 재미있게도 연구자들은 추천서비스에 대한 선호도가 낮았다. 이는 페르소나를 설정할 때 찾은 '신뢰도의 목숨을 건다'라는 특징과 잘 맞아떨어지는 것으로 공신력 없는 서비스에 대한 신뢰도가 없기 때문에 추천을 믿지 못하겠다는 반응이 있었다.

  그렇기 때문에 기존 연구자 채용시장에서 일어나는 [지인을 통한 채용] 형태를 온라인에서 구현할 수 있다면 오히려 연구자들의 신뢰를 얻을 수 있을 것이라고 생각하여 '소셜 활동을 통한 채용 매칭'이라는 키워드를 떠올리게 되었다.

  PM 공부를 시작할 때 고객문제에 대한 정의가 가장 중요하지만, 어렵고 오래 걸린다는 이야기가 있었는데 정말 그러했다. 또한 방향성이 180도 변하니 시장조사, 페르소나, 유저 저니가 완전히 달라지게 되어 새로 설정을 해야 했다. 고객 문제를 제대로 정의하지 못했기 때문에 일을 추가적으로 진행해야 한 것이다. 아무리 시간이 걸리더라도 실제 잠재 고객이 가진 문제를 정의하는 것을 우선으로 하고 중요시 여겨야 하는 말이 확실히 와닿는 순간이었다고 할 수 있다.

 

(3) 페르소나와 유저저니맵

  개인적으로는 UX 리서치를 기반으로 페르소나와 유저 저니 맵을 만드는 것은 고객을 다각적으로 볼 수 있는 계기를 만들어 준다고 생각하기 때문에 심여를 기울여 만들려고 노력한다. 

  또한 어떤 Task나 시나리오를 작성해 고객이 어떻게 반응을 하는지를 예측해보고 거기서 나오는 Pain point를 이해하는 것이 서비스의 방향성, 개선점을 찾을 수 있는 단초를 제공하기 때문에 더 자세히 구체적으로 적어보려고 노력하는 것이다.

  페르소나와 유저저니맵을 협업을 통해 만들다 보니 다양한 시각을 통해 다각적으로 고객을 평가할 수 있다는 장점이 있었지만 단점으로는 이러한 다양한 시각이 서비스의 방향성, 개선점을 찾는데 도움이 되지 않을 수 있다는 생각이 들었다. 조금 다른 말로 하자면 불필요한 디테일이 너무 많다는 것이다.

  물론 서비스의 기획, 사업의 시작 단계에서는 과한 정보가 있어야 할지도 모른다. 왜냐하면 아직 방향성이 확실히 되지 않았기 때문이다. 하지만 어느 정도 PMF를 찾은 서비스, 혹은 개선점을 찾는 서비스들은 이런 페르소나를 조금은 방향성을 생각해서 나누어 생각해 봐야 할 것 같다. 여기서 유저 세그먼트를 통해 충성도가 있는 고객들의 대표 페르소나, 신규의 대표 페르소나 등 하나의 페르소나가 모든 고객을 대표하는 것이 아닌 각각의 특성에 맞게 페르소나를 설정하고 유저 저니 맵 혹은 유저 스토리를 통해 백로그를 쌓아 가야 할 것이다.

  개인적으로는 이런 페르소나를 설정하는 것과 유저 저니 맵, 유저 스토리를 작성하는 것을 좋아하기도 하고 세분화하는 것을 선호한다고 생각을 했었는데 이번 프로젝트를 통해 확인을 할 수 있었다.

---

  앞으로 남은 2주 동안 디자인 프로세스의 남은 2단계 Develop과 Deliver 중 Develop에 대한 내용을 다루게 될 것이다. Develop에서는 솔루션을 찾고, 실제적인 제품에 대한 백로그를 찾는 과정이 될 예정이다.

 

제가 공부하고, 이해해본 PM에 관련된 내용을 포스팅으로 남깁니다.
잘못된 생각이나 혹은, 이견, 참고자료 등은 댓글로 남겨주세요.
감사합니다