리서처의 주된 역할은 "데이터를 근거로 무엇을 어떻게 만들까에 대한 결정의 불확실성을 낮추는 일"이라고 할 수 있다. 그렇다면 프로덕트 개발 전반에 걸쳐 이 소금과 같은 그들의 스킬셋이 부재한 회사는 어떻게, 무엇을 근거로 의사결정을 내리는가. 내가 현재 일하는 회사도 디자이너는 여섯이지만 리서처는 없다. 이런 환경에서 우리 회사는 어떻게 굴러가는지 간략하게 소개하고자 한다. (best practice가 아닌 이렇게 하는 경우도 있구나 하는 정도로 이해해주면 좋을 것 같다) ----- 1️⃣ 무엇을 만들까/어떤 문제를 해결할까 우리는 PLG(product-led growth)에 전혀 의존하지 않은 세일즈 중심으로 돌아가는 B2B회사다. 그래서 프로덕트가 해결해야 할 문제 정의가 이루어지는 단계에서 세일즈와 커스터머서비스(CS)의 인풋을 많이 반영한다. 그들은 고객과 긴밀한 관계를 가지고 있기에 여과되지 않은 인풋을 전달해 줄 수 있지만 실제로 프로덕트를 사용하는 엔드유저의 피드백이라기 보다 CS와 터치포인트를 가지는 소위 buyer나 champion들의 피드백인 경우가 많아 제한적이긴 하다. 더불어 CS에서 POC(proof of concept: 제품구매 결정 전 고객이 일정 기간동안 프로덕트를 사용해보는 트라이얼의 개념)를 진행하는 동안 받는 피드백들도 프로덕트 조직으로 유입된다. 그들이 결국 구매하지 않기로 한 경우(churn)에도 유용한 배움들을 얻을 수 있다. 우리 회사의 경우 "X에서는 이게 되는데 너희 프로덕트는 왜 이런 기능이 없니"라는 종류의 피드백이 많아 이 또한 Jira백로그에 쌓이게 된다. (슬랙과의 인터그레이션을 통해 티켓 모양 이모지를 달면 슬랙 메세지가 Jira티켓으로 전환되는 시스템도 사용 중이다) 그리고 이것들이 프로덕트의 비전과 전략과 아우러져 크게 몇가지 initiative들이 정의 내려진다. (이 부분은 내가 참여하지 않는 과정이기에 이렇게 대충 넘어가자) ----- 2️⃣ 어떻게 만들까/어떤 솔루션을 구현할까 이 단계에서 디자이너는 대략적인 솔루션을 몇가지 구체적 디자인 안으로 녹여낸다. 그리고 나면 피엠, 테크리드와 협업하여 다음 두가지 질문에 답하며 솔루션에 대한 불확실성을 줄여나간다. - 이렇게 만들면 유저들이 효율적으로 잘 쓸 수 있을까? (usability) - 이렇게 만들면 시간 내에 개발할 수 있을까? (feasiblity) 이때 우리 회사에서 적극 활용하는 것이 바로 dog fooding이다. 우리가 만드는 툴이 엔지니어를 타겟으로 하는 것이라 내부적으로도 많은 피드백을 끌어낼 수 있다. 이 단계에서 디자이너는 동료 개발자를 인터뷰하거나, 슬랙으로 디자인을 설명하는 짧은 동영상을 공유하여 피드백을 모으는 형태의 리서치를 한다. 우리가 하지 않는(못하는?) 리서치의 방법은 usability.com과 같은 툴을 통해 unmoderated research를 하는 것이다. 타겟이 일반 컨수머가 아니기에 참여할 사람을 찾는 것이 어렵기도 하고 내부적으로 그러한 인프라가 구축되어 있지도 않다. 있다고 한들, 디자이너가 디자인 하기도 바쁜데 다각도의 리서치를 하는 것은 실질적으로 불가능한 일일 것이다. 우리 회사가 굴러가는 모습이 사실 이상적인 모습은 아니라고 생각한다. Product Analytics를 전문적으로 담당하는 사람이 없어 정량적인 데이터를 통한 의사결정도 매우 약하고, 다양한 루트로 모여지는 피드백을 쉽게 기록하고 접근할 수 있는 레파지토리도 부재하다. 좀 주먹구구식이라는 생각이 들지만 여튼 굴러는 간다. 그리고 나는 내 위치에서 내가 할 수 있는 것을 하고 있다. 하지만 좀 더 전문적이고 깊이있는 리서처가 있다면 더 경쟁력있는 제품을 분명 만들 수 있을텐데 하는 아쉬움이 있다. 그것 또한 리더쉽이 판단하는 trade-off겠지만.