brunch

You can make anything
by writing

C.S.Lewis

by 김선유 Aug 29. 2021

무엇이 고객을 기쁘게 하는가?

어떠한 기능도 Delighter 일 수 없다

소프트웨어 개발자인 우리는 '기능'에 대해서 정말 많이 생각한다. 제한된 리소스와 시간 안에서 '어떤 기능'을 개발해야 고객의 만족도를 높일지 말이다. 짧게는 스프린트, 길게는 분기별로 로드맵을 짤 때 우리가 반드시 개발해야만 하는 '기능'에 대해서 끊임없이 고민하고 그 과정에서 팀원들끼리 많은 논쟁을 하기도 한다.

내가 근무하고 있는 HR Platform 테크 스타트업인 Swingvy는 KANO 모델이라는 프레임워크를 개발할 '기능'을 카테고리징 하는데 참고하고 있다. 하나의 프레임워크가 우리가 프로덕트를 인식하는 철학(?) 마인드셋에 상당한 영향을 미치고 있는 것 같아 이에 대한 나의 생각을 정리해보려 한다.

우선 KANO Model이 무엇인지 간단히 살펴보자. KANO 모델은 고객 만족으로 직결되는 상품과 서비스의 속성 정의를 돕는 모델로, 1980년 일본의 카노 노리아키(狩野紀昭)에 의해 1980년대에 연구된 제품 개발에 관련된 상품기획 이론이다.

Kano 모델은 제품 품질의 영향을 미치는 구성요소로 크게 5가지를 소개한다(여기서는 3가지만 다루겠다).

Mandatory quality(a.k.a. basic, must-have quality): Mandatory는 기본적으로 반드시 갖춰야 하는 품질 요소이다. 예를 들어, HR Platform의 경우 회사 직원들을 추가하고 삭제하는 것은 당연히 제공해야 하는 기능이다.

Performance / one-dimensional quality: Performance은 요소/기능의 존재와 정도가 많을수록 고객의 만족도 커지는 품질 요소이다. 클라우드 file storage 서비스의 경우에 파일 다운로드, 업로드 속도는 빠르면 빠를수록 고객의 만족도는 높을 것이다. 다다익선의 품질요소.

Delighter / Attractive quality: Delighter은 고객이 기대하지는 않았으나 큰 만족을 주는 품질 요소이다. 이는 다른 경쟁자들과 차별화시키는 고유한 가치를 지니는데, 이는 Mandatory와 Performance를 모두 먼저 충족시켜야 효과를 발휘한다. Delighter가 없다고 해도 고객들은 그것을 찾진 않겠지만 꾸준히 Delighter가 투자한다면 고객에게 기쁨을 줄 수 있다.

나는 위의 KANO 모델의 3번째 요소인 "Delighter" 품질요소의 정의 자체에 대해 회의적인 시각을 가지고 있다. 고객이 기대는 하지 않은 요소이면서도, 다른 경쟁자들과 차별시키는 요소라는 게 있기는 할까? 다른 경쟁자에 대한 경쟁우위에 영향을 미치는 요소라면, 그것이 고객이 우리에게 기대하는 바가 아닌가? 어떻게 이러한 요소가 고객에게 있어도 그만 없어도 그만일 수 있을까? (우리가 개발하고자 하는 모든 기능은 고객의 피드백과 니즈에서 출발한 것이다. 어느 기능도 고객이 원하지도 않았는데 우리의 창의적인 발상에서 출발한 것은 없을 것이다.)

이처럼 기능을 3가지 중 하나의 요소중 하나로 분류하는 것은 결코 현실과 맞지 않는다고 생각한다. 3가지의 참고 사례를 통해 이해를 돕고자 한다.

참고 사례

원티드 - 관리자 페이지

원티드는 회사와 지원자를 연결해주는 인재 매칭 플랫폼으로, 지원 공고에 지원자가 지원을 하면 관리자 페이지에 지원자를 검토의견 할 수 있는 란이 있다.

근래에 평가점수라는 폼이 "Good", "Bad", "의견만 작성"이라는 라디오 버튼이 생겼다. 내 기억으론 전에는 '평가'라는 라디오 버튼이 없고 '의견 작성'이라는 텍스트 필드만 존재했었다. 라디오 버튼이 생기기 전, 우리 팀 같은 경우에는 '합격' 혹은 '불합격'이라는 텍스트를 직접 기입해 지원자 당락여부를 표시했었고, 그것이 불편하다고 느끼진 않았다.

처음 이 기능이 생겼을 때 나는 "오? 이런 기능이 생겼네? 생각도 못했는데 유용하겠군"이란 생각을 했었고 나에게는 Kano모델의 "Delighter" 정의와 딱 부합하는 경험을 주었다. 하지만 공고에 지원자가 하루에도 수십, 수백 명이 들어와 빠르게 합격, 불합격 의사표시를 해야만 하는 몇몇의 사용자들에게는 이 기능은 정말 필요로 하는 "Mandatory" 품질요소이지 않을까? 같은 기능이지만 어떤 사용자에겐 Performance이기도, Delighter 혹은 사용자 환경에 따라 Mandatory가 되기도 한다.

