PM이 되어 다시 읽은 인스파이어드
좋은 제품을 만들기 위한 한걸음
모든 훌륭한 제품 이면에는 지칠 줄 모르고, 무대 뒤에서 최선을 다하는 누군가가 있다는 것이다. 그 사람은 제품 팀을 이끌며, 비즈니스 목표에 부합하는 방향으로 기술과 디자인을 통해 고객의 실제 문제를 해결한다.
제품 기획의 필독서로 불리는『인스파이어드』를 오랜만에 다시 꺼내 읽었다. PM을 꿈꾸던 시절 봤던 책이었는데, 실제 현업에서 경험을 쌓으며 다시 보니 같은 내용을 읽어도 느낌이 새로웠다.
예전에 읽을 때는 “나도 이렇게 본질에 충실한 제품 기획을 해보고 싶다”는 부푼 꿈을 품은 느낌이었다면, 지금은 현실적으로 “우리 조직에서도 정말 이런 개념들을 적용할 수 있을까?” 하는 의심 반, 희망 반의 마음이 든다.
결국 좋은 제품을 만든다는 건 혼자만의 인식 변화나 노력으로 이루어지기 힘들고, 다양한 방법론 또한 조직의 상황에 따라 다르게 적용할 수밖에 없는 요소들이 너무 많다는 것을 알았다. 그래서 책 속 내용을 마치 정답처럼 완벽하게 따라 할 수 없다는 걸 깨달았기 때문인지도 모르겠다.
그럼에도 불구하고, 제품 중심 조직을 만들기 위한 다양한 방법론과 강력한 제품팀이 지닌 핵심 프로세스들을 다시금 접하는 것은 큰 도움이 되었다. 그래서 이번에 책을 다시 읽으며 느꼈던 것을 정리해 보았다.
1. 지속적인 제품 발견과 실행
"모든 제품팀이 필수적으로 해야 하는 기본적인 두 가지 활동이 있다. 만들 제품을 발견하는 것과 시장에 그 제품을 전달하는 것이다."
우리 팀은 현재 듀얼 트랙 애자일 방법론(Dual-Track Agile)을 채택하여 진행하고 있다. 이터레이션 내에서 discovery(기획)와 delivery(디자인, 개발)라는 두 개의 트랙을 운영하며 지속적으로 제품을 개발하고 개선해 나가고 있다. 그러나 아직까지 우리 팀은 대부분의 스펙에 대해 두 트랙을 병렬적으로 진행하기보다는, 특정 스프린트에서 기획 스프린트 과정을 거친 뒤 디자인 스프린트를 수행하고, 디자인이 완료되면 개발로 넘어가는 방식으로 일하고 있다. 물론 위 과정 속에서 이해관계자들 간의 지속적인 소통은 이루어지고 있지만, 큰 맥락에서 보면 미니 워터폴 방식에 가까운 것 같다.
하지만 내가 PM 역할을 맡게 되면서, 어쩌면 나의 부족함이 오히려 팀의 긍정적인 변화를 이끌었던 걸까? 나는 아직 경험이 부족했기에 실무자들의 이야기를 더욱 귀 기울여 들었고, 기획 과정에서 고민이 생기면 실무자들에게 적극적으로 찾아가 조언을 구했다. 기획 단계부터 디자이너와 함께 더 나은 UI/UX를 고민하고, 개발자와 함께 실제 구현 가능성, 현재의 DB 구조나 기존 연계 기능에 대한 디테일한 논의를 시작했다. 과거의 기존 기획자 분들은 많은 실무 경험과 높은 도메인 지식을 바탕으로 디자이너나 개발자의 리소스 투입을 discovery단계에서 최소화했던 반면, 나는 오히려 디자이너, 개발자분들 모두 함께 제품을 만들어가는 빌더(bulider)라고 생각하고 discovery단계 또한 나만의 업무로 한정하지 않았다.
이러한 업무 방식이 이전보다 효율적인지는 잘 모르겠다. 하지만 나는 적어도 구성원 모두가 함께 참여하며 우리가 만드는 제품에 더 많은 책임감과 가치를 느끼게 되길 바랐다. 근데 어느새 그런 분위기가 팀 안에 조금은 자리 잡은 것 같아 요즘 조금 뿌듯하게 느끼는 부분이다. 물론 실무자 입장에서는 내 생각과는 다르게 “내가 왜 이런 것까지 신경 써야 하지?”라고 느낄지도 모르겠다... 그래도 아직까지는 이런 고민을 함께 나눠주시고, 때론 나보다도 더 적극적으로 의견을 제안해 주는 분들이 많아 늘 감사한 마음이다.
그렇다면 점점 진짜 듀얼 트랙 애자일로 가까워지고 있는 지금, 앞으로 내가 더 노력해야 할 부분은 무엇일까?
2. 검증된 제품 백로그의 중요성
"제품 발견의 목적은 좋은 아이디어와 그렇지 않은 아이디어를 빠르게 판별하는 것이다. 제품 발견의 산출물은 검증된 제품 백로그(validated product backlog)이다."
앞으로 내가 더욱 노력해야 하는 부분은 바로 제품 백로그에 있는 일이 만들 만한 가치가 있는 것인지에 대한 검증을 철저하게 하는 것 같다. 검증된 제품 백로그가 산출되는 과정은 아래 네 가지 중요한 질문의 답을 하는 과정이라고 한다. 이 질문들을 중심으로 하나하나 답을 해가며, 나의 역할을 명확히 하고 내가 기여할 수 있는 부분을 정리해 보았다.
1. 사용자들이 이 제품을 사용할 것인가? ( = 가치)
아직까지는 가치를 직접 발굴하거나 검증하는 작업을 경험하지 못했다. 지금까지는 주로 이미 과거에 검증된 문제 상황을 해결하는 방식의 기획 업무를 해왔기 때문이다. 앞으로는 좀 더 주도적으로 유저 인터뷰, 피드백 수집, 실제 사용 데이터 분석 등을 통해 다양한 관점에서 문제를 바라보고, 사용자의 진짜 니즈를 파악하여 가치를 발굴하는 역량을 키워야겠다.
2. 사용자가 이 제품을 어떻게 사용하는지 이해할 수 있는가? ( = 사용성)
UI/UX 리서치, 유저 플로우 설계 등 기존에 이미 실행하고 있는 것들도 있다. 하지만 앞으로 단순히 모든 프로덕트에 정답처럼 적용되는 그런 UI/UX를 설계하는 것을 넘어 우리 서비스의 일관성 유지나 인지적 편리성까지 디테일하게 고민해보고 싶고, 이를 위해 우리 서비스의 디자인 패턴이나 가이드라인을 가장 잘 이해하고 있는 디자이너와 함께 고민하고 적용하는 과정을 거쳐야겠다.
3. 우리 엔지니어가 이것을 만들어 낼 수 있는가? ( = 실현 가능성)
기획 초기 단계에서부터 기술적으로 예상되는 제약 사항, 보완이 필요한 부분 등을 명확히 하여, 필요하다면 기획안을 수정하거나 구현 범위를 조정하는 등 현실적인 접근을 해나가야겠다. 또한 프로젝트 관리 측면에서도 현재 진행 중인 이터레이션 상황을 명확하게 파악하여 ‘좋은 기능은 필수적으로 제공해야 한다’는 무조건적인 인식이 아닌 팀이 보유한 리소스를 현실적으로 고려하여 일정을 산정할 수 있도록 해야겠다.
4. 우리 이해관계자가 이것을 지지하는가? ( = 사업 유효성)
결국 우리가 만드는 제품 혹은 기능이 조직 성과에 임팩트를 가져올 수 있을지. 실제 조직 성과 지표에 도움이 될지, 조직이 더 우선시해야 하는 기능이 있는지. 제품 팀 내에서가 아닌 조직 전반적으로 우선적으로 생각하는 가치가 있는지도 같이 검토해야겠다.
마치며,
제품 관리자로서 '기본적'으로 갖추어야 하는 역량과 책임들은 비슷하다는 생각이 들었다. 각 챕터를 보면서 "이 내용은 다른 책에서도 본 적이 있는데", "이건 이미 알고 있던 건데" 하며 과거에 그런 제품 관리자가 되겠다고 여러 번 다짐했던 것이 떠올랐다. 하지만 막상 출근 후 업무에 치이다 보면 어느새 마음에서 멀어져 있는 경우가 많았던 것 같다. 그래도 이번에 책을 다시 읽고, 정리해 보며 내 본 역할에 대해 다시금 일깨울 수 있어서 좋았다. 그리고 이번에는 내가 그동안 부족하다고 생각했던 부분도 있었지만, 팀 내에 긍정적인 변화를 가져온 부분을 작성하며 스스로 팀에 기여하고 있다는 자신감도 조금 생긴 것 같다.
책에서는 제품 관리자의 책임을 이야기하며, 제품이 성공하면 팀의 모든 사람이 제 역할을 잘 해냈기 때문이고, 제품이 실패하면 그것은 제품 관리자의 잘못이라고 하였다. 역시 도메인을 떠나 '관리자(manager)'라는 직무는 성공의 영광보다는 실패의 책임을 더 무겁게 짊어져야 하는 자리라는 생각이 다시금 들었다.
아직은 경험이 부족하다는 이유로 팀원의 도움이라는 보호막 뒤에 있을지 모르겠지만, 앞으로 우리가 나아가야 하는 제품의 비전에 대해서 끊임없이 고민하고 고객, 데이터, 시장과 산업 등 제품 관리자가 깊은 이해를 갖추어야 하는 영역들에 대해서 집요하게 파고들며 좋은 제품 관리자가 되기 위한 자산들을 잘 쌓아 나가도록 해야겠다.
