Customer Centric 체크리스트

요즘 "실리콘밸리 프로세스의 힘"이라는 책을 읽고 있습니다. 개인적으로는 프로세스를 세세하게 정의하는 것을 그렇게 즐기지 않는터라 큰 기대를 하고 읽은 책은 아니지만 여러모로 도움이 되는 책이고, 그 중에서 제일 먼저 도움을 받고 정리할 수 있었던 내용을 먼저 공유 드립니다.

이 책에 보니까 고객 집중적(Customer Focused)과 고객 중심적(Customer Centric)으로 일하는 것을 구분하며 고객 중심적(Customer Centric)으로 일해야 하며, 프로세스 설계의 기반에 "고객 중심 철학"을 기저에 깔아야 한다는 이야기가 있었는데요. 사실 영어권의 개념이다보니 처음부터 확 들어오는 개념이 아니더라고요. 그래서 며칠 동안 리서치를 좀 해보고 스스로 정리한 개념의 차이와 각각을 더 잘하기 위해서 어떻게 해야 하는지를 정리했습니다. 참고로 제가 하는 일을 더 잘하기 위한 정리였기에 다소 제 도메인에서만 워킹하는 이야기가 많습니다. 그러니 각자 필요한 부분을 따로 정리하시기를 추천 드립니다. 😀

Customer Centric vs Customer Focused

일단 기본 전제는 이렇습니다.

'고객의 요청에 잘 대응하는 팀(Customer Focused)'에서 '고객의 성공을 먼저 설계하는 팀(Customer Centric)'이 되어야 한다.

Customer Focused

• 관점: 외부에서 내부로 (Outside-In), 고객의 요구를 듣고 제품을 개선한다.
• 접근 방식: 반응적 (Reactive), 요청과 문제에 대응한다.
• 목표: 단기적 만족도 향상, 문제 해결
• 초점: 고객이 원하는 것 (Wants)
• PM/PO의 역할: 고객 피드백을 백로그에 반영하고 기능을 제공하는 실행가

Customer Centric

• 관점: 내부에서 외부로 (Inside-Out), 고객의 입장에서 생각하고 문제를 정의한다.
• 접근 방식: 선제적 (Proactive), 숨겨진 니즈를 파악하고 미래를 예측한다.
• 목표: 장기적인 고객 성공, 고객 생애 가치(LTV) 극대화
• 초점: 고객에게 필요한 것 (Needs)
• PM/PO의 역할: 고객의 근본 문제를 해결하고 비즈니스 임팩트를 창출

저는 Customer Focused라고 해서 무작정 나쁘다고는 할 수 없다고 생각합니다. 어쩌면 어떤 고객의 문제는 잘 해결할 수 있으니까요. 다만 ROI가 조금 낮고 성장의 레버를 제대로 당기기는 어렵긴 할 겁니다.

Customer Centric 플라이휠

사실 Customer Centric은 일회성 프로젝트가 아니라, 끊임없이 돌아가는 플라이휠이어야 합니다. 제가 생각하기에는 4가지 단계 정도를 계속 돌리면서 learn as you go 상태로 계속 성장해야 합니다.

1. 고객의 세상으로 들어가기: 고객의 말을 듣는 것을 넘어, 고객의 하루와 업무를 관찰하고 진짜 문제를 발견합니다. 혹은 가상의 워크플로우나 하루를 구상한 다음에 하나씩 체크하는게 필요합니다.
2. 문제를 날카롭게 정의하기: 발견한 문제를 명확히 정의하고, 해결을 위한 측정 가능한 가설을 세웁니다. 이 단계에서는 문제를 더 딥하게 파고 들면서(e.g. 5whys) 제품으로 혹은 우리 회사가 해결할 수 있는 고객 문제 레이어까지 파고들고, 혹은 고객이 완수하길 원하는 과업(job)들을 생각하고 정리(Jobs To Be Done)하면서 문제를 정의해야 합니다.
3. 함께 만들고 검증하기: 최소한의 자원으로 가설을 검증하고, 고객과 함께 올바른 솔루션을 찾아냅니다. 여기에서 고객과 함께 솔루션을 만드는 것을 고객을 메이커로 넣으라는 뜻은 아닙니다.(뭐...넣을 수도 있겠네요.)
4. 성과를 측정하고 배우기(Measure & Learn): 우리의 솔루션이 실제로 고객의 문제를 해결했는지 측정하고, 그 배움을 다음 사이클의 동력으로 삼습니다.

