Amazon 고객 중심 접근과 내러티브 커뮤니케이션을 위한 6-Pager
팀의 이전 스프린트 회고 및 플래닝에서, “팀원들이 집중하고 있는 목적이 흐릿하거나, 일치하지 않는 것 같다.” 는 문제를 제기했다.
(원인 1) 스프린트의 메인 가설이 불분명한 채로 스프린트가 시작되었으며,
(원인 2) MVP가 검증되었다는 착각에서부터 시작하여 팀 내 KPI 달성을 목표로 설정하다보니,
(결과 1) MVP의 단위가 무거워지고,
(결과 2) MVP의 각 요소에 가설이 담겨있지 않은 것을 발견했기 때문이다.
이에 따라, 스프린트의 핵심 가설을 재설정하고, 이에 맞는 인수조건 설정 & 최소 액션을 재정의할 필요성을 느꼈다.
그렇다면, 그 가설들을 팀원들에게 어떻게 전달해야하는가?
스프린트 플래닝을 위해 검증할 가설들을 어떤 기준으로 1) 쪼개고, 2) 구조화하며, 3) 어떻게 우리 팀원들에게 가시적으로 전달하며(=시각화 방법), 4) 어느 정도로 구체화할 것인지에 대한 것이 정리되어야 한다는, 새로운 Problem을 찾을 수 있었다.
reference | [도서] 순서 파괴: 지구상 가장 스마트한 기업 아마존의 유일한 성공 원칙, 콜린 브라이어,빌 카
- 작년 SOMA 고도화 과정에서 했던 ‘AWS 워킹 백워드 교육’을 떠올렸다. 당시에는 시장에 배포된 뒤 예상되는 반응을 먼저 추정한 뒤, 그 피드백에 대한 방어책을 나열하며 가설을 설정하기에 더욱 더 고객 중심적으로 워킹한다는 감상이 있었지만, 이 방식의 특장점이나 세부적인 방법론을 알지는 못했다. 이 방법론을 좀 더 이해하고 프로덕트에 적용해보고자 관련 도서를 찾았다.
- 책 추천사의 “‘순서 파괴’로 당신의 작업량을 줄일 순 없다. 하지만 명백한 진실은 이로써 실패 확률이 ‘제로’에 가까워진다는 것이다!” 라는 말이 후킹했다. 실패하지 않는 방법론은 우리에게 가장 필요한 것이었다.
모든 가설을 미리 나열하는 단계에서 어떤 관점을 가져야 하는가.
가설들을 어떤 기준으로 구조화/세분화/구체화하며 어떤 순서로 진행할 것인가.
다른 팀원에게 어떻게 전달할 것인가.
� 이미지가 아닌 글에 의존할 것!
① Narrative, 줄글은 데이터 요소 간의 연결고리를 설명하기에 용이하다.
PPT는 정보를 숨기고 강조하기 너무나 용이하다.
1) 청중을 무지하고 수동적으로 만들며 발표자의 신뢰성을 깎아내리며
2) 아이디어를 위장시키고,
3)상대적 중요성을 인지하지 못하게 할 뿐 아니라
4) 아이디어 간에 상호연결성을 무시하도록 하는 경향이 있다.
이를 파악하기 위한 질문이 오히려 회의 진전을 방해할 때도 있다.
내러티브는 무엇이 중요한지 & 서로 어떻게 연관되어 있는지를 더 잘 생각하고 이해하도록 유도한다.
1) 아이디어의 구체화가 가능하며, (지면의 자유)
2) 독자에게 전후 맥락을 살피고, 비교하게 하며, 재구성할 수 있게 이끈다.
3) (말하는 속도) * 3 = (읽는 속도)
4) (PPT의 정보 밀도) * 6 = (내러티브 문서의 정보 밀도)
② 내러티브 방법론1: 6-Pager
1) 회의 시간이 1h이라면, 회의 문서는 6p가 적절하다. (페이지 당 3분, 총 20분 간 검토 시간을 가질 시, 토론 시간을 회의 시간의 2/3으로 남겨둘 수 있다.)
→ 이는 참석자에게 수준 높은 피드백을 요청하기 위함이다.
→ 6페이지 제한을 통해, 가장 중요한 이슈만 토론하게 하는 강제력을 행사할 수 있다.
2) 실시간 코멘트는 공개할 필요는 없다. 어차피 토론 때에 볼 수 있다.
3) 토론 중에 남겨지는 모든 이야기는 서기가 기록한다.
4) 참석자는 입증되기 전까지는, 내러티브의 모든 문장(작성자의 동기가 아닌, 문장의 내용)이 옳지 않다고 간주한다.
→ 이 자료가 과연 옳은지 / 규명해낼만한 또 다른 핵심적인 진실은 없는지 / 발표팀의 내러티브가 아마존 리더십 원칙(ex. 이 정책은 고객 친화적인가?)에 부합하는지 등을 묻게 한다.
(ex. 내러티브에 ‘고객의 반품 가능 기간을 타 기업보다 2개 길게 설정한다.’라고 적혀있다면, 반품 가능 기간을 더 길게 설정하는 것이 정말로 고객 친화적인지 의심하는 것이다. 오히려 99%의 정직한 아마존의 고객들이 반품 검수를 기다려야만 할 필요가 없다는 것을 파악, 이를 개선하는 것이 더 고객 친화적인 정책이 된다. → No-hassle, 짜증 없는 반품 정책 = 반품시킨 상품을 접수하기 전에 환불하도록 조치하는 정책을 도입.)
6-Pager의 활용 방안으로 참고하면 좋을 레퍼런스를 첨부한다. [1] [2]
� 기획이 시작된 순간, 가장 먼저 보도자료부터 작성할 것!
주 목적: 내부적 관점 → 고객 관점으로 전환하는 것.
고객 경험을 규정한 뒤, 팀이 구축해야하는 명확한 이미지에 도달할 때까지
좋은 제품을 출발점으로 삼아
팀이 구축해야하는 명확한 이미지에 도달할 때까지, 거꾸로 되짚어가며 반복적으로 일한다.
구성 요소 ①, PR = 언론 보도자료
실제 보도자료를 작성하는 시점을 떠올려보면, 1) 완성되어 있는 기능과 2) 이에 대한 피드백도 다 방어가 되어 있어야 한다. 이 모든 기조가 프로덕트의 당위성을 높여주고, 사용자가 느끼는 감정에 더 초점을 맞추게 되기 때문에, 보도자료를 작성하는 것이 워킹 백워드의 핵심 단계가 될 것이다.
[작성 방식]
1p 이내, 몇 개의 단락 (너무 긴 문서는 의사소통에 실패하기 마련이다.)
제품 콘셉트에 관한 내러티브를 출시 준비를 완료한 상태의 언론 보도자료처럼 여기자. (개발을 다 끝낸 뒤 마케터에게 제품을 넘겨주고 보도자료를 작성하게 하면, 그제서야 고객 관점이 되어 늦기 마련이다. 이를 해결하기 위해 기능/비용/고객경험/가격을 합의한 뒤 어떻게 개발할 지 규명하다보면 워킹 백워드하게 된다.) (비용 투입 이전에 개발 단계에서의 도전과제를 미리 파악할 수 있으므로, 위험관리 측면에서도 기능한다.)
그래서 뭘 어쩌라는 건데? 라는 질문이 나오면 실패. 고객 경험을 묘사하지 못한다면 그 제품은 개발할 가치가 없다. (부족한 설명은 목업을 필요로 하게 되고, 이는 너무 많은 비용을 요구한다.)
구성 요소 ②, FAQ = 자주 묻는 질문
작성자가 고객 관점으로 계획의 상세 내용을 공유하면서, [사내의 운영, 기술, 제품, 마케팅, 비즈니스 개발, 재무 등]에서 직면할 다양한 리스크와 도전 과제에 대응하는 공간이다. (5p 미만)
외부적: 고객이 물을만한 것(=고객 니즈), 사용법 및 가격(= 경제성, 손익)
내부적: 팀과 경영진이 물을만한 것, 예산 및 개발에 대한 실질적인 질문
+) Chapter 중 나왔던 질문을 일부 소개한다.
작성자는 예상되는 모든 문제들을 최대한 빠짐없이 리스트업하는 것이 가장 추구해야 하는 모습일까요? >> PM도 모든 위험요소를 관리하긴 힘들다고 생각한다. 보도자료 역시 제품을 개발하는 한 팀이 모두다 관여해야 하는건 아닐까? AWS에서 진행되는 방식인걸 감안하면 A팀이 개발해야 하는 것에 대해 개발자,마케터, 등이 쓰고, 여러 부서 PM이나 경영진들이 모인 자리에서 발표하는 느낌이 아닐까 싶다.
보도자료 만드는데 얼마정도 걸리는 지에 대해서도 설명되어 있나요? >> 관련 언급은 찾지 못했다. 예상해보면 스프린트 플래닝하는 것과 비슷한 리소스지 않을까, 플래닝할 때 제품에 마케팅, 출시에 대한 예상 인수조건과 지표까지 다 예상하고 진행하는 것이기 때문에, 이때 고민했던 걸 더 간략하게 요약하는 리소스가 추가적으로 발생되지 않을까 싶다.
Keep
✔︎ 01 모든 가설을 미리 나열하는 단계에서 어떤 관점으로 진행하는 것이 좋은가.
보도자료는 사용자가 어떻게 느낄지를 어필하는 것이 가장 중요하기 때문에, 사용자 관점을 챙기며 & 결과물에서 시작하기에 모든 기능을 백워드하게 살필 수 있다는 점에서 좋은 접근방법인 것 같다.
보도자료를 통한 질타에 미리 대응한다는 것 그 자체로서 위험관리가 된다.
︎︎ ︎✔︎ 03 다른 팀원에게 어떻게 전달할 것인가.
기획안이 방식으로 내러티브하게 작성하면, 내 생각의 빈 부분을 채워두게 된다는 점에서 좋은 자료가 될 것이다.
보도자료를 SEO에도 사용하기 좋아보인다.
+) 인상깊었던 구절들
우리는 주주의 장기적 관심과 고객의 관심을 완벽하게 일치시킨다는 확고한 신념을 가지고 있습니다. → 결국 어느 정도의 MVP, PMF를 검증한 뒤에는 사내 혹은 유관자의 KPI와 고객의 value를 연결하는 것에 초점을 맞춰야 회사가 성장할 수 있다는 것을 의미하는 듯 하다.
‘아마존인 되기’는 ‘마인드 셋’에 달려있다 — 이 개념은 놀라울 정도로 프랙털 적이어서 조직 규모에 상관없이 도움을 받을 수 있다. → 시스템 구축에 힘쓰는 것도 좋은 목표가 될 것 같다.
거대 조직에서 이러한 변화를 시도하려면 간단명료한 실행 방침을 내려야 한다. ‘지금부터 발표용 소프트웨어는 마이크로소프트 워드다. 파워포인트가 아니다.’
Problem
✘ 01 그 가설들을 어떤 기준으로 구조화/세분화/구체화하며 어떤 순서로 진행할 것인가.
실제로 팀에서 어떤 순서로 쪼개서 개발에 착수하면 되는지에 대해서는 나오지 않는다, 실제 운영보다는 맨 처음 기획과 경영진이 신규 출시 기능에 대해 어떤 스탠스를 가져야하는지에 관한 책인 것 같다.
이렇게 보도자료를 통해 접근하면 M(inimum)VP의 범위가 커질 우려가 된다. 항상 유의할 것.
Try
이 방법론이 적용된 뒤 가치가 통했는지를 측정하기 위해 3개월 간 시도한 뒤, 참여자들에게 정성적인 답변을 요구해보자. → Q. 3개월 정도는 지속되어야 전략의 승패를 결정할 수 있는 것인가? 다소 길게 느껴지는데, 이는 스프린트 단위가 더 긴 대규모 조직이라 그런걸까?
이 책을 참고하여 (워킹 백워드적 관점 — 고객 중심의, 결과물로부터 시작하는) 가설 검증 & 기획안 작성에 대한 목차를 작성해볼 필요가 있다.
인수조건과 별개로, 6장. 성과지표: 아웃풋이 아닌 인풋을 관리하라, 스스로 통제할 수 있는 일에 매달릴 것! 는 읽어보고 싶다. KPI를 설정하는 과정에 숨어있던 문제점을 발견할 수 있을지도?
이 글은 SW마에스트로 14기 수료생들과 함께 운영하는 PO Chapter에서 공유한 내용입니다.
또한, 2024.09.15. 에 Medium에서 작성된 글임을 밝힙니다.