# [PGF 1기-김장호] 순서파괴 사전 과제

**1. 6-Pager(내러티브) 문화**

- 6-Pager(내러티브)가 가진 목적(왜 필요한가), 가치(무엇을 바꾸는가), 활용성(어떤 상황에서 특히 강한가)을 고려시 만약 지금 여러분의 제품 조직에 6-Pager 문화를 도입하는 것에 대해 어떻게 생각하시나요? 찬성or반대?

    - 찬성합니다!

- 찬선/반대의 이유가 무엇인지 상세한 의견을 들려주세요.

    - 아마존의 6-Pager 문화에 저는 본연의 취지에는 찬성하지만, 현실적인 우려도 있어서 그 부분을 같이 나눠보려 합니다.

    - 저는 기획 리뷰를 할 때 와이어프레임을 작성하더라도 그 옆에 텍스트 중심의 1페이지 짜리 문서를 꼭 덧붙입니다. 저는 이 문서를 '상위 기획서'라고 부르는데요. 기획 배경, 상세 요구 사항, 핵심 기능 명세, 실행 계획, 추가 검토 사항 등을 정리해 둡니다. 개발자나 디자이너가 기능을 구현할 때, 이 기능이 왜 필요한지 배경과 기획 의도를 공유하기 위해서입니다.

    - 텍스트 중심의 문서를 작성하면 와이어프레임이나 이미지로는 대충 넘어갔을 예외 케이스나 기능 간의 충돌 지점이 명확히 드러납니다. 글의 흐름을 쭉 따라가다 보면 "아, 이 부분은 앞뒤가 안 맞네", "이건 놓쳤었네" 하며 스스로 발견하게 됩니다. 그런 면에서 6-Pager는 남을 설득하기 이전에 기획의 디테일을 다듬는 점검표로서 가치가 있다고 봅니다.

    - 하지만 실무에서 제가 느끼는 가장 큰 장벽은 팀원들이 문서를 잘 읽지 않는다는 점입니다. 저희 팀원들은 텍스트보다는 시각적인 자료를 통한 '직관적인 이해'를 선호합니다. "읽히지 않는 문서는 결국 종이 뭉치에 불과하다"는 말이 있듯이, 아무리 상세한 명세서를 써도 개발자가 해당 문서를 제대로 읽지 않으면 소통이 어긋나거나 QA 과정에서 기획 의도와 다른 결과물이 나오는 경우가 빈번합니다. 이러한 상황에서 6페이지짜리 문서를 제시하는 것은 오히려 소통의 장벽만 높이는 일이 될 수 있지 않을까 하는 우려가 있습니다.

    - 6-Pager가 나온 이유를 살펴보면, 결국 휘발되는 PPT 발표에 시간을 쓰기보다 문서를 통해 짧은 시간 내에 모든 팀원의 이해도를 하나로 모으는 '동기화된 상태'를 만드는 것이 훨씬 효율적이라 판단했기 때문일 텐데요.

    - 아마존은 그 동기화의 도구로 텍스트를 택했지만, 만약 우리 팀에게 그 도구가 와이어프레임과 이미지라면 그것을 만드는 데 시간을 들이는 건 당연한 선택일 수밖에 없지 않을까 생각합니다. 팀마다 정보를 동기화하는 최적의 방식은 다를 수 있기 때문입니다.

    - 그래서 저희 조직에 도입한다면, 저는 6-Pager를 의사결정의 기반으로 삼되, 소통할 때는 여전히 시각 자료를 병행하는게 현실적인 것 같습니다.

**2. KPI를 '결과지표'가 아닌 '인풋지표'로 운영하기**

- 현재 여러분의 조직과 회사는 통제하기 어려운 결과지표(예: MAU, 매출, ROAS, 구독 전환율, 리텐션) 중심으로 운영되고 있나요? 아니면 인풋지표(팀이 직접 움직일 수 있는 행동/품질 지표) 를 목표로 운영 중인가요?

    - 현재 저희 조직은 지표 문화가 정착되어가는 단계로, MAU와 레거시 서비스에서 후속 서비스로의 '전환율'이라는 결과지표를 중심으로 운영되고 있습니다.

    - 그렇다보니 서비스 기획자 입장에서 전환율이 낮다는 결과만으로는 무엇을 개선해야 할지 파악하기 어려운 부분이 많습니다. 숫자가 낮을 때 "기능이 부족한 건지, 그냥 옮기기 귀찮은 건지, 아니면 진짜 바빠서 못 하는 건지" 원인을 쉽게 알 수 없기 때문입니다.

    - 책을 읽으며 느낀 점은, 결국 당장 내일이라도 건드릴 수 있는 '레버'가 무엇인지 찾아야 한다는 것입니다.

    - 제가 마이그레이션 업무에서 느낀 가장 큰 장벽은 두 가지였습니다. 사용자는 새로운 기능보다 '익숙한 UI'를 잃기 싫어한다는 것, 그리고 의사결정을 하는 실무 PM들은 이미 게임 개발 일정만으로도 과부하 상태라 마이그레이션을 검토할 여력이 없다는 점입니다. 

    - 이를 해결하기 위한 세 가지 인풋지표를 설정해 보았습니다.