제품 개발 각 단계별 Customer Centric 접근

이제부터 제품을 관리하는 각각의 단계별로 우리가 Customer Centric하게 일하고 있는지, 반대로 Customer Focused하게 일하고 있는지를 스스로 체크해보는 질문 리스트를 공유 드립니다. 제 생각에 모든 순간에 똑같은 에너지를 쏟을 수는 없습니다. 그럼 선택과 집중이 아니죠. 결정적인 순간에 특히 잘해야 한다고 생각해서 좀 더 결정적인 순간은 강조해서 말씀 드립니다.

저는 이렇게 정리해봤습니다.

• 상황: 어떤 상황에서
• 질문: 우리는 스스로에게 어떤 질문을 던져야 하는가
• 누가: 스스로에게 질문을 던져야 하는가, 팀이 함께 질문을 던져야 하는가
• 채점 기준: 내가 한 답이 Centric과 Focused 중에서 뭐에 더 가까운가?
• 중요도:
  • Critical: 이때 놓치면 모든 것이 어긋난다
  • Must-have: 반드시 거쳐야 할 과정
  • Nice-to-have: 문화를 만드는 습관

상황 1. 신규 기능/개선 아이디어를 접했을 때

• 질문: 이 기능 요청의 진짜 배경은 무엇일까? 고객은 이걸 통해 어떤 근본적인 일(Job)을 해결하려는 걸까?
• 누가: 스스로 & 동료들과 함께
• 채점 기준
  • Focused: 가장 큰 규모의 고객사 A가 요청했어요.
  • Centric: 고객들이 공정한 평가 결과를 구성원에게 설명하는 데 어려움을 겪고 있고, 이 기능이 그 문제를 해결하는 첫 단추가 될 수 있어요.
• 중요도: Must have

상황 2. 백로그 우선순위를 결정할 때 👑

• 질문: 이 기능이 얼마나 많은 돈을 벌어다 줄까?가 아니라,이 기능이 해결하는 고객 문제가 얼마나 고통스러운가? 그리고 얼마나 많은 고객이 이 고통을 겪고 있는가?
• 누가: 동료들과 함께 (PM, 리더십)
• 채점 기준
  • Focused: 가장 많은 고객이 요청한 기능 순서대로 정렬했습니다.
  • Centric: 가장 고통이 크고, 우리의 장기적 비전과 맞는 고객 문제부터 해결하기로 결정했습니다. 데이터와 인터뷰로 근거를 마련했습니다.
• 중요성: Critical, 팀의 한정된 자원을 어디에 쓸지 결정하는 순간이라서...이때의 잘못된 판단은 막대한 매몰 비용을 만듭니다.

상황 3. 솔루션 및 UX를 설계할 때 👑

• 질문: 어떻게 하면 이 기능을 가장 쉽게 쓰게 만들까?를 넘어,이 기능이 고객의 실제 업무 흐름(Workflow)에 자연스럽게 녹아드는가? 고객의 하루를 더 복잡하게 만들지는 않는가?
• 누가: 동료들과 함께 (PM, 디자이너, 개발자)
• 채점 기준:
  • Focused: 버튼은 여기, 입력창은 저기. 기능 자체는 논리적으로 완벽해요
  • Centric: 인사팀 담당자가 평가 시즌에 이 기능을 쓰기 전후의 상황까지 고려했어요. 이 기능 덕분에 엑셀을 켜는 일이 한 번 줄어들 거예요.
• 중요도: Critical, 제품의 방향성이 정해지는 순간이기 때문입니다. 물론 개발 과정에서 약간씩 변화를 줄 수 있지만, 그래도 잘못된 판단이 매몰비용이 크게 나오는 순간이기도 합니다.

