brunch

You can make anything
by writing

C.S.Lewis

by Jamin Nov 12. 2024

제품 발견, 수집하고 정리하기

(다시) 매일 글쓰기 (051/100)

무엇을 목표로 제품을 만들 것인가

제품 관리의 여정은 명확한 목표 설정에서 시작됩니다. 회사의 미션과 비전을 바탕으로 우리가 해결하고자 하는 문제를 정의하는 것이죠. 이는 단순히 제품을 만드는 것이 아니라, 고객의 진정한 니즈를 충족시키는 것입니다. 최소 기능 제품(MVP) 단계를 지나고 나서도 이 과정은 계속되어야 합니다. 시장은 끊임없이 변화하고 고객의 요구사항도 함께 진화하기 때문입니다.


하지만 현실은 복잡합니다. 우리는 종종 수많은 요구사항, 버그 리포트, 새로운 아이디어 속에서 헤맬 때가 많습니다. 이런 혼란 속에서 체계적인 정보 수집이 필수적입니다. 이를 위해 '수집함(Inbox)' 시스템을 구축하는 것이 좋은 시작점이 될 수 있습니다. 다양한 채널에서 들어오는 정보를 한 곳에 모아 관리하는 것이죠. 이때 중요한 것은 맥락을 최대한 보존하는 것입니다. 나중에 정보를 처리할 때 당시의 상황을 정확히 이해할 수 있어야 하니까요.


이걸 제품발견(혹은 제품 발굴, Product Discovery)의 과정이라고 보는 게 맞습니다. 제품 관리에서 가장 중요한 개념 중 하나죠. 고객의 실제 문제를 찾아내고 이해하는 과정입니다. 고객 인터뷰를 통해 직접적인 피드백을 얻고, 시장 조사로 전반적인 트렌드를 파악하며, 데이터 분석을 통해 객관적인 사실을 확인하고, 경쟁사 분석으로 우리의 위치를 가늠하는 것을 포괄합니다. 할 게 많고, 생산되는 정보량이 어마무시합니다.



제품을 잘 만들려면, 잘 적는 것이 우선이다

그래서 수집함을 잘 운영하는 것이 중요합니다. 회사의 여러 커뮤니케이션 채널에서 수집된 정보를 한 곳에 모으는 것이 좋습니다. 슬랙, 노션, 먼데이, 지라 등 여러 도구가 있지만 이를 하나로 통합하는 것이 필요합니다. 이를 위해 전사적인 소통 체계를 마련할 필요가 있을 수 있습니다. 그리고 수집할 때는 가능한 한 맥락을 보존해야 합니다. 수집 즉시 처리하지 않고 다른 과정을 거칠 예정이므로, 배경 정보를 충분히 적어두어야 합니다. 수집 대상은 요구사항, 발견한 문제, 새로운 아이디어 등 다양합니다. 가끔 머릿속에만 있는 것들도 있습니다. 귀찮더라도 일단 꺼내어 적어야 합니다.


이 단계에서 수집한 정보는 온전하지 않을 수 있고, 가설일 수 있습니다. 틀릴 수 있다는 생각으로 많이 모으는 것이 유리합니다. 이것이 재료 수집의 과정입니다. 다시, 수집한 재료에는 고객의 소리, 버그 등 다양한 채널이 포함됩니다. 이 수집 내용이 제품에 바로 반영되지 않을 수도 있지만, 우선은 다 적습니다. 어떤 게 중요한지 지금은 알기가 어렵습니다. 대원칙! 사용자 중심으로 생각하고 공감하려 해도, 사람인지라 완전히 공감하기는 어렵습니다. 그러니 우선 수집하고, 다음 단계에서 정리합니다. 대신, 수집하는 과정에서 직접 영업팀이나 고객과 소통할 때, 수집한 모든 것을 해결하겠다고 약속하는 것은 피해야 합니다. 실제로 이게 문제인지 아닌지도 아직 검증하지 않은 상태니까요.



제품을 잘 만들려면, 정리정돈의 반복이 필요하다.

수집한 일감과 별개로, 달성하고자 하는 목표가 떠오른다면 자유롭게 적습니다. 그런 다음 이 목표들과 수집된 것들을 합쳐서 분류합니다. 목표에 일감이 포함되는 것이 일반적이지만, 새로운 목표가 나올 수도 있습니다. 이 단계에서는 구조화에 얽매이지 않고 최대한 많은 아이디어를 나열합니다. 군집을 찾는 수준에서 정리하고, 완벽을 추구하지 않습니다.


놓치는 것이 있을 수 있지만, 이는 수집 과정의 문제이니 여기서는 합치고 쪼개는 것에 집중합니다. 달성 가능성과 구체성은 이후 문제로 변환하면서 다시 정리할 수 있습니다. 일단 적고, 가능한 수준에서 분류합니다. 너무 많은 시간을 쓰지 않도록 주의합니다. 이는 일종의 프렙(재료 준비) 과정으로, 어떤 일이 있을지 미리 살펴보는 것입니다. 물론 이 과정이 잘되면 다음 단계가 쉬워지지만, 여기에 너무 많은 에너지를 쏟지 말아야 합니다. 단계를 나누는 이유는 각 단계의 부담을 줄여 실행을 더 집중적이고 빠르게 하기 위함입니다.



발견된 것을 목표로 만들어보기. 

