고객에게 원하는 것을 묻는 방식은 효과가 없다

 (techbooks.substack.com)
8P by GN⁺ | ★ favorite | 댓글 1개
  • 제품 로드맵 논의에서 영업·마케팅·R&D·사업 책임자는 모두 고객을 말하지만, 정작 고객이 제품을 고용한 일(job) 을 놓치면 판단 기준이 흐려짐
  • Intuit는 설문에서 나온 150개 기능 요청을 따라가다 feature chase에 빠졌고, 어떤 기능이 진짜 중요한지 가를 나침반이 없었음
  • 밀크셰이크 사례에서는 맛·가격·식감 질문으로는 매출이 늘지 않았지만, 구매 상황을 관찰하자 아침 통근자의 긴 출근길과 허기가 핵심 job으로 드러남
  • 같은 밀크셰이크라도 아침에는 베이글·프로틴바·주스와, 오후에는 아이에게 주는 간식 선택지와 경쟁해 평가 기준과 경쟁 제품이 달라짐
  • Job to be done을 찾으려면 가까운 문제, 아무것도 하지 않는 선택, 우회 행동, 사람들이 피하려는 일, 비정상적 사용을 관찰해야 함

고객 요청이 로드맵의 나침반이 되지 못하는 이유

  • 로드맵 회의에는 부서마다 서로 다른 고객 입력이 들어옴
    • 영업은 고객과 계속 대화하므로 가장 시급한 요구를 안다고 봄
    • 마케팅은 기존 브랜드를 활용해 새 버전, 새 맛, 새 색상, 특별 제안을 만들 수 있다고 봄
    • R&D는 새 기술이나 응용에서 나온 기능과 이점에 집중함
    • 사업 책임자는 연말까지 P&L에 도움이 될 출시를 원함
  • 각 접근은 일부 타당하지만, 자기 관점을 뒷받침하는 정보만 보는 확증 편향에 빠질 수 있음
  • 더 큰 문제는 어느 모델도 고객의 job을 직접 반영하지 않는다는 점임

Intuit가 빠진 기능 추격

  • Intuit는 고객이 원하는 새 기능을 묻는 설문을 광범위하게 진행했고, 고객은 긴 희망 기능 목록을 제시함
  • Intuit CEO였던 Cook에 따르면 고객은 “150개 기능”을 요구했고, 개발팀은 어떤 기능이 더 중요한지 몇 주 동안 논쟁함
  • 팀원들은 모두 고객에게 맞는 선택이라고 믿었지만, 실제로는 판단 기준이 없었음
  • 고객이 제품을 어떤 일에 쓰려고 “고용”하는지 모르면 올바른 기능을 구분하기 어렵고, Cook은 이를 나침반 없이 항해하는 상황에 비유함

밀크셰이크 매출이 늘지 않았던 이유

  • 패스트푸드 체인은 밀크셰이크를 더 많이 팔기 위해 이상적인 소비자 프로필에 맞는 고객을 불러 질문함
    • 더 싸야 하는지
    • 더 덩어리가 있어야 하는지
    • 더 씹는 맛이 있어야 하는지
    • 더 초콜릿 맛이 강해야 하는지
  • 고객은 원하는 점을 말했지만, 이를 바탕으로 무엇을 해야 할지는 분명하지 않았음
  • 체인은 고객 피드백에 맞춰 여러 시도를 했지만, 몇 달 뒤 밀크셰이크 카테고리의 매출 변화는 없었음

