「プロダクトマネージャーのしごと 第２版」要約・読書メモ 中編
こんにちは
前回の記事
に引き続き、こちらの書籍の6章〜10章までを簡単なサマリと私自身の考察も踏まえて共有させていただきます。
第6章 ユーザーに話しかける（あるいは「ポーカーって何？」）
要約
ユーザーとの会話はすべてのプロダクトマネージャーにとって簡単に自然にできるものではない。
ユーザーとの会話は社内のステークホルダーとのやりとりとは異なるものだ。
ユーザーにあなたの仕事をさせてはいけない。ニーズを理解し、そのニーズへの最良の取り組みとしての具体的なプロダクトと機能について考えること。それが、プロダクトマネージャーのしごとである
必読のポイントと考察
ユーザーにあなたの仕事を依頼してはいけない
OXOのリサーチャーが「計量カップに求めることは何ですか？」と顧客に質問すると、一見筋のよさそうな特徴がスラスラとリストアップされた。
一方で実際に計量カップをつかってもらうようにお願いすると、みな一貫して目盛りを横から読もうとしてカップの横に屈むパターンを発見できた。これによって「上から読む計量カップ」が生まれた。
ユーザーに”機能リスト”を挙げてもらおうとしてはいけない。
ユーザーには、
自分たちの目的やニーズと、それに対応する会社の独自の機会を結びつける責任はない。
それはユーザーではなく、あなたの仕事である。
考察
私も幾度かユーザーリサーチを体験しましたが、直接やりとりを行うという経験は正直あまり多くなくこの点は学んでいくべき領域だと認識しています。
（家族がネットで買い物をするときどうやって商品をさがしているか横で黙って見せてもらったりはしていますが。）
また、組織としても、課題の探索（ディスカバリー）よりも、すでに「試したいアイディア」が山積していて、実施するリサーチもこちら側の考えた”ある具体施策”にたいするフィードバックを得るという趣のものが近いように感じます。
プロダクトや事業目標への強い想いは必須ですが、こちらの実現したいこと、検証したいことへの想いが強すぎると、ユーザーの真のニーズを曇りなく受け止めることができなくなってしまうのかもしれません。
第7章 「ベストプラクティス」のワーストなところ
要約
ベストプラクティスは出発点にすぎない。それは汎用的で指示的な解決策ではない。
「仕事のやり方をどう変えるのか」ではなく、チームが価値を届けるのにどう役立つかを考えよう。
うまくいったこと、いかなかったことを見て継続的に調整をしよう。
必読のポイントと考察
現実と恋に落ちる
「正しい」プロダクトマネジメントができているかどうかは気にするな。
どんな組織にも制約はあって窮屈なものである。「完璧に」プロダクトマネジメントをする方法などはない。
あなたのエネルギーは制約と限界をなくそうとするよりも、ユーザーに価値を届けるために使う方が良い。
考察
組織が成熟するとプロセスや規律、手続きが重視されるようになってきます。ポジティブな実績をつむほどに、「ベストプラクティス」の名の下にそれは仕組化、ヨコテンが期待されるようになります。 ただそれらを守ることや守らせることだけを目的化させず、それが「ユーザーに価値を届けることに貢献できているのか」という視点で「ベストプラクティス」を常にアップデートしていくことが必要なのだと考えます。
第8章 アジャイルについての素晴らしくも残念な真実
要約
アジャイルとは個人、相互作業、練られた計画から離れて、未知の世界へと導く必然的な変化を尊重し受け入れることを学ぶことである。
フレームワークに絶対的な役割の定義を求めようとすることはやめよう。プロダクトの仕事は常に曖昧さを操ることだと肝に銘じておこう。
必読のポイントと考察
アリスター・コーバーンの「アジャイルのこころ」を再発見する
コラボレーションする
デリバリーする
内省する
改善する
この4つのシンプルなことばは多くの説明を必要としない。
「内省する」を除けば他の３つは知っている人は多い。
心から内省し改善する時間を取れるなら、どんな状態から始まってもそれなりに良い状態に行き着くはず。
アジャイルプロセスを導入する組織が犯す唯一最大の間違いは、フレームワークやプラクティスを導入し、すぐにうまくいかないからと完全な失敗を宣言するような全か無かの手法をとってしまうことである。
考察
アジャイルに限らず、専門用語は曖昧で誤解を生みやすいものです。その解釈の違いでそれこそ信仰上の争いのように議論が迷走するようなシーンはたびたび経験します。
このコーバーンのアジャイルのこころのようなシンプルな表現はそんな状況から抜け出すのに有用なもののように感じます。
アジャイルであることを目指している私たちは、「内省する」「改善する」というものについて 実際どこまでできているでしょう。
Retrospectiveというイベントを催しているけど、そこで内省し改善にむかえているのか
ベロシティは計測できているのか。その結果、任意のタイムボックスで達成できるものの感覚はつかめるようになってきているのか。
「アジャイルであろうとしている自分たちの振る舞い」自体に、より内省と改善の意識を向けると良いのかもしれません。
第9章 ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）
要約
ロードマップは道ではない。プロダクト仕様書はプロダクトではない。ユーザーストーリーはユーザーではない。ドキュメントはユーザーに必ずしも価値を届けるものではない。
ロードマップをどう使うか？は組織の中で率直で明確な会話をして考えよう。ロードマップの唯一の持ち主を目指してはいけない。
ドキュメントを意図的に不完全にすることによってチームでコラボレーションができる。最初のドラフトは1ページ。1時間以上使わないようにしよう。
必読のポイントと考察
最高のドキュメントは不完全
不完全なドキュメントを共有すると、怠け者だとか中途半端だと思われることを心配するかもしれない。
ただ、同僚に良い印象を与えることなど、チームに関わってもらうことに比べたらまったく重要ではない。
「意図的に不完全」なドキュメントはチームのコラボレーションを加速する。
それを共有したとき、チームからの質問や貢献は前に進めるために不可欠になる。
考察
より正確で詳細な（・・と自分がおもっている）長大なドキュメントに時間をかけてチームに共有をしようとしてしまう癖が私にもあります。
出てくるであろう指摘・懸念・質問は事前にその答えを記述し、読んだだけで考慮されていることが理解できて、安心を与えるようなドキュメント。
ただ、確かにコラボレーションを促すには向かないのかもしれません。
そして執筆前の「自分の思い込み」が大きく外れていた場合にはタイムロスになるだけです。
最近わたしは、ワイヤフレームや初稿の要件定義書には意識的に余白を残しラフなものにするようにしています。FigmaやMiroでより本物っぽいイメージをかっこよく描くことや、思いつくかぎりのエッジケースを網羅した機能一覧などはさけて、絵コンテのようなコンセプチュアルなものに留めるのです。
細かな仕様は後から頻繁に変わるため、効率的ということだけでなく。枝葉末節な点に議論が向いてしまうことを抑止して満たすべき主旨を共有するというためにはその方が都合がよい場合があります。
チームで会話しながら作るようなドキュメントと、 顧客や役員向けのプレゼンや事実を伝えるべきレポートとは取り扱いや考え方を改める必要がありそうです。
第10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち
要約
大袈裟でイケてる戦略資料はチームの意思決定をよくするために必ずしも役にたつものではない。
チームのゴールと戦略はシンプルに保ち、何よりもチームと緊密に働き、戦略と実行はいつでも密接に結びつけておくこと。
アウトプットに対するチームの裁量と自由度を上げたいならば、達成したいアウトカムといつまでに達成するのかを具体的にしよう。
必読のポイントと考察
優れた戦略と実行は不可分だ
戦略的な仕事は重要で、外部から注目を集める。これによってあなたはチームから引き剥がされる恐れがある。戦略と実行を結びつけるのがあなたの仕事である。
「超重要戦略会議」で幹部のお墨付きを得た包括的で形式上素晴らしい戦略資料であっても、現実のプロダクトチームの意思決定と実行につながるものでなければ、まったく使い物にならない。
未完成の戦略文書はチームに持ち込んで、一緒に「試乗」して日々の意思決定の役立つ指針になるかを見てみるとよい。
考察
これも多くの大規模な組織での典型的なケースを表しているようにみえます。
「戦略」という言葉はどこか絶対的な権威の象徴かのように用いられる一方で、どうしてもクローズドな場で現実とは距離のある場所で限定された情報の中で議論されるものになりがちです。
プロダクトマネージャーは積極的に上位の戦略や幹部クラスの戦略の真意を把握し、それをチームの戦略とそして実行につながるよう還元する必要があります。それがもし、戦略が目指しているアウトカムを生み出すことにつながれば、 「何をつくるか」というアウトプットに対する裁量や自由度を今以上にもつことができるようになるのだと思います。
中編は以上です
最後の後編もがんばって書きますのでお楽しみに！
つづく
この記事が気に入ったらサポートをしてみませんか？