CODEX 4. B2B 고객은 한 사람이 아니다.
B2B 제품을 개발하는 스타트업이 흔히 빠지는 함정이 있습니다. 실무 담당자와 미팅 후 환호하는 것입니다. "우리 제품을 너무 좋아해요! 이건 무조건 팔립니다!" 하지만 그의 팀장과 미팅하면 예산 이야기를, 임원과 미팅하면 전략 방향 이야기를 듣다가 결국 프로젝트는 조용히 사라집니다. 왜일까요?
고객을 '한 사람'으로 착각했기 때문입니다. 실무자는 자신의 업무 효율을, 관리자는 팀의 성과를, 경영진은 회사의 성장을 봅니다. 이들의 필요는 모두 다릅니다. 우리의 역할은 각 연주자의 필요를 모두 충족시키면서, 동시에 전체 교향곡을 완성시킬 단 하나의 '중심 문제'를 찾아내는 것입니다.
표면의 문제(Appearent Problem)와 중심 문제(Central Problem)를 구분해야 합니다
이해관계자가 여럿일 때 문제 정의가 어려운 이유는, 각자가 자신의 '표면 문제'만을 이야기하기 때문입니다.
표면의 문제(Apparent Problem)는 각 이해관계자가 자신의 입장에서 느끼는 개별적인 고통입니다. 실무자는 "이 소프트웨어는 너무 쓰기 불편해요"라고 말하고, 관리자는 "우리 팀원들의 업무 현황이 한눈에 파악되지 않아요"라고 말하며, 경영진은 "경쟁사보다 프로젝트 처리 속도가 느립니다"라고 말합니다.
중심 문제(Central Problem)는 이 모든 표면의 문제를 관통하는 단 하나의 핵심적인 병목 지점입니다. 고객사 스스로도 명확히 인지하지 못하는 경우가 많습니다. 예를 들어 "수주-제작-납품으로 이어지는 핵심 워크플로우가 비효율적이다"와 같은 것입니다.
이 중심 문제를 해결하면, 실무자의 불편함이 해소되고, 관리자의 니즈가 충족되며, 경영진의 전략적 목표가 달성됩니다. 흩어져 있는 점(표면 문제)들을 이어, 하나의 선(중심 문제)으로 만드는 것이 우리의 진짜 과제입니다.
고객은 제품이 아닌, 결과를 고용합니다 : Jobs to be Done
하버드 경영대학원의 클레이튼 크리스텐슨 교수가 주창한 'Jobs to be Done(해야 할 일)' 이론은 이 복잡한 상황을 꿰뚫는 강력한 렌즈를 제공합니다. 이 이론의 핵심은, "고객은 제품을 사는 것이 아니라, 자신의 '일을 처리하기 위해(to get a job done)' 제품을 고용한다"는 것입니다.
이 이론은 여러 이해관계자가 얽힌 B2B 상황에서 특히 강력한 통찰을 줍니다. 오케스트라의 각 연주자들은 같은 제품을 보더라도, 각자 다른 '일'을 시키기 위해 고용하려 합니다.
사용자(User)는 '반복적인 보고 업무를 줄이고, 창의적인 일에 집중하고 싶다'는 기능적(Functional)인 일을 위해 제품을 고용합니다. 관리자(Manager)는 '우리 팀의 업무 현황을 실시간으로 파악하고, 성과를 예측하고 싶다'는 관리적(Managerial)인 일을 위해 제품을 고용합니다. 경영진(Decider)은 '회사의 비효율을 줄여, 시장 경쟁력을 높이고 싶다'는 전략적(Strategic)인 일을 위해 제품을 고용합니다.
결국 우리가 찾아야 할 '중심 문제'란, 이 모든 이해관계자들이 공통적으로 해결되기를 바라는 가장 중요한 '일(The Job)'인 셈입니다. 우리의 진짜 역할은 각자가 원하는 기능(Feature)을 파는 것이 아니라, 조직 전체가 기꺼이 '고용'할 만한 가치가 있는 궁극적인 '일'을 정의하고 해결하는 것입니다.
슬랙(Slack)은 어떻게 조직 전체를 설득했나
오늘날 최고의 협업툴로 꼽히는 슬랙의 초기 성장 전략은 구매 조직을 공략한 완벽한 예시입니다.
슬랙은 처음부터 CEO나 CIO를 찾아가지 않았습니다. 개발자, 디자이너와 같은 '사용자(User)'에게 먼저 파고들었습니다. 사용자는 슬랙의 압도적인 편의성에 열광하며 자발적인 '영향력자(Influencer)'가 되어 팀에 슬랙을 전파했습니다.
팀의 '관리자(Buyer)'는 슬랙 도입 후 팀의 소통 비용이 줄고 개발 속도가 빨라지는 것을 데이터로 확인했습니다. 마침내 '결정권자(Decider)'는 '전사적인 소통 비효율'이라는 '중심 문제'를 해결하기 위해 슬랙의 전사 도입을 승인했습니다.
슬랙은 각 연주자에게 최적의 악기를 제공하면서, 결국 오케스트라 전체의 연주를 바꾸는 데 성공한 것입니다.
이해관계자 지도를 그리고 중심 문제 관통하기
1단계. 이해관계자 목록화
미팅에 나온 한 사람이 고객의 전부라고 착각해서는 안 됩니다. 내 제안서가 최종 결재되기까지 거쳐야 하는 모든 사람의 역할을 지도 위에 그려야 합니다. 우리 제품의 챔피언이 되어줄 '사용자'는 누구이며, 최종 지갑을 여는 '결정권자'는 누구인지 파악해야 합니다.
2단계. 각자의 문제(Pain) 듣기
각 이해관계자를 만나 그들의 언어로 문제를 들어야 합니다. 이때 "우리 제품 어때요?"라고 묻지 않아야 합니다. "팀장님의 가장 큰 고민은 무엇인가요?", "주로 어떤 일로 야근하시나요?", "CEO에게 어떤 숫자를 보고하실 때 가장 스트레스받으시나요?"처럼 그들의 성공과 실패에 대한 이야기를 들어야 합니다.
3단계. 중심 문제(Keystone Problem) 연결하기
각기 다른 연주자들이 내는 소리(표면 문제) 속에서, 이들을 하나로 묶는 공통의 화음(중심 문제)을 찾아내야 합니다.
"개발팀의 잦은 야근(사용자 문제)과 프로젝트 납기 지연(관리자 문제), 그리고 경쟁사 대비 낮은 시장 출시 속도(경영진 문제)는 모두 '개발-배포 프로세스의 비효율'이라는 하나의 중심 문제에서 비롯됩니다."
이 문장을 완성할 수 있을 때, 비로소 제품은 단순한 '기능'이 아닌, 조직 전체를 위한 '솔루션'이 됩니다.
브런치 작가 jaha Kim 님의 동의 하에 [Startup Codex 22]콘텐츠를 활용하여 제작 되었습니다.
jaha Kim 님의 다른 콘텐츠가 궁금하다면 하단의 링크를 통해 확인할 수 있습니다.
© 2026 GritBD. 본 사이트의 모든 콘텐츠는 저작권법의 보호를 받습니다. All rights reserved