관찰로 드러난 아침 밀크셰이크의 job

  • 질문을 “사람들이 어떤 일을 해결하려고 이 식당에 와서 밀크셰이크를 고용하는가”로 바꿈
  • 팀은 하루 18시간 동안 매장에서 고객을 관찰함
    • 언제 밀크셰이크를 사는지
    • 어떤 옷을 입었는지
    • 혼자 왔는지
    • 다른 음식도 함께 샀는지
    • 매장에서 마시는지, 차를 타고 떠나는지
  • 오전 9시 전 밀크셰이크가 많이 팔렸고, 구매자는 대개 혼자 와서 밀크셰이크만 산 뒤 차를 타고 떠났음
  • 아침 고객들의 공통된 job은 길고 지루한 출근길을 견디고, 오전 중반의 허기를 피하는 것이었음
  • 경쟁 대안은 있었지만 완벽하지 않았음
    • 바나나는 너무 빨리 먹게 되어 오전 중반에 다시 배고픔
    • 도넛은 부스러기가 떨어지고 손가락이 끈적해져 옷과 운전대가 더러워짐
    • 베이글은 건조하고 맛이 없을 때가 많고, 크림치즈나 잼을 바르며 운전해야 하는 문제가 있음
  • 밀크셰이크는 얇은 빨대로 걸쭉한 음료를 오래 마셔야 해서 시간을 채워주고, 오전 내내 배부르게 해주며, 컵홀더에 들어감

같은 제품도 시간대마다 다른 경쟁을 함

  • 사람들은 하루 중 서로 다른 두 상황에서 밀크셰이크를 서로 다른 job을 위해 고용함
  • 아침 밀크셰이크는 베이글, 프로틴바, 신선한 주스 병과 경쟁함
  • 오후 밀크셰이크는 아이를 위해 장난감 가게에 들르거나, 일찍 집에 가서 농구를 하는 선택과 경쟁함
  • 같은 제품이라도 job이 다르면 경쟁 제품과 평가 기준도 달라짐

Job to be done을 찾는 다섯 가지 단서

  • 1. 가까운 곳의 job 찾기

    • 데이터 중심 세계에서도 큰 혁신 중 일부는 Job to be done에 대한 직관에서 출발함
    • Khan Academy는 Sal Khan이 사촌이 스트레스 없이 수학을 배우도록 돕고 싶었던 데서 시작했고, 같은 고통을 느끼는 사람이 많았음

  • 2. 아무것도 하지 않는 선택과 경쟁하기

    • 소비자가 자신의 job을 만족시키는 해법을 찾지 못하면 아무것도 하지 않기로 선택할 수 있음
    • 기업은 기존 경쟁사의 점유율을 빼앗는 방법만 보지 말고, 보이지 않는 수요가 어디 있는지도 봐야 함
    • Airbnb의 글로벌 호스피탈리티·전략 책임자 Chip Conley에 따르면, Airbnb “게스트”의 40%는 Airbnb가 없었다면 여행을 하지 않았거나 가족과 함께 지냈을 것이라고 답함

  • 3. 우회 행동과 보상 행동 보기

    • OpenTable은 레스토랑 예약을 둘러싼 오래된 우회 행동에서 나옴
    • 친구들과 가능한 시간을 맞춘 뒤 식당에 전화했지만 자리가 없으면, 다시 친구들에게 연락하고 다른 식당을 찾는 과정을 반복해야 했음
    • OpenTable은 이 예약 job을 해결함

  • 4. 사람들이 하기 싫어하는 일 찾기

    • Clayton Christensen은 이를 negative jobs라고 불렀고, 부정적 job은 좋은 혁신 기회가 될 수 있음
    • Harvard Business School 동문 Rick Krieger와 파트너들은 아들의 인후염 검사를 위해 응급실에서 몇 시간 기다린 뒤 QuickMedx를 시작했고, 이는 CVS MinuteClinics의 전신이 됨
    • CVS MinuteClinic은 예약 없는 환자를 즉시 보고, 전문 간호사가 결막염, 귀 감염, 인후염 같은 일상 질환에 약을 처방할 수 있음
    • 의사에게 꼭 가지 않아도 된다면 가고 싶어 하지 않는 사람이 많기 때문에, MinuteClinic은 CVS 약국 매장 안에 33개 주 1,000곳 이상 생김

  • 5. 비정상적 사용 보기

    • 사람들이 어떤 일을 끝내기 위해 직접 우회 행동이나 보상 행동을 만든다면, 그 job은 중요하고 기존 해법에 대한 좌절도 크다는 신호일 수 있음
    • 이런 상황은 잠재력 높은 혁신 기회로 이어질 수 있음