상황 4. 성공 지표를 정의할 때

• 질문: 우리의 성공 지표는 무엇인가?가 아니라,이 기능의 성공을 고객의 긍정적 변화로 어떻게 증명할 수 있는가? 그리고 그 변화가 어떤 지표로 나타나는가?
• 누가: 스스로 & 동료들과 함께
• 채점 기준:
  • Focused: 성공 지표는 기능 채택률(Adoption rate) 20% 달성입니다.
  • Centric: 이 문제를 해결하면 고객은 평가 결과 취합을 팀 단위로 할 수 있게 됩니다. 개인 단위의 반복을 할 필요가 없습니다. 그러므로 성공 지표는 취합에 걸리는 총 시간으로 봅시다. 500명 규모에서 2시간을 단축시키면 성공입니다. 이를 측정할 방법도 설계했습니다.
• 중요도: Must-have, 플라이휠을 제대로 돌리기 위한 필수 재료를 모으고, 학습 사이클을 완성하는 과정이기 때문입니다. 이 과정을 건너뛰면 팀의 성장이 멈춥니다.

상황 5. 기능 출시 후 회고 및 성과 측정 시

• 질문: 기능 사용률이 왜 이렇게 낮지? 어떻게 홍보할까?가 아니라,우리가 해결하려던 고객의 문제가 정말 해결되었나? 우리의 가설 중 무엇이 틀렸을까?
• 누가: 동료들과 함께 (제품팀 전체)
• 채점 기준:
  • Focused: 사용자들이 아직 기능을 잘 몰라서 그래요. 가이드를 더 만들어야겠어요.
  • Centric: 우리의 가설이 틀렸던 것 같습니다. 고객의 진짜 문제는 A가 아니라 B였을 수 있다는 lesson learned가 쌓였네요. 다시 문제를 들여다봅시다.
• 중요도: Must-have, 플라이휠을 제대로 돌리기 위한 필수 재료를 모으고, 학습 사이클을 완성하는 과정이기 때문입니다. 이 과정을 건너뛰면 팀의 성장이 멈춥니다.

상황 6. 고객 불만 및 CS 티켓을 검토할 때

