원문
14 questions to ask as a Product Manager
https://medium.com/design-bootcamp/14-questions-to-ask-as-a-product-manager-bf7382c75928
14 questions to ask as a Product Manager
There are no technical requirements to be a product manager. You don’t need a fancy degree, or to pass a certification exam that tests for…
bootcamp.uxdesign.cc
PM으로서 물어야 하는 14개의 질문
특별한 기술이 있어야만 PM이 될 수 있는 것은 아니다. 뛰어난 학위가 필요한 것도 아니고, 분야에 대한 깊은 지식을 검증하는 자격시험에 통과해야 하는 것도 아니다. 다양한 배경을 가진 사람들이 PM이 되고, 때로는 사람들과 일하며 문제 해결하는 것을 좋아해서 PM이 되기도 한다.
그러나 프로젝트를 관리하는 일은 때로 무척 정신 없이 진행되는 것처럼 느껴지기 때문에 처음에는 어려울 수 있다. 당신은 불완전한 정보 속에서 중요한 결정을 내려야 한다. 복잡한 요구사항들을 취합하고 깊은 논의를 나누기에는 시간이 부족하다. 당신은 다른 사람들이 실제로 작업을 완료할 수 있도록 구조를 만들어야 하며, 어딘가 서로 아귀가 맞지 않는다면 그 책임은 당신에게 있다.
다행히도 당신의 삶을 훨씬 쉽게 만들어줄 신묘한 트릭이 하나 있으니, 바로 질문을 하는 것이다.
올바른 질문은 언제나 상황을 명확히 하고, 당신을 바른 방향으로 전진시킨다. 이 아티클에서 우리는 제품에 대한 가상의 문제를 다룰 것이다. 그에 대해 요구사항 수집부터 해결책 제시에 이르는 동안 14개의 질문을 던지고, 실행과 후속 조치까지 하는 것으로 끝맺을 것이다.
여기서 소개되는 질문들은 내가 PM으로서 매일 그대로 사용하고 있는 것들이다. 여러분에게도 이 내용이 도움이 되기를!
요구사항 수집
자, 상황을 설정해보자. 당신은 온디맨드(on-demand)로 고양이 사료를 배달하는 멋진 기술 스타트업의 새 PM이다. (제법 괜찮지 않은가?) 지금은 월요일 아침이고 비트감 있는 lo-fi 음악이 퍼지고 있다. 슬랙의 알림음이 '띵' 들려오고, 그것을 열어 운영팀 현업의 질문을 받는다.
- 잠깐 이야기 괜찮아요?
- 앱에 대해서 라이더들의 컴플레인이 많이 접수되고 있는데, 이 문제에 대해 얘기를 나누고 싶었어요.
"네, 그럼요. 시간 괜찮아요."
- 좋아요, 오후에 초대 보낼게요!
[Side note : 대화가 시작되는 동안 말해두자면, 이 질문들은 시간에 걸쳐서 여러 사람들에게 주어진다. 정확한 워딩은 당신이 대화하는 상대에 따라서 달라질 수 있다.]
1. 무엇이 문제인가?
개방형 질문으로 시작하는 것은 사람들이 자신의 말로 최대한 많은 정보를 당신에게 주도록 독려한다. 가능하다면 그들이 말하는 동안 노트를 작성하는 것이 좋다. 어떻게 진행되는지 보자.
나 : 그러니까, 지금 문제가 뭐예요?
운영 현업 : 어젯밤에 자전거 사고를 낸 사람이 있는데, 핸드폰이 너무 밝아서 그랬다네요. (화면이 어두운) 구글 지도를 보다가 주문 정보를 보려고 앱을 바꾸면서 주변을 볼 수 없었대요. 다친 곳은 없어요. 그런데 이런 일이 몇 번 있었어요. 라이더들이 앱에 불만을 많이 하고 있는데, 가야하는 길이 잘 안 보인다는 거죠.
2. 현재 상태는 어떠하고 이상적인 상태는 무엇인가?
앞선 질문으로 많은 정보를 얻게 될 것이고, 다음 작업은 그것을 풀어내고 단순화하는 것이다. 지금 어떻게 돌아가고 있고, 누가 어 변화를 요구하고 있는가에 대한 기준선을 세우는 것은 유용한 방법의 하나이다. 나중에 user flow(즉, 일련의 동작들)로 이것을 묘사하는 것이 좋다.
나 : 라이더들이 밤에 우리 앱을 사용하는 행태는 어떻고, 그래서 당신 생각에는 어떤 변화가 필요하죠?
운영 현업 : 날이 어두워지면 라이더들이 대체로 화면 밝기를 낮추는데, 그러면 주문 상세 정보가 안 보이는 것 같아요. 그래서 라이더들은 화면이 눈부시지 않으면서도 중요한 내용을 볼 수 있는 '다크 모드'를 원하고 있어요.
3. 내가 제대로 이해한 게 맞는지 확인해도 될까요?
누군가 당신에게 설명한 문제가 복잡한 것이라면, 당신이 이해한 내용을 다시 확인하는 것이 좋다. 그렇게 함으로써 당신이 추정하는 내용이 맞는지 확인하고, 당신이 놓친 것이 없는지 점검할 수 있다(팁 : 좋은 관계 형성에도 도움이 된다.). 나중에 당신은 이 이슈와 잠재적인 해결책을 많은 사람들에게 소개하게 될 것이므로, 그것에 대해 어떻게 소통할지 익혀두기에도 좋을 것이다.
나 : 내가 제대로 이해한 게 맞는지 확인해도 될까요? 그러니까, 화면이 너무 밝아서 운전자들이 밤에 우리 앱을 쓰기 어렵고, 그래서 사고가 발생한다는 거죠. 당신이 필요하다고 말한 다크 모드는 이동 중에도 주문 세부 정보를 볼 수 있는 상태인 거고요.
운영 현업 : 그런 셈이죠. 그리고 우리 앱과 내비게이션 앱 간에 전환할 때도 모드가 잘 작동해야 돼요.
4. 이 문제는 어떤 영향을 끼칠 수 있는가?
이 질문을 통해서 이 문제가 독립적인 사건인지 반복적인 패턴인지 이해해야 한다. 더 나아가 사용자, 수익 또는 다른 주요 지표의 감소 측면에서 이 문제의 심각성을 정량화하는 것이 좋다.
나 : 라이더가 줄거나 비용이 발생하는 등 문제의 영향에 대한 자료가 있나요?
운영 현업 : 음, 라이더들의 보험료랑 병원비를 우리가 내고 있는데, 그게 좀 비쌀 때가 있어요. 그리고 라이더들 대상으로 사용 패턴에 대한 설문조사를 했는데, 30%가 저녁에는 다른 앱을 사용한다고 했어요. 더 확인해보니, 우리 앱이 안전하지 않기 때문이라는 거죠.
[Side note : 이 모든 정보는 추후에 데이터 분석을 통해 검증하는 것이 좋다.]
5. 이것은 우리가 당장 해결해야 할 가장 중요한 문제인가?
문제를 이해했다면, 당신이 수행하고 있는 다른 모든 일과 비교한 이것의 우선순위를 정해야 한다. 만약 이것이 명확하고 심각한 효과가 있거나, 더 넓은 회사 목표와 관련이 있다면 중요하게 다루어져야 한다. 또한 이를 이해관계자와 회사의 나머지 사람들에게 알리고 설득할 준비를 해야 한다. 그러니 이것은, 스스로에게 가장 먼저 물어야 할 질문이다.
나 : 이것은 우리가 지금 당장 해결해야 할 가장 중요한 문제인가?
또 다른 나 : 좋은 질문이야 나 자신. 우리는 이번 분기 프로젝트 먼저 끝내야 돼. 그 다음의 일로는, 백로그가 대부분 기술 부채(tech debt)에 대한 것이고, 라이더의 온라인 시간을 늘리는 것이 다음 분기의 OKR이기 때문에 이 문제를 우선시할 수 있어. 다음 4주 동안 솔루션의 범위를 정하고 그 후에 개발을 시작하자.
해결책 제시하기
문제를 충분히 이해했다면(나아가 데이터 분석, 조사 및 UX 테스트로 뒷받침된다면), 이제 해결책을 다룰 차례다. 프레젠테이션 작성을 시작하면서 팀의 도움을 받아 몇 가지 중요한 질문에 답하는 것이 좋다.
6. 우리가 만들어야 하는 이상적인 사용자 경험은 무엇인가?
이제 창의력을 발휘해서 사용자들의 입장이 되어보고, 가능한 최고의 사용자 경험을 상상해보자. 기술적인 제약이나 비용은 아직 생각하지 말자. 그것은 나중의 일이다.
이 단계에서는 보도자료와 FAQ(자주 묻는 질문)를 작성하는 것이 도움이 될 수 있다. 최종 사용자에게 기능을 설명하는 가상의 보도 자료를 작성하는 것은 Amazon에 의해 대중화된 방식이다.
나 : 우리가 만들어야 하는 이상적인 사용자 경험은 뭘까요?
디자이너 : 라이더의 휴대폰이 밝기를 감지해서, 차 안처럼 주변이 어두워지면 자동으로 다크모드로 바뀌는 게 좋겠죠. 그게 기본 설정이고, 라이더가 자동 전환 설정을 끄고 수동으로 전환할 수도 있을 거예요. 라이더가 서비스에 가입할 때 자동 또는 수동 중에 선택할 수 있게 하고, 웹사이트에서도 그 기능을 강조하면 좋을 것 같아요.
7. 문제 해결의 성공을 어떻게 측정할 것인가?
다음으로, 현재 측정할 수 있는 단일 지표을 선택해야 한다. 지표는 해결하려는 문제와 연관되어 있으며 쉽게 조작할 수 없는 것이어야 한다. 나중에 이를 사용하여 기능이 성공했는지 여부를 확인하게 될 것이다.
나: 문제가 해결되었는지 어떻게 알 수 있을까요? 성공을 어떻게 추적하면 좋을까요?
분석가 : 주 목표는 저녁 시간대의 접속 시간을 늘리는 거예요. 우리 앱을 사용하는 게 더 안전하다고 느끼게 된다면, 타사 앱으로의 이탈이 줄어들겠죠. 그리고 이 기능을 활성화하는 라이더의 비율과 월간 만족도 조사 점수도 계속 주시할 거예요. A/B 테스트를 실행하면 결과를 확인하기 좋을 겁니다.
8. 이 기능을 구현할 수 있는 선택지로는 어떤 것들이 있는가?
이것은 특히 디자이너, 엔지니어링 매니저를 포함해 모든 팀과 나눠야 할 대화이다. MECE(mutually exclusive, collectively exhaustive; 중복 없이 누락 없이) 원칙을 사용해 선택지의 전체 리스트를 작성해 보자. 그리고 시간을 들여 각각의 장단점을 논의해 보자. 하나 혹은 두 개의 선택지가 유력한 후보로 명확히 드러날 수도 있다.
나 : 이 기능을 구현할 수 있는 방법은 어떤 것들이 있을까요?
테크리드 : 몇 가지 방법이 있을 것 같아요.
1. 앱의 색 조합 전체를 다크모드로 바꾸고 사용자에게 전환을 허용하지 않는 거예요. 가장 빠르지만 최선의 UX는 아니죠.
2. 자동으로 색을 전환하는 자동화 라이브러리를 사용할 수 있고요.
3. 색 조합 두 개를 정의하고, 시스템 설정을 통해서 사용자가 라이트모드/다크모드 중 선택하도록 할 수 있어요.
4. 기타 등등
[Side note : 이것들은 단지 예시이다. 당신이 다크모드를 어떻게 구현해야 할지 실제로 조사한 것이 아니다.]
9. 사용자들은 우리의 잠재적인 해결책과 어떻게 상호작용할까?
여건이 된다면 이 질문이 도움이 될 수 있다. 최초의 어프로치를 결정했다면, Figma나 기타 디자인 툴로 제작한 프로토타입을 사용자들이 사용해보도록 하고 어디에서 어려움을 겪는지 관찰하자. 회사 내에서 사용자들과 특히 밀접한 구성원들을 대상으로 수행해도 좋다.
나 : 우리의 잠재적인 해결책에 대해서 사용자들은 어떻게 생각할까?
UX리서처 : 사용자들은 메인 네비게이션 메뉴에서 다크 모드가 제공되는 것을 원하고 있어요. 그렇지만 프로필 페이지에 대해서는 예외예요. 자신들의 뱃지가 잘 진열된 모습을 보고 싶어하거든요. 그리고 대부분의 사용자는 주변이 어두워질 때 자동으로 다크모드로 전환되는 것에 긍정적이에요.
10. 우리의 해결책은 얼마나 걸리는가? 그리고 이를 더 저렴하게 구현할 수 있는 방법이 있는가?
전반적인 어프로치를 결정했고, 프로덕트의 스펙에 대한 초안을 잡았다. 이제 가격을 확인할 차례다. 엔지니어링 매니저에게 얼마나 걸릴지 현실적인 추정치를 요구하자. 세부 작업별 추정이 필요한 것은 아니고, 주/월 단위 답변이면 충분하다.
만약 초기 구현이 너무 오래 걸린다면, 80-20 rule을 사용해서 이행 범위를 과감하게 축소하도록 하자. 최소한의 솔루션으로도 핵심은 전달할 수 있으며, 그밖의 '있으면 좋은' 요건들은 다음 버전을 위해 남겨두어도 괜찮다.
나 : 우리 해결책을 구현하는 데는 얼마나 걸릴까요? 그리고 이를 더 저렴하게 구현할 수 있을까요?
테크리드 : 전부 다 하려면, 회귀 테스트(regression testing)와 앱 스토어 출시를 포함해서 약 6-8주 필요해요. 만약 자동 야간 감지 요건을 제외한다면, 3-4주로 단축될 거예요.
실행 및 회고
프로젝트를 훌륭하게 디자인하고 범위를 정했다면 이제 구축을 시작할 시간이다!
11.자신이 무엇을 해야하는지 모두가 알고 있는가?
신규 기능의 개발을 시작하는 시점에, 사양을 제시하고 중요한 질문에 대해 논의하는 짧은 킥오프 미팅을 갖는 것이 좋다. 이 자리에서는 이해도를 확인하는 것이 매우 중요하며, FO(feature owner)를 지정하는 것도 도움이 될 수 있다(일반적으로 해당 기능에 대해 가장 많은 작업을 수행하는 개발자를 FO로 지정한다).
나 : 자신이 무엇을 해야하는지 다들 알고 있죠?
모바일 개발자 : 세부적인 케이스들에 대해서 고려가 더 필요해요. 사용자가 라이트 모드에서 시스템 얼럿을 받게 하면 어떨까요?
12. 이 기능에 대해서 동료 그리고 사용자에게 어떻게 전달할 것인가?
사용자를 대상으로 하는 변화에는 그것을 사용자에게 알리는 과정이 필요하다. 6번째 질문에서 작성한 보도자료와 FAQ가 도움이 될 것이다. 월간 뉴스레터에 글을 한 문단 싣는 정도가 될 수 있고, 웹사이트의 재구축이 될 수도 있다. 또한 릴리스의 영향을 받게 될 내부의 팀에게도 미리 알려야 한다.
나 : 이 기능에 대해서 동료들 그리고 사용자에게 어떻게 전달할까요?
마케터 : 라이더 랜딩페이지에 스크린샷을 몇 개 추가하면 좋을 거예요. 그리고 월간 프로덕트 업데이트 이메일에도요.
13. 초기 데이터는 어떠한가?
개발이 완료되고 (바라건대) 큰 문제 없이 기능이 출시되었다면, 즉시 통계를 확인하자. 중요한 이벤트를 추가하는 것을 잊었거나 이상한 버그가 발생하여 자료가 정상적으로 수집되지 않을 수 있다. 제대로 작동하는 것으로 확실시된다면, 데이터의 양이 유의미한 수준에 도달할 때까지 기다려 보자(A/B 테스트를 실행하고 있다면, 유의미한 통계가 나올 때까지).
나 : 초기 데이터는 어때요?
분석가 : iOS 반응은 무척 긍정적이에요. 운전자 절반이 사용하고 있어요! 안드로이드는 그보다 10% 정도 낮은데, 디자인에서 뭔가 놓친 게 있을까요?
14. 다음 단계는 무엇인가? 어떻게 이것을 더 개선할 수 있는가?
어려울 것 없다. 앞선 질문에 대한 답으로부터, 어떻게 개선할 것인지 제법 명확한 아이디어를 얻을 수 있었을 것이다.
나 : 모두 잘했어요! 이제 다음 버전을 생각해 봅시다. 어떻게 개선해야 할까요?
디자이너 : 강조색을 바꾸죠.
분석가 : 안드로이드에서 일어나는 버그를 해결해야 해요.
엔지니어 : 기술 부채들을 처리해야 해요.
아아아아ㅏㅏㅏ 그럼 여기까지!
맺는 말
앞서 우리는 14가지 질문과 그 질문에서 도출된 답변이 어떻게 복잡한 문제를 구조화하고 효과적인 해결책을 정의하는 데 도움이 되는지 살펴보았다.
살펴본 것처럼, 올바른 답을 갖고 있는 것보다는 올바른 질문을 던지는 것이 더 중요하다. 질문을 던지고 답을 구하는 과정에서, 종종 자신의 지식에는 생각보다 중대한 공백이나 숨겨진 추정이 있다는 것을 발견하게 된다. 이것은 그 자체로 하나의 즐거움이 된다.
질문을 던지는 것은 협업을 위한 중요한 도구이다. 자신이 뭔가를 모른다는 것을 인정함으로써 해결책을 함께 찾기 위해 다른 사람들을 초대하는 것이다. 그때, 사람들은 당신이 마이크로매니징을 하는 것이 아니라, 전문성을 존중하는 것으로 느끼게 된다.
그럼, 도움이 되었기를!
'IT 블로그 > 아티클·정보' 카테고리의 다른 글
| [번역] ERP가 중요한 8가지 이유 (3) | 2024.09.29 |
|---|---|
| [번역] UX라이팅의 16가지 규칙 (0) | 2024.02.04 |
| [번역] 7가지 검증된 UX 리서치 기법의 특징과 장점 (0) | 2023.09.24 |
| 개명하면 CI, DI가 변경될까? - CI,DI의 개념과 특징 (0) | 2022.09.06 |
| [번역] UX를 측정하기 위한 5가지 지표 (0) | 2022.03.18 |
댓글