Rebuild: 98で紹介されていたので、英語だけどがんばって読んでみた。Inspiredと同じ方向性のプロダクトマネジメント本。違う人が同じ事柄について書いているという印象。しかし少しずつ違う視点が入っていて、プロダクトマネージャーの役割が立体的に見えるという意味で両方読む価値はあると思う（もう読んでしまったのでこう言うしかない）。

英語はかなり平易。使われている語彙がだいぶ簡単なので、他の英語の本に比べて読みやすいと感じる。それでも自分はちまちま読んで一ヶ月くらいかかった。

話題が割と新しめ。Google Buzzと写真共有アプリのColor（懐かしい！）が失敗した話が導入部分。

またInspiredに比べてスタートアップの文脈が強かったり、初期のビジネス的成功という点に重点が置かれている気がする。

以下、自分が線を引いた部分とコメント。引用の下の日本語は拙訳。

Chapter 1: Role And Resoponsibility Of The Product Manager

余談だけど今まで読んだPM本、だいたいPMの定義から入る傾向にある。

The only thing that matters is getting to product/market fit. Product/market fit means being in a good market with a product that can satisfy that market.

最も大事な事柄は、製品/市場フィットに達することだ。製品/市場フィットとは、その市場を満足させることができる製品を伴う、良い市場という意味だ。

The product manager’s mission is to achieve business success by meeting user needs through the continuous planning and execution of digital product solutions.

プロダクトマネージャーのミッションとは、デジタルプロダクトソリューションの継続的な計画と実行を通してユーザーのニーズを満たし、ビジネスを成功させることである。

It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.

手持ちの技術を買う人を探すのに比べれば、問題がある市場を探して技術で解決するする方が遥かに易しい。

First, they need to have their heads in the clouds. PMs need to be leaders who can look into the future and think strategically. They need to be able to develop a vision for where a product should go — and they need to be able to communicate that vision effectively. Further, PMs need to show their teams how they plan to get to that vision. And I do mean show — through sketches, prototypes, storyboards, or whatever it takes to get the message across.

まず、彼らは頭を雲の中に突っこむ必要がある。PMは未来を見通して戦略的に考えるリーダーである必要がある。製品はどこに向かうべきなのかというビジョンを生み出す必要がある。そしてそのビジョンを効果的に伝える必要がある。さらに、PMはビジョンを達成するためにどう計画を立てるかチームに示す必要がある。スケッチ、プロトタイプ、ストーリーボード、メッセージを行き渡らせる方法なら何でも使って。

Good PMs are also able to remain flexible and change course when needed, perhaps when there is a big shift in market needs or expectations, or a great business opportunity presents itself.

良いPMは、必要なときには、そして恐らく特に市場ニーズや期待、偉大なビジネスの機会が存在するときには、柔軟さを保持したまま進路を変更することができる。

Consensus cultures often produce watered down, unexciting products.

合意の文化はしばしば骨抜きの、ありきたりな製品を生み出す。

It was a passing comment and I didn’t really think much of it at the time, but since then I keep going back to that conversation, and the importance of fairness in the product management profession. All the characteristics I just talked about are great, but above all, fairness is the one that a PM simply cannot do without.

これは口をついて出てた言葉で、そのときは深く考えていなかった。しかし私はそのときの会話と、プロダクトマネジメント職においての公平さの重要性に立ち戻り続けている。私が語ってきた全ての特徴は素晴らしい。しかし公平さこそ、PMがこれ抜きには何もできないものだ。

Chapter 2: Uncovering Needs

また製品は以下の3つのニーズを満たさなければならないとして話が進む。

User needs
Buisiness needs
Technical needs

この中でTechinal needsの中には技術的負債なども含まれて居る。PMにとっては技術的負債もマネジメント対象である。

So, user needs research is always the first place to look for how the product can make money.

ユーザーニーズのリサーチは、製品がどのようにお金を生み出すかを探し出す際に、常に出発点となる。