• 질문: 이 문제를 어떻게 가장 빨리 해결하고 티켓을 닫을까?가 아니라,이 불만은 어떤 더 큰 시스템적 문제의 신호일까? 이 티켓이 다시는 생성되지 않게 하려면 무엇을 해야 할까?
• 누가: 동료들과 함께 (CS, PM, 개발자)
• 채점 기준:
  • Focused: 버그를 수정하고 사용자에게 해결되었다고 알립니다. (문제 해결에만 집중
  • Centric: 이 버그의 근본 원인을 파고드니, 특정 데이터 구조의 문제임을 발견했습니다. 이번 기회에 구조 개선을 논의합시다. (근본 원인 해결에 집중)
• 중요도: Nice-to-have, 그래도 다른 단계가 잘 지켜진다면 보완 가능한 순간입니다. 물론 이 순간도 잘하면 습관이 되어버린다는 강점이 있죠.

Customer Centric의 함정

물론 이게 함정이 아예 없는 것이 아닌데요. 가장 큰 함정은 PM/PO가 스스로를 Customer Centric하다고 착각하면서 본인의 신념에 따라 제품을 만드는 상황이라고 봅니다. 너무 편향되어 버리는 것이죠. 이게 생각보다는 꽤 흔하면서도 은밀하게, 그러면서도 훨씬 파괴력은 강한 부작용이거든요. 한 번 함정에 빠지면 좀 오래 갑니다. 특히나 스스로 Customer Centric하다고 자기 스스로까지 속이는 정도라면 진짜 팀에 엄청난 해악을 끼칩니다.

이 문제는 '나(PM) = 고객'이라는 착각에서 시작되어, 조직의 구조와 문화 속에서 강화되며, 결국 누구도 견제할 수 없는 '신념의 괴물'로 진화하는 기전을 가집니다.

함정 발생 기전: 어떻게 '신념'이 '고객 중심'이라는 탈을 쓰는가?

이 문제는 주로 아래 4단계의 심리적, 환경적 기전을 통해 발생한다고 생각합니다.

1. 과거 경험에 최고 전문가로서의 신념이 버무러짐: 대체로 PM의 강력한 개인적 경험에서 시작되는 경우가 많습니다. 과거에 특정 문제를 직접 겪었거나, 특정 방식으로 성공했던 경험이 '이 문제(도메인)에 대해서는 내가 최고 전문가다. 최소한 팀 내에서는 내가 제일 잘 안다.'라는 강한 신념을 형성합니다. 이는 종종 강력한 비전과 리더십으로 포장되어 긍정적으로 비춰지기도 합니다.
2. '대표 고객'의 일반화 오류와 확증 편향: PM은 자신의 신념과 비슷한 특성을 가진 초기 고객이나 지인 몇 명과 소통하며 자신의 생각이 맞다는 확신을 얻습니다. 이 소수의 '우호적인 샘플'을 전체 시장의 목소리인 것처럼 일반화하고, 이후에는 자신의 신념을 지지하는 데이터나 의견만 선택적으로 받아들이는 확증 편향이 작동합니다. 이 단계에서 반대 의견을 가진 고객은 아직 우리 제품의 가치를 모르는 사람 혹은Edge Case, 우리 고객 아님 정도로 치부하고, 긍정적인 피드백을 준 고객의 말만 반복해서 인용합니다.
3. 문제가 아닌 솔루션에 대한 애착 형성: 고객의 문제를 해결하는 것에 집중하는 것이 아니라, 자신이 상상한 솔루션(제품/기능) 그 자체에 강한 애착을 갖게 됩니다. 이때부터 제품은 고객의 문제를 해결하는 도구가 아니라 나의 비전을 실현하는 창작물이 됩니다. 이 때 주로 나오는 위험 신호는 누군가 솔루션의 단점을 지적하면, 고객의 문제를 해결할 더 나은 방법을 찾는 것이 아니라, 자신의 아이디어를 방어하고 설득하는 데 대부분의 에너지를 쏟습니다.
4. 고객 데이터의 유리한 해석: 데이터를 객관적인 학습의 도구가 아닌, 자신의 신념을 정당화하는 근거로 사용하기 시작합니다. 수많은 데이터 중 자신의 가설에 유리한 지표만 골라내어 "보세요, 고객들이 이렇게나 좋아합니다"라고 주장합니다. 예를 들어, DAU/MAU는 정체되어 있는데, 신규 가입자 수만 보여주며 "시장의 반응이 뜨겁다"고 말하는 것이죠.

사실 위의 일은 진짜 어설프게 뛰어난 PM/PO가 정말 잘 빠지는 함정입니다. 아찔하죠?

함정 강화 기전: 어떻게 '신념의 PM'은 더 망가지는가?

이렇게 발생한 문제는 조직의 문화와 프로세스 속에서 다음과 같이 빠르게 강화됩니다.

1. 빠른 실행 문화의 왜곡과 성과에 대한 착각: 고객 리서치, 데이터 검증 과정을 시간 낭비라고 여기고, 자신의 신념에 따라 빠르게 의사결정하고 실행하는 PM은 겉보기에 매우 유능하고 추진력이 강해 보입니다. 조직이 성과(Impact)가 아닌 속력(Speed)나 활동을 칭찬하는 문화일 경우, 이런 PM은 오히려 인정을 받고 그의 행동은 더욱 강화됩니다.
2. 심리적 안전감의 부재와 에코 챔버 형성: PM의 강한 신념에 반대 의견을 제시하는 팀원은 비전이 없는 사람, 팀워크를 해치는 사람으로 낙인찍힙니다. 몇 번의 경험 후 팀원들은 침묵을 선택하고, PM의 의견에 동조하는 사람들만 남는 에코 챔버(Echo Chamber)가 만들어지죠. PM은 이 상황에서 침묵을 모두의 동의라고 착각하게 됩니다.
3. HiPPO (Highest Paid Person's Opinion)와의 결탁: 신념이 강한 PM은 자신의 비전을 경영진이나 상사(HiPPO)에게 매우 설득력 있게 포장하는 능력이 뛰어난 경우가 많습니다. 일단 경영진이 PM의 신념을 지지하기 시작하면, 실무진의 합리적인 의심이나 데이터에 기반한 우려는 경영진의 결정을 흔드는 불필요한 저항으로 치부되어 묵살됩니다.
4. 피드백 루프의 완전한 파괴: 제품 출시 후 부정적인 시장 반응이나 데이터가 나와도, 이것을 학습의 기회로 삼지 않습니다. "고객들이 아직 가치를 모를 뿐이다", "마케팅이 부족했다", "조금만 더 개선하면 될 것이다"라며 실패를 인정하지 않고, 기존의 신념을 유지하는 방향으로 모든 원인을 돌립니다. 결국 실패로부터 배우는 가장 중요한 성장 기회를 스스로 차단하게 됩니다.

이러한 기전이 맞물려 돌아가기 시작하면, PM은 "나는 고객을 위해 이렇게나 치열하게 일하고 있다"고 굳게 믿지만, 실제로는 자신만의 세계에 갇혀 조직의 리소스를 낭비하고 시장으로부터 고립되는 최악의 상황이 만들어집니다. 이를 막기 위해서는 개인의 신념이 아닌 검증 가능한 가설과 시스템으로 일하는 문화를 의도적으로 구축하는 노력이 반드시 필요합니다.

마무리: 결국 중요한 것은 겸손한 확신

긴 글을 마무리하며 다시 한번 제가 이 정리를 시작했던 이유를 돌아봅니다. 그것은 단순히 '일을 더 잘하기 위해서'라기보다, '우리가 만드는 제품과 우리 자신에 대한 자부심을 잃지 않기 위해서'에 더 가까웠던 것 같습니다.

제가 마지막에 '신념의 괴물'이라는 다소 자극적인 표현까지 쓰며 함정을 길게 설명한 이유도 여기에 있습니다. 우리가 오늘 이야기한 플라이휠과 체크리스트는 단순히 일을 더 잘하기 위한 도구를 넘어, 우리 스스로가 만든 편향과 신념의 감옥에 갇히지 않도록 지켜주는 최소한의 안전장치입니다.

Customer Centric으로 일한다는 것은 역설적으로 "내가 틀릴 수 있다"는 겸손함에서 시작됩니다. 고객보다 똑똑해서가 아니라, 고객을 더 깊이 이해하려는 태도가 진짜 Customer Centric의 출발점입니다.

강력한 비전과 빠른 실행력은 분명 큰 장점입니다. 하지만 그것이 우리 자신과 팀의 눈을 가리는 독선이 되지 않으려면, 우리는 의식적으로 멈춰서서 질문을 던져야 합니다.

• "우리가 지금 해결하려는 고객의 진짜 문제가 뭐였죠?"
• "우리의 이 가설이 틀렸을 수도 있다는 증거는 무엇일까요?"
• "이 성공이 정말 고객의 성공을 의미하나요?"

어쩌면 제가 오늘 쓴 글의 핵심은 '완벽한 프로세스'를 도입이 아니라, '더 나은 질문'을 던지는 습관을 우리 팀의 문화로 만드는 것이라고 생각합니다. 물론 이 모든 걸 하루아침에 완벽하게 할 수는 없습니다. 저도 아직 배우는 중이고, 때로는 Customer Focused적 접근이 더 나은 선택일 수도 있다고 생각해요.

중요한 건 "우리가 지금 어떤 상태인지" 의식적으로 인식하고, 필요할 때 한 단계 더 깊이 들어갈 수 있는 능력을 기르는 것 같습니다.

고객 중심의 여정은 정답이 정해진 지도를 들고 가는 것이 아니라, '고객의 성공'이라는 북극성만 보고 함께 나침반을 맞춰가는 탐험과 같습니다. 그 여정에서 서로가 서로에게 최고의 동료가 되어줄 수 있기를 바랍니다.