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の社内テンプレートの複製ではない。