Product Management에 필요한 문서 작성법 커리어에 도움되는 아티클 237 어제에 이어서 오늘도 제가 좋아하는 '문서'에 대한 이야기입니다 :) 오늘은 제품이 만들어 지는 과정에 필요한 사양과 요구사항을 정의하는 문서에 대한 내용인데요. 이 콘텐츠만 참고해도 Product Manager 또는 서비스 기획자가 어떤 일을 하는 직무인지, 누구와 협업이 필요한 역할인지, 핵심 역량은 무엇인지 알게 될 것 같습니다. 아래는 저자가 이야기하는 제품 사양과 요구사항 문서에 대한 생각인데요. 크게 공감이 되어서 제 생각도 살짝 붙여보았습니다. 서비스 기획자와 Product Manager는 협업하는 직군 전문가의 역할을 이해하고, 기획 의도에 맞춰 자신들의 역량을 마음껏 발휘할 수 있도록 제품 요구 사항을 문서를 만들어낼 수 있어야 합니다. 문서를 처음보는 사람이라면 누구나 쉽게 이해가 되도록 풀어서 잘 설명해야 합니다. 제품을 기획하는 사람의 목적과 의도, 제품을 사용하게 될 사람이 제품을 통해 얻게 될 가치를 공감할 수 있도록 만들어야 합니다. 제품 사양과 요구사항을 설명하는 문서 뿐만 아니라 모든 문서는 반드시 완전히 완성된 상태로 리뷰를 진행하지 않아도 괜찮다고 생각합니다. 문서의 역할은 기본적인 논의의 토대를 마련하고, 이를 협업하는 구성원들과 리뷰하면서 부족한 부분을 보완하고 새로운 아이디어를 도출하는 과정을 돕는 장치이기 때문입니다. 제품 문서의 기본: 제품 사양, 요구사항 정의서 작성법 콘텐츠 제공 위키북스 저자 모준승 제품 및 서비스를 정의하는 가장 기본적인 문서에는 크게 두 가지 종류가 있습니다. 1) 제품 사양 문서(Product Spectification, 이하 'Product Spec') - "어떤 제품을 왜 만드는 것인가"라는 질문에 답하는 문서 제품을 정의하는 가장 기본적인 문서입니다. 제품에 관여하는 개발과 디자인, 마케팅, 비즈니스 담당자가 이 문서를 참고합니다. 따라서 제품 사양 문서는 여러 이해관계자에게 제품의 목표와 타깃 유저, 제품에 대한 세부 내용을 알려주고, 이를 토대로 조직이 제품의 청사진을 파악할 수 있도록 도와야 합니다. '여러 이해관계자가 보고 이해할 수 있어야 한다'는 의미는 모두가 이해할 수 있는 용어를 사용해 내용을 구성해야 한다는 뜻입니다. 그래서 제품 사양 문서를 작성할 때는 지나치게 기술적인 내용은 담지 않는 게 좋습니다. 2) 제품 요구사항 정의서(Product Requirement Document, 이하 'PRD') - "어떤 기능을 왜 만들 것인가"라는 질문에 답하는 문서 제품 요구사항 정의서는 제품 기능을 기획하는 단계에서 작성하는 문서입니다. 제품 사양 문서에서 '요구 사항'에 해당하는 부분을 보다 구체화한 문서입니다. '어떻게' 제품과 서비스를 만들 것인가 보다는 '왜' 제품과 서비스를 만들어야 하는지에 집중합니다. 제품 요구사항 정의서는 기획 문서인 동시에 제품과 서비스를 올바르게 만들기 위한 가이드를 제공합니다. 팀이 제품을 보다 효율적으로 만들 수 있도록 돕고, 사용자에게 긍정적인 가치를 전달할 수 있도록 고민합니다. 1. 개요 작성하기 1) 문제 정의 (우리가 만들 제품이 어떤 문제를 해결하기 위한 것인가) 문제 정의는 제품 사양 문서를 작성할 때 가장 중요한 부분입니다. 이는 곧 우리가 만들어갈 제품의 근본적인 존재 이유와 직결되기 때문입니다. 여기서 '문제'란 우리 제품을 사용하게 될 사용자가 원하는 것을 의미하며, 그 사용자가 원하는 것을 해결하는 것이 곧 제품을 만드는 목적이자 배경이기 됩니다. 2) 목적 및 배경 (왜 이 제품이 필요한가) 문제가 발생한 사회적 배경을 설명해도 되고, 제품의 기획 목적과 배경을 설명해도 됩니다. 우리가 만들고자 하는 제품이 왜 만들어져야 하는지를 설득시키면 됩니다. 3) 주요 사용자 (문제를 가지고 있는 사용자는 누구인가) 이제 이 문제를 겪고 있는 대상이 누구인지를 설명합니다. 앞에서 기술한 문제를 겪고 있는 대상이 바로 주요 사용자(Target User)가 될 것입니다. 4) 유저 스토리/유저 저니맵 (사용자가 우리의 제품을 어떻게 사용할 수 있을 것인가) 유저 스토리(User Story)는 주요 사용자가 문제를 해결하기 위해 행동하는 상황을 묘사합니다. 사용자가 겪은 문제 상황, 우리 제품을 인식하는 계기, 우리 제품을 사용해서 문제를 해결해 가는 일련의 과정을 그려보는 것입니다. 유저 저니맵(User Journey Map)은 유저 스토리를 시간 순서로 나열한 형태입니다. 보통 사용자가 문제를 해결하는 과정을 '인식→탐색→비교→사용→구매'로 구분할 수 있습니다. 각 단계별로 사용자가 취할 행동, 달성하고 싶은 단계별 목표, 해당 단계에서 사용자가 느끼게 될 감정이나 우리 제품과 맞닿을 지점 등을 명시합니다. 5) 사용자 가치(고객을 위해 어떤 일을 해야 할까?) 사용자 가치에는 사용자가 우리 제품을 통해 문제를 해결할 수 있는지, 제품으로 무엇을 할 수 있을지, 제품을 통해 어떤 가치를 느낄 수 있는지를 작성합니다. 사용자 가치는 앞서 명시한 문제와 목적 및 배경과 연관성을 가져야 합니다. 6) 개발 원칙 (제품을 만드는 과정에서 원칙은 무엇인가) 개발 원칙에는 의사결정 원칙이나 개발 가이드를 제시합니다. 이는 PM이나 기획자가 부재할 때, 개발자가 스스로 개발 우선순위를 선택할 수 있도록 도와줍니다. 2. 기회 및 임팩트 작성하기 1) 기회 기회란, 우리가 만들 제품의 제반 환경을 의미한다. 따라서 시장 환경, 사회적 분위기, 기술의 발전, 정부 정책 등을 기회로 볼 수 있습니다. 시장 환경 분석의 일환인 SWOT 분석이나 STP 방식으로 기재하는 게 일반적이나, 최근 트렌드나 정부 정책, 사회적인 분위기 등을 작성해도 좋습니다. 2) 가설 및 가설 검증 지표 실제로 제품을 출시하여 고객이 사용해 보기 전까지는 제품의 실효성이나 수익성을 명확하게 검증하기 어렵기 때문에, 가설을 수립하여 빠르게 검증하고 개선이 필요한 문제를 발견했을 때 해결 방안을 모색할 수 있습니다. 3) 임팩트 예측 우리 제품이 가져올 경제·사회적 가치 또는 사용자가 우리 제품을 통해서 얻게 될 가치를 의미합니다. 3. 제품 정의 및 요구사항, 마일스톤, FAQ 작성하기 1) 제품 정의 및 요구사항 제품 정의 및 요구사항에는 제품의 구체적인 형태를 제시하고, 제품을 구성하는 기능과 기술 요건을 작성합니다. 이 내용을 토대로 개발 및 디자인팀과의 논의를 진행하는데, 이때 구현 가능한 요인들을 산출합니다. 또한 비즈니스팀과는 제품이 나아가야 할 방향 및 전략을 도출할 수 있고, 이 과정에서 더 나은 제품이나 기술 방안이 논의될 수 있습니다. 2) 마일스톤 마일스톤에는 제품 제작 일정을 작성합니다. 글로 작성하는 경우도 있지만, 일반적으로는 타임라인으로 볼 수 있도록 바 형태의 간트 차트로 구성합니다. 3) FAQ FAQ에는 제품 사양 문서로 파악하기 어려운 사항이나 각 팀에서 궁금해할 수 있는 부분을 사전에 충분히 고민해서 작성합니다.