- 만약 제품에 인풋지표를 중심으로 목표를 설정한다면, 어떤 지표를 핵심 레버로 두고(Top 1~3) 어떤 액션아이템을 설계할 수 있을까요? 그리고 그 선정 이유는 무엇인가요?

    - **지표 1. 핵심 기능 갭(Gap) 해소율**

        - **선정 이유:** 유저들이 마이그레이션을 거부하는 가장 큰 이유는 "기존에 하던 일을 못 할까 봐"입니다. 아무리 새 기능이 많아도, 오늘 당장 써야 하는 기능이 없으면 넘어오지 않습니다.

        - **액션 아이템:**

            - 레거시 기능 사용 로그 분석 → 실제 사용 기능 Top 20 추출

            - 해당 기능들 중심으로 개발 스프린트 우선순위 재편

            - 기능 개발 로드맵 구성 및 공유

    - **지표 2. 온보딩 소요 시간**

        - 선정 이유 : 마이그레이션에서 가장 큰 심리적 저항은 "배우는 데 시간이 든다"는 겁니다. 지표 1이 기능의 유무라면, 지표 2는 기존 습관대로 일할 수 있느냐를 봅니다. 일감 확인, 생성, 알림처럼 매일 하던 일을 새 서비스에서 막힘없이 완료할 수 있어야 합니다.

        - 액션 아이템

            - "레거시 사용자용 빠른 시작 가이드" 별도 제작 (일반 온보딩과 분리)

            - 레거시 UI와 신규 UI 워크플로우 차이 매핑 후, 변화된 구간에 인앱 가이드/툴팁 삽입

    - **지표 3. 전환 지원 콘텐츠 준비율**

        - **선정 이유:** PM들은 마이그레이션에 궁금한 게 생겨도 직접 테스트하거나 매뉴얼을 찾아볼 여력이 없습니다. 질문할 수 있는 창구를 열어두고 쌓인 문의를 FAQ로 정리하면, 개별 질문 하나가 조직 전체의 전환 장벽을 낮추는 자산이 됩니다.

        - **액션 아이템**

            - 핫채널(직통 창구) 대응 데이터 누적 → 마이그레이션 FAQ 라이브러리 구축

            - 기능 비교표 배포 (실무자가 일일이 대조하지 않아도 한눈에 차이 파악)

**3. 책을 읽으며 인상깊었던 주제나 다른 멤버들과 의견을 나누고 싶은 주제가 있었다면 공유해 주세요.**

**가장 인상 깊었던 것: "PR/FAQ (Working Backwards)"**

- 처음에는 단순히 아마존식 문서 포맷 이야기인 줄 알았습니다. 그런데 읽다 보니 이 과정 자체가 '기획의 선후 관계를 바로잡는 장치'가 된다는 생각이 들었습니다. 

- 보통 기획을 하다 보면 기능부터 정의하고, 나중에 그 기능을 정당화하기 위해 "이게 왜 필요한지" 근거를 끼워 맞추게 될때가 종종 있습니다. PR/FAQ는 그 흐름을 막고 고객의 가치에서 출발하도록 한다는 것이 책 제목 '순서 파괴'가 가장 잘 드러나는 대목 같아서 인상 깊었습니다.

**나누고 싶은 주제**

- **실무에서 PR/FAQ 방식이 실제로 작동할 수 있을까?**

    - 아무래도 책으로만 접하다 보니 아마존이라는 특정 문화, 특정 규모에서만 작동할 수 있는 사례처럼 느껴지는데, 우리나라 기업에서 실제 도입해보신 사례가 있는지 궁금합니다.

- **'고객 집착'과 '내부 설득' 사이의 타협**

    - 아마존의 리더십 원칙 첫 번째가 Customer Obsession인데, 이게 단순히 "고객을 중요하게 생각해요"가 아니라 의사결정의 기준점 자체를 고객에 두는 구조를 만들어가는 제 1원칙인 것 같아 인상 깊었습니다. PR/FAQ 먼저 쓰는 것도 그 구조의 일부인 것 같구요.

    - 그런데 실제 일하다 보면, 기획의 출발점은 분명 사용자 니즈였는데 구현 단계로 넘어가면 어느 순간 내부 이해관계자 설득이 목적이 되어버리는 순간들이 있습니다. 개발팀에게는 "구현이 쉽다"고, 디자인팀에게는 "기존 디자인 시스템을 크게 안 건드린다"고 각각 설득하며 어떻게든 OK를 받아내는 것 자체가 목적이 될때가 있습니다. 

    - 즉 사용자 문제를 해결하는 게 아니라 기능 개발을 완료하기 위한 합리화가 중심이 되는 순간들. 이런 갭을 느끼신 적 있는지, 있다면 어떻게 해결하셨는지 궁금합니다.

For the site tree, see the [root Markdown](https://slashpage.com/pgf.md).