'사용자'를 모르면 좋은 프로덕트는 탄생할 수 없다.
그러나 실제로 프로덕트를 만들 땐 사용자를 고려하기보다는 기능 개발에만 몰두하곤 한다. 프로덕트가 출시되는 데 집중한 나머지, 사용자가 정말로 이 기능을 원하는지에 대해서는 고려하지 않는 경우를 많이 겪게 되는 것이다.
사용자 중심으로 사고하지 못하는 근본적인 원인은 본질을 벗어난 3가지 집착 때문.
•
첫째, 사용자가 얻게 될 가치가 아닌, 당장 내가 만드는 기능에 대한 집착
•
둘째, 목표와 궁극적으로 추구해야 할 가치가 아닌, 정해진 일정을 맞추는 것에 대한 집착
•
셋째, 실제 프로덕트가 배포되고 나서 사용자들이 해당 기능을 통해 실질적인 가치를 얻었는지 확인하지 않고, 계속해서 새로운 것을 만들어야 한다는 집착
이러한 집착에 빠지는 이유는 성과를 판단하는 기준을 잘못 설정했기 때문. 사용자를 분석하는 일이 아니라 '기능의 제작 여부'를 성과라고 생각하면 이런 식의 함정에 빠지기 쉽다.
PM에게 '사용자 중심적 사고'가 중요한 이유
기술적으로 완벽한 프로덕트를 출시했다 하더라도(물론 그런 일은 거의 불가능하지만) 프로덕트의 가치를 공감하고 실제로 사용하는 사용자가 없다면, 그 프로덕트는 살아남을 수 없다. 이와 반대로, 사용자는 많더라도 프로덕트가 제공하는 가치를 통해 회사가 얻을 수 있는 이익이 없는 프로덕트 역시 살아남을 수 없다.
결국 제품이 생존하려면 우리 프로덕트를 통해 사용자가 무엇을 얻고 싶어 하는지 아는 게 매우 중요.
•
우리 프로덕트에 관심을 갖는 사람들은 누구인지
•
불편함을 감수하고서라도 우리 프로덕트를 사용하고 싶은 이유는 무엇인지
•
우리 프로덕트를 위해 얼마큼의 비용 또는 노력을 지불할 수 있는지
•
우리 프로덕트의 해결을 바라는 사용자의 문제는 무엇인지
이러한 고민을 기반으로 제품을 만들어 나가야 사용자는 물론이고 회사의 성장에도 도움이 되는 성과를 만들 수 있다.
프로덕트를 만들기 전: 우리 제품을 누가 좋아해 줄까?
1) 익숙함을 버리고 프로덕트를 사용할 사용자 고민하기
처음 프로덕트를 만들 때, PM이 집중해야 하는 부분 중 하나는 '지금 이 프로덕트(혹은 이 기능)가 시장에 나왔을 때, 어떤 사람들이 사용할까?'에 대한 고려.
창업을 하거나 새로운 기능을 만들 때 우리는 보통 사람들이라면 이렇게 행동할 것이라고 쉽게 가정한다. 이 때문에 사용자에 대한 고민보다는 프로덕트를 언제까지 어떻게 만들지에 더 집중하고 만다.
★이렇듯 사용자가 아닌 '언제'와 '어떻게'에 집중하면, 기존 경쟁자들을 이길 수 없는 무난한 프로덕트를 만들거나, 반대로 완벽을 기하는 바람에 출시가 늦어지기도 한다.
우리 프로덕트가 출시됐을 때, 어느 정도의 손해를 감수하고서라도 우리 프로덕트를 이용해 줄 의사가 있는 사용자는 누구인가?기존의 익숙함을 버리고 우리 프로덕트를 사용하고 싶은 이유가 무엇일지 에 집중한다면 더 명확한 방향성을 기반으로 프로덕트를 성장시킬 수 있다.
ex) 모두의 요금제라는 서비스.
나의 스마트폰 사용 패턴에 맞는 저렴한 요금제를 찾아주는 서비스.
→ 이 서비스는 스마트폰을 사용하는 모든 사람들을 자신의 잠재 고객이라고 여기지 않는다.
모두의 요금제가 타깃으로 하는 잠재 고객은 현재 자신이 사용하고 있는 스마트폰 요금제에 불만이 있는 사람, 즉 다른 요금제로 변경했을 때의 불편함을 무릅쓰더라도 더 많은 혜택을 얻고자 하는 사용자이다. 이렇게 설정한 사용자를 기반으로 마켓을 공략할 수 있었던 것이다.
2) 유저 인터뷰를 통해 요구하는 기능의 본질 파악하기
간혹 사용자 중심적 사고를 '사용자의 요청사항을 곧장 기능으로 만드는 것'이라고 생각하는 PM이 있는데, 그럴 경우에는 다음과 같은 문제가 발생한다.
•
사용자 요청 속에 숨어 있는 본질을 파악하지 않은 채, 다른 제품들을 벤치마킹하는 데에만 시간을 들인다.
•
그 결과, 사용자의 문제를 전혀 해결해 주지 못하는 잘못된 기능을 만들게 된다.
•
사용자에게 '이걸 원한 게 아니었는데…'라는 피드백을 받고, 해당 기능은 실제로 사용되지 않습니다.
•
내부적으로는 '만들어 달라고 해서 만들었더니 안 쓰네…'라는 생각으로 이어지며, 사용자에 대한 부정적인 피드백이 축적됩니다.
이러한 과정이 반복되면 PM은 VOC*를 신뢰하지 못하고, 사용자 피드백보다는 주관적인 감에 따라 중요한 결정을 내리게 된다. 따라서 프로덕트 팀은 사용자로부터 개선 요청이 들어와도 바로 기능화하는 대신, 사용자를 대상으로 다음 내용을 파악하는 게 우선이다.
* Voice of customer, 고객의 목소리
•
1) 해당 기능을 만들어 달라고 요청하는 이유는 무엇인지
•
2) 해당 기능이 없어서 최근에 겪은 문제는 무엇인지
•
3) 해당 문제를 해결하기 위해 현재는 어떤 식으로 프로덕트를 사용하고 있는지
위 내용을 바탕으로 사용자가 요청한 기능이 지금 겪고 있는 문제를 근본적으로 해결할 수 있는지, 만약 해결할 수 없다면 어떤 방식으로 접근해야 더 좋은 임팩트를 줄 수 있을지 고민하고 개선해야 한다.
이렇게 근본적인 문제를 알고 해결하면, 프로덕트 팀은 사용자가 해당 기능을 원하는 이유와 그것을 가장 빠르게 제공할 수 있는 방식을 먼저 이해할 수 있기 때문에 훨씬 더 수월하게 프로덕트를 개선할 수 있다.
ex) 온라인 주문 플랫폼.
주문 플랫폼을 통해 주문을 받는 한 사장님이 주문이 오면 바로 문자로 알려 달라는 기능을 요청.
이 요청을 그대로 기능화한다면, 하루에 주문량이 1,000개인 사장님은 오히려 문자 때문에 불편함을 겪을 수도 있다. 이렇듯 '주문이 들어올 때마다 문자 보내주기'라는 목적은 달성했지만, 또 다른 문제가 생기는 꼴이 되는 것.
만약 해당 기능을 요청한 사장에게 아래와 같은 내용을 물어봤다면?
•
1) 해당 기능을 만들어 달라고 요청한 이유는 무엇인지
→ 오후 7시 이후부터 오전 8시까지 들어온 주문을 확인하지 못해서 배송이 늦어지는 실수가 발생하기 때문에
•
2) 해당 기능이 없어서 최근에 겪은 문제는 무엇인지
→ 주문을 확인하지 못해서 7일 이상 주문 대기로 남아있던 상품 때문에 고객에게 클레임이 들어옴
•
3) 해당 문제를 해결하기 위해 현재는 어떤 식으로 프로덕트를 사용하고 있는지
→ 주문이 없더라도 지속적으로 웹사이트에 들어가서 주문을 확인함
이 세 가지 질문을 바탕으로 사용자가 요청한 기능의 본질은 '주문 상태를 지속적으로 파악할 수 있는 기능'임을 간파할 수 있다. 그리고 이를 가장 쉽고 간편하게 처리할 수 있도록 다음의 두 가지 기능을 제공할 수 있다.
•
매일 오전마다 특정한 시간에 들어온 주문들 중에 사장님이 바로 처리해야 하는 주문들을 문자로 전송하기
•
처리되지 않은 주문들은 주문 리스트 상단에 배치되도록 변경하기
이렇듯 VOC를 통한 기능 요청은 유저 인터뷰를 통해 문제의 본질을 찾는 게 핵심.
프로덕트를 만들면서: 우리 제품한테 무엇을 원할까?
1) 목적을 달성할 수 있는 최소한의 조건으로 제품 만들기
페이스북의 COO였던 셰릴 샌드버그는 'Done is better than perfect(완성이 완벽보다 낫다)'라는 말을 모토로 삼았다. 쉽게 말해, 완벽한 프로덕트를 선보이려고 애쓰기보다는 조금 부족한 걸 알더라도 최소한의 기준을 맞춰서 빠르게 배포하는 게 낫다는 뜻.
물론 이렇게 출시하면 '왜 이런 식으로 불편하게 만들었지…', '이 정도는 고려하고 만들어야 하는 거 아닌가?' 하는 피드백을 들을 수도 있다. 때론 이렇게 출시하면 사용자들이 불편함을 겪을 거라는 사실을 알고 있으면서도 배포해야 한다.
그래야 사용자가 원하는 것에 집중하면서 빠르게 성장할 수 있다. 즉, 사용자와 프로덕트 팀이 제품을 바라보는 관점을 맞추는 과정이라고 보시면 된다.
'사용자는 이럴 것이다'라는 생각은 허상에 가깝다. 따라서 프로덕트를 만들면서 우리가 예측한 사용자들의 피드백과 실제 프로덕트의 피드백은 절대로 100% 일치할 수 없다. 다시 말해 완벽한 프로덕트를 만드는 것은 불가능.
물론 우리가 예측한 사용자의 피드백을 받는다면 희소식. 사용자 피드백을 기반으로 어떤 점들을 개선해갈지 우선순위를 정하기 더 쉬울 테니. 반대로, 예측하지 못한 피드백이라면 더더욱 좋은 일. 당연히 만들어야 한다고 생각한 기능에 쓸데없는 시간을 낭비하지 않아도 되니까.
이렇듯 우리는 '사용자가 목적을 달성할 수 있는 최소한의 조건'에 집중해야 한다. 이를 우선적으로 선보이고, 고객 피드백을 직접 들으면서 프로덕트를 점진적으로 발전시켜 나가는 것.
2) 완료 기준을 '배포'가 아니라 '사용자 피드백'으로 잡기
어느 정도 경력이 있는 PM은 “우리 조직은 워낙 바빠서 최소한의 기능만 넣은 프로덕트를 배포하면 그걸로 끝일 거야. 이런 방식은 이론상으로만 존재할 수 있어”라고 생각할 수 있다.
꼭 새로운 기능을 만들어야 앞으로 나아간다고 생각하는 조직일 경우, 충분히 그럴 수 있다. 일단 기능 배포는 완료했으니까 빨리 다른 걸 하자고 생각하는 순간, 제품 개선은 어려워진다.
그래서 프로덕트가 점진적으로 발전하려면 '기능의 배포'가 아니라 다음과 같은 기준에 주목해야 한다.
•
전체 활성화 사용자 중 10%의 사용자가 이 기능을 사용한다.
•
이 기능을 사용하는 사용자들의 NPS*가 33점 이상이다.
*Net Promoter Score, 프로덕트에 대한 고객 만족도
기능을 배포했다고 끝이 아니라, 배포한 기능을 실제로 잘 사용하고 있는지, 얼마나 만족하고 있는지 등을 파악해야 한다. 이 수치를 바탕으로 새로운 기능들을 추가하면서 프로덕트를 성장시켜야 한다.
처음부터 완벽한 계획을 세우려고 하기보다는 1차 배포 후, 사용자 피드백을 반영해서 2, 3차 계획을 세우는 것이 좋다.
프로덕트를 만들고 나서: 우리 제품에 얼마나 만족하고 있을까?
1) 사용자 만족도를 파악할 수 있는 지표 체크하기
프로덕트를 배포하고 나서도 사용자 중심적 사고를 유지해야 한다. 생각했던 기능을 다 만들었다고 끝이 아니라, 사용자가 이 기능에 정말로 만족하는지를 잘 파악해야 한다.
이는 배포 이후, 특정 기간 이내에 아래 조건들을 얼마큼 달성했는지 여부로 파악할 수 있다. 달성 기준은 자신의 조직이나 팀에 맞게 설정.
•
NPS 점수
•
실제로 얻은 수익
•
전환율
•
유저 인터뷰를 통한 만족도 조사
이 조건을 만족스럽게 달성했을 때가 바로 프로덕트를 마무리해도 되는 시점. 이렇게 프로덕트의 종료 기준을 사용자의 반응으로 잡아야 그다음에 집중해야 하는 우선순위도 보다 효과적으로 선정할 수 있다.
2) 지속적으로 사용자 피드백 받기
프로덕트를 설계하는 과정에서 유저 인터뷰에 참여했던 사용자는 기본적으로 우리 프로덕트에 대한 관심도가 높다. 또한, 자신의 의견이 실제 프로덕트에 반영됐다는 사실을 알았다면 우리 제품에 더 큰 관심을 갖고 팬이 됐을 가능성이 매우 높다.
따라서 우리는 이들을 잘 활용할 줄 알아야 한다. 이들을 대상으로 다음과 같은 질문을 인터뷰하는 것도 좋은 방법.
•
실제로 구현된 기능을 사용해 봤는지
•
언제, 어떤 상황에서 사용했는지
•
만약 사용하지 않았다면, 어떤 상황에서 사용할 것 같을지
•
기능을 사용하는 과정에서 어떤 생각이 들었는지 (이때, "좋았나요, 안 좋았나요?"에 대한 질문은 금물! 오로지 사용자의 경험에 대해서 물어봐야 한다)*
이러한 인터뷰는 앞으로의 프로덕트 방향성을 잡아가는 데 큰 도움이 된다.
성공하는 제품을 만들고 싶다면 사용자와 친해져라.
지금까지 사용자 중심적 사고를 바탕으로 프로덕트를 설계하고, 만들고, 지속적으로 성장시키는 과정을 살펴보았다. 하지만 사용자를 안다는 것은 굉장히 힘든 일이다.
우리가 만드는 프로덕트의 사용자는 너무 많고, 그렇다고 가장 중요하고 생각하는 사용자를 특정지어서 그들만을 위한 프로덕트를 만드는 것 역시 어렵기 때문이다.
그런 탓에 객관적인 근거 없이 대표나 의사 결정권자들의 감을 믿거나 스스로의 직관대로 결정을 내리기도 한다. 하지만 이런 식의 의사결정은 많은 위험요소들이 존재한다.
•
아무도 원하지 않거나 반쪽짜리 기능을 만들어서 사용자를 떠나게 만든다
•
시간이 한참 지난 뒤에 해당 기능에 대한 니즈가 없음을 깨닫는다
•
시장에 과감하게 진출할지, 더 투자할지, 관둬야 할 지 결정하기 어렵다
이와 같은 위험 요소를 줄이고 좋은 프로덕트를 만들기 위해선 사용자를 잘 아는 게 우선. 지금이라도 늦지 않았으니, 제품을 사용하는 사용자들과 이야기를 나눌 기회를 꼭 만들어보길!
핵심
•
PM은 프로덕트를 설계하고, 만들고, 지속적으로 성장시키는 과정에서 항상 사용자와 긴밀하게 소통해야 한다.
•
프로덕트를 만들기 전: 우리 제품을 누가 좋아해 줄까?
1) 기존의 익숙함을 버리고, 우리 프로덕트를 사용할 만한 사용자 고민하기
2) 유저 인터뷰를 통해 사용자가 요구한 기능의 본질 파악하기
•
프로덕트를 만들면서: 우리 제품한테 무엇을 원할까?
1) 사용자가 목적을 달성할 수 있는 최소한의 조건으로 제품 만들기
2) 완료의 기준을 '기능 배포'가 아니라 '사용자 피드백'으로 잡기
•
프로덕트를 만들고 나서: 우리 제품에 얼마나 만족하고 있을까?
1) 사용자 만족도를 파악할 수 있는 지표 체크하기
2) 지속적으로 사용자 피드백 받기