더 나은 질문

  • W. Edwards Deming은 “올바른 질문을 할 줄 모르면 아무것도 발견하지 못한다”고 말함
  • 더 나은 질문은 고객에게 무엇을 원하는지 묻는 것이 아니라, “그 제품을 어떤 일을 하기 위해 고용했는가”를 묻는 것임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 제품 관리의 고전적 실수는 대체로 사용자가 자기 필요를 안다고 가정하는 데서 시작함. 실제로는 드물고, 진짜 필요를 파악하는 게 제품 쪽의 일임
    사람들이 실제로 쓰기 전까지는 지금 만드는 것이 사용자가 원하는 것이라는 증거가 없고, 사용자가 요청한 것이 곧 필요라고 봐서도 안 됨
    영업팀이 “X를 만들지 않으면 계약을 못 닫는다”고 해도, X를 만든 뒤 아무 차이가 없을 수 있음. 원인은 영업 쪽 분석이 틀렸기 때문임
    특히 신제품은 사용자가 먼저 요구하지 않으므로 설명하고 보여줘야 하며, “자동차가 처음 나왔을 때 고객은 더 빠른 말을 원했다”는 예가 여기에 해당함

    • 문제는 실제로 파고든 사람이 없다는 데 있고, 그래서 제품 담당자의 80%는 순효과가 마이너스라고 봄
      누가 뭔가를 요구하면 이유를 캐야 함. 정비소에 가서 발전기를 갈아달라고 했는데 그대로 갈아주면 불만이 남을 수 있지만, “왜 갈아야 하느냐”를 묻고 보니 문제는 솔레노이드였고 그걸 고치면 이동이라는 진짜 목적이 해결됨
      그래서 시니어 개발자가 제품 담당자보다 더 나은 제품 감각을 보일 때가 많음. 1~2년 개발하다 자격증 따고 제품 직무로 간 사람으로는 베테랑의 깊이를 이기기 어려움
      가정이 무엇이든, 대화하고 파고들지 않으면 차선의 결정을 하게 됨
    • “더 빠른 말” 비유의 반례로 Segway를 봄. 사람들은 정말로 도시에서 더 빠르게 걸어 다니는 방법을 원했을 수도 있음
      사용자 조사를 통해 문제 영역과 기능 공간을 이해하는 데는 전적으로 찬성하지만, 실제로는 자동차 발명가보다 Segway 만드는 사람을 훨씬 더 많이 봤음
      창업자 직감이나 형편없는 사용자 조사로 만든 뒤, 고객 요청을 “더 빠른 말”이라고 가볍게 무시하는 경우가 많음. 내가 내 업무 영역을 모른다는 전제하에 추가된 맞춤 워크플로에 적응할 시간도 에너지도 의지도 없음
      B2C와 B2B의 차이가 있을 텐데, 이런 조언이 적용될 때 그 구분은 거의 보지 못했음. 사용자 피드백을 무시하자는 뜻이 아니라는 건 알지만, 그렇게 해석되는 장면을 너무 자주 봐서 새 비유가 필요함
    • 요약하면 “고객 말을 듣지 말고, 고객을 관찰하라”에 가까움
      물론 그대로 받아들이면 안 되지만, 사용자가 뭘 원하는지 묻는 것보다 행동을 관찰하는 편이 더 통찰을 주는 경우가 많음. 다만 무엇을 배우고 싶은지 알 수 있도록 관찰 환경을 잘 설계해야 함
    • 비디오게임도 좋은 예임. 게이머는 특히 시뮬레이션 게임에서 처음엔 멋져 보이지만 재미는 없는 아이디어를 많이 냄
      예를 들면 “우주선 안을 걸어 다니고, 미소운석 충돌 뒤 선체를 고치려고 우주 유영을 할 수 있어야 한다” 같은 것임
      반대로 회사나 개발자가 이 논리를 과하게 적용해서, 자기 게임을 즐기지 않는 플레이어가 틀렸다고 탓하는 일도 흔함
    • 영업 담당자가 말하는 고객 요구를 그대로 믿는 문제는 매우 흔하고, 조직 차원에서 막기도 어려움
      영업이 사용자와 가장 많이 접촉하므로 제품 관리자는 보통 그 말을 그대로 따르기 쉬움

  • 이메일 지원을 많이 하다 보면 XY 문제가 기능 요청으로 위장한 사례를 자주 봄. https://en.m.wikipedia.org/wiki/XY_problem
    누군가 기능을 요청하고, 대개 추가하기도 쉽지만 먼저 근본 문제를 이해하려 함. 고객은 문제를 말하지 않고 자기 해법을 말하는 경우가 많고, 그 해법은 나쁜 접근이거나 아예 틀린 접근일 때도 있음
    기능을 우아하게 추가하고 문서화해 다른 사람에게도 쓸모 있게 만들려면, 그것이 해결하는 진짜 고통을 이해해야 함
    “고통을 찾아 없애라”는 강력한 판매 기법이기도 함. 때로는 고객이 아니라 영업팀 내부의 고통 때문에 기능이 추가되며, 의사결정자가 중요하다고 생각하고 데모가 잘 된다는 이유만으로 실제 고객은 쓰지 않을 기능이 들어가기도 함

    • 조직 내부에서 나온 요구 중에는 비즈니스 쪽도 왜 원하는지 제대로 말하지 못하고, “체크해야 할 것 같아서 체크한다” 수준인 것도 있음
      특히 레거시 소프트웨어 교체 때는 더 이상 쓰이지 않는다는 확신이 높고 만들 비용이 가치보다 큰 잡동사니까지 옮기라는 압력이 항상 있음
      예를 들어 아무도 실제로 읽지 않는 보고서 생성을 놓지 못하는 비즈니스 담당자들이 있음

  • 글은 좋지만 제목은 정말 싫음. 고객에게는 많은 것을 물어봐야 하지만, 액면 그대로 받아들일 것은 아주 적음
    고객이 요청한 기능을 그대로 구현하는 건 망하는 지름길이고, “X를 하게 해달라”를 넘어서 계속 질문하고 파고들어야 함
    공정하게 말하면 글도 사실상 그 얘기를 하고 있지만, 진부한 제목에 지쳤음
    Christensen과 Deming 추천에 동의하고, Sidney Dekker도 추가하고 싶음. 특히 "Field Guide to Human Error"가 좋고 다른 책들도 괜찮을 것 같음

    • 고객 말은 많이 들어야 하지만 거의 액면 그대로 받아들이면 안 됨. 다만 “지금 바로 구매 주문서에 서명할 건가?” 같은 질문은 예외임
      해법이 실제이고 고객에게 팔릴지 검증하는 가장 좋은 방법 중 하나는 “지금 이걸 사겠습니까?”라고 묻는 것임. “네, 청구서 보내고 주문 진행합시다”면 뭔가 검증된 것임
      반대로 “음, 아마도요, 구매 위원회와 얘기해볼게요” 같은 반응이면 아직 헤매는 중임
      제품이 아직 준비되지 않아 실제 판매까지 가지 않더라도, Steve Blank가 말한 것처럼 “지금 백만 달러를 내겠습니까?”, “그럼 얼마를 내겠습니까?”, “무료로 주면 즉시 도입하겠습니까?” 같은 질문으로 이어갈 수 있음. 이런 답이 고객 눈에 실제로 어떤 위치인지 알려줌
      https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
    • 고객 말을 듣고, 그들의 비즈니스를 배우고, 더 나아지게 도와야 함. 묻고 그대로 만드는 것과, 듣고 종합하는 것은 다름
    • 제목이 아주 만족스럽지는 않음. 눈길을 끌면서도 진실에 가까운 제목을 찾기가 어려운데, 어떤 제목이 좋을지 궁금함

  • 경험상 고객은 자기가 뭘 원하는지 모름. 그래서 창업자가 그 문제를 더 잘 풀 무언가를 만들고 싶어 하는 이유가 있음
    “검증하기 전에는 만들지 말라”는 조언은 정말 싫음. 내게는 문자 그대로 한 번도 먹힌 적이 없고, 유도 질문을 던지면서 동시에 자기 발을 쏘는 것과 같음
    왜 이 일을 하는지에 대한 확신이 있어야 함. 전혀 모르는 산업에 뛰어드는 사람이 되면 실패 확률은 99%임. 뭘 하는지 알고 있다면 성공 확률은 60% 이상이어야 함
    첫눈에 문제 해결이 된다는 걸 사람들이 이해하는 제품은 팔기 쉬움. 같은 문제를 겪어봤고, 그 문제를 해결하려고 나섰기 때문임

    • “검증”이 무엇을 뜻하느냐에 따라 다름. 내게 검증은 문제의 존재와, 어떤 해법을 찾는 사람이 얼마나 많은지임
      그래서 많은 검증 우선 사이트가 해법 설명을 일부러 모호하게 한다고 봄
    • “검증하기 전에는 만들지 말라”가 먹히지 않았다고 하지만, 같은 문제를 겪은 사람이었고 그걸 해결하려고 했다면 이미 검증한 것 아닌가 싶음
      본인이 원형 고객이었던 셈임

  • “Henry Ford가 사람들에게 원하는 걸 물었다면 더 빠른 말을 원한다고 했을 것”이라는 진부한 인용은 괜히 진부해진 게 아님. 대부분의 사람은 자기가 뭘 원하는지 모르고, 그래서 좋은 제품 설계자가 큰돈을 받음
    구분해야 할 것은 제품 비전과 피드백을 듣는 법임
    사람들의 문제를 해결하는 새 제품을 설계하는 일에는 묘책이 없고, 경험·직감·기술 이해·기존 대안 관찰·기술적/경제적/사회적 변화 예측 등이 섞인 기술임
    반면 피드백을 듣는 일은 설계한 것이 의도대로 작동하는지, 사용자를 헷갈리게 하는 것이 무엇인지, 방해물이 무엇인지 확인하는 일임. 여기서는 사용자 관찰, 테스트, 설문 같은 고전적 방법이 유용함
    쉬워 보이지만 전혀 그렇지 않음. 현실이 이념과 충돌해도 원칙을 굽히지 않는 디자이너, 대다수 사용자가 겪고 지원 포럼과 소셜 미디어에서 분노하는 버그를 inexplicably 고치지 않는 회사들을 많이 봤음
    두 기술은 매우 다르고, 하나를 잘하기도 어려운데 둘 다 잘하기는 더 어려움. 글은 Intuit를 사례로 쓰지만, 정부에 로비해 독을 유지하면서 그 해독제를 파는 사업에서 정말 훌륭한 일을 하는 역학은 독자에게 남겨둠

    • 그래도 더 빠른 말을 사육하는 세계적 산업은 여전히 꽤 큼. 자동차 산업보다 훨씬 작지만, 수익성 있는 틈새 시장임

  • 고객은 세금 신고의 고통을 줄이고 싶어 하는데, Intuit는 그 고통이 계속 강하게 남도록 정부에 로비함

  • 우리 제품의 역사는 이 스펙트럼 전체를 지나왔음
    처음에는 고객인 은행들이 자기 비즈니스를 어떻게 보는지, 우리 제품이 어떻게 개선할 수 있을지만 관심이 있었음. 뭘 하는지도 모른 채 아이디어를 빠르게 쌓았고, 고객의 사소한 변덕까지 맞추려 허둥댔음. 우리가 그들의 비즈니스를 받을 자격이 없다고 느꼈음
    중간쯤에는 성과가 나기 시작했고, 10곳 넘는 고객을 각자 원하는 방식대로 모두 만족시키려고 제품을 만들면 결국 아무것도 남지 않는다는 걸 깨달음
    지금 우리 제품은 특정 소프트웨어나 기술이라기보다 턴키 컨설팅 패키지에 가까움. 고객은 이제 자기 비즈니스를 어떻게 운영할지 우리에게 가이드를 구함. 이런 버스를 운전하게 되면 훨씬 더 자신 있게 소프트웨어 스택을 표준화할 수 있음. 최근에는 “지루함”이라는 단어가 우리 어휘에 들어왔음
    우리 고객군의 재미있는 점은 무리 지어 움직이는 성향이 강하다는 것임. 몇 곳만 특정 방향으로 움직이게 만들면, 나머지는 거의 노력 없이 따라오게 할 수 있음. 위험 회피 성향의 은행가에게만 적용되는 이야기는 아닌 것 같음

  • 글에 빠진 흔한 함정은 목소리 큰 소수 고객에게 귀를 기울이는 것임
    Hacker News나 다른 기술 친화적 플랫폼만 읽었다면, 작은 화면이면서 성능 좋은 iPhone에 엄청난 수요가 있다고 생각해도 이상하지 않았을 것임
    실제로 iPhone mini 판매량은 실망스러웠음. 기술 하드웨어에 대해 온라인에 오래 글 쓰는 사람들은 전체 iPhone 고객층을 대표하지 않는다는 뜻임

    • iPhone mini 판매량이 실망스럽다는 건 누구 기준인지 모르겠음. 대부분의 Android 폰보다 많이 팔렸고, 초기 몇 세대 iPhone보다도 훨씬 많이 팔렸음. iPhone 3G, 3GS, 4도 실망스러웠던 건가
      비율이 낮았다고 해서 출하 대수가 낮았다는 뜻은 아님
      현실적으로 어떤 회사를 만들더라도 iPhone Mini보다 훨씬 적은 수를 팔 가능성이 큼. 그렇다면 Apple 기준으로 실망스러운 판매량이니 해고되고 파산해야 하나? 2천만 대 미만을 파는 회사는 전부 청산해야 하나? 작은 iPhone 출하량보다 작은 고객층을 대상으로 하는 회사들은 존재하지 말고 평균적인 사람을 위한 평균 제품으로 대체돼야 하나? Mac Studio도, XDR 디스플레이도, 15인치 4,000달러 MacBook도 없어져야 하나?
    • Apple 기준으로 실망스러웠다는 뜻, 즉 겨우 수천만 대 수준이라는 얘기임
      iPhone mini에 매우 만족하는 사람들을 몇 명 알고 있고, 이제 그들에게는 업그레이드할 대상이 없음. 그래도 이쪽이 더 싸긴 함

  • 사람들이 자기 문제를 스스로 해결할 줄 알았다면 돈을 주지 않았을 것임
    컴퓨터로 어떤 일을 하려면 어느 정도 기술 능력이 필요하긴 하지만, 대부분은 규칙을 따르고 Excel을 창의적으로 쓰면 해결 가능함
    가치는 사람들이 문제를 풀 수 있는 프레임워크를 주고, 그들이 미처 생각하지 못한 예외 상황까지 고려해 대신 생각한 뒤, 그 규칙 체계를 프로그램으로 컴파일하는 데서 나옴

  • 웃기게도 고객에게 원하지 않는 것을 물어보는 건 실제로 잘 작동함
    고객에게 원하는 걸 묻는 건 위원회식 설계와 비슷함. 사람들이 원하는 것은 한 명의 예술가가 만든 잘 정리되고 자기일관적인 비전에서 몇 가지만 뺀 형태임

답변달기