제로베이스 PM 스쿨 수강생의 아티클 스터디입니다.
TL;DR
1. 정말로 “사용자 중심”으로 사고하는 방법이란, 사용자가 원하는 것들의 본질을 캐치해내는 사고 과정
2. 사용자 중심의 사고를 방해하는 또는 착각하는 3가지:
- 사용자의 가치가 아닌 나만이 느끼는 가치 또는 기능에 대한 만족에 취해서,
- 서비스의 궁극적인 목표와 비전과 가치가 아닌 정해진 일정에 쫒겨서,
- 배포에 그치지 말고 사용성 평가를 통해 실질적인 가치 제공을 하고 있는지 평가하지 않고 단순히 새로운 것을 만드는 것에만 그쳐서
3. VoC 등 사용자의 목소리 그 자체를 받아들이지 말고 사용자가 원하는 니즈의 근본적인 동기를 파악하고, 이에 대한 평가와 판단을 기준으로 서비스를 개선하라
Summary
사용자 중심으로 사고하지 못하는 근본적인 원인
본질을 벗어난 3가지 집착 때문
본질을 벗어난 3가지 집착
첫째, 사용자가 얻게 될 가치가 아닌, 당장 내가 만드는 기능에 대한 집착
둘째, 목표와 궁극적으로 추구해야 할 가치가 아닌, 정해진 일정을 맞추는 것에 대한 집착
셋째, 실제 프로덕트가 배포되고 나서 사용자들이 해당 기능을 통해 실질적인 가치를 얻었는지 확인하지 않고, 계속해서 새로운 것을 만들어야 한다는 집착
PM에게 '사용자 중심적 사고'가 중요한 이유
•
기술적으로 완벽한 프로덕트를 출시했다 하더라도 프로덕트의 가치를 공감하고 실제로 사용하는 사용자가 없다면, 그 프로덕트는 살아남을 수 없다.
•
결국 제품이 생존하려면 우리 프로덕트를 통해 사용자가 무엇을 얻고 싶어 하는지 아는 게 매우 중요
◦
우리 프로덕트에 관심을 갖는 사람들은 누구인지
◦
불편함을 감수하고서라도 우리 프로덕트를 사용하고 싶은 이유는 무엇인지
◦
우리 프로덕트를 위해 얼마큼의 비용 또는 노력을 지불할 수 있는지
◦
우리 프로덕트의 해결을 바라는 사용자의 문제는 무엇인지
프로덕트를 만들기 전: 우리 제품을 누가 좋아해 줄까?
익숙함을 버리고 프로덕트를 사용할 사용자 고민하기
•
사용자가 아닌 '언제'와 '어떻게'에 집중하면, 기존 경쟁자들을 이길 수 없는 무난한 프로덕트를 만들거나, 반대로 완벽을 기하는 바람에 출시가 늦어지기도
•
“우리 프로덕트가 출시됐을 때, 어느 정도의 불편함을 감수하고서라도 우리 프로덕트를 이용해 줄 의사가 있는 사용자는 누구인가?”
•
기존의 익숙함을 버리고 우리 프로덕트를 사용하고 싶은 이유가 무엇일지
•
모든 사용자를 충족시키는 것은 불가능하다
유저 인터뷰를 통해 요구하는 기능의 본질 파악하기
•
사용자 중심적 사고를 '사용자의 요청사항을 곧장 기능으로 만드는 것'이라고 생각한다면, 다음과 같은 문제가 발생
◦
사용자 요청 속에 숨어 있는 본질을 파악하지 않은 채, 다른 제품들을 벤치마킹하는 데에만 시간을 들입니다.
◦
그 결과, 사용자의 문제를 전혀 해결해 주지 못하는 잘못된 기능을 만들게 됩니다.
◦
사용자에게 '이걸 원한 게 아니었는데…'라는 피드백을 받고, 해당 기능은 실제로 사용되지 않습니다.
◦
내부적으로는 '만들어 달라고 해서 만들었더니 안 쓰네…'라는 생각으로 이어지며, 사용자에 대한 부정적인 피드백이 축적됩니다.
•
따라서 프로덕트 팀은 사용자로부터 개선 요청이 들어와도 바로 기능화하는 대신, 사용자를 대상으로 다음 내용을 파악하는 게 우선
◦
해당 기능을 만들어 달라고 요청하는 이유는 무엇인지
◦
해당 기능이 없어서 최근에 겪은 문제는 무엇인지
◦
해당 문제를 해결을 위해 현재는 어떤 식으로 프로덕트를 사용하고 있는지
•
위 내용을 바탕으로 사용자가 요청한 기능이 지금 겪고 있는 문제를 근본적으로 해결할 수 있는지, 만약 해결할 수 없다면 어떤 방식으로 접근해야 더 좋은 임팩트를 줄 수 있을지 고민하고 개선
•
예시
이번에는 온라인 주문 플랫폼을 예로 들어 볼게요. 주문 플랫폼을 통해 주문을 받는 한 사장님이 주문이 오면 바로 문자로 알려 달라는 기능을 요청했다고 가정해 보죠.
이 요청을 그대로 기능화한다면, 하루에 주문량이 1,000개인 사장님은 오히려 문자 때문에 불편함을 겪을 수도 있습니다. 이렇듯 '주문이 들어올 때마다 문자 보내주기'라는 목적은 달성했지만, 또 다른 문제가 생기는 꼴이 되는 겁니다.
◦
1) 해당 기능을 만들어 달라고 요청한 이유는 무엇인지→ 오후 7시 이후부터 오전 8시까지 들어온 주문을 확인하지 못해서 배송이 늦어지는 실수가 발생하기 때문에
◦
2) 해당 기능이 없어서 최근에 겪은 문제는 무엇인지→ 주문을 확인하지 못해서 7일 이상 주문 대기로 남아있던 상품 때문에 고객에게 클레임 생김
◦
3) 해당 문제를 해결하기 위해 현재는 어떤 식으로 프로덕트를 사용하고 있는지→ 주문이 없더라도 지속적으로 웹사이트에 들어가서 주문을 확인함
◦
이 세 가지 질문을 바탕으로, 사용자가 요청한 기능의 본질은 '주문 상태를 지속적으로 파악할 수 있는 기능' 임을 간파할 수 있습니다. 그리고 이를 가장 쉽고 간편하게 처리할 수 있도록 다음의 두 가지 기능을 제공할 수 있겠죠.
▪
매일 오전마다 특정한 시간에 들어온 주문들 중에 사장님이 바로 처리해야 하는 주문들을 문자로 전송하기
▪
처리되지 않은 주문들은 주문 리스트 상단에 배치되도록 변경하기
프로덕트를 만들면서: 우리 제품한테 무엇을 원할까?
목적을 달성할 수 있는 최소한의 조건으로 제품 만들기
•
Done is better than perfect(완성이 완벽보다 낫다)
•
사용자와 프로덕트 팀이 제품을 바라보는 관점을 맞추는 과정
•
'사용자는 이럴 것이다'라는 생각은 허상에 가깝다
◦
따라서 프로덕트를 만들면서 우리가 예측한 사용자들의 피드백과 실제 프로덕트의 피드백은 절대로 100% 일치 불가능!
◦
완벽한 프로덕트를 만드는 것은 불가능!
•
사용자가 목적을 달성할 수 있는 최소한의 조건에 집중
완료 기준을 '배포'가 아니라 '사용자 피드백'으로 잡기
•
꼭 새로운 기능을 만들어야 앞으로 나아간다고 생각하는 조직일 경우, 일단 기능 배포는 완료했으니까 빨리 다른 걸 하자고 생각하는 순간, 제품 개선은 어렵다
•
그래서 프로덕트가 점진적으로 발전하려면 '기능의 배포'가 아니라 다음과 같은 기준에 주목해야함
◦
전체 활성화 사용자 중 10%의 사용자가 이 기능을 사용한다.
◦
이 기능을 사용하는 사용자들의 NPS*가 33점 이상이다.
프로덕트를 만들고 나서: 우리 제품에 얼마나 만족하고 있을까?
사용자 만족도를 파악할 수 있는 지표 체크하기
•
NPS 점수
•
실제로 얻은 수익
•
전환율
•
유저 인터뷰를 통한 만족도 조사
지속적으로 사용자 피드백 받기
•
프로덕트를 설계하는 과정에서 유저 인터뷰에 참여했던 사용자는 기본적으로 우리 프로덕트에 대한 관심도가 높다
•
또한, 자신의 의견이 실제 프로덕트에 반영됐다는 사실을 알았다면 우리 제품에 더 큰 관심을 갖고 팬이 됐을 가능성이 매우 높음
•
이들을 대상으로 다음과 같은 질문을 인터뷰하는 것도 좋은 방법
◦
실제로 구현된 기능을 사용해 봤는지
◦
언제, 어떤 상황에서 사용했는지
◦
만약 사용하지 않았다면, 어떤 상황에서 사용할 것 같을지
◦
기능을 사용하는 과정에서 어떤 생각이 들었는지 (이때, "좋았나요, 안 좋았나요?"에 대한 질문은 금물! 오로지 사용자의 경험에 대해서 물어봐야 한다)*
*PM 수강생 차수연님의 아티클 스터디 중 일부입니다.
