서비스기획자가 UI,UX만큼 공부해야 하는 것
개발 언어가 아닌 구조, 그리고 비즈니스와 법의 영향도
개발적으로 복잡한 프로덕트에게 요구되는 기획자의 역량
작년에 진행했던 프로젝트는 인력의 한계상 많은 외주 기획인력을 썼었다. 실제 나아가야할 기획 방향을 진두지휘하는 인하우스 기획자로서 외주기획자에게 바라는 것은 문제를 정의하는 능력은 아니었다. 문제의 정의와 방향성은 이미 프로덕트를 설계하는 내쪽에서 정의했고 외주 기획자는 적합하게 빠르게 개발이 진행할 수 있을 만큼의 로직과 정책을 정의히서 진행해주기를 바랬다. 사실 이 부분은 아주 실질적인 부분이고 개발, 디자인 등에 대해서 정확히 이해하고 소통할 수 있어야했다. 근데 이커머스라는 복잡한 프로덕트의 특성상 많은 외주 기획자들이 힘들어한 포인트가 있었다. 바로 유즈 케이스가 사용자 레벨보다 데이터와 정산의 영역까지 고려되어야 한다는 점이었다.
예를 들면 주문의 취소버튼이 어디에 있어야 편할까만 고민하는 것은 하수, 중수는 취소가 어느 정책적으로 물류가 어떤 시점까지 가능하고 그 시점을 체크하기 위해서 어떤 데이터를 어떻게 체크할 수 있는지도 알아야한다. 더 나아가서 그 데이터가 처음부터 우리가 클레임을 구현할 때 활용할 수 있도록 설계되어 있는지도 판단할 수 있어야한다. 그리고 고수는 취소데이터를 생성할 때 추후에 정산 등에서 사유와 비용을 어떻게 처리할 수 있을지 판단할 수 있고 이 와중에 트레이드오프 관계를 판단할 수 있어야한다. 고객의 편의를 높이면 더 들어가는 비용관점도 알고 판단할 수 있어야한다.
이러한 관점이 어려운 가장 큰 이유는 고객의 UI레벨에서만 생각하는 버릇을 들였기 때문이었다. 구현의 방식과 로직은 관심에 두지 않고 오로지 Ui의 설계와 디자인적 요소에만 역량을 집중시켜왔기 때문에 실제 좋은 프로덕트의 구조적인 부분은 개발에 전가하는 것이다. 해결해야하는 문제만 던져주는 꼴이 된다. 기획자는 프로덕트의 중요성을 지속적으로 알리기 위해서 WHY를 설명한다. 그런데 개발에 보내는 케이스나 구조에 대한 고려없는 그림은 why도 what도 how에도 모두 못 미친다. 그저 주제의식 정도에만 해당하지 않나하는 생각이 들었다. 균형이 깨졌다.
어떤 기획자가 되어야하는가에 대해 고민하자
요즘 나의 고민은 그래서 어떤 기획자가 되어야하냐는 점이다. 애자일 방법론에서 기획은 How를 다루지 않아야 개발자의 역량을 발휘할 공간이 생긴다고 말한다. 하지만 비즈니스적인 영향도와 스프린트나 마일스톤을 쪼갤 개발 업무 우선순위를 정하려면 개발 구조에 대한 이해도는 필수적이다. 디자인과 UI, 텍스트의 정의도 중요하지만 구조적인 부분의 프로덕트를 다룰때는 결국 정책과 법이 시스템에 어떤 영향을 주는지에 대한 똑바른 이해가 중요하다. 재밌다고 해서 한쪽에만 치우쳐진 공부를 해서는 안된다.
만약 이 글을 읽으면서 아예 감이 안온다면 진짜 큰 일이다. 개발자에게 가서 내가 기획하는 것들에 대한 시스템적 이해수준을 넌지시 물어보고 본인의 역량이 혹시 치우친 것이 아닌가 생각해볼 때가 아닐까.
여튼 이에 대해서 요즘 많이 공감하고 고민하게 한 두가지 아티클을 공유하려고 한다. 안타깝지만 영어다. 조만간 이러한 생각들을 바탕으로 내 생각도 정리해서 내 아티클을 쓸 생각이다. 하지만 그 전에 관심이 많다면 먼저 읽어보길 추천한다.
인스파이어드로 유명한 마티 케이건의 아티클이다. 몇가지 문장만 뽑아봤다.
These people have this overly simplistic notion that product management and product design work to define the problem, and then engineering works to build a solution.
Such a nice, clean separation between what product and design do, and what engineering does. Unfortunately, this overly simplistic thinking usually kills any chance for real innovation.
hopefully it’s clear to you that this goes well beyond just engineering. It is the collaboration of product (representing value and viability), design (representing usability) and engineering (representing feasibility) that generates great products.
It is the interplay between these three dimensions. Technology enables better experiences and new functionality. Good user experiences aren’t just usable, but they increase value. And of course understanding the various legal, privacy, ethical, financial, sales, and marketing constraints informs the functionality, experience and value. It is the intense give-and-take between these considerations that can yield a winning solution.
https://svpg.com/discovery-problem-vs-solution/
두번째 아티클은 맥킨지가 발행한 product manager의 유형에 대한 글이다.
유형표를 보면서 자신의 역량과 현재상태에 대한 진단을 해볼 수 있었다. 담당하는 프로덕트의 성격에 따라서 좀 더 개발과 구조에까지 알아야하는 범위가 넓어지고, 좀 더 IT회사에 가깝다면 이 부분도 중요하게 다뤄져야함을 알 수 있다.
New responsibilities for product managers include overseeing the application programming interface (API) as a product, identifying and owning key partnerships, managing the developer ecosystem, and more.
