회사용 일정 관리 도구를 만드는 팀이 있습니다. 사용자 인터뷰에서 현장 직원들은 “입력이 너무 많다”고 말합니다. 같은 주에 영업 담당이 큰 거래처의 요청을 전해 옵니다. “결재 단계를 세 개 더 넣어 주면 내년에 300명분을 더 사겠다고 합니다.” 쓰는 사람은 입력을 줄여 달라고 하고, 사는 사람은 입력을 늘려 달라고 합니다. 둘 다 고객입니다.
기업을 상대로 파는 B2B 제품에서는 이런 장면이 자주 생깁니다. 제품을 사기로 정하는 사람, 돈을 내는 사람, 매일 쓰는 사람, 설정을 관리하는 사람이 서로 다르기 때문입니다. 이 글에서는 B2B 제품의 PdM이 개인 고객 제품과 다르게 생각해야 할 점과, 여러 고객의 요구를 하나의 제품 방향으로 정리하는 순서를 다룹니다.
개인 고객 제품과 무엇이 다른가
표는 가로로 밀어서 볼 수 있습니다.
| 구분 | 개인 고객(B2C) 제품 | 기업 고객(B2B) 제품 |
|---|---|---|
| 고객 | 사는 사람과 쓰는 사람이 대개 같음 | 사는 사람, 쓰는 사람, 관리하는 사람이 다름 |
| 구매 결정 | 한 사람이 대개 짧은 시간에 결정 | 여러 사람이 검토하고 몇 주에서 몇 달이 걸림 |
| 판매 방식 | 가입하고 바로 씀 | 영업 담당이 상담, 시연, 견적, 계약을 거침 |
| 요청의 출처 | 많은 사용자의 작은 신호 | 큰 고객 몇 곳의 분명하고 강한 요청 |
| 지표의 단위 | 사용자 한 명 | 고객사(계정) 하나 |
| 변경의 부담 | 앱을 바꾸면 사용자가 적응 | 고객사의 업무 절차, 교육, 다른 시스템 연동이 함께 흔들림 |
이 차이 때문에 B2B 제품의 PdM은 “누가 고객인가”라는 질문부터 다시 해야 합니다.
구매에 관여하는 사람 나누기
한 고객사 안에서도 제품을 보는 눈이 다릅니다. 고객사마다 이름은 다르지만 대개 아래 역할로 나눌 수 있습니다.
표는 가로로 밀어서 볼 수 있습니다.
| 역할 | 주로 묻는 것 | PdM이 할 일 |
|---|---|---|
| 구매 결정자(부서장, 임원) | 이 제품으로 무엇이 좋아지는가, 비용 대비 효과가 있는가 | 제품이 해결하는 업무 문제와 효과를 숫자와 사례로 설명할 수 있게 준비 |
| 실제 사용자(현장 직원) | 내 일이 쉬워지는가, 배우기 어렵지 않은가 | 사용 데이터와 인터뷰로 불편을 찾고 줄임 |
| 관리자(고객사 IT 담당, 운영 담당) | 계정과 권한을 쉽게 관리할 수 있는가, 기존 시스템과 연결되는가 | 관리 화면, 권한, 연동, 데이터 내보내기를 기능으로 다룸 |
| 검토 부서(보안, 법무, 구매) | 보안 기준과 계약 조건을 지키는가 | 보안 문서, 데이터 보관 위치, 약관 질문에 답할 자료를 영업과 함께 준비 |
PdM이 사용자만 보면 계약이 안 되고, 구매 결정자만 보면 계약 뒤에 아무도 쓰지 않는 제품이 됩니다. 계약은 했는데 쓰는 사람이 없으면 다음 갱신 때 계약이 끝나기 쉽습니다. 두 쪽을 함께 봐야 하는 이유입니다.
맨 앞의 예로 돌아가면, 결재 단계를 원하는 쪽은 관리 책임이 있는 구매 결정자이고 입력이 많다고 말하는 쪽은 사용자입니다. 이때 질문을 바꿔 봅니다. 결재 단계를 원하는 진짜 이유는 무엇인가? 고객사 관리자와 이야기해 보니 “누가 무엇을 바꿨는지 나중에 확인할 수 있어야 한다”는 요구였다고 해 봅시다. 그렇다면 결재 단계를 늘리는 대신 변경 이력을 남기고 관리자가 확인할 수 있게 하면, 사용자의 입력은 늘리지 않고 구매 결정자의 걱정은 해결할 수 있습니다.
큰 고객 한 곳의 요청을 다루는 법
B2B에서 어려운 결정 가운데 하나는 큰 고객 한 곳의 강한 요청입니다. 매출이 걸려 있으니 거절하기 어렵고, 그대로 만들면 다른 고객에게는 쓸모없는 기능이 쌓입니다. 이런 요청은 아래 순서로 판단합니다.
- 요청 뒤의 문제를 확인합니다. 고객이 말한 기능이 아니라 그 기능으로 해결하려는 업무 문제를 적습니다. 영업 담당을 거쳐 온 요청이면 고객사의 실제 사용자나 관리자와 직접 이야기할 기회를 요청합니다.
- 다른 고객에게도 같은 문제가 있는지 확인합니다. 고객 지원 기록, 다른 고객 인터뷰, 영업 담당이 들은 내용을 함께 봅니다. 여러 고객에게 있는 문제면 제품 기능으로, 한 곳에만 있는 문제면 다른 방법을 찾습니다.
- 제품 안에서 해결할지, 설정으로 해결할지, 제품 밖에서 해결할지 고릅니다. 모든 고객에게 같은 기능을 주는 방법, 고객마다 켜고 끌 수 있는 설정으로 주는 방법, 연동이나 데이터 내보내기로 고객이 직접 해결하게 하는 방법이 있습니다. 한 고객만을 위한 맞춤 개발은 마지막에 고릅니다.
- 계약과 일정 약속은 PdM이 확인한 뒤에 합니다. 영업 과정에서 “다음 분기에 됩니다”라는 약속이 먼저 나가면 로드맵이 계약서에 묶입니다. 영업 담당과 미리 기준을 정해 둡니다. 예를 들면 “로드맵에 이미 있는 기능만 시기를 말할 수 있고, 없는 기능은 검토하겠다고만 답한다” 같은 기준입니다.
한 고객만을 위한 기능은 만드는 데서 끝나지 않습니다. 테스트, 문서, 고객 지원, 다음 기능과의 충돌까지 계속 비용이 듭니다. 그 고객이 떠난 뒤에도 기능은 남습니다.
영업, 고객 성공 담당과 함께 일하기
B2B 제품에서 고객을 가장 자주 만나는 사람은 PdM이 아니라 영업 담당과 고객 성공(도입 뒤 고객이 제품을 잘 쓰도록 돕는 일) 담당입니다. 이들의 정보를 제품 결정에 쓰려면 정해 둔 방식이 필요합니다.
- 요청을 한 곳에 모읍니다. 메신저와 회의에서 흩어지게 받지 않고, 고객사 이름, 요청 내용, 그 뒤의 문제, 계약 규모, 급한 정도를 같은 형식으로 남깁니다.
- 놓친 거래(수주 실패)의 이유를 받습니다. 계약이 안 된 이유가 기능 부족인지, 가격인지, 보안 심사인지 영업 담당이 짧게 적게 합니다. 몇 달이 모이면 제품의 약한 부분이 보입니다.
- 해지와 갱신 신호를 함께 봅니다. 고객 성공 담당이 보는 “사용이 줄어드는 고객사” 목록은 PdM에게 가장 빠른 경고입니다.
- 결정을 이유와 함께 돌려줍니다. 요청을 미루거나 거절할 때 영업 담당이 고객에게 설명할 수 있는 문장을 함께 줍니다.
고객사 단위로 측정하기
개인 고객 제품은 사용자 수와 사용 빈도를 봅니다. B2B 제품은 여기에 고객사 단위 지표를 함께 봅니다.
표는 가로로 밀어서 볼 수 있습니다.
| 지표 | 확인하는 것 |
|---|---|
| 라이선스(좌석) 사용률 | 계약한 사용자 수 가운데 실제로 쓰는 사람의 비율. 낮으면 갱신 때 계약 규모가 줄어듦 |
| 핵심 기능을 쓰는 고객사 비율 | 제품의 중심 가치를 실제로 쓰는 고객사가 얼마나 되는지 |
| 도입에 걸린 기간 | 계약에서 실제 업무에 쓰기 시작할 때까지의 기간. 길면 설정과 교육에 문제가 있음 |
| 갱신율과 확장 | 계약이 끝날 때 다시 계약하는 비율, 사용자나 기능을 늘리는 비율 |
고객사 하나 안에서도 부서마다 사용이 크게 다를 수 있습니다. 평균만 보지 말고 잘 쓰는 고객사와 안 쓰는 고객사를 나눠 무엇이 다른지 비교합니다.
변경을 배포할 때
B2B 고객은 제품이 바뀌면 사내 교육 자료, 업무 절차, 다른 시스템과의 연동을 함께 고쳐야 할 수 있습니다. 그래서 변경을 배포할 때 아래를 미리 정합니다.
- 화면이나 동작이 크게 바뀌는 변경은 고객사 관리자에게 먼저 알리고, 가능하면 관리자가 켜는 시점을 고를 수 있게 합니다.
- 연동에 쓰는 기능(API, 데이터 형식)의 변경은 충분한 기간을 두고 알리고, 이전 방식도 일정 기간 함께 지원합니다.
- 고객 지원과 고객 성공 담당이 같은 설명을 할 수 있도록 알림보다 먼저 자주 묻는 질문(FAQ) 문서를 준비합니다.
바로 쓰는 B2B 제품 점검 목록
- 주요 고객사마다 구매 결정자, 사용자, 관리자, 검토 부서가 누구인지 적었습니다
- 큰 고객의 요청을 기능이 아니라 그 뒤의 업무 문제로 적었습니다
- 같은 문제가 다른 고객에게도 있는지 확인했습니다
- 제품 기능, 고객별 설정, 연동 가운데 무엇으로 해결할지 정했습니다
- 영업 담당과 일정 약속에 대한 기준을 정했습니다
- 요청과 놓친 거래의 이유를 한 곳에 같은 형식으로 모읍니다
- 사용자 지표와 함께 고객사 단위 지표(라이선스 사용률, 갱신율)를 봅니다
- 큰 변경은 고객사 관리자에게 먼저 알리는 절차가 있습니다
B2B 제품의 PdM은 한 사람의 고객이 아니라 한 회사 안의 여러 사람을 상대합니다. 사는 사람의 이유와 쓰는 사람의 불편을 함께 확인하고, 큰 고객 한 곳의 요청을 여러 고객의 문제로 바꿔 판단하면 계약도 되고 실제로 쓰이는 제품에 가까워집니다.
참고
- 특정 자료를 옮기지 않고 널리 알려진 개념을 바탕으로 직접 썼습니다. 본문의 일정 관리 도구와 고객 요청은 설명을 위해 지어낸 예입니다.
- 요청을 받을지, 미룰지, 거절할지 판단하는 방법은 이 블로그의 「기능 요청 다루기」 글을, 여러 사람을 설득하는 방법은 「이해관계자 관리」 글을 함께 보세요.