Amazon PR/FAQ: 개발 전에 약속을 검증 가능하게

Amazon의 전 임원 Colin Bryar와 Bill Carr는 Working Backwards를 원하는 고객 경험부터 정의한 뒤 무엇을 만들지 결정하는 방법으로 설명한다. 이들의 회고는 2004년 이후 주요 사업과 이 방식을 연결하며, 2005년 디지털 미디어와 웹 서비스 분야의 시도도 다룬다. 핵심 문서는 가상의 보도자료와 고객·제공 가능성에 관한 질문을 결합한다.^[1]

저자들이 설명하는 것은 즉각 승인을 얻는 영업 발표가 아니라 반복 토론, 미해결 질문과 수정이다.^[1] 별도의 Amazon 인터뷰에서 Jeff Wilke는 신제품 자원을 승인하기 전에 좋은 PR/FAQ를 보고, 먼저 작은 팀에 자원을 제공한다고 말했다.^[2] 이는 관리 관행의 설명이지 재무 효과를 측정한 대조 실험이 아니다.

자료는 모든 프로젝트가 같은 순서로 진행됐거나 문서 전에 탐색용 코드가 전혀 없었다고 증명하지 않는다. 이 형식 자체가 Kindle이나 AWS의 성공을 만들었다는 증거도 아니다. 기획 문서의 가상 고객 발언은 예상 결과이지 실제 후기가 아니며, 관찰된 고객 증거로 제시해서는 안 된다.^[1]

분석과 적용

잘 다듬은 발표문도 슬라이드처럼 불확실성을 숨길 수 있다. 편익마다 필요한 가정, 검증 방법과 실패 조건을 연결하자. 수요, 제공 가능성과 지속 가능한 비용을 구분해야 한다. 매력적인 편익이라도 기술이나 경제성 측면에서 실현 불가능할 수 있다. 글은 자신감을 연출하기보다 증거의 빈틈을 드러내야 한다.

분석과 적용

1. 고객 집단 하나, 현재 대안과 겪는 문제를 정한다.
2. 이용량·후기·성능을 지어내지 않고 구체적인 편익안을 하나 쓴다.
3. 필요한 조건을 행동, 기술, 서비스 역량과 비용으로 나눈다.
4. 가정마다 현재 증거, 다음 시험, 담당자와 결정 기준을 기록한다.
5. 증거와 모순되면 수정·검증·중단을 선택하고 기각한 버전과 이유를 남긴다. 이는 우리의 응용 틀이며 Amazon 내부 양식을 복제한 것이 아니다.