PM은 모든 과정에 참여하는 사람입니다
유저를 사로잡는 서비스 기획의 모든 것에서 뽑은 54개의 핵심파트
흔히 사람들이 PM 하면 생각하는 업무들이 있다. 데이터 분석, 기획, 프로젝트 매니징, 운영, 커뮤니케이션 등등. 이 책은 사람들이 흔히 PM 하면 생각하는 업무들을 잘 나열해 놨다. 하나하나마다의 깊이가 넓다고 할 수는 없지만, 전반적인 흐름을 잘 보여주고 있다. 이 마저도 PM 같다고 할까.
책에서는 정말 다양한 업무를 PM이 한다고 해야 하지만, 사실 현업을 하다 보면 조직 상황에 따라 하지 못하는 일들이 훨씬 더 많다. 그래서 나 역시도 이 책에 나온 업무들을 모두 하지는 못한다. 그렇지만 이 책을 보면서 아 맞아 'PM은 이런 일도 하지', '이런 생각을 또 할 수 있어야 하지', '이런 관점으로 프로덕트를 또 사용자를 봐야 하지' 하는 생각을 다시 한번 할 수 있었다.
* '프로덕트: 유저를 사로잡는 서비스 기획의 모든 것'은 한빛미디어에서 리뷰 요청과 함께 보내주신 책이다. 리뷰 요청과 함께 받은 책이라고 해서 특별히 더 좋게 쓴 부분은 없다. 이전에 쓴 여러 글처럼 좋다고 생각한 부분만을 편집하고, 요약했다.
사용자 중심 기획
PM의 역할과 범위
1. 제품이란 ‘기능들의 조합으로 사용자가 목적을 달성하도록 도와주는 온라인 서비스의 총체'를 뜻합니다.
2. PM은 IT 제품과 서비스에서 사용자와 비즈니스가 가진 문제를 파악하고 가설을 세워 해결하는 역할을 합니다. 그리고 디자이너, 개발자와 협업하여 기획을 제품화하고 출시하기까지 모든 과정에 참여합니다.
3. PM은 사용자의 니즈를 꾸준히 파악하면서 기업의 비즈니스 가치도 높이는 방향으로 제품과 서비스를 개선합니다. 이 과정을 끊임없이 반복하죠. 즉, 이들은 제품, 서비스의 시작점인 기획부터 출시 후 관리까지 모든 과정을 함께합니다.
서비스 기획의 시작과 끝, 사용자 이해하기
4. PM의 업무 중 가장 중요한 일이 바로 ‘문제를 찾고 해결하는 것'입니다. 사용자가 불편함을 느끼는 지점을 찾아내고 해결하는 거죠. 이 업무는 새로운 서비스를 만들든 기존 서비스를 개선하든 반드시 필요한 과정입니다. 그리고 이는 사용자를 이해하는 데에서 시작합니다.
5. 시장에서 살아남는 제품과 서비스를 만들기 위해서는 프로덕트 핏과 마켓 핏을 이해해야 합니다. 프로덕트 핏이 ‘제품, 서비스가 사용자의 문제를 해결해 주는가'라면, 마켓 핏은 ‘사용자가 해당 제품, 서비스에 돈을 지불할 용의가 있는가'를 뜻합니다.
6. 보통 많은 제품, 서비스가 프로덕트 핏만 있고 마켓 핏까지는 검증하지 못해 지속적인 운영을 하지 못하는 경우가 많습니다.
서비스 기획부터 출시까지, 개발 방법론
7. PM은 백로그에서 사용자에게 임팩트가 높은 피처를 잘 선정하고 관리하는 능력을 갖춰야 합니다.
린 스타트업과 MVP
8. 시장 검증을 위해 개발한 최소한의 기능을 가진 제품이 MVP로, 사용자의 피드백을 수집하고 이를 바탕으로 다음 단계로 나아가는 것이 린 스타트업입니다. 이때 ‘최소한'의 의미를 오해해서는 안됩니다. 최소한이란 기능이 모자라다는 뜻이 아니라 시장에서 사용자의 니즈를 검증할 수 있을 정도의 최소한이란 뜻입니다. 즉, 제품으로 사용이 가능한 최소한의 조건을 갖추어야 합니다.
문제 해결을 위한 생각 도구들
9. 사람의 뇌는 의사결정을 하기 전에 감정적으로 먼저 설득이 되어야 행동으로 옮기게 설계되어 있습니다. 이는 제품이나 서비스가 아무리 좋아 보여도 왜 그것을 사용해야 하는지에 대한 공감이 없다면 행동으로 이어지지 않는다는 뜻입니다.
성공하는 제품을 위한 리서치
비즈니스의 목표와 시장 이해하기
10. 이해관계자들을 인터뷰할 때는 해결책이나 세부 기능에 집중하기보다 목표 고객은 누구인지, 해결하고자 하는 문제점은 무엇인지, 조직과 프로젝트의 목표는 무엇인지 등에 집중하는 것이 좋습니다.
리서치의 기본, 데스크 리서치
11. 데스크 리서치를 시작할 때는 현재 시장과 고객이 어디를 향하고 있는지 전체적인 흐름을 파악하는 것이 도움이 됩니다.
사용자의 니즈를 파악하는 리서치
12. 사용자 리서치는 사용자에 초점을 맞춰 리서치를 수행하는 반면, UX 리서치는 서비스 및 제품이 사용자와 상호작용 하면서 미칠 수 있는 모든 요소를 개선하는 데 초점을 맞춥니다.
인사이트를 분석하는 데이터 모델링
흩어진 데이터에서 인사이트 찾기, 어피니티 다이어그램
13. 어피니티 다이어그램은 앞서 인터뷰, 관찰 등으로 수집한 정성적, 정량적 데이터를 모아 패턴을 파악하고 그 안에서 인사이트를 도출하는 일종의 데이터 정리 기술입니다.
사용자를 대표하는 가상 인물, 퍼소나
14. 플랫폼을 기획할 때는 ‘Hard side’라는 개념을 활용하면 퍼소나의 우선순위를 쉽게 정할 수 있습니다. Hard side란 공급자/소비자, 콘텐츠 창작자/구독자, 운전자/승객, 호스트/게스트 등 양측을 연결하는 플랫폼에서 어떤 쪽을 먼저 데려오는 것이 비즈니스의 성공을 이끄는가에 대한 부분입니다. 더 데려오기는 힘들지만 이들을 데려오는 것이 핵심인 것이죠.
아이데이션을 통한 솔루션 도출과 우선순위
아이디어를 발산하는 워크샵
15. HMW(how might we)는 ‘어떻게 하면 ~할 수 있을까?’라는 질문을 던져 실행 가능한 해결책을 찾는 일종의 생각 도구입니다. HMW의 핵심은 사용자가 원하는 것이 무엇인지 더 구체적으로 질문하는 것입니다.
16. 주의할 점은 HMW 뒤에 오는 문장이 모호하거나 지나치게 제한되어서는 안 된다는 것입니다. 제품이나 서비스와의 연관성은 물론이고 문제 해결에 필요한 질문을 고민해야 합니다.
17. 크레이지 8(crazy 8)은 8분 안에 8개의 피처를 구상하는 방식으로, 아이디어 발산을 위한 생각 도구입니다. 번뜩이는 아이디어는 아이디어가 더 이상 떠오르지 않을 때까지 쥐어짜 냈을 때 나올 확률이 높습니다.
중요도에 따른 피처 우선순위 세우기
18. 우선순위를 정할 때는 자원 대비 사용자 가치를 고려해야 하기 때문에 가로축을 필요한 자원으로 설정하고 세로축은 사용자에게 제공할 가치의 크기로 설정합니다.
19. 피처의 우선순위를 제대로 세우는 과정은 전체 프로젝트에 중요한 영향을 줍니다. 한정된 시간과 인력으로 사용자에게 가장 가치가 높은 피처를 개발해야 사용자 경험도 개선하고, 제품/서비스가 시장에서 살아남을 확률도 높아지기 때문입니다. 이런 우선순위에 대한 의사결정을 잘하는 것이 프로덕트 매니저의 중요한 역할입니다.
솔루션의 방향성 정립하기
20. As is와 To be를 잘 정의하면 현재 사용자가 가진 문제가 무엇이고 어떻게 해결할 것인지 프로젝트의 전체적인 방향을 한눈에 확인할 수 있습니다.
서비스 기획 A to Z
피처를 구체화하고 팀을 일치시키는 유저 스토리
21. 유저 스토리란 쉽게 말하면 하나의 피처 단위를 설명하는 짧고 간결한 문장을 뜻합니다. 애자일 방법론을 적용한 조직에서는 유저 스토리를 이용해 구현할 피처들의 목록을 작성하고, 각 유저 스토리가 어느 정도의 복잡도와 범위로 구현되어야 하는지에 대해 내부 인원이 논의해서 효과적으로 컨센서스를 이끌어 낼 수 있습니다.
22. 유저 스토리는 짧은 문장이지만 다음의 3가지 요소를 포함해야 합니다. AS는 사용자, I WANT는 사용자가 하려는 행동, 즉 피처를 뜻합니다. 그리고 SO THAT은 사용자가 I WANT에서 한 행동으로 얻으려는 결과입니다.
23. 걸킨(gherkin)은 유저 스토리를 작성할 때 활용할 수 있는 일종의 구문 양식으로, 애자일 문화가 자리 잡은 조직에서 종종 사용하는 방법입니다.
24. 사용자 여정 지도(user journey map)는 사용자들이 제품이나 서비스를 처음 접하는 시점부터 사용을 끝내는 시점까지의 여정을 시각적으로 보여주기 때문에 전체적인 그림을 놓치지 않고 작업하는 데 도움이 됩니다.
25. 사용자 여정 지도를 작성할 때는 사용자가 제품/서비스를 이용하는 과정을 몇 개의 주요 단계로 나누고, 각 단계별로 만족도, 불편 사항, 니즈 그리고 개선할 기능 등을 정리하는 방식으로 구현합니다.
논리적 흐름을 그리는 유저 플로 & 와이어 프레임
26. 태스크 플로(task flow)와 유저 플로(user flow)는 사용자가 제품/서비스를 이용하면서 수행하는 작업과 화면의 흐름을 나타냅니다. 2가지 모두 흐름을 보여 준다는 역할은 같지만, 목적은 다릅니다. 태스크 플로는 분기나 오류를 고려하지 않고 큰 그림을 확인하는 것이 목표로, 높은 계정의 단계만 순서대로 나열합니다. 반면 유저 플로는 분기, 오류 그리고 피처를 구현할 때 필요한 사항까지 고려해 작성합니다.
27. 유저 플로의 역할은 제품/서비스의 흐름을 보면서 우리가 고려해야 할 사용자 경험과 발생하는 다양한 경우의 수를 고려하는 것입니다.
개발자에게 사랑받는 서비스 기획서 작성하기
28. 기획서는 말 그대로 소통을 위한 문서일 뿐 어떤 툴을 사용하느냐는 중요하지 않습니다. 기획 의도와 디자인을 개발자에게 잘 설명하는 것이 가장 큰 목표라는 점을 잊어서는 안 됩니다.
29. 에러 케이스(error case)란 특정 플로나 피처에서 발생할 수 있는 오류와 이에 대한 대응을 정리한 문서입니다. 에러 케이스와 기획서를 함께 작성해 두면 사용자가 오류를 일으킬 때 또는 기술적으로 오류가 날 때 사용자의 다음 행동을 제대로 된 방향으로 유도할 수 있습니다.
운영까지 고려한 백 오피스 기획하기
30. 백 오피스는 운영을 위해 설계, 개발하는 것이므로 화려한 디자인보다는 정보 구조나 가독성을 우선으로 고려하고 설계해야 합니다.
31. 백 오피스 설계에 익숙하지 않다면 대부분 데이터가 준비되어 있다는 가정하에 사용자 화면을 먼저 디자인하는데요. 이 경우 다양한 상황에 대응하기가 어렵습니다. 따라서 초기엔 항상 데이터가 없는 시작점부터 설계를 고려하는 것이 좋습니다. 실제 제품/서비스가 운영되려면 어떻게 데이터가 생성되고 이 데이터가 사용자에게 어떻게 보이는지 그리고 인터랙션 하는지 전체를 고려할 수 있어야 합니다.
사용자가 길을 잃지 않는 ‘정보 구조' 작성하기
32. 정보 구조(information architecture)는 정보의 성격이나 순서, 우선순위 등에 따라 구조화하는 것을 의미합니다. 잘 설계한 정보 구조는 사용자의 접근성을 높이고 사용자 스스로 길을 찾을 수 있도록 돕습니다.
33. 사용자가 유입되고 전환되는 과정은 결코 쉽지 않은 반면 이탈은 아주 쉽고 빠르게 이루어집니다. 이를 방지하기 위해서는 사용자가 진입하는 순간부터 명확한 정보 구조를 제공해 원하는 것을 빠르게 찾을 수 있도록 도와주어야 합니다.
피처의 완성도를 높이는 QA와 테스트 케이스
34. 개발 서버에서 1차 테스트가 완료되면 사용자가 실제로 사용하는 것과 동일한 데이터를 가진 환경인 스테이징 버전(staging version)으로 제품/서비스를 배포합니다. 스테이징 버전에서도 2차 테스트를 거치고 문제가 없다면 실제 사용자가 사용하는 운영 서버(프로덕션 서버)에 배포합니다. 이를 프로덕션 배포(production deployment)라고 부릅니다. 배포 후에는 회원가입이나 결제 등 가장 중요한 피처를 다시 한번 확인하는 스모크 테스트를 하기도 합니다.
35. 테스트 케이스는 100% 통과를 목표로 하지 않습니다. 부족한 부분이 있을 가능성을 염두에 두고 실무자들의 협업으로 보완해 나가는 것이 바람직합니다.
친절한 서비스의 완성, 사용성 테스트
사용성 테스트가 필요한 이유
36. 설계자와 사용자의 입장은 다르며 그 차이를 예측할 수 없는 경우도 많습니다. 이 차이를 줄이기 위해 가장 접근하기 좋은 방법 중 하나가 사용성 테스트(usability test)입니다. 사용성은 사용자가 제품/서비스에서 제공하는 정보를 얼마나 쉽게 인지하고 빠르게 목적을 달성하느냐를 가늠하는 척도입니다.
사용성을 높이는 ‘제이콥 닐슨의 10가지 휴리스틱 평가'
37. 문제를 해결하거나 발견하거나 빠른 의사결정을 위해 경험을 활용해 직관적으로 문제를 파악하고 결과를 예측해 의사결정을 내리기도 하죠. 논리적인 사고보다 직감적인 사고나 경험에 의해 축적된 의사결정 프로세스를 따르는 것을 가리켜 휴리스틱(heuristic)이라고 합니다.
38. 시스템 상태의 시각화는(visibility of system status)는 사용자에게 시스템의 현재 상태를 시각적으로 보여주는 것입니다.
39. 현실 세계를 반영한 시스템(match between system and the real world)은 사용자가 일상에서 접하는 것과 가깝도록 표현해서 친숙함을 주는 것입니다.
40. 사용자의 제어와 자유(user control and freedom)는 사용자에게 적절한 통제권을 주어 잘못된 행동을 스스로 바로잡을 수 있도록 하는 것입니다.
41. 일관성과 표준(consistency and standards)은 하나의 제품/서비스 또는 브랜드 안에서는 레이아웃, 색상, 톤, 매너 등을 유지하는 것입니다.
42. 오류 방지(error prevention)는 사용자가 실수를 하기 전에 미리 방지하는 설계입니다.
43. 기억보다 인지(recognition rather than recall)는 사용자가 기억해야 할 것들을 최소화하는 것입니다.
44. 유연함과 효율성(flexibility and efficiency of use)은 사용자의 숙련도에 따라 여러 가지 수행 방법을 준비하는 설계가 필요하다는 뜻입니다.
45. 심미성과 간결한 디자인(aesthetic and minimalist design)은 시각적으로 아름답되 군더더기 없는 디자인을 뜻합니다.
46. 사용자의 오류 인식/진단/제거 (help users recognize, diagnose, and recover from errors)는 오류가 발생했을 때 사용자가 스스로 문제를 파악하고 수정할 수 있도록 설계해야 한다는 뜻입니다.
47. 지원과 도움 문서(help and documentation)는 도움말이나 설명서와 같이 사용자가 어려움을 겪거나 궁금증이 있을 때 도움을 줄 수 있는 다양한 유형의 문서나 서비스가 제공되어야 합니다.
사용자를 움직이는 실전 심리학
행동경제학
48. 결핍(scarcity)은 적은 자원에 더 높은 가치를 부여하는 현상을 의미합니다. 보통 사람은 얻는 것보다 잃는 것에 대해서 더 크게 반응하는 경향이 있습니다.
49. 선택 과부하(choice overload)란 선택지가 지나치게 많으면 오히려 선택을 하기가 어려운 것을 뜻합니다. 사람은 의사결정을 할 때마다 에너지를 소비하는데, 이때 사용할 수 있는 에너지의 양은 무한하지 않습니다.
50. 피크엔드 법칙(peak-end rule)은 사람이 특정 경험을 판단할 때는 전체 상황을 떠올리기보다 감정적으로 절정이었던 순간과 마지막 순간을 기준으로 판단한다는 것을 뜻합니다.
사용자의 습관을 만드는 훅 모델
51. 훅 모델은 사용자가 제품/서비스를 한 번 사용하는 데서 그치지 않고 습관으로 형성되기까지의 과정, 즉 사이클을 뜻합니다. 훅 모델은 계기, 행동, 가변적 보상, 투자라는 4단계로 이루어져 있는데, 사용자가 이를 반복해서 경험하면 일상의 한 부분이 될 확률이 높다는 이론입니다.
데이터와 논리로 무장하기
데이터 중심으로 사고하기
52. 가설이란 ‘어떤 문제나 사안에 대해 가지고 있는 예측'을 뜻하고 지표는 ‘성과, 상태를 측정해 수치화한 것'을 뜻합니다.
53. 좋은 지표는 크게 3가지 특징이 있습니다. 좋은 지표는 상대적입니다. 좋은 지표는 이해하기 쉽습니다. 좋은 지표는 제품/서비스의 방향성과 우선순위를 결정하는 데 도움이 됩니다.
54. 사용자의 행동을 분석하고 지표를 개선하는 것은 끝없는 가설 검증의 과정이기도 합니다. 제품의 지표 성장은 시도하는 실험의 양이 결정한다는 통계도 있습니다. 실무에서는 한 번의 실험으로는 유의미한 결과를 얻지 못하는 경우가 흔하니 결과가 나오지 않아도 실망하기보다 논리적인 근거를 바탕으로 지속적으로 실험을 설계해 보기 바랍니다.
