Stop Gathering Requirements
고객이 해결해야 할 진짜 문제를 찾고, 표현하고, 실행하자.
백그라운드.
Product Manager가 무난하게 과제를 진행하는 모습을 생각해보면, 내부/외부 고객들의 "요구사항 수집"을 통해 해야 할 일을 정의하고, 우선순위를 정한 다음에 차근차근 업무를 수행해 나갈 것이다. 과연 제대로 된 Product를 만들고 있다고 할 수 있는가? Value-add 할 수 있는 Product manager로서 무엇을 해야 하는지, 무엇이 중요한지, 늘 고민하고 집중해야 할 숙제가 여기 있다. 바로 훌륭한 Product Manager는 올바르게 문제를 간파 할 수 있어야한다는 것이다.
누군가 벽에 구멍을 뚫기 위해 "드릴이 필요하다"는 요청을 했다고 해보자. Requirement 에만 집중하다보면 어떤 성능의, 어떤 가격의 드릴이 필요할까에 집중하게 된다. 그러나 생각해보면 정작 해결해야할 문제는 "벽에 1cm 구멍이 필요하다"이다. 망치와 못이 있다면, 바로 만들 수도 있었던 것이다. 마케팅에서 고객 want가 아닌 need를 파악하라고 강조할때 주로 예시로 드는 내용이지만, product requirement에서도 마찬가지이다. 주로 고객들은 need가 아닌 want를 이야기 하기 때문에.
Stop Gathering Requirements
제목을 보고 뜨끔한 포스팅이 여기 있다. 내용을 요약해보면, 그저 그런(심하게 말하면 나쁜!) Product Manager는 "고객 지향"에 근거하여 고객 인터뷰 및 내부 Stakeholder와의 커뮤니케이션을 통해 요구사항을 수집하고 Feature list를 정리한다. 이러면 성공적인 제품을 만들 수 있을 것 같지 않은가? 저자는 좋은 Product Manager가 되고자 한다면, Request의 이면에 있는 Unmet Needs를 간파하고, 인사이트를 통해 Requirement를 Drive 할 수 있어야 진정한 Product Manager가 될 수 있다고 한다.
보통의 경우 고객들은 그들이 진짜 원하는 것, 본질적인 문제를 모른다. Product Manager라면 고객/내부 이해관계자보다 높은 수준의 이해와 인사이트를 통해 초기 Requirement에 Value-Add 하여 더 나은 솔루션을 도출할 수 있는 기회를 찾아야 한다.
개인의 역량과 노력 그리고 노하우가 수반되어야겠지만, 이러한 접근에 대해 참고할 수 있는 방법론은 무엇이 있을까?
진짜 문제를 찾고 해결하기 위한 방법
“If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it,”
- Albert Einstein
1) 먼저 Stakeholder가 "요청"이 아닌 "문제"를 이야기하도록 하라.
먼저 요구사항을 전달한 Stakeholder가 있다면, "비즈니스/고객 문제"로 설명할 수 있도록 도와줘야 한다. Feature와 같은 요청사항이 아닌, 해결해야 할 문제가 무엇인지 그들이 표현할 수 있도록 유도하고 결과적으로 Requirement를 Business Problem으로 Reframing 할 수 있도록 도와줘야 한다는 얘기다. 방법론이라기보다는 Product를 함께 만들어가는 이해관계자와 일을 할 때 어떤 식으로 업무를 처리하고 그들을 Education 할지에 대한 Mind-set에 가까운 얘기다. 자세한 내용은 아래 포스팅을 참조.
2) 이제 그럼 해결할 문제를 찾아 정의하라.
혁신 분야에서 가장 저명한 학자인 Clayton M. Christensen은 고객이 해결해야 하는 근본적인 문제를 "Jobs To Be Done"이라고 부른다. "Finding the right job for your product"를 참고하면 해결해야 할 고객 문제는 관찰하고 - 참여하고 - 글로 써보고 - 생각하는 과정에서 찾는 것이라고 했다. 어디를 살펴봐야 하는지, 어떻게 살펴봐야 하는지, 어떻게 인사이트를 도출하는지는 아래 포스팅을 참고해보자.
3) 고객의 job을 표현하고 실행하기: UX / 서비스 디자인 접근법, Agile 방법론
바라보는 관점이 차이가 있긴 하지만, "고객의 Job"을 찾아내고 / 정의하고 / 과제화 한다는 관점에서 아래와 같은 다양한 접근법들이 있다. 함께 참고하면 좋겠다.
UX 접근법으로 Job 찾기 - 목표 지향 디자인 / 멘탈모델
. UX 분야 구루인 앨런 쿠퍼는 "목표 지향 디자인"이라는 관점을 유행시켰다. 고객의 목표와 과업 그리고 Context를 강조한다. 마찬가지로 기능이 아닌 고객의 과업을 아주 중요하게 강조하고 있다. UX나 서비스 기획업무를 하는 분들은 Must-Have 아이템이 아닌가 싶다.(아주 두껍다)
. 사용자의 "멘탈 모델"이라는 용어도 소개된다. Affinity Diagram이라는 탬플릿을 통해 사용자의 Job을 탐색해볼 수 있다.
서비스 디자인 접근법으로 표현하기 - Journey Map, Experience Map
. Adaptive Path, Frog Design 등 유명 디자인 펌들은 User Journey Map, Customer Experience Map 등 사용자/고객의 Process를 기반으로 문제를 정의한다. 위에서 언급한 멘탈모델과 비교하여, Experience Map은 좀 더 완성된 형태의 Consulting 산출물에 가깝지 않은가 생각된다. 이 분야에서 독보적인 회사들이 뽑아내는 Visual과 인사이트 수준을 직접적으로 참고할 수는 없겠지만, Experience Map에서 추구하는 방향과 평가 속성들은 참고할 만하다.
Agile 방법론으로 실행하기 - User Story Mapping
. Scrum 방법론에 따라 User Story를 정의하고, 이를 각 Sprint에 Align 하는 방법을 소개한다. 제대로 해본 적은 없는데 최근 회사에서 시도하고 있어서 조만간 해볼 것 같다. Agile 방법론을 적용하고 있거나, 혹은 Feature List기반으로 구현에만 몰입하여 본질을 놓치고 전체를 조망하지 못하는 실수를 자주 범하는 과제가 있다면 이 방법을 참고해보자.
이런저런 이론들과 Tool들이 있지만, 사실 소화하기도 어렵고 내 회사에 안 맞을 수도 있다. 무엇보다 중요한 것은 Product Manager가 requirement에 대해 어떤 생각과 태도로 업무를 수행하느냐이다. Stakeholder가 요청사항이 아닌 문제를 표현하도록 유도하며, 진짜 문제를 찾아 Job으로 정의하여, 좋은 솔루션을 도출함으로써 훌륭한 Product를 만들 수 있을 것이다.
