6-Pager(내러티브)가 가진 목적(왜 필요한가), 가치(무엇을 바꾸는가), 활용성(어떤 상황에서 특히 강한가)을 고려시 만약 지금 여러분의 제품 조직에 6-Pager 문화를 도입하는 것에 대해 어떻게 생각하시나요? 찬성or반대? 찬선/반대의 이유가 무엇인지 상세한 의견을 들려주세요.
Q. 6-Pager(내러티브)가 가진 목적(왜 필요한가), 가치(무엇을 바꾸는가), 활용성(어떤 상황에서 특히 강한가)을 고려시 만약 지금 여러분의 제품 조직에 6-Pager 문화를 도입하는 것에 대해 어떻게 생각하시나요? 찬성or반대?
1.
김하경
a.
상세 기획을 논의할 때는 시각 자료가 필요합니다. 그러나 회의 참석자 중 단 한 명이라도 해당 내용의 전후 맥락을 충분히 이해하지 못한 상태라면, 워드 문서가 아니더라도 내러티브 기반 문서를 사전에 공유하거나 회의 시작 시 함께 읽는 방식이 훨씬 효과적이라고 느꼈습니다. 실제로 이러한 방식이 팀원들과 아이디어를 나누고 발전시키는 데 더 적합했습니다.
b.
내러티브를 작성하는 과정에서는 내가 왜 이런 생각을 했는지 스스로에게 끊임없이 질문하게 됩니다. 한 문장 한 문장 집중해 쓰다 보면 기획 의도가 더욱 명확해지고, 고객 관점에서도 한층 깊이 사고하게 됩니다. 궁극적으로는 지금 우리가 이것을 해야하는 이유를 한층 명확히 제시할 수 있었습니다.
YM: 6pager의 사용 시점과 목적, 단계에 대한 논의 선행 필요 ! 식스페이저의 활용성 중 PM의 제품/고객 세계관을 완성시키는데 큰 활용점
2.
김장호
a.
아마존의 6-Pager 문화에 저는 본연의 취지에는 찬성하지만, 현실적인 우려도 있어서 그 부분을 같이 나눠보려 합니다.
b.
저는 기획 리뷰를 할 때 와이어프레임을 작성하더라도 그 옆에 텍스트 중심의 1페이지 짜리 문서를 꼭 덧붙입니다. 저는 이 문서를 '상위 기획서'라고 부르는데요. 기획 배경, 상세 요구 사항, 핵심 기능 명세, 실행 계획, 추가 검토 사항 등을 정리해 둡니다. 개발자나 디자이너가 기능을 구현할 때, 이 기능이 왜 필요한지 배경과 기획 의도를 공유하기 위해서입니다.
c.
텍스트 중심의 문서를 작성하면 와이어프레임이나 이미지로는 대충 넘어갔을 예외 케이스나 기능 간의 충돌 지점이 명확히 드러납니다. 글의 흐름을 쭉 따라가다 보면 "아, 이 부분은 앞뒤가 안 맞네", "이건 놓쳤었네" 하며 스스로 발견하게 됩니다. 그런 면에서 6-Pager는 남을 설득하기 이전에 기획의 디테일을 다듬는 점검표로서 가치가 있다고 봅니다.
d.
하지만 실무에서 제가 느끼는 가장 큰 장벽은 팀원들이 문서를 잘 읽지 않는다는 점입니다. 저희 팀원들은 텍스트보다는 시각적인 자료를 통한 '직관적인 이해'를 선호합니다. "읽히지 않는 문서는 결국 종이 뭉치에 불과하다"는 말이 있듯이, 아무리 상세한 명세서를 써도 개발자가 해당 문서를 제대로 읽지 않으면 소통이 어긋나거나 QA 과정에서 기획 의도와 다른 결과물이 나오는 경우가 빈번합니다. 이러한 상황에서 6페이지짜리 문서를 제시하는 것은 오히려 소통의 장벽만 높이는 일이 될 수 있지 않을까 하는 우려가 있습니다.
e.
아마존은 그 동기화의 도구로 텍스트를 택했지만, 만약 우리 팀에게 그 도구가 와이어프레임과 이미지라면 그것을 만드는 데 시간을 들이는 건 당연한 선택일 수밖에 없지 않을까 생각합니다. 팀마다 정보를 동기화하는 최적의 방식은 다를 수 있기 때문입니다.
YM: 6pager의 사용 시점과 목적, 단계에 대한 논의 선행 필요
3.
이설희
•
맥락을 공유하고 일의 싱크를 맞추는 과정에서 사용할 수 있는 도구가 굉장히 많고 실무에서도 다양한 방식을 시도하고 있는데요. 6-Pager 문서를 도입하고 싶다고 생각했던 이유는, 잘 작성된 6-Pager 직접 봤을 때 느낀 점은 모든 맥락이 최대한 빈틈없이 이해가 되고 이 일을 왜 하는지가 명확해졌던 경험 덕분이에요.
YM: 오~! 6pager 직접 본 경로가??
4.
이정훈
→ 찬성하지만 어려움 예상
•
우려스러운 부분은 Top down으로 시작되는 프로젝트들이 많아 6pager의 목적과 의도에 부합하는 문서를 작성할 수 있을지, 문서 작성에 시간이 너무 많이 들지 않을지 우려스럽고
•
어려울 것으로 예상되는 부분은 최종 의사결정자가 bullet을 선호합니다.
•
Bottom up / Squad / DRI 등의 조직문화, 구조등이 설립되어야 제 역할을 할 수 있을 것 같다고 생각합니다.
YM: 결국 리더가 6pager를 이해할 수 없다면/네러티브 문화를 리딩할 수 없다면 현실적으로 어려움. —> 6Pager의 활용성 중 하나가 프로젝트팀의 얼라이언스도 있지만, C레벨, 리더가 다양한 프로덕트/PM들과 방향성 및 주요목표를 얼라이언스 시키는데 있기도 함.
5.
최순용
•
하지만 이를 실제 현업 메이커(디자이너, 개발자)들에게까지 일괄 적용하는 것에는 현실적인 허들이 큽니다. 현재 저희 조직은 PM이 와이어프레임과 상세 스펙을 어느 정도 결정한 뒤, 이를 바탕으로 디자이너와 개발자가 리뷰하며 내용을 추가하고 수정하는 방식이 오랫동안 깊게 자리 잡고 있습니다.
•
특히, 시각적인 솔루션과 구체적인 기능 스펙으로 소통하는 데 익숙한 실무 관계자들에게 텍스트 위주의 6-Pager라는 새로운 문서 체계를 학습하고 설득하도록 하는 것은 상당한 리소스와 반발이 예상됨니다..현재 회사는 스타트업 같은 속도감 있는 가설 검증과 개발 문화를 추구하고 있지만, 실제 일하는 방식은 다소 굳어져 있는 상태입니다. 따라서 6-Pager를 전사적으로 강제하기보다는, 신규 프로젝트 기획 등 '목적에 대한 뾰족한 합의'가 필요한 상위 기획 단계에서 제한적으로 먼저 도입해 보는 것이 좋을것 같으며. 이후 실무진들의 이해도와 텍스트 문서를 통한 컨텍스트 공유의 필요성이 충분히 올라왔을 때 점진적으로 적용하는 것이 현실적이라고 생각합니다.
◦
25년 연초에 6pager(1pager)도입을 시도해 봤지만 실무진들의 불만이 너무 강했음
YM: 실패에 대한 기회비용과 실패 회고의 기준 부재로 인한 실패원인 분석 어려움, 경험적으로 식스페이저는 고객중심의 제품세계관 설정과 공감대 형성을 통해 성공확률을 올리는 방안.
2. KPI를 '결과지표'가 아닌 '인풋지표'로 운영하기
•
현재 여러분의 조직과 회사는 통제하기 어려운 결과지표(예: MAU, 매출, ROAS, 구독 전환율, 리텐션) 중심으로 운영되고 있나요? 아니면 인풋지표(팀이 직접 움직일 수 있는 행동/품질 지표) 를 목표로 운영 중인가요? 만약 제품에 인풋지표를 중심으로 목표를 설정한다면, 어떤 지표를 핵심 레버로 두고(Top 1~3) 어떤 액션아이템을 설계할 수 있을까요? 그리고 그 선정 이유는 무엇인가요?
1.
김하경
a.
고객 관점의 서비스에 집중한 인풋지표(예: 가입 후 제한 시간 내 핵심 경험 도달률, 개인화 추천/큐레이션)에 더 높은 비중을 두고 있습니다.
b. 리텐션을 직접 목표로 삼기보다는, ‘재사용을 만들어내는 동기 설계’를 인풋지표로 설정할 수 있을 것 같습니다. 현재 문제를 동기 부족으로 본다면, 다음 세 가지를 핵심 레버로 설정할 수 있다고 봅니다.
YM: 왜 결과지표로 많이 운영되는가?? 인풋지표로 운영을 내부 도입시 우려되는 요소가 있을까? —> OKR/KPI 연동 이슈
3. 책을 읽으며 인상깊었던 주제나 다른 멤버들과 의견을 나누고 싶은 주제가 있었다면 공유해 주세요.
1.
김하경: (식스페이저)고객 데이터 확보가 충분히 이루어지지 않은 초기 서비스일 경우, 제안을 할 때 필요성과 필요한 이유(왜 이걸 해야하는지)를 어떻게 설정할 수 있을지 다른 분들의 의견을 들어보고 싶습니다. (타서비스 비교, 서비스 핵심 가치 기반, 논문&이론 기반 등...)
YM: 6pager의 고객의 니즈 분석(인터뷰+정량적)과 시장 분석, 기업미션의 얼라이언스를 통해 설득 진행
2.
김장호
a.
실무에서 PR/FAQ 방식이 실제로 작동할 수 있을까?
•
아무래도 책으로만 접하다 보니 아마존이라는 특정 문화, 특정 규모에서만 작동할 수 있는 사례처럼 느껴지는데, 우리나라 기업에서 실제 도입해보신 사례가 있는지 궁금합니다.
YM: (제가 알기론 없음)
b.
'고객 집착'과 '내부 설득' 사이의 타협
•
아마존의 리더십 원칙 첫 번째가 Customer Obsession인데, 이게 단순히 "고객을 중요하게 생각해요"가 아니라 의사결정의 기준점 자체를 고객에 두는 구조를 만들어가는 제 1원칙인 것 같아 인상 깊었습니다. PR/FAQ 먼저 쓰는 것도 그 구조의 일부인 것 같구요.
•
그런데 실제 일하다 보면, 기획의 출발점은 분명 사용자 니즈였는데 구현 단계로 넘어가면 어느 순간 내부 이해관계자 설득이 목적이 되어버리는 순간들이 있습니다. 개발팀에게는 "구현이 쉽다"고, 디자인팀에게는 "기존 디자인 시스템을 크게 안 건드린다"고 각각 설득하며 어떻게든 OK를 받아내는 것 자체가 목적이 될때가 있습니다.
•
즉 사용자 문제를 해결하는 게 아니라 기능 개발을 완료하기 위한 합리화가 중심이 되는 순간들. 이런 갭을 느끼신 적 있는지, 있다면 어떻게 해결하셨는지 궁금합니다.
YM: 6pager의 부재로 인해 발생된다 해석, 즉 프로덕트 전략, 지도가 없다보니 지향점과 기준의 부재로 Task 해결(속도,단순기능)에 포커싱됨. —> 초기 미팅때 식스페이저 싱크업과 기획문서의 뿌리를 식스페이저와 연결해 프로젝트 매니징 진행
3.
이설희
a.
아마존의 리더십 원칙은 그렇게 많음에도 불구하고 실제로 직원들 사이에서 살아숨쉬는 행동 강령으로 작용한다고 합니다. (실제 아마존을 근무하셨던 분께 들었어요.) 전세계 글로벌에 수많은 임직원이 그렇게도 강하게 리더십 원칙을 지킬 수 있었던 동력이 무엇일지 이야기를 나눠보고 싶어요. 리더십 원칙 중 우리 회사에 꼭 적용하고 싶은게 있는지도 궁금해요.