커리어에 도움되는 아티클 229 일을 하면서 문서화의 중요성을 깨달은 것은 특히 스타트업에서 근무한 경험이었습니다. 넘치는 아이디어와 다양한 의견을 채팅 채널과 회의에서 논의되고 휘발되어 버리는

커리어에 도움되는 아티클 229 일을 하면서 문서화의 중요성을 깨달은 것은 특히 스타트업에서 근무한 경험이었습니다. 넘치는 아이디어와 다양한 의견을 채팅 채널과 회의에서 논의되고 휘발되어 버리는 경우가 많았기 때문입니다. 이와 같은 사례를 극복하고자 문서를 간단히 만들고 저장하는 습관을 들이고 있습니다. 문서가 없이는 회의를 시작하지 않고 회의가 끝나면 문서를 바로 만들고 공유하는 것입니다. 오늘 소개하는 프로덕트 매니지먼트를 위한 원 페이저 문서 작성 방법은 우리가 잘 아는 아마존의 식스 페이저와 유사합니다. 제품에 대한 스토리를 담아서 제품을 만드는데 관여하는 구성원에게 공유하기 위한 목적입니다. 그럼 프로덕트 관리를 위한 원 페이퍼에는 어떤 내용이 들어가고, 어떻게 작성하면 좋을지 콘텐츠를 확인해 주세요 :) 모두의 이해를 높이는 원 페이저 작성법 저자 모준승 저는 PM(product manager)이 되면 가장 먼저 제품의 히스토리를 살핍니다. 특히 제품이 만들어진 배경과 제품이 해결하고자 하는 문제, 그리고 그 문제를 어떻게 해결하려고 노력했는지에 대한 기록을 중요하게 봅니다. 히스토리를 보는 이유는 두 가지입니다. 앞으로 만들어갈 제품의 방향성을 수립하기 위해, 그리고 고객이 우리 제품을 쓰는 이유를 알기 위해. 그런데 대부분의 팀에는 제품에 대한 히스토리가 말로만 떠다닙니다. 심지어는 이 제품이나 기능이 왜 만들어져야 하는지에 대한 근거도 찾기 어렵죠. 최신화된, 잘 정리된 문서가 없는 것은 기록 남기기를 귀찮아하는 보통의 업무 스타일을 반영합니다. 우리는 문서화, 페이퍼 워크는 시간 낭비라는 얘기를 심심찮게 듣습니다. 반면, 성장을 돕는 기록 문화가 정착된 기업도 많습니다. 대표적인 사례는 아마존인데요. 아마존의 CEO 제프 베조스는 2017년에 파워포인트 발표 문화를 없애는 대신 '6 page Narratives'를 도입했습니다. 서술 형식으로 아이디어의 흐름을 온전하게 공유하고 미팅의 질을 높이기 위함입니다. 회의에 앞서 30분 동안 참석자들은 6장이 넘지 않는 메모를 읽습니다. 준비에 시간이 드는 대신 미팅의 효율이 무척 높아졌다고 합니다. 하지만 기록 중심의 업무 프로세스에도 단점은 있습니다. 시간이 가면 갈수록, 제품이 고도화되면 고도화될수록 문서의 양이 방대해진다는 겁니다. 나중에는 제품에 대한 히스토리나 제품을 정의하는 문서를 찾기가 어려워지죠. 이때 큰 힘을 발휘하는 것이 원 페이저(one pager)입니다. 원 페이저란 프로덕트 구성원이 제품 개발의 목표를 파악하고, 만드는 이유를 공감하며, 무엇을 만들어야 할지 파악할 수 있도록 만들어진 한 쪽짜리 문서입니다. 원 페이저를 읽고 나면 우리는 아래의 질문에 대답할 수 있습니다. (제품 개발 시작) 왜, 어떻게 이 제품을 만들어야 할까? (제품 개발 완료) 왜, 어떻게 이 제품이 만들어지게 되었을까? 원 페이저, 장점 ✅ PM이 제품 개발에 온전히 집중할 수 있습니다. PM은 원 페이저를 쓰는 동안 제품을 명확히 정의할 수 있게 됩니다. 원 페이저를 작성하기 위해 히스토리를 찾고, 문서화하는 과정에서 제품에 대한 이해가 깊어집니다. 원 페이저를 쓰고 나면 우리가 해야 할 일과 하지 않을 일을 구분하면서 제품의 방향성을 설정하기가 한층 수월합니다. 추상적인 아이디어를 구체화하는 과정에서 여러 가지 이득이 따릅니다. 제품 개발에 필요한 리소스를 파악하게 되고, 개발 방향에 대한 새로운 아이디어를 얻습니다. 구성원 입장에서는 자신이 어떤 역할을 하게 될지 예상하는 데 도움을 받습니다. 또한 원 페이저는 의사결정에 필요한 직관력의 토대가 되어 줍니다. 제품 개발에 대한 배경지식을 정리하면서 관련한 데이터를 충분히 학습한 까닭입니다. ✅ 한 페이지가 때로 100시간을 벌어 줍니다. 원 페이저는 우리 제품이 어떤 문제를 해결하기 위해 존재하며, 어떤 배경을 갖고 있고, 어떤 가설을 검증하며, 그래서 우리가 무엇을 시도해볼 수 있을지를 알려줍니다. 제가 스토리텔링 방식의 서술로 이해와 기억을 돕자 구성원들은 더 적극적으로 의견을 내고 질문을 해왔습니다. 원 페이저 덕분에 공감대가 생겨 자연스럽게 더 폭넓은 이야기가 오갔습니다. 수많은 경우의 수에 미리 대처할 수 있었던 것은 물론이고, 하지 말아야 할 것을 구분하면서 개발 리소스를 줄일 수도 있었습니다. 초기에 또는 필요한 시점에 사용한 원 페이저 작성 시간의 효과는 기대 이상이었습니다. 멤버 커뮤니케이션이 원활해졌고, 계획한 일정대로 업무가 진행되는 긍정적인 효과가 있었습니다. 원 페이저, 작성 방법 원 페이저의 구성을 살펴보겠습니다. 크게 '개요'와 '세부 내용'으로 나뉩니다. 개요에서는 제품 개발 및 프로젝트에 대한 전체적인 맥락과 배경, 방향을 설명합니다. 구성원들은 개요를 통해 프로젝트의 핵심과 자신이 수행할 역할을 이해합니다. 개요는 읽는 사람들이 이해하기 쉽도록 스토리로 구성하는 것이 좋습니다. 프로젝트의 목표 프로젝트의 'why'입니다. 왜 해야 하며, 무엇을 얻을 수 있는지를 설명하는 부분입니다. 우리가 도달하고자 하는 지점이나 제품이 만들어갈 변화를 구체적으로 표현합니다. 근거와 목표는 숫자로 정하는 것이 좋습니다. 그래야 구성원들이 우리가 어떤 목표를 달성해야 하는지 확인할 수 있고, 제품 개발에 따라서 목표에 도달하고 있는지를 추적할 수 있습니다. 목표를 가시적으로 확인할 수 있으면 구성원들의 동기 부여에도 도움이 되기 때문에 목표를 달성하기 위한 아이디어를 모으는 데도 도움을 줍니다. 해결하고자 하는 문제 사용자 관점에서 문제를 명확하게 정의합니다. 사용자가 지금 어떤 어려움에 직면해 있고, 이를 어떻게 해결하려고 노력하고 있는지, 그럼에도 불구하고 문제가 해결되지 않았다면 그 이유는 무엇인지 등을 작성합니다. 문제에 대한 명확한 정의는 구성원이 사용자가 겪고 있는 문제에 공감하게끔 해줍니다. 사용자 인터뷰 등을 통해 실제 사용자의 목소리를 들려주는 방향이 가장 신뢰도가 높고 이입하기도 쉽습니다. 과거와 현재 시도되고 있는 해결책과 그 한계 선행 서비스의 한계, 또는 우리 서비스의 지난 노력이 여기에 해당합니다. 이 과정은 매우 중요합니다. 같은 실수를 반복하지 않기 위해, 또 새롭게 시도해볼 수 있는 방향을 찾아내기 위해 과거의 실패 위에 올라서는 겁니다. 현재 존재하는 기회 시장에 대한 공신력 있는 분석 자료, 기사, 데이터로 제품의 성공 가능성을 보여주는 부분입니다. 구성원들이 진입하려는 시장의 규모를 면밀히 파악하면 우리의 제품의 성공 가능성과 지속 가능성, 매출 규모 등을 생각해보게 할 수 있는데요. 이런 생각을 해보는 것 자체로 구성원들에게 동기부여가 되고, 결과적으로는 제품 개발에 대한 자발적인 참여를 이끌어낼 수 있습니다. 우리의 해결책과 개발 방법 그래서 우리는 목표를 달성하기 위해서 우리가 무엇을 만들어야 하고, 어떻게 만들어야 하는지를 서술합니다. 이 부분을 읽으며 구성원들은 본인이 담당하고 기여할 수 있는 부분을 예상하게 됩니다. 우리 제품의 검증 방법 우리 제품을 어떻게 검증할지 밝힙니다. PMF, 즉 프로덕트-마켓 핏(product-market fit)을 어떻게 찾아낼 것인지가 담겨야 합니다. 우리의 해결책을 시장에서 검증할 방법을 알지 못하면 구성원들은 그야말로 망망대해를 표류하게 됩니다. 실패할 경우의 방안 원 페이저를 작성하면서 실패를 고민하고, 실패를 막기 위한 여러 의견을 수집하고 대비해 보세요. 플랜 B와 예측 가능한 문제에 대한 최선의 해결책을 고민할 기회입니다. 세부 내용: 이야기에 디테일을 더하다 목표(Objective) 우리가 제품으로 달성하고 싶은 것과 측정 가능한 성과, 즉 핵심 성과(key results)를 함께 적습니다. 수치화된 핵심 성과는 목표 달성 정도를 지속해서 확인하면서 동기를 부여하는 과정에 유용합니다. 월별 또는 연도별로 목표 달성 수치를 명확하게 측정하고 수정할 때도 도움이 됩니다. 배경(Background) 단위 업무에 따라 필요한 정보를 정확하게 파악하고, 배경을 독립적으로 사고할 수 있게끔 카테고리별 정보를 구분지어 서술합니다. 가설과 검증 전략(Hypothesis Analysis) 우리 제품에 시장성이 있는지를 파악하기 위한 영역입니다. 원 페이저는 대부분의 경우 제품 개발을 시작하는 단계에서 작성하므로 사용자의 문제, 타깃, 해결책 등에 대한 검증된 데이터가 부족합니다. 뒤집어 말하면 사업 내의 모든 가설이 검증 대상이 될 수 있습니다. 따라서 검증이 필요한 모든 부분, 예를 들어 니즈·타깃·해결책·고객 유입 채널·구현 가능성 등과 이를 검증할 전략을 적는 것이 좋습니다. 이렇게 체계적으로 가설 검증 전략을 정의함으로써, 원 페이저를 읽은 구성원은 PM의 밑그림과 전략을 이해할 수 있습니다. PM이 '어떤 결정을 왜 내렸는지', 나아가 '어떤 결정을 내릴 수 있을지'까지 짐작해볼 수 있게 됩니다. 원칙(Guiding Principles) 원 페이저에 정리한 원칙은 의사 결정이 필요한 순간의 판단 기준이 됩니다. 지금 단계에서 우리가 집중해야 할 부분, 우선순위로 둬야 할 업무를 구성원에게 명확히 인지시키는 겁니다. 원칙이 없으면 새로운 의견, 새로운 주장에 따라 제품의 방향성이 계속 흔들리는 문제가 발생합니다. 원칙은 보통 4~6개 정도가 적당합니다. 가장 중요한 원칙을 1번으로 매기면서, 우리가 제품을 개발하는 과정에서 꼭 지켜야 하는 것들을 정리합니다. '기획자나 PM이 부재중일 때 구성원이 이 원칙을 참고해 스스로 결정을 내릴 수 있는가?'를 생각하면서 만드는 것이 좋습니다. KPI(key performance indicator) KPI, 즉 핵심성과지표는 측정 가능한 숫자로 설정하는 것이 좋습니다. 예를 들어 광고를 집행하는 업무에 대해서는 클릭률(CTR, click through rate)을, 랜딩페이지로 이메일을 수집한다면 수집한 메일의 수를 지표로 제시할 수 있겠습니다. 로드맵(Roadmap) 전체적인 제품 개발 일정을 짜서 업무의 진행 상태와 기간을 보여줍니다. 역할에 따른 투입 시기를 예측할 수 있어 구성원들은 각 단계를 미리 준비할 수 있습니다. 로드맵은 PM이 혼자 만들지 않고, 구성원들과 원 페이저를 공유하면서 완성합니다. 참고 자료(References) 원 페이저를 작성하면서 참고한 자료나 제품을 개발하면서 벤치마크할 만한 자료를 제시합니다. 또는 시장 분석 자료나 선행 서비스에 대한 분석을 기록할 수도 있습니다. 분량상 한 장 안에 담기 어렵다면 별첨으로 구성하면 됩니다. 레퍼런스는 원 페이저에 공감하지 못하는 구성원, 이해에 어려움을 겪는 구성원에게 필요한 배경지식을 제공해 줍니다. 또는 우리 서비스의 핵심 근거를 객관적인 자료를 통해 백업할 수도 있으며, 구성원에게 전달할 참조점을 아카이브하는 것도 좋습니다.