배달의 민족 - 선물하기

배달의 민족도 최근 '선물하기' 기능을 출시했다. 카카오는 선물하기 기능이 꽤 예전부터 있었는데 배달의 민족은 비교적 최근에 이 기능이 출시되었다.

역시 배민답다. 같은 선물하기 기능이라고 해도 카카오 선물하기에 6가지 이모티콘과는 발전한 형태인 것 같다. 고객의 상황에 맞게 굉장히 많은 '포스터'를 취향껏 고를 수 있다.

이것은 Mandatory인가, Performance인가, Delighter인가? 배민의 선물하기 UX(사용자 경험)에는 단순히 '포인트를 다른 사용자에게 선물할 수 있다'라는 기능을 넘어 배민만의 브랜드 아이덴티티가 고스란히 잘 드러나 있다. 배민에서 이 기능을 개발하기로 의사결정을 내릴 때, 다른 서비스들이 이 기능을 먼저 출시했으니 급하니 우선 금액을 보낼 수 있는 '기능'부터 출시하고 보자라고 했을까? 나는 결코 아니라고 생각한다.

배민 제품팀이 정의하는 Mandatory는 단순히 '배민포인트를 다른 사용자에게 보내기'라는 기능 이상의 브랜드 경험을 주는 것 자체가 Mandatory였을 것이다. KANO 모델에 의하면 선물하기 '포스터'는 Delighter라고 정의할 수 있겠지만, 배민의 선물하기 UX는 Mandatory이자, Performance, Delighter이어야만 한다라는 배민의 철학을 엿볼 수 있는 부분이다.

슬랙 - Write now, send later

주말에 종종 일을 하는데 동료에게 주말에 DM을 하기엔 미안하고, 그렇다고 해서 지금 할 말을 써놓지 않으면 까먹을 것 같아서 곤란한 적이 있는가? 그렇다면 일단 메시지를 보내 놓기보다는 내가 지정한 '시간'에 보내길 원했던 적이 있을 것이다. 이러한 슬랙 사용자들을 위해 최근에 슬랙은 "Write now, send later"라는 메시지 예약기능을 출시했다.

추측하기에 이 사용자 피드백은 오랜 백로그로 있었을 것 같다. 메시지를 미리 스케쥴링할 일이 없는 사용자에게는 뜻밖의 기능일 수 있겠으나, 오랜 기간 이 기능을 기다려온 고객에게는 매우 반가운 기능일 것이다. 그래서 이 작은 기능마저도 단순히 Performance다, Delighter다 라고 정의할 수 없을 것이다. 고객에 따라 니즈가 매우 높을 수도 전혀 아닐 수도 있기 때문이다.

위 3가지 사례를 통해 내가 말하고 싶은 요는 단순하다. 소프트웨어 제품 개발에서는 어떠한 '기능'을 KANO model 이 정의하는 3가지 카테고리 중 하나로 편하게 정의할 수 없다는 사실이다. 이를 가지고 '우선순위'를 메기는 것은 더더욱 위험해 보인다. 카테고라이징 하거나 큰 맥락에서 개념 잡을 때는 참고할 수 있겠지만, 기능 개발의 우선순위를 판단하기에는 비즈니스적인 부분도 고려가 되지 않는다.

때때로 이러한 프레임워크가 의사결정을 하는 데 있어 효율성을 높이기도 하지만, 사실은 더 깊은 고민과 가로막아 개발하려는 '기능'에 대해 되려 단편적인 사고를 하게끔 만드는 건 아닌가라는 생각이 든다. 1980년대에 만들어진 낡은 프레임워크보다는 팀에서 중요시 생각하는 가치를 반영한 자기만의 '프레임워크', 혹은 굳이 프레임워크가 아니더라도 'PMF(Product Market Fit)에 따른 우선순위' 기반으로 소통한다면 더 다각적인 인사이트를 가지고 의사결정을 할 수 있지 않을까?

처절하게 살아남아야 하는 스타트업 생태계에서 우리가 개발하는 크고 작은 모든 '기능'들이 사실은 살아남기 위한 몸부림일 것이다. 기업은 바보가 아니다. 우리가 하는 모든 액션은 서바이벌을 위한 전략적 선택이다. KANO모델이 정의하는 Mandatory(기본적으로 반드시 갖춰야만 하는 품질요소)만 개발한다면 우리가 이겨야 하는 경쟁사들과 어떤 차별점이 생길 것인가? 고객이 우리를 선택해야만 하는 이유, 다른 경쟁사들이 따라 할 수 없는 높은 장벽을 쌓기 위해 어떤 '요소'가 필요할지 치열하게 고민해야 한다.

KANO모델이 정의하는 Delighter에서 한 단계 나아가야 한다. 궁극적인 목표는 배민의 선물하기처럼(단순히 기능적인 차원을 넘어) 우리 모든 사용자 경험이 말 그대로 Delightful 한 수준으로 만드는 것이 아닐까.

keyword