이번 포스팅에서는 고객 개발-제품 개발 간의 연결관계에 대해서 정리했습니다. 푸른밤의 Product Manager로서 B2B 서비스에서 고객과 지속적으로 커뮤니케이션하면서 고객이 겪는 문제를 정의하고 그 문제로부터 우리 제품의 next to do를 정의하는 과정에 대해 정리했습니다.
오늘은 제가 예전에 올린 UI 디자이너 채용공고에서 적었던 내용 중 “고객이 저기 있다. 가서 보든가, 묻든가 암튼 가자.”라는 문장에 함축된 ‘고객 개발’ 이야기를 하겠습니다.
제가 디자이너 소개를 부탁할 때, 항상 “푸른밤 제품 파트는 매주 한 번씩 고객을 만나는 것이 디폴트입니다. 그러니 디자인만 하는 디자이너보다는 이런 우리 행동이 이해가 되어야 합니다.”라는 당부를 했습니다. 이리도 중요하다 생각하는 ‘고객 개발’이 Product Management와 어떻게 연결되는지 적어보겠습니다.
고객 개발 : 고객은 본인이 원하는 게 뭔지 알고는 있다.
이 부분부터 시작하는 것이 좋겠네요.
고객에게 무엇을 원하느냐고 물으면 고객은 ‘더 빠른 말’이라고 대답할 것이다. – 헨리 포드
대부분 다 아는 말입니다. 실제로 고객을 만나서 저희 제품에 대해 물어보면 별의별 기능을 다 제안합니다. “이런 기능이 있으면 좋겠어요. 저런 기능이 있으면 좋겠어요.” 등의 얘기가 나오는데요. 제품을 만드는 사람 입장에서 봤을 때, 이런 기능이 도대체 왜 필요한가 싶은 것도 있고, 반대로 ‘그건 맞는 말이네요.’라고 속으로 말하게 되는 기능도 있습니다.
하지만 제가 이런 미팅에서 가장 집중해서 캐치하고자 하는 것은 ‘우리 고객이 이 기능을 제안하게 된 배경’입니다. 고객들은 제품의 개발과정과 그 과정에서의 어려움 같은 것을 생각하지 않으며, 또한 하기도 어렵습니다. 본인이 생각하기에 (겪고 있는 문제를 해결하기 위해서) 적합한 솔루션을 말하게 됩니다.
그렇기 때문에 고객이 “너네 제품 이렇게 했으면 좋겠어.”라고 말하게 되면 이 사람이 이 솔루션(기능)을 고안하게 된 문제가 무엇인지 확인하고 정의해야 합니다.
참고로 이런 문제-솔루션 연결 관계가 굉장히 비이성적인 경우도 있습니다. 그럼에도 불구하고 일단은 그 문제를 듣는 것이 중요합니다. 그래야만 문제-솔루션의 논리적 연결보다 더 중요한, 이 문제를 겪는 고객의 맥락을 이해할 수 있습니다.
이 맥락이란 것은 굉장히 다양합니다. 회사 내의 의사 결정권자의 업무 스킴, 고객사의 업무 처리 프로세스, 하다못해 상사의 니즈 등등이 있습니다. 이런 맥락과 문제의 나열에 대해서 고객들은 쉽게 얘기하지 않지만 한 번 얘기하면 쭉 얘기하게 되는데요, 이 모든 것들을 정리하는 것은 미팅이 끝나고 난 다음에 Product Management 입장에서 정리해야 합니다.
즉, 고객을 매주 만나서 고객에게 뭔가를 듣는 과정은 단순히 고객에게 어떤 기능을 만들어 줘야 하는가를 고객에게 듣기 위한 것이 아니라 고객이 겪는 문제에 대해서 공감하면서 <고객 개발>을 진행하는 것입니다. 그리고 전 B2B 서비스를 하기 때문에 고객을 그루핑하는 것이 B2C 서비스 대비 굉장히 쉽습니다.
근데 왜 자주 만나서 ‘고객 개발’ 하나요?
1. 고객과 저 사이의 거리를 좁혀야 하니까.
친분을 말하는 것이 아니에요. IT스타트업에 있는 분들이 하는 서비스에서 주 고객이 IT 스타트업이 아닌 경우, 좀 더 넓게 봐서 IT업계가 아닌 경우 고객과 본인의 라이프 패턴 자체가 아예 다릅니다. 이걸 고객을 계속 만나면서 단순하게 짐작하는 것이 아닌 vivid한 사례를 보는 것이 훨씬 더 편하고 좋습니다.
사소한 것이지만 저희 서비스를 이용하는 고객사를 방문했을 때, 고객이 쓰고 있는 랩탑이 램2GB짜리 PC여서 고객 사용 환경으로 세팅해서 테스트를 진행하기 위해 제가 저희 팀 분들에게 집에서 안 쓰는 랩탑을 좀 달라고 요청하는 내용입니다. 16GB 램의 MBP 레티나 15를 쓰는 저는 어지간한 웹페이지에서 어려움을 겪을 리가 없죠. 물론 이런 데이터 수집이 오히려 바이어스 된 데이터 수집일 수는 있으니 밸런스를 잘 잡는 것도 중요합니다.
2. 결국 친분
어찌 보면 친분이라고 할 수도 있는데요. 저같이 Product Manage하는 사람들이나 ‘고객 개발’ 담당자들이야 사람 만나서 인터뷰하고 대화하는 것이 자기 업인 사람들이겠지만 고객은 그렇지 않습니다.
샤이샤이샤이한 고객을 한 번만 만나선 고객의 얘기를 제대로 들을 수 없습니다. 결국 자주 만나면서 경계심을 풀게 해야 하고 친해져야 합니다. 그렇게 친해지게 되면 고객이 먼저 건의를 하게 되기도 합니다.
3. 어정쩡한 우선순위 기능의 우선순위 확정
제가 Product Managing을 하면서 고객 개발 과정에도 참여하는 목적은 명확합니다. 여러 고객군의 고객과 꾸준히 커뮤니케이션하면서 다음에 우리가 해야 할 일(have to do)를 정의하기 위함입니다.
대부분의 Product Manager 혹은 기획자분들은 아시겠지만 해야 할 일은 많고 시간과 사람과 돈, 그리고 기회는 늘 부족합니다. 그래서 우린 업무의 우선순위를 잡게 되고 그 우선순위에 따라 일을 진행하게 됩니다.
그런데 꼭 보면 이번 스프린트에 포함이 안 되고 다음으로 미루려는 일인데 지난번 스프린트에서도 밀려왔던 일들이 있습니다. 저는 이걸 중간 우선순위의 역설이라고 표현하는데요, 우선순위가 높은 일들은 자원 투입이 많더라고 하게 됩니다. 하지만 어정쩡한 우선순위의 일들은 대부분 ROI를 따지게 될 수 밖에 없는데 중간 우선순위 일들이 다 그렇듯 Return이 비슷비슷해 보입니다. 그럼 인풋이 적은 일이 선택됩니다. 시간이 지나면 계속 다음 스프린트로 넘어가게 되는 어정쩡한 우선순위 기능이 늘어납니다.
하지만 데이터상으로 어정쩡하다고 생각한 기능이 고객 개발 과정을 거치면 우선순위가 조정되는 경우가 많습니다. 대신 이때, ‘이 기능을 만드려고 하는데 어떻게 생각하세요?’라고 묻지 않습니다. ‘이런 게 좀 불편할 것 같다고 생각되는데 어떠세요?’ 혹은 ‘이런 문제를 너님이 겪고 있을 것 같은데 어떠세요?’라고 묻습니다.
이 과정을 거쳐서 더 나은 스프린트를 구성하기 위해 고객을 만나야 합니다. 이 과정 역시 우리가 생각한 이 기능의 “문제” 위주로 고객과 커뮤니케이션하는 원칙을 준수해야 합니다.
정리하며
물론 제가 하고 있는 것이 정답이라고 하긴 애매합니다. 제가 일하고 있는 푸른밤은 영업, 마케팅, 제품 담당이 따로 있어서 제가 이쪽 일만 해도 되는 여유도 있고요. 반면에 제가 대표로 있던 회사에서는 제가 이 일을 마케팅, 제품 관리를 다 해야 해서 고객 개발에 참여할 여유가 많이 부족했습니다.
그럼에도 불구하고 고객 개발이 중요한 이유는 고객을 지속적으로 만나면서 커뮤니케이션을 이어나가면 확실히 고객에 대한 이해도, 제품 개발의 고객 정합도를 exponential하게 증가시킬 수 있기 때문입니다.
하지만 이런 고객 개발의 과정 중 하나로 고객을 만날 때 꼭 아래의 사항을 주지하셨으면 좋겠습니다.
- 어찌 되었든 이 과정은 데이터 분석과 병행되어야 합니다. 안 그러면 목소리가 큰 고객에게 현혹될 수 있어요.
- 고객이 제안한 솔루션이 아닌, 고객이 겪는 문제와 그 문제를 둘러싼 맥락이 중요합니다. 그러고 나서 솔루션을 찾아야 합니다.
- 솔루션 간의 우선순위가 나눠질 때, 2~3단위의 스프린트 동안 계속 다음 스프린트로 밀리면서도 스프린트에서 사라지지 않는 일은 고객을 만나서 우선순위 재정의에 참고해야 합니다.
- 고객을 직접 만나기 어려운 경우, 하다못해 CS 업무에 Product Management 담당자들이 참여해야 합니다.
원문: Ahn Changyeong