Chapter 6: User-Centered Design And Workflows

三つのA

AARRRみたいなやつ

Acquisition 獲得: 新しいユーザーがサインアップした
Activation 利用開始: 獲得したユーザーが最初の購入をした
Activity 活発さ: 最初に購入したユーザーが戻ってきてさらに活動した

It won’t always be easy, but every UCD project should be measurable in terms of its impact on the business; tying it to one of the three ‘A’s is a good structured way of anchoring all design changes in business goals and, ultimately, revenue.

いつも簡単ではないけれど、すべてのUCD(User Centered Design）プロジェクトはビジネスのインパクトとして計測できるものであるべきだ。三つのAはデザインの変更がビジネスのゴール、つまるところレベニューに結びつけるための構造化された良い手法である。

Chapter 7: Specifications

I always think about error handling as the bastard child of user experience design. No one thinks about it until it’s too late, and then they try to sweep it under the rug.

私は常々エラーハンドリングはユーザー体験デザインの庶子であると考えている。手遅れになるまで誰もエラーについては考えず、そのときには敷物の下に追いやろうとする。

The prototype is often the part of the spec that’s most referenced by developers, since it’s the most useful.

プロトタイプは一番実用的なので、よく開発者から最も参照される仕様のひとつになる。

Chapter 8: Build and Release

個人的にはエンジニアとデザイナーのコミュニケーションにも触れているのが面白かった。

The main issue is that designers and developers approach their respective crafts from very different perspectives. Design is about composition — how to put hundreds of tiny elements together so that the whole makes sense. Development is about deconstruction — how to break down the whole into pieces that can be implemented effectively.

問題は、デザイナーと開発者がそれぞれ違った観点でもの作りにアプローチしているということだ。デザインとは構成すること、つまり数百の小さな要素を集めて理解しやすいように組み立てることである。開発は脱構築すること、つまり効率良く実装できる要素に分解することである。

Chapter 9: Assess and Iterate

Research triangulation — also known as mixed method research — is a helpful methodology to keep in mind here.

混合研究法として知られるリサーチの三角測量は、ここで覚えてくと助けになる手法だ。

という話から、以下の3つの手法をそれぞれ補完的に使うという話が語られる。

Webアナリティクス
オンライン調査
ユーザビリティテスト

A/B testing shouldn’t be used on its own to make decisions — it should always be used in conjunction with other research methods, both qualitative (such as usability testing and ethnography) and quantitative (such as desirability studies).

A/Bテストはそれ自身を決定に使ってはならない。質的（ユーザビリティテストやエスノグラフィーのような）と量的（望ましさの調査のような）両方を含む他のリサーチ手法と組み合わせて使うべきである。

Since every research and testing method comes with its own limitations, a combination of methods is the only way to get the full picture and make the right decisions.

全てのリサーチとテストの手法はそれぞれ限界が伴うので、全体像を把握し、正しい決断を行うためには複数手法を組み合わせて使うことが唯一の道である。

おわりに

最初にも書いたけれど、プロダクトマネージャーの役割が立体的に見えるという意味で良い本だと思う。ぜひ日本語版も出て欲しい。まだ誰も手を付けていないなら翻訳か監訳かやりたいという気持ちがあるのだけど、どういう手順で進めれば良いのかわからない（出版社を通して翻訳権を取得する必要がある？）。どなたかその辺りの知見やツテなどあれば教えて頂けるとありがたいです。

Making It Right: Product Management For A Startup World (English Edition)

作者: Rian van der Merwe
出版社/メーカー: Smashing Magazine
発売日: 2014/07/21
メディア: Kindle版
この商品を含むブログを見る

追記

これまで聞いた中で最も僕の中のプロダクトマネージャー像に近い - Making It Right: Product Management For A Startup World を読んだ - ninjinkun's diary http://t.co/R5TBTmTJNO
— takejune (@takejune) 2015年10月13日