다음 단계에서는, 발견된 것을 기반으로 목표를 작성합니다. 완벽하지 않아도 좋습니다. 물론 여기서 Jobs-to-be-done이나 User Story 나 여러 가지 프레임워크를 도입해 볼 수도 있지만, 일단은 자유롭게 '목표'라는 큰 틀에서만 정리합니다. OKR에서의 Objective를 '대충' 쓰되, 주술관계가 분명하고 가능한 5W 1H가 포함된 형태의 문장으로 씁니다. 특히 Measurable, Time-bound, Relevant에 집중합니다. 이 세 가지 요소는 목표의 제약 조건을 결정하는 데 중요합니다. 


이 중, 측정 가능성은 늘 어려운 부분입니다. 목표를 어떻게 측정할지(성공 기준)를 설정해야 합니다. 데이터나 숫자에 근거하면 좋지만, 우선은 무엇을 성공이라 부를지 묘사하는 것도 괜찮습니다. 성공의 정의를 간략하게라도 써두는 것이 추후의 제품 발견에서 제품 전달(Deliver)로 넘어갈 때 주요한 기준이 될 수 있긴 합니다. 그렇지만 여기서 너무 힘쓰지 맙시다. 다시, 잘게 쪼개어 접근하고 있으니 여기서는 '목표화'의 초안을 잡는다고만 생각합시다. 


목표화가 되려면, 시간 제약을 걸어야 됩니다. 시간 제약이 없는 목표는 그냥 꿈에 불과하다고 누가 말했죠. 또 당연한 거지만, 우리의 제품의 새로운 목표가 제품의 비전과 회사의 목표와 정렬이 되어 있는지 관련성도 따져야겠습니다. 다시, 여기서 구체화에 너무 집착하지 말아야 합니다. 일종의 초벌구이 정도로 생각해야 합니다. 이번 구체화의 목적은 카테고리화와 정렬을 위한 것입니다.



가차 없이 오와 열을 맞추기

이후에는 도출된 목표를 카테고리로 묶고, MECE 원칙(겹치지 않고, 빠지지 않도록, Mutually Exclusive, Collectively Exhaustive)에 따라 정리합니다. 목표를 합치거나 나눌 수 있습니다. 규모는 상황에 따라 다르지만, 한 분기 정도의 일에 집중할 수 있는 수준이 현실적입니다.


그리곤 각 목표 간의 관련성과 의존성을 파악해 정렬하며, 겹치지 않도록 우선순위를 정합니다. 동등한 우선순위는 두지 않습니다. 나중에 바꿔도 되니까, 정렬 알고리즘을 생각해 보면서! 무조건 순서를 두어 정렬합니다. 기준은 이 단계에서는 비즈니스나 고객에게 주는 가치를 기준으로 정합니다. 난이도나 시간 같은 제약 조건은 나중에 다시 반영할 수 있습니다. 즉, 여기서는 목표의 가치(Desirability)에 집중합니다(디자인 싱킹 방법론에서는 이거 다음에 feasibility, viability 따지라고 하죠). 


어차피 우선순위는 반복적으로 수정되고 재평가되며, 지속적으로 관리될 것입니다. 아직 의사결정을 내린 게 아니니, 가차 없이 순서를 메깁니다. 이 작업은 하루, 일주일, 한 달 단위로 반복해 진행해야 합니다. 반복이 중요합니다. 새로운 수집된 할 일, 목표가 있을 것이기 때문에 평가는 주기적으로 일어나야 합니다. 그리고 그 과정에서 다양한 사람의 의견도 넣게 되겠지요. 그러니, 특히 처음 할 때는 이래도 되나? 이거랑 이거랑 이게 맞나? 하는 의문이 들 때 직감을 따라도 됩니다. 일단은요. 



끝나지 않은 여정

이 과정의 결과물은 제품이 아닐 것입니다. 로드맵이나 기획서도 아니고요. 따라서 이 문서를 들고 어디 가서 이야기를 하면, 그래서 뭘 하라고? 의 질문이 나올 수도 있겠죠. 더 다듬어야 할 것입니다. 그럼에도 이 목록이 관리되는 것이 중요합니다. 무엇을 무시하고, 어디에 집중할지 알 수 있게 되니까요. 워런 버핏이 목표를 적고 줄여나가라고 한 것과 같습니다. 가능한 목표를 줄이되, 놓치지 않기 위해 우선 모든 것을 기록하고 나서 줄이는 것입니다.


그래도 이 과정을 거치고 나면 어떤 제품을 만들고, 어떤 기능을 개발해야 할지에 대한 큰 그림이 그려질 것입니다. 물론 이 모든 과정이 선형적이지 않을 수 있고, 순서가 바뀔 수도 있습니다. 중요한 것은 제품 발견이라는 큰 작업에 대한 이해입니다. 제품은 고객의 문제를 해결해야 하므로 상상이나 예술적 영감으로 만드는 것이 아닙니다.


그래서 발명이 아닌 '발견'입니다. 찾아내는 것이 우선입니다. 발명은 이 발견된 것을 어떻게 구현할지의 문제로, 주로 디자이너와 개발자의 역할이 더 클 수 있습니다. 결국, 제품 발견은 ‘문제의 발견’과도 같습니다.



초고: 2024.09.11 

탈고: 2024.10.03

매거진의 이전글 삶의 원칙: 틀리는 게 안 하는 것보다는 나을지도
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari