PM 역량 알아보기

방망이 깎던 노인처럼 문서 작성하기
PM에게 문서 작성이 중요한 이유

"다리를 지으면서 강을 건넌다"

이런 말이 있을 정도로 스타트업은 빠른 속도로 성장한다. 때문에 문서화가 제대로 이뤄질 틈이 부족하다. 동시에 근속 연수 또한 중소기업이나 대기업 대비 짧은 편이라서, 어떨 땐 히스토리를 아는 사람이 아무도 남아있지 않은 경우도 발생하기도 한다. 위의 안드로메다와 같은 상황이 비일비재한 거다.

이런 환경에서 신입 PM은 어떻게 해야 할까?
이번 포스팅에서는 문서 작성이 중요한 이유, 그리고 내가 겪은 시행착오와 배움을 공유하고자 한다.

PM에게 문서 작성이 중요한 이유

1. 히스토리 아카이빙 및 공유
2. 프로덕트 공부의 산출물(역기획)

1. 히스토리 아카이빙 및 공유

직무 관계없이 조직에서 일하는 사람이라면 누구나 히스토리를 관리해두어야 하겠지만, PM에게는 특히 중요하다. PM은 히스토리를 바탕으로 새로운 히스토리를 만드는 사람이기 때문이다.

한편, '이 프로덕트가 왜 이렇게 만들어졌는지' 문서는 알고 있다. 그 속에 적힌 히스토리를 숙지해야 현상을 제대로 파악할 수 있고, 문제 원인을 찾아 해결하는 것도 가능해진다. 문서는 맥락에 대한 이해를 가능케 하고 그 결과, 보다 나은 결정을 내릴 수 있도록 돕는다.

PM은 혼자서 문제를 해결하는 사람이 아니다. 여러 협업자에게 전략적 콘텍스트와 목표 결과물에 대해 명확하게 공유해야 한다.(전략적 콘텍스트가 궁금하다면 <임파워드>를 읽어보길 추천한다.)

이때, 문서화된 히스토리를 통해 PM은 효율적으로 문의에 대응할 수 있다. 본인이 부재한 상황에서도 협업자들의 이해를 돕고 그 결과 일이 정상적으로 진행되도록 도울 수 있다. 일일이 담당자를 찾지 않아도 되게끔 할 수 있다면 커뮤니케이션 리소스도 아낄 수 있으니 얼마나 좋은가!

현재 내가 속한 조직에서는 노션으로 문서를 공유하고 아카이빙하고 있는데, 검색 기능을 활용해서 문의에 빠르게 대응하거나 확인하고 싶던 내용을 쉽게 찾을 수 있었다. 꼭 노션이 아니더라도 조직에 적합한 문서 아카이빙 툴을 선택해 적용함으로써 업무의 효율성을 높일 수 있을 거라고 생각한다.

2. 프로덕트 공부의 산출물(역기획)

문서를 작성하기 위해서는 뼈대를 세우고, 살을 붙이고, 부족한 부분을 보완하는 과정을 거치게 된다. 기존에 남겨져 있는 히스토리로부터 현재의 프로덕트가 가진 배경을 파악하고, 그 안의 세부적인 사항들(ex. A 기능의 플로우, B 팝업이 노출되는 이유 등)을 이해하면서 유저들이 어떤 식으로 우리 프로덕트를 경험하는지 전반적으로 알게 된다.

단기간에 빠르게 실력을 쌓는 방법으로 '역기획'이 유용하다는 것은 서비스 기획자나 프로덕트 매니저, 해당 직무를 준비하는 이들에게도 익히 알려져 있는 이야기이다. 타 프로덕트의 역기획도 도움이 되겠지만, 신입 입장에서는 실무에서의 문서 작성 또한 동일한 배움의 기회였다. 오히려 반드시 거쳐야 하는 과정이었다고 생각한다.

실제로 신입인 나에게 이번 프로젝트가 주어진 이유는 그 과정에서 우리 프로덕트에 대해 전반적인 내용을 파악할 수 있기 때문이기도 했다. 이를 통해 실무에서 학습과 산출을 동시에 경험했고, 그 배움을 정리하여 지금의 포스팅을 작성하고 있다.

부실하게 작성된 문서는 제 기능을 하지 못한다.

입사 후 첫 1개월 동안 이미 화면이나 플로우 차트가 나와있는 상태에서 개발/디자인/QA 측에 전달할 스토리보드를 작성하는 업무를 진행했다. 처음에는 타인이 작성한 문서 내용을 그대로 가져온 후 그 위에 내용을 덧붙이는 방식으로 스토리보드를 작성했다. 그래야 빨리 결과물을 만들 수 있다고 생각했기 때문이었다.

결과적으로 그 방식은"부실공사"였다. PM인 나부터가 담당 기능에 대한 이해도가 부족했으며, 커뮤니케이션에서는 빈번하게 빈틈이 발생했다.

그때 깨달았다.
내가 작성한 문서는 대략의 형태만 갖췄을 뿐, 제 기능을 하지 못한다는 것을.

감사하게도, 동료 PM분과의 피드백 과정을 거치면서 문제 원인을 알게 됐다.
그동안 나는 잘못된 순서로 문서 작성을 진행하고 있었다.

[BEFORE] 잘못된 문서 작성 방식(= 부실공사가 이뤄진 과정)

1. 히스토리 확인 : 히스토리를 가져와 뼈대 만들기
2. 스토리보드 작성 : 뼈대 위에 살 붙이기
3. 스토리보드 보완 : 테스트 및 문의 진행하여 추가사항 확인하고 문서 디벨롭

[AFTER] 회고를 통해 수정한 문서 작성 프로세스

1. 스토리보드 작성 : 테스트를 통해 디테일한 요건까지 최대한으로 작성한다.
2. 히스토리 확인 : 1에서 확인하기 어려운 것은 직접 문서를 찾아보거나 문의해본다.
3. 스토리보드 보완 : 위에서 확인한 내용을 바탕으로 기존의 작성해둔 내용을 보완하여 완성한다.

피드백 이후 회고(레슨런 작성)를 거치면서 문서 작성 프로세스를 수정했고, 리더와의 1on1에서도 이 내용을 공유했다. 레슨런과 액션 플랜은 공유하면 공유할수록 단단해지고 반복적으로 실행될 확률이 높아지니, 이 글을 발행함으로써 또 한 번 머릿속에 깊이 새겨지길 바란다.

더하여, 문서 작성할 때 지키고자 하는 룰이 있다. "내가 100% 확신할 수 있는 내용만 작성하는 것"이다. 그렇지 않은 경우, 두세 번 확인하고 검증해야 하는 상황이 발생하고 나 하나뿐만 아니라 여러 협업자들의 리소스를 허비하게 된다. 내가 작성한 문서 속 내용은 온전히 내 책임이 된다는 걸 잊지 말자.

결론. 탄탄한 문서를 작성하기 위해서는 정공법을 사용해야 한다. 샛길 같은 건 없다. 흰 도화지에 스케치부터 직접 해야 한다. 성실하게 작성한 문서는 빛을 발한다.

과연 어떤 문서가 좋은 문서인가?

"PM은 다양한 이해관계자와 일한다"는 말을 실감하게 된 건 하나의 문서를 두고 여러 관점에서의 커뮤니케이션을 하며 일을 되게 만드려 애쓰는 경험을 하면서부터였다. 금번의 시행착오를 겪는 동안, 취준 시절에 뵈었던 한 PO님이 해주셨던 조언이 떠올랐다.

PM이 작성하는 문서는 다양한 이해관계자들을 고객으로 하는 프로덕트다. 어떤 문서를 작성했을 때 이들과 보다 효율적으로 일할 수 있는지, A/B 테스트도 유저 인터뷰도 해볼 수 있을 거다. 물론, 방망이 깎는 심경으로 탄탄한 문서를 작성하고 난 후의 이야기이다.

최근에는 내가 작성한 문서에 대한 직/간접적인 피드백을 받을 수 있었다. 특히 개발 리뷰나 사업부 리뷰와 같이 공식적인 자리에서 받은 질문들은 꼼꼼히 메모해뒀다. PM이 작성한 문서를 검토할 때, '개발자 혹은 사업부에서는 어떤 것을 중요시 여기는지'를 알 수 있어 유익했다. 추후에 보다 나은 문서를 작성하는 데에 도움이 될 것 같다.

과연 어떤 문서가 좋은 문서인가?

읽는 대상의 관점을 이해하여 그들이 원하는 정보를 명확히 확인할 수 있도록 작성된 문서가 좋은 문서라고 생각한다. 이와 관련해 책 『The One Page Proposal』을 통해 보다 구체적인 지침을 얻을 수 있었다. 한 번쯤 읽어보기를 추천한다.

이번 포스팅 또한 나와 같은 고민을 하는 이들에게 도움이 되기를 바라며, 오늘의 글을 마친다.

추천 컨텐츠