고객의 언어로 문제 정의
힘들지만 PM의 가치를 높여 주는 핵심 역량
들어가며
지난 글(마에스트로와 잡부 사이 어디, PM)에서 자신 있게 얘기한 PM의 정의를 복습하면 아래와 같다.
PM은 고객의 문제를
고객의 언어로
끊임없이 정의하는 직군
이 정의에서 가장 강조를 한 것은 고객의 언어이다. 고객의 언어로 문제를 정의한다는 것은 고객의 입장이 되어서 문제를 고찰하는 것이다. 평소에 몸 담고 있는 회사(비주얼 시장의 생태계를 혁신하려는 (주)미리디)에서도 시니어PM이라는 이름으로 주니어들에게 가장 많이 잔소리하는 부분이기도 하고, PRD를 리뷰하거나, 기획 논의를 할 때에도 가장 집중해서 캐묻는 부분이기도 하다. 그런데 지금 돌이켜 보면 왜 굳이 그렇게까지 강조하는 이유에 대해서 친절하게 알려준 것 같지는 않다. 그래서 이번 글에서는 고객의 언어로 문제를 정의하고 표현하는 것이 (1) 어떤 의미인지, (2) 어떠한 장점들이 있는지에 대해서 평소의 생각들을 이야기 해보려 한다. (그리고 회사에 가서 평소 했던 잔소리에 대해서 조금 더 친절하게 설명해야 겠단 생각이...)
고객의 언어로 문제를 정의하는 것은 어떤 의미인지
실무에서 문제를 해결하기 위해 기획을 하다 보면 크게 두 가지 관점으로 접근한다. 이 두 가지 관점을 어떻게 명명하는 것이 정확한 것인지는 모르겠지만, 나는 이를 (1) 공급자 언어로 문제를 정의하는 것 (2) 고객의 언어로 문제를 정의하는 것으로 구분한다. 공급자의 언어로 문제를 정의하는 것은 기능적 표현으로 무엇인가를 명세하는 것이다. 고객의 언어로 문제를 정의하는 것은 고객의 문제(불편)이 무엇인지를 지적하고 해결안을 명세하는 것이다.
고객의 언어로 문제를 정의하는 것 vs 공급자 언어로 문제를 정의하는 것
실무에서 접할 수 있는 간편한 예를 들면 "SNS 로그인 기능"과 같은 것이 있다고 하자. 이를 위의 두 프레임으로 얘기를 하자면 전형적으로 공급자 언어로 문제를 정의한 것이다. 아니 그러면 이를 어떻게 다르게 표현할 수 있다는 말인가? 사실 SNS 로그인 기능이 너무 쉽게 나오는 표현이지만, 이 기능이 왜 나오는지에 대해서 조금 더 파고 들면 매우 다양한 이유에서 나오고 있음을 알 수 있다.
1. 고객은 복잡한 비밀번호에 대한 피로감이 있다.
2. 고객은 복잡한 회원가입 절차에 대한 피로감이 있다.
3. 고객은 계정 복구를 하는 과정의 복잡함에 대한 피로감이 있다.
4. 고객은 개인정보가 안전하게 보호되는지에 대한 피로감이 있다.
5. 고객은 ...
그냥 퉁쳐서 SNS 로그인 기능 구현이라고 하면 되지만, 위에 열거한 각자의 이유들에 대해 천착하면 SNS 로그인과 다르게 접근하는 것이 더 효율적으로 해결하는 것일 수도 있다. 예를 들어, 복잡한 회원가입 절차의 피로감을 간단하게 UXUI 접근으로 해결할 수가 있다. 예를 들어, 규제가 많은 토스와 같은 금융 서비스에서는 SNS 로그인을 적용하기도 쉽지 않지만, SNS 로그인보다 더 편하게 회원가입을 유도하는 UXUI로 문제를 해결한 것이라 본다. (제약 속에서의 다른 최선) 개인정보의 안전한 보호에 대해서는 QR 코드 로그인과 같은 기능을 사용할 수도 있다. 최근 회사에서 로그인 유지 기능에 대한 이야기가 나왔는데, 보통의 서비스 관점에서 보면 너무나 당연한 것처럼 보이지만, 우리 서비스는 공용 PC에서의 사용이 많을 수도 있다는 부분 때문에 로그인 유지 기능이 되려 보안이 문제가 될 수 있다. 한 번 더 생각해 보면, 서비스에 존재하는 SNS 로그인 기능도 공용 PC를 많이 사용하는 우리의 입장에서는 보안상 불안한 기능일 수도 있다. (공용 PC에 카카오톡이 로그인 되어 있거나 하는 것은 꽤나 흔히 있는 사고이다.)
즉, 고객의 언어로 문제를 파고 들다 보면, 쉽게 SNS 로그인 기능을 구현하자라는 말이 나오기는 어렵다고 생각한다. (하지만 보통 쉽게 SNS 로그인 기능 구현해요! 라고 한다. 이 글을 열심히 쓰는 나 역시... 반성하면 그렇다.)
고객... 어려운 고객... 하지만 게으른 PM고객의 언어로 문제를 정의하는 것의 장점
고객의 언어로 문제를 정의하는 것이 어떠한 의미가 있는지가 위의 설명으로 간단하게라도 전달되었으면 좋겠다. 물론 공급자 언어로 정의를 해도 뛰어난 PM들은 여러 요인들을 잘 버무리면서 문제를 해결해 나간다. (분명 그렇게 잘하는 사람들도 매우 많다.) 그럼에도 불구하고 난 고객의 언어로 문제를 정의하는 것이 습관화 될 때, 실무적인 관점에서도 매우 중요한 장점들이 여러 가지가 있다 생각하고, 그것에 대해 간단히 얘기해 보려 한다.
1. 기능의 정의는 최선의 방법이 아닐 가능성이 높다.
앞서 고객의 언어로 문제를 정의하는 것의 의미에 대해서 간단히 얘기했지만, 공급자 언어로 문제를 정의하다 보면, 실제로 해결해야 하는 고객의 문제를 효율적이고 본질적으로 해결하는 것이 아닐 가능성이 높다. 꽤나 흔한 빈도로 고객의 관점에서 조금 더 생각해 보면, 처음에 떠올린 기능 외에 다른 해결책이 더 좋은 해결책일 가능성이 높다. 그리고 더 좋은 해결책인지가 확실하지는 않더라도, 더 효율적인 해결책이 나오기도 한다. 즉 고객의 언어로 문제를 정의하게 되면, 언제나 최선의 방법은 아닐지 몰라도, 그럴 가능성을 높여주며, 과한 액션을 취하는 것을 막아준다.
2. 고객의 입장에서 정의해야 백로그의 우선 순위를 정리하기 좋다.
개인적으로 생각하는 PM이 업무에서 챙겨야 할 가장 중요한 Top3를 꼽으면 반드시 들어가는 것이 백로그 관리인데, 고객의 언어로 문제를 정의하면 백로그 관리에 의미가 생기며 우선 순위를 고민하기 좋아진다. 백로그는 해야 할 것과 하지 않아도 될 것에 대한 구분이라 생각하고, 언젠가는 다 해야 하는 일들에 대해 정리하는 것이라 생각한다. 그럼에도 불구하고 어떤 것을 먼저 해야 할지에 대해 잘 정의를 해야 효율적으로 업무가 진행되기 마련이고, 이를 도와주는 훌륭한 프레임워크들이 많이 있다. 예를 들어 ICE, RICE, MOSCOW 등인데, 많은 PM들이 이를 잘 활용할 것이라 생각한다. 다만 이러한 프레임워크는 분명 좋으면서도 애매한 영역이 반드시 생긴다.
예를 들어 백로그1과 백로그2의 ICE 점수가 각각 105점, 106점이라고 하자. 진정으로 백로그2가 백로그1 보다 ICE가 1점이 높기 때문에 먼저 해야 하는 백로그라고 정의할 수 있을 것인가? (물론 그럴 수 있다.) 뭐를 먼저 하든 상관 없을 수 있지만, 이러한 영역에서 의사결정을 할 때, 고객의 입장에서 정의가 된 백로그는 많은 도움이 된다. 숫자가 아닌, 내러티브가 있는 서사는 사람을 본능적으로 이끄는 부분이 있기 때문이다. 고객의 목소리를 조금 더 세게 고객의 곡소리로 바꾸면, 더 구슬프고 찰진 곡소리들이 눈에 직관적으로 들어오기 마련이다. 그런데 이게 SNS 로그인 기능 구현이라고 정의되면, 와닿는게 달라진다.
3. 문제를 더 잘게 쪼개기 편리하다.
지난 글(마에스트로와 잡부 사이 어디, PM)에서 얘기했던 것 중의 하나는, PM은 문제를 끊임없이 정의하는 것이라고도 했다. (청과물 가게 사장님의 예를 들면서, 문제를 어떻게 쪼개었는지에 대해 이야기) 고객의 언어로 문제를 정의하면 문제를 더 잘게 쪼개는 것이 편리해진다. (상기한 SNS 로그인 기능을 구현하기 위해 고객의 언어로 4개 이상의 문제로 쪼개는 것) 대부분의 경우 큰 문제가 눈에 먼저 보이게 되고, 이를 해결하는 과정에서 더 작은 문제들이 잘게 잘게 쪼개어진다. 그리고 이를 잘 표현하는 구조가 애자일 프레임워크로 에픽과 스토리 구조이다. 유저스토리는 의미있는 고객의 문제 해결 단위라고 간단히 얘기할 수 있는데, 이는 배포의 단위가 되기도 한다. 고객에게 의미있는 변화를 주는 배포라는 것은, 애자일에서 강조하는 고객과의 소통 속에서 빠른 피드백을 받을 수 있는 단위라는 것을 의미한다.
기능을 명세함에 있어서 고객의 언어가 아닌 공급자의 언어로 하게 되면, 내러티브가 없는 기능만 주르륵 나열이 되기 쉽다. 그렇게 되면 이 기능이 왜 필요하고, 이 시점에서 이 기능을 내는 것이 맞는지, 그리고 이 기능이 고객에게 의미있는 변화를 주는지에 대한 판단이 서기 쉽지 않다. (버튼이 하나 생겼다고 고객에게 의미있는 변화를 주는 것이 아니다. 버튼을 통해 고객의 어떤 문제를 해결하는 것이 있다면 그것이 변화를 주는 것이다.) 하지만 고객의 언어로 정의를 하게 되면 큰 문제 속에 숨어 있는 자잘한 문제들의 연결이 쉬워지고, 큰 문제를 해결하는 과정에서 계속해서 고객과 소통할 수 있는 가능성을 높여 준다.
4. 문제를 해결했을 때의 성과와 임팩트를 더 의미있게 볼 수 있다.
평소 가지고 있는 생각 중 하나는 모든 지표는 고객을 바라봐야 한다는 것이다. 지표들은 고객의 무엇인가를 해결해주고 있음을 상징적으로 잘 보여줄 수 있어야 한다. 이때 이 지표를 설정함에 있어서 고객의 문제를 정말 잘 해결하고 있는지를 보기 위해서는 문제 자체를 고객의 언어로 잘 정의해야 한다. 조금 극단적인 예를 들면 SNS 로그인 기능 구현이라고 한 뒤 지표를 볼 때, 쉽게 생각해볼 수 있는 것은 SNS 로그인 기능을 얼마나 사용하느냐와 같이 접근하기 쉽다. 하지만 SNS 로그인 기능을 많이 사용했다고 과연 우리는 고객의 로그인 과정에서의 불편함을 해결했다고 자신있게 말할 수 있을까? 고객은 SNS 로그인을 하고 있지만, 다른 경로로 공용 PC에서 개인 정보가 털리는 불편함을 겪고 있을 수도 있다.
이와 관련해서 볼 만한 내용으로 북극성 지표라는 개념이 있다. 스타트업 종사자라면 대부분이 들어봤을 딜라이트룸의 알라미는 DAU(Daily Active User)가 아닌 DWU(Daily Woken User, 일일 깨운 유저)라는 지표를 정의했는데, 고객의 문제를 해결하는 것을 잘 정의한 지표라고 생각한다. (북극성 지표? 그게 스타트업에 왜 필요한데?)
어렵다... 하지만
나 역시 기능 명세가 편하고, 나의 두뇌를 믿으며 간단하게 정리한 기능 명세하면서(그리고 뭔가 기능 명세를 그렇게 하는 것이 때로는 멋있어 보이기도 한다. 공급자의 언어는 전문가 언어 같달까...?)로 고객의 문제를 해결했다고... 기억하려고 애쓰는 척을 하지만... 실제로 그렇지 않게 되는 것도 잘 알고 있다. 나는 그만큼 두뇌가 명석하지 않은 것도 알기 때문이다. 그래서 고객의 언어로 문제를 정의하는 것으로 계속해서 체화하기 위해 노력을 하고 있다. PM의 많은 역량들이 배우고 익힘으로 사용할 수 있 것이 아니라, 계속해서 습관적으로 체화해야 하는 영역의 것이라 생각한다. 체화는 쉽지 않다. 하지만 언젠가는 해야 하고, 하게 되는 것이다.
밥 먹는 것을 체화한다는 것... 여기서 3년이 지났지만 여전히 어른처럼 먹으려면...아이가 밥을 먹는 것이 체화가 되면, 부모가 너무 너무 너무 편한 것처럼, PM이 고객의 언어로 문제를 잘 정의하게 되면, 메이커들이 너무 너무 너무 편해진다. 그리고 고객들은 더욱 편해진다.
저의 이런 글은 저만의 생각이 아니라, 저와 함께 하는 그리고 함께 했던 많은 동료들과 소통하면서 가지게 된 공동의 산출물이라 생각합니다. 저에게 많은 생각을 던져 주고 함께 고민하는 미리디의 PM 동료들과 메이커 분들, 그리고 이전에 (주)두부의 동료들, 지금은 없어진 (주)네트워크디파인즈의 동료들께 항상 감사합니다.
