고객의 목소리를 듣지 말아야 할 때
미디엄에 연재된 프로덕트 관련 아티클을 읽고 번역/요약하여 공유합니다.
원문과 다른 내용이 있다면 언제든 제보 부탁 드립니다.
원문
When You Should Not Listen to Your Customers
Henry Ford left us with some open questions.
https://productcoalition.com/when-you-should-not-listen-to-your-customers-f72f5ae04087
Maret Kruve | Oct 10, 2023
“사람들에게 뭘 원하는지 물었다면, 더 빠른 말이라고 답했겠죠.“
헨리 포드의 이야기는 직접 피드백의 한계에 대해서는 설명하지만, 그 한계를 극복하는 방법에 대해서는 설명하지 않는다.
이 아티클은 제품관리의 실용적 측면에서 사용자 필요(user needs)를 네 가지로 분류하고 각 분류를 활용하는 어려움, 그리고 그 어려움을 극복하는 방법을 제안한다.
User Insight iceberg1. 표현된 필요(Expressed needs)
사용자가 명확하게 표현할 수 있는 필요.
고객이 공개적으로 논하거나 불평하는 문제, 요청하는 기능, 제안하는 개선.
표현된 필요의 어려움
1
사람들은 자신이 좋아하거나 필요한 것(like or need)을 원하는 것(want)으로 혼동한다.
2
필요를 해결책으로 제시한다
제안 효과(Einstellung effect) 때문에, 상황에서 가장 적절한 해결책이 아닌 경험해본 존재하는 해결책 중 비슷한 것을 요청한다
제안 효과 극복 방법
5why 방법론 : 원하는 것을 왜 원하는지 묻기. 솔루션 뒤에 숨은 진짜 문제를 밝혀내는 데에 도움이 된다.
2. 표현되지 않은 필요(Unexpressed needs)
사용자가 인지했으나 표현하지 않는 필요
모든 사용자가 공유하기 적절하거나 중요한 게 뭔지, 어떻게 피드백 해야 하는지 모든 알지는 못한다. 어떤 사용자는 피드백을 제공하는 시간을 들이는 데에 가치가 있는지 생각한다.
표현되지 않은 필요의 어려움
발견하는 것이다. 모르는 문제를 해결할 순 없다.
극복방법: 적극적인 고객 리서치
제품 사용 너머의 사용자들의 삶을 탐험하라. 과거 고객, 현재(존재하는) 고객, 잠재적 고객과 정기적으로 연결되어라.
최적의 리서치는 제품 중심이 아닌 고객 중심이다. 사용자의 삶은 우리 제품 중심으로 돌아가지 않으므로, 기능 대신 맥락과 워크플로우에 대해 질문하라.
분석은 만능이 아니다. 사람들의 행동을 알려주지만 행동의 이유와 감정을 알려주지 않고, 우리 제품 밖에서의 행동을 알 수는 없다.
양적/질적 방법론을 함께 사용하는 게 좋다.
3. 인식되지 않은 필요(Uncognised needs)
사람들은 갖고 있다는 것을 모르지만 관찰을 통해 발견할 수 있는 필요
1
무엇이 문제인지 정의되어있지 않다고 해서 그것이 기회가 되지 않는 것은 아니다.
모두 다 음악을 듣기 위해서는 CD와 플레이어가 있어야 하고 그렇게 했던 것을 떠올려보라. (아무도 CD플레이어를 가지고 다니는 것을 문제라고 생각하지 않았다)
2
잠재의식에 뿌리를 둔 욕망. 사회적 검증의 필요성이나 친숙한 경험에 대한 선호와 같은 영향력의 정도를 인식하지 못하는 경우들.
무의식적 선호와 편견은 행동과 의사 결정에 큰 영향을 미칠 수 있으며, 때로는 표현된 목표, 가치, 요구와 일치하지 않는 선택을 하게 한다.
인식되지 않은 필요의 어려움
1
거짓말하려고 의도하는 것은 아니지만, 사람들은 자신 있게 틀린 얘길하고, 제품팀이 적절하지 않은 의사결정을 하게 만든다.
극복방법: 관찰
말하는 것이 아니라 뭘 하는지를 봐야한다. 자기보고에 의존하지 않는 데이터 분석이나 고객 쉐도잉, 그밖에 다른 관찰적 방법론을 사용해야 한다. 관찰 방법은 이론이 아닌 현실에서 펼쳐지는 사람들의 행동, 행동 및 선택을 관찰하고 분석하는 것을 포함한다.
관찰은 문제로 정의되지 않은 기회와 사람들의 말과 행동의 모순을 발견할 수 있게 한다.
그러니 언제든 가능하면 관찰을 먼저 하고 질문을 나중에 하라.
2
(분명하게 언어화되지 않고 관찰에서 추론되기 때문에) 해결책에 대한 요구가 표현된 필요에 비해 확실하지 않다
지루한 관찰이라고, 문제가 아니라고, 항상 그래왔다고 말할 수 있다. 하지만 자동차, 컴퓨터, 인터넷은 그 지루한 관찰과 그것에 대한 창의적인 해결책이었다.
때로는 현상에 도전하는 것이 현명하며, 겉보기에 평범한 관찰조차도 이유가 될 수 있다.
4. 잠재적 필요(Potential needs)
아직 존재하지 않는다. 대게 그 필요의 맥락이 없기 때문.
예를 들면 차가 있기 전에 안전벨트에 대한 필요가 없고 인터넷 전에 온라인 쇼핑이 대한 필요가 없었던 것.
새로운 해결책은 이전에 가능하지 않았던 것을 할 수 있게 하고, 새로운 행동, 요구, 필요, 선호를 창조한다. 선호는 새로운 환경이 만들어지기 전까지는 존재하지 않는다.
급진적 혁신에만 적용되는 것이 아니라 어떤 시기든 새로운 것이 만들어질 때 적용된다. 스케일과 리스크가 다를 뿐.
잠재적 필요의 어려움
1
미래 예측은 거의 불가능하고 과거에서는 배울 것이 거의 없다. 과거 데이터는 미래를 예측해주지 않는다
극복방법: 실험
새로운 데이터를 만들어라.
(trial-and-error experimenting )
프로토타입을 만들고 테스트하고 파일럿을 운영하는 것은 가능한 정보의 양을 늘리고 미확인 숫자를 줄인다.
프로토타이핑에도 불구하고 처음에 성공이 실패처럼 보일 수 있다. 시장의 비전과 타이밍도 옳다는 점을 감안할 때, 신제품을 올바르게 얻는 데 적어도 3세대가 걸릴 것이다.(Mac의 예)
그래서 미래를 위해 건설할 때, 당신은 위험을 감수하고 반복해야 할 뿐만 아니라 인내심과 많은 행운이 필요하다.
—
사람들의 행동을 보라(실제 무엇을 하는지)
사람들이 하는 말을 믿지 말라
사람들이 미래에 할 수 있다고 예측하는 것을 믿지 말라
대담해져라. 그리고 창의력을 발휘하라.
Comment
아티클에서 말하는 것은 결국 리서치/관찰을 통해 고객의 진짜 문제를 찾아라는 것이다.
실제 업무를 하며 특히 1번의 경우를 많이 겪는다.
B2B 고객의 니즈를 대할 때 가장 힘든 것이, 그들이 매우 강력하게 특정 기능에 대해 요구한다는 점이다. 게다가 높은 매출을 가져다 주는 고객일수록 외면하기 어려워 당황스럽다.
일반적으로 B2B 고객을 직접 대면하거나 커뮤니케이션하는 일은 제품팀이 아닌 영업부서나 운영부서에서 담당하기에, 고객이 겪고 있는 문제가 아닌 원한다고 말하는 기능이 전달되어 들어오는 경우가 왕왕 있다.
PO는 기능에 대한 요구가 있을 때, ‘왜 이게 필요하다고 하세요? 이걸 하려는 이유가 무엇인가요?’를 질문해야 한다.
잘못된 솔루션을 구현하고자 투입되는 자원은 시간과 인적자원 뿐만 아니라 잘못된 일을 하느라 진행하지 못한 일도 포함된다. 잘못된 의사결정의 대가는 생각 보다 크다. 요구 이면의 진짜 문제를 찾아야 한다.
데이터 드리븐이 어느 곳에서나 강조되고 있는데, 이 아티클이 이야기한 것 처럼 우리 제품 밖에서의 사람들의 행동을 알 수 있는 방법 역시 함께 모색해야 한다는 교훈을 얻었다. 특히 아래의 문장들이 내게는 울림을 줬다.
최적의 리서치는 제품 중심이 아닌 고객 중심이다. 사용자의 삶은 우리 제품 중심으로 돌아가지 않으므로, 기능 대신 맥락과 워크플로우에 대해 질문하라.
제품은 고객이 있어야, 고객이 신나게 사용을 해야 의미가 생긴다. 언제나 중심은 우리가 아닌 고객이고, 고객이 우리에게 드러내는 말과 행동이 아닌 그들의 삶 속에서 우리 제품이라는 솔루션을 선택하고 사용하는 맥락을 이해해야 탁월한 제품을 만들 수 있다.
