by
Feb 27. 2022
문제 해결 관점에서 바라보는 프로덕트 팀의 일
하는 건 달라도 결국 사용자의 문제를 해결한다
프로덕트는 사용자가 '문제'를 해결하는 수단이다
인생은 늘 고민과 문제의 연속이다. 그리고 비즈니스도, 프로덕트도 문제의 연속이다.
그러나 여기서 '문제'란 비단 심각한 서비스 오류, 강경한 고객 불만 접수를 이야기하는 게 아니다. 이는 고객의 니즈 needs 혹은 페인 포인트 pain point를 이야기한다. 일상 혹은 어떤 특정 상황에서 무언가를 하고 싶지만 하지 못해 발생하는 간극, 아쉬움, 불편함 등. 그리고 모든 비즈니스는 이를 해결해주고 그 대가로 보수를 제공받는다.
가령 구직자를 위한 채용 공고 서비스라면, 구직자인 사용자는 '주변에서는 채용 공고를 모아서 볼 수 없는 불편함'이라는 문제 혹은 페인 포인트를 경험한다. 그렇다면 서비스는 우선 채용 공고를 모아 게시하고 주기적으로 업데이트함으로써, '채용 공고를 모아서 볼 수 없다'는 문제를 해결한다.
그리고 나아가서는 '매번 서비스에 로그인해야만 볼 수 있어서 공고를 놓친다'는 문제를 push알림이나 이메일 콘텐츠 등을 통해 해결하거나, '공고도 확인했고 지원도 했는데 이력서 확인 여부를 모르겠다'라는 문제를 인사담당자와의 메시지 기능을 통해 해결한다.
1. 사용자는 일상 혹은 어떤 특정한 상황마다 문제-불편함, 아쉬움, 간극-를 겪는다.
2. 프로덕트는 사용자가 그 문제를 해결할 수 있도록 서비스, 기능, 디자인 등을 제공한다.
3. 사용자는 프로덕트를 통해 문제를 해결한다.
4. 프로덕트 덕분에 문제가 해결된 사용자는 그 대가로 보수를 제공한다.
즉, 프로덕트는 사용자가 자신의 문제를 해결하는 데 사용하는 수단이다.
프로덕트 팀은 사용자가 문제를 해결할 수 있도록 돕는다
이처럼 프로덕트는 사용자가 겪고 있는 문제 problems를 해결 solve 함으로써 가치 value를 제공하는 수단이기 때문에, 프로덕트의 팀원이 하는 일은 사용자가 문제를 해결할 수 있도록 돕는 팀이다. 프로덕트 팀의 구성원이 마주하는 모든 사건과 업무, 역할과 논의는 모두 이 맥락에서 생각해볼 수 있다.
PM 혹은 기획자의 일
통상적으로 PM 혹은 서비스 기획자가 하는 일은 아래와 같다(고 한다. 무엇이든 회사마다, 조직마다, 팀마다, 때마다 다르니 100%는 당연히 아니다)
1. 우리의 사용자가 누구인지 발견, 정의한다
2. 그들이 겪는 문제/페인 포인트가 무엇인지 발견, 이해, 정의한다
3. 그중에서 어떤 문제를 풀 것인지, 왜 풀 것인지 정의하고 공유, 설득한다
4. 서비스 내에서 사용자가 해당 문제를 풀 수 있는 기능, 정책을 기획하고 정의한다
5. 이 문제를 해결함으로써 결과적으로 비즈니스 목적 (매출, MUV 등) 이 달성되도록 돕는다
결국 PM 혹은 서비스 기획자가 하는 일은 누구의 문제를, 왜, 그리고 어떻게 풀 것인지를 정의하는 일이다.
그러다 보니 일상의 업무 시간에는 자연스럽게 아래의 일들을 하게 된다.
1. 풀어야 할 문제를 발견하거나 혹은 사용자를 정량적으로 알기 위해 GA, Amplitude를 살펴본다
2. 풀어야 할 문제를 발견하거나 사용자를 정성적으로 알기 위해 voc 접수 내역 등을 살펴본다
3. 풀어야 할 문제라고 생각되는 것에 대해 심층적으로 알기 위해 고객 인터뷰를 진행한다
4. 당면한 문제를 제대로 이해하고 해결하기 위해 무엇을 알아야 할지, 무엇을 살펴보거나 인터뷰해야 할지 가설을 세우고 수정해나간다
5. 우리 고객에게는 이런 문제가 있고 이것을 해결할 수 있도록 돕는 게 왜 중요한지 근거를 마련하고, 이를 공유, 설득한다
6. 그걸 언제, 어떻게 풀어나갈 것인지 유관자(타 부서, 팀 내 구성원 등)들과 논의하고 조율한다.
7. 그걸 풀 수 있는 기능을 설명하고자 와이어프레임, 스토리보드, 유저 스토리 정책 문서 등을 작성한다.
8. 이걸 하는데 참고할 아이디어를 찾고자 레퍼런스를 살펴본다
그러나 아쉽게도 서비스 기획 취업을 희망하는 이들에게 나온 강의, 교재의 대부분은 1번, 또는 7번과 8번에 집중되어 있다. tool을 다루는 법을 알려주거나, 문서를 만드는 데의 노하우, 디테일, 프레임워크를 알려준다.
그건 어디까지나 맨 마지막에 나오는 문서일 뿐이다. 옆 사람 붙잡고 물어봐서 인수인계받으면 되거나, 한 두 번 혼나가며 배우면 마는 일이다. "N연차 서비스 기획자는 이렇게 문서를 관리합니다", "000의 PO의 템플릿 30종 공유" 같은 식의 강의들. 혹은 문제 해결 관점이 빠진 채 다른 서비스의 서비스 흐름만 베껴가며 만드는 스토리보드 등. 그걸 포트폴리오로 만들어주고, 제출하라는 조언들.
문제를 제대로 발견하고, 정의하고, 이를 위해 가설을 세우고 수정해나갈 수 있는 논리력과 고객 중심적 사고만 있다면, 와이어프레임/스토리보드 따위는 온보딩 기간에 사내 양식에 맞춰 만들면 그만 아닐까?
나 역시 주니어이니 확신할 순 없다. 그러나 내가 PM으로 직무를 전환하며 본 면접은 컨설팅 면접에 가까운 면접이었고, 내가 PM 채용 인터뷰에 참여한다면, 나 역시 가설을 세우고, 문제를 발견하고 정의한 경험에 대해 물을 테다.
프로덕트 디자이너의 일
내가 디자이너가 아니기에 디테일한 건 알지 못한다. 그러나 프로덕트 팀의 관점에서, 아래의 내용이 핵심이자 본질, 그리고 우선순위라고 생각한다.
1. 우리의 사용자가 누구인지 발견, 정의한다
2. 그들이 서비스를 사용하며 겪는 문제/페인 포인트가 무엇인지 발견, 이해, 정의한다
3. 이 문제를 해결할 수 있다고 생각되는 디자인 가설을 제시한다
4. 제시한 디자인 가설이 실제로 그 문제를 해결하는지 검증한다.
5. 이 문제를 해결함으로써 결과적으로 비즈니스 목적 (매출, MUV 등) 이 달성되도록 돕는다.
적어놓고 보니 PM/기획자와 크게 다르지 않다.
고객을 이해한다는 관점에서 프로덕트 매니저와 프로덕트 디자이너는 다르지 않다고 생각한다.결국 프로덕트 디자이너가 하는 일은 고객이 우리 서비스에서 문제를 해결하는 과정에서 겪는 불편함, 아쉬움을 해결하는 UX와 UI를 설계하는 일이다. 문제를 해결하는 과정을 더 쉽게, 효과적으로, 직관적으로, 혼선 없이 만드는 UI를 통해 이용 경험 UX를 개선하는 일이다.
그러다 보니 일상의 업무 시간에는 자연스럽게 아래의 일들을 하게 된다.
1. 풀어야 할 문제라고 생각되는 것에 대해 심층적으로 알기 위해 고객 인터뷰를 진행한다
2. 이 문제를 해결할 수 있다고 기대되는 디자인 가설을 만들어, 이를 확인하기 위해 Usability Test 등을 진행한다.
3. 테스트 결과에서 인사이트를 도출해 이를 공유하고, 디자인에 수정/반영한다.
4. 변경된 디자인이 실제로 고객의 문제를 더 잘 해결해주는지 지표를 확인한다.
5. 이 과정에 참고할 아이디어를 찾고자 레퍼런스를 살펴본다
다만 앞에선 PM/기획자에게는 특정 프레임워크, 문서 양식을 가르쳐주는 강의나 레퍼런스를 피상적으로 살펴보는 연습에 대해 다소 회의적인 의견을 적었지만, 디자인에서는 일부 필요한 것 같다. 구체적인 툴을 다루며 결과물을 만들어야 하고, 시각적인 산출물에는 일종의 트렌드 혹은 통용되는 기준이 존재하니까.
프로덕트 개발자가 하는 일
이 역시 나는 디테일하게 잘 알지 못한다. 그러나 결국 프로덕트를 통해 사용자의 문제를 해결하는 걸 돕는다, 는 관점에서 개발자의 일은 결국 아래와 같이 정리할 수 있다고 생각한다.
1. 고객이 문제를 해결하는데 필요한 기능이 제대로 구현되도록 한다. 제공하기로 한 가치를 안정적으로 제공한다.
2. 제공하기로 한 가치가 갑작스레 제공되지 않는 경우, 이에 대응한다.
3. 더 많은 문제를, 더 빠르고 효율적이면서도 안정적으로 제공할 수 있는 환경, 인프라, 구조를 설계하고 이를 관리, 업데이트한다
주니어 PM으로써, 그것도 개발 백그라운드가 없는 PM으로써 이 영역에 대해서는 정말로 디테일하게 아는 바가 없기에 길게 적을 것은 없다.
그러나 한 가지 단언하는 건, 개발이라고 해서 프로덕트를 통해 고객의 문제를 해결한다, 라는 관점에서 결코 벗어날 수 없다는 점이다. 고객의 문제를 해결하지 않는데, 그런 서비스는 왜 필요하겠으며 그런 서비스를 구현하는 개발 역시 왜 필요할까.
프로덕트 팀이 하는 일은 사용자가 문제를 해결할 수 있도록 하기 위함이다
팀이 함께 하는 업무, 논의, 미팅도 모두 같은 맥락에서 이해해볼 수 있다.
1. 아이데이션
: 사용자의 문제를 발견하고 정의한 뒤, 이걸 잘 해결할 거라고 생각되는 아이디어를 취합하는 방식이다
2. I.C.E. (Impact, Confidence, Ease)
: 아이데이션을 통해 언급된 여러 아이디어 중, 진행 여부와 우선순위를 결정하기 위한 기준이다. 어떤 아이디어가 고객의 문제를 더 많이 해결할 거라고 생각하는지 (Impact), 해결할 확률이 높다고 기대하는지 (Confidence), 좀 더 빠르고 안정적으로 해결할 거라고 생각하는지 (Ease) 생각해보는 과정이다.
3. 신규 서비스 기획
: 현재 제공하고 있는 제품 외에, 시장에 존재하는 고객과 그들의 문제/페인 포인트 중 아직 해결하지 못하고 있는 걸 해결하기 위해 고안한 제품이다.
4. 리뉴얼
: 현재 제공하고 있는 제품이 기대만큼 고객의 문제를 해결해주지 못하고 있다고 생각되어, 이를 개선해서 고객이 좀 더 쉽게, 빠르게, 편리하게 문제를 해결하도록 하는 업무다.
5. Hot-fix
: 고객이 문제를 제대로 해결하지 못하는 상황이 발생해 긴급하게 대응하는 일이다.
6. GA / Amplitude / SQL / 히트맵
: 고객이 어떤 문제를 겪는지 정량적으로 추정하기 위해 살펴보는 일이다.
7. VOC 이해 / 고객 인터뷰
: 고객이 실제로 어떤 문제를 겪는지, 어떤 맥락에서 겪는지 심층적이고 정성적으로 이해하기 위해 하는 일이다.
8. UT
: 우리가 의도한 대로 고객이 프로덕트를 통해 문제를 쉽게, 빠르게, 편리하게 문제를 해결하는지 확인하는 일이다.
