In the fine grained services approach that we use at Amazon, services do not only represent a software structure but also the organizational structure. The services have a strong ownership model, which combined with the small team size is intended to make it very easy to innovate. In some sense you can see these services as small startups within the walls of a bigger company. Each of these services require a strong focus on who their customers are, regardless whether they are externally or internally.
サービスは強いオーナーシップのモデルを持っており、それは革新を非常に容易にすることを目的とした小さなチームサイズと統合されたものです。
ある意味では、あなたはこれらのサービスをより大手の会社という組織の中で小さな一歩とみなすことができます。
社内外に係らず、これらのサービスはそれぞれ、彼らの顧客が誰であるかというということに強く焦点を当てる必要があります。
To ensure that a service meets the needs of the customer (and not more than that) we use a process called “Working Backwards” in which you start with your customer and work your way backwards until you get to the minimum set of technology requirements to satisfy what you try to achieve. The goal is to drive simplicity through a continuous, explicit customer focus.
The product definition process works backwards in the following way: we start by writing the documents we'll need at launch (the press release and the faq) and then work towards documents that are closer to the implementation.
製品定義プロセスは、次のように後方に動きます：
我々は、開始（プレス・リリースおよびＦＡＱ）するために必要となる文書を書くことから始め、実現するためにより近い文書を目指して努力します。
![[削除済みユーザ]](https://secure.gravatar.com/avatar/695023b4efd563721d13716b1457bc73.png?d=identicon&mode=crop&r=PG&s=42)
製品定義のプロセスは以下の方法で逆戻りをします。立ち上げに必要な資料 (プレスリリースやFAQ)を書き出すことから始め、そして実際の開発段階に近い資料の作成に取りかかるのです。
当社は｢逆向き解決法｣という手法を用います。どのようなものかというと、顧客と取引を進める際に
逆向きに物事を進めることで、最低限必要な技術を手に入れて、設定した目標に到達する方法です。
目標は継続してはっきりと顧客に焦点を置くことで、簡素化させることです。
｢逆向き解決法｣の製品定義以下のようになります。
まず当社は、業務の発足に必要な目標(プレスリリースもしくはFAQ)を設定し、
そして実現可能に近い目標に向けて業務を行います。
製品定義プロセスは、次のように後方に動作します：私たちは、ローンチ時に必要となるであろうドキュメント（プレスリリースおよびFAQ）を書くところから始め、その後の実装により近いドキュメントに向かって作業します。
The Working Backwards product definition process is all about is fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build. It typically has four steps:
Start by writing the Press Release. Nail it. The press release describes in a simple way what the product does and why it exists - what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product - not just how we think about it internally.
Write a Frequently Asked Questions document. Here's where we add meat to the skeleton provided by the press release. It includes questions that came up when we wrote the press release.
プレス・リリースを書くことから始めてください。それに集中してください。プレス・リリースは、製品が何をするのか、なぜ存在するのか ― どんな特徴と利益があるのか ―を単純な方法で述べます。
それは、非常に明確で適切である必要があります。プレスリリースを書くことは、世界が製品 ―ただ我々が心の中でどのように考えいるのかではなく ― をどのように理解するかを、前面に出して明確にすることです。
よく尋ねられる質問に関する文書を作成してください。これは、プレスリリースによって提供される、製品の骨格に肉付けする場所なのです。我々がプレス・リリースを書いたときに起こった質問を含みます。
FAQの資料を作成します。ここで、プレスリリース資料で作られた骨組みに肉付けをします。プレスリリースを書いた際に浮かんだ質問を含みます。
You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have.
Define the customer experience. Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product.
顧客エクスペリエンスを定義しましょう。顧客が製品を使ってするかもしれない様々なことに対し、顧客エクスペリエンスを正確で詳細に記述してください。ユーザー・インターフェースを備えた製品については、我々は、顧客が使用する各画面のモックアップを構築することになります。 Webサービスのためには、コードスニペットを含むユースケースを書きます。それはあなたが製品を使っている人を想像できる、その方法を描写します。
顧客体験を定義します。その商品を使ってするであろう様々なことにおける顧客経験をしっかりと詳細に説明します。ユーザインターフェースのある製品ならば、それぞれの顧客が使うスクリーンの実物大模型を作ります、ウェブサーピスについては、コードスニペットを含む、商品を使う人々を想像できるユースケースを作成します。
The goal here is to tell stories of how a customer is solving their problems using the product.
Write the User Manual. The user manual is what a customer will use to really find out about what the product is and how they will use it. The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product. For products with more than one kind of user, we write more than one user manual.
Once we have gone through the process of creating the press release, faq, mockups, and user manuals, it is amazing how much clearer it is what you are planning to build.
ここでの目標は、顧客が製品を使いながら、どのように問題を解決するかのストーリーを伝えることです。
ユーザーマニュアルを書きましょう。マニュアルは、顧客が、それが実際にどのような製品であり、どのようにそれを使用するかについて調べるために使用するものです。ユーザ・マニュアルは一般的に、概要、使用方法、索引の、三つのセクションがあり、それらの中に製品使用上ユーザが必要とする全てが書いてあります。複数の種類のユーザのための製品については、複数のユーザマニュアルを作ります。
プレスリリース、 FAQ 、モックアップ、およびユーザ・マニュアルを作成するプロセスを終えたら、あなたが何を作ろうとしているかどれほどクリアになるか、それはもう素晴らしいほどです。
We'll have a suite of documents that we can use to explain the new product to other teams within Amazon. We know at that point that the whole team has a shared vision on what product we are going the build.
