fladdict

Amazonでは製品開発をするとき、まず最初にプレスリリースを書くらしい。これは”Working-Backwards“と言うデザイン手法。面白げなので色々と調べてみた。

Working-Backwards法の商品開発では、お客様の視点をスタート地点にするため、開発前にプレスリリースを作成する。プレス内容は、既存プロダクトの問題点と、それを新製品がどう解決するかが中心になる。

プレスがユーザーに響かなかった時点でプロジェクトはボツ。そもそもその商品は作らない。これにより見当違いな商品を作るリスクを、一番最初の段階で低コストに回避できる。

このWorking-Backwards法で書くプレス内容は主に以下のとおり。

見出し
顧客が商品を理解できるタイトル
副題
ターゲット層と、彼らのメリットを1行で。
概要
商品の特徴と利点をまとめる。この段落で全てを理解できるように。
課題
このプロダクトが解決する課題を説明。
解決
プロダクトがどのように課題を解決するかを説明。
コメント
自分による紹介コメント（社長のコメント的なもの）。
使い方
どれくらい使い方が簡単かを説明。
ユーザーからの声
仮想ユーザーからのコメント。
締め
最後にしめ、次にユーザーがどうすればいいかを示す（Amazonで買えます！等）。

プレスは1〜1.5ページほどに納め、長過ぎる場合はFAQなどを作って補足する。

ちなみに、Amazonでは社内グループでのパワポは非推奨だとか。なぜなら口答プレゼンは、プレゼンターの話術に依存するからだとか。最終出力であるプレスやQ&Aに落とし込むことで、商品価値を中立的に見極める為。

Amazonの会議では、最初の10-15分はみんなプレスを読み、完全の沈黙状態になることも珍しくないのだそうです。

一般的なWorking-Backwards法では、最終的には本開発スタートまでにプレス、Q&A、ユースケース、マニュアルなどを作る。

プレスリリースを作る

その商品の存在意義と魅力を説明できるプレスリリースを作る。ユーザーに響かなければ、プロジェクトは終了

Q&Aを作る

プレスリリースを元にQ&Aを作る。プレスを読んだ人が疑問に思うこと想定し、プロダクトの魅力を理解できるようにする。

カスタマー・エクスペリエンスを作る

このプロダクトお客が、いつ、どのように使うのかのシナリオをまとめる。ここでリアリティがなかったら作り直す。モックアップや、エピソード、デモビデオなどを作ってみる。

マニュアルを作る

このプロダクトは何か？　どのように使うか？　注意することは？といった「お客様が知るべきこと」をまとめた、簡単なユーザーマニュアルを作る。

同様の手法としては、「ゲームストーミング ―会議、チーム、プロジェクトを成功へと導く87のゲーム」にて、パッケージから製作を開始するDesign the Box法が、「Innovation Games」という洋書でProduct Box法として紹介されています。このInnovation Gamesのほうは未訳らしいので、日経BPとかから翻訳でて欲しい。

確かにこういった作り方をすれば、確実に誰得の地雷プロダクトを作らないですみそう。

＜追記＞
ここら辺の手法を調べるのには、Inspired: How To Create Products Customers Loveと、「リーンソフトウェア開発と組織改革」という本もいいらしいです。リーン・スタートアップならぬ、リーン・ソフトウェア開発。ここら辺はまだ未読。