brunch

라이킷 2 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이십사 Jan 05. 2023

고객사의 말은 곧이곧대로 듣는 게 아니다

왜곡하지 말고 잘 이해해야 한다

사용자의 말은 곧 '법'이라고 생각하고 서비스를 개발하는 팀이 많다. (특히 B2B에서)

대체적으로 요구사항을 적극 수용하고, 빠르게 개발하여 피드백을 주는 훌륭한 회사라고 볼 수 있다.

하지만 일정 규모 이상 커지고, 고객사/사용자가 많아지게 되면 이 전략은 더 이상 훌륭하다고만은 볼 수 없다.

고객사의 가장 흔한 거절멘트로는 '이것만 만들어주면 결제할게'가 있다.

우리는 그럼 이 이 기능을 만들어야 할까? 이때 따져봐야 할 조건은 3가지가 있다.

1. 이 요구사항을 누가 말했고 누구를 통해서 들었는가?

이는 요구사항을 정확하게 이해하기 위한 가장 핵심적인 부분인데, 보통 무시하는 경우가 많다.

요구사항을 실 사용자가 말했는지, 의사결정 권한이 있는 탑 레벨에서 말했는지를 알아야 한다. 실 사용자는 '불편해서' 말할 가능성이 많고, 탑 레벨은 '그럴 것 같아서, 혹은 그러고 싶어서' 얘기하는 경우가 많다. 후자의 경우 의도가 훨씬 짙다고 볼 수 있다. 고객사는 진짜 필요해서가 아니더라도, 계약하지 않을 명분을 만들기 위해서 혹은 개발사를 나름대로 검증해보기 위해서 요구사항을 툭툭 던지는 경우가 부지기수다. 이런 경우를 걸러내는 센스도 필요하다.

또한 말은 축약하고 전달하다 보면 본인 의견이 들어가 의도치 않은 왜곡이 생기기 마련이다. 보통 우리는 최전선에 있는 고객센터, 세일즈팀으로 부터 이 얘기를 전달받게 되고 그들의 경험을 존중하기 때문에, 그들의 입에서 나온 것이 고객의 소리 그대로 생각하는 경향이 있다. 하지만 우리 회사의 팀원은 회사에 대한 이해도(조직, 기능 등)가 높고 본인의 KPI를 신경 써야 하는 직업인이기에 의견을 관철시키기 위해 조금 과장되거나, 오히려 아예 묵살하거나 하는 경우도 있다는 걸 이해해야 한다. 팀원의 말을 무시하라는 뜻이 아니라, 최대한 팩트 위주로 가능하면 녹취를 들어서라도 뉘앙스를 그대로 이해할 필요가 있는 것이다. 잘 이해하고 공감할수록 좋은 프로덕트가 나오기 마련이다.

2. 이 기능이 필요하다고 할 때, 앞 뒤 상황(맥락)과 업무 프로세스는 어떻게 되는가?

단편적으로 '기능 A'가 필요하다고 말할 때에는 그 이면에 숨겨진 불편함, 이해관계, 특정 상황이 있을 거라고 가정해야 한다.

예를 들면 '매출합계를 뽑아주는 기능 만들어주세요'라고 요구사항을 받았다고 해보자. 기능은 간단하다. 데이터베이스에 가지고 있는 데이터를 엑셀로 저장할 수 있게 만들어 주면 된다. 하지만 도대체 왜 매출합계를 엑셀로 가지고 있어야 할까? 우리 서비스에서 모두 조회가능하고, 검색도 잘 되는데 말이다.

여기에는 여러 이유가 있다. '데이터가 날아가기 전에 아카이빙 하는 느낌을 내고 싶어서(소유)', '세금 신고를 용이하게 하기 위해서(세무, 법률)', '엑셀이 더 편해서(기능불편함)' 등..

하지만 내가 본 가장 흔한 이유는 '보스가 시켜서'이다. 보스는 직접 시스템을 들여다보기에는 바쁘고, 조작법을 익히기에도 용의치 않다. 왜인지는 따져봐야 하지만 내가 겪은 반복적인 업무의 대부분은 그랬다. 이 상황을 명확하게 이해하면 기능 개발에도 많은 영향을 끼치는데, 보고가 용이하게 개발할지, 단순히 엑셀만 뽑아서 주는지에 따라 해당 실무자의 만족도는 대폭 달라질 수 있다.

3. 스탠더드인가?

앞선 글에서 SaaS를 스탠더드로 생각하고 우리의 몸을 맞추자고 했다. 그렇다면 서비스를 만드는 입장에서 역시 대부분의 고객에게 최고의 효과를 가져다주는 '스탠더드' 인지를 매우 심도 있게 고민해야 한다. 이 고민은 단순히 20%의 고객이 아닌 80%의 고객을 위해 만들어야 한다는 '다수결'로 오해할 수가 있다. 하지만 어느 업계의 '스탠더드'가 된다는 건 업계 전반에 방향성을 제시해 줄 수 있는지에 더 가깝다.

매우 다양한 고객사를 만나보고 나오는 불만사항, 고객사가 보지 못하는 업계의 문제점을 종합해서 결정을 내려야 한다는 거다. 이때 데이터 분석도 해보고 인터뷰도 해보는 등 방법이 어찌 되었건 한번 기능개발이 되면 회사의 방향성이 변화되고 추후에 돌이키기 어려울 수 있기 때문에 결정의 무게감을 느끼고 가장 결정을 잘할 수 있는 사람이 결정하면 된다.

내가 본 어떤 회사는 적은 고객이 '화'를 낼 정도로 강하게 어필하는데, 데이터를 보니 스탠더드가 아니라고 판단했는지 요구사항을 들어주지 않았다. 나는 이 의사결정을 존중하지만 옳지는 않았다고 생각한다. 고객이 화를 낼 정도라면 소수의 고객이라고 하더라도 훨씬 깊게 프로덕트를 사용하고 있어서 나오는 문제점이었는데 잘 쓰는 사람 10명보다 덜 쓰는 사람 90명과 회사의 KPI(가령 MAU 등..)를 위한 의사결정이기 때문이다.

스탠더드는 절대 다수결이 아니며 만드는 사람의 철학에서 만들어지는 결과물이라는 사실을 명심해야 한다.

고객의 말은 그대로 정답이 아니라 여러 가지 힌트라고 생각하고, 그 힌트들을 종합하여 정답을 찾아내는 게 우리 메이커들이 할 역할이다. 고객의 말을 곧이곧대로 문제점이자 정답이라고 '땡큐'를 외치는 실수를 범하지 말자.

환자가 본인이 알고 있는 지식으로 '왼쪽 가슴에 통증이 있어요, 위통약 주세요' 했을 때 아무런 의심도, 진료도 없이 약부터 내주는 의사를 신뢰할 수 있겠는가? 사실 그 환자는 심장이 아픈 건데 말이다.

keyword