感情タグBEST3
Posted by ブクログ
プロダクト主導型の戦略
■なぜプロダクト主導型になるのか?
よくある間違いとして、プロダクト主導型企業と、「プロダクト主導型長」(PLG,Product-led Growth)の混同がある。PLGは、実際にはプロダクト主導型組織になったことによる副産物に過ぎない。PLGとは、見込み顧客のコンバージョン、ユーザーの維持、顧客の拡大のために、プロダクト(およびプロダクトデータ)を活用する方法だ。しかし、プロダクト主導型企業になることは、単にプロダクトの作り方を変えることではない。プロダクトジャーニーを根本的に考え直すのだ。それは、プロダクトを単なる売りものとみなす考え方から、プロダクトはユーザーにとって最初のモーメント・オブ・トゥルースであるという考え方に変えることだ。しかし、この変化を成功させるには、組織全体を変革する必要がある。プロダクト主導型になることで期待できる効果は以下の通りである。
・より柔軟で変化に強い
・より早いイノベーション
・より大きな価値提供
・デジタルアダプションによる収益と顧客維持の向上
・効率的な拡大
■プロダクト主導型企業の特徴
・プロダクトに地位を与える
・データインフォームドである
*意思決定においてデータを参考にしつつ、最終的にはその他の定性情報も含めて総合的に判断を行うデータ活用のアプローチ。なお、それに対して類似の概念の「データドリブン」は、データを最優先にして意思決定をするというてんで違いがある。
・共感的である
・協調的である
・プロダクトこそが顧客体験である
CHAPTER１ 終わりを思い描くことから始める
■SAFE
SAFe (Sealed Agile Framework) には、私がよく使うモデルがある。考え方は簡単だ。「ユーザー/ビジネス価値」、「時間価値」、「機会の有効性/「リスクの低減」についてのスコアを特定するというものだ。「ユーザー/ビジネス」とは、ユーザーやビジネスにおいてそれぞれ発生する具体的な価値の尺度だ。これには、収益、解約、その他の財務上の成果が含まれる。「時間価値」は、重大なリニューアル、マーケティングイベント、または新しい規制への対応など、作業項目の適時性を勘案することだ。例えば、税務ソフトを作っていて、改正された税法をサポートする必要がある場合、この「作業の「時間価値」は他の項目に比べて非常に高くなる。「機会の有効性/「リスクの低減」では、投資による長期的な影響と潜在的な機会を計測する。これは、技術的負債への対応やAPI提供の価値を評価する際の重要な要素になる。例えば、ユーザーが技術的負債への対応を求めることはないだろうが、だからと言って、もし対処しなければ、将来のすべての作業の品質に影響を与える可能性がある。
これらのスコアはすべて相対的な数値になる。SAFeを使う場合には、スコアの基準作りが必要だ。前述の領域で、スコアが低いことがわかっている代表的な作業を1つ選び、それを「1」とする。そして、新しい作業を評価するときには、チームとともに、その作業が基準となる仕事の価値と比較して2倍なのか、3倍なのか、はたまた10倍になっているかどうかを問えばよい。こうしたスコアを集計すれば、遅延コストの代わりになる総合的な価値を表すスコアが得られる。
この延長線上にあるのが作業のコストだ。まず、総合的な価値のスコアを作業の労力である。そして、「重み付けされた最短の作業から着手」という優先順位づけを行う。この手法は、「手の届く果実(大きな労力をかけずとも達成できる目標」を特定するのに役立つ。しかし、私の経験では、このテクニックは、大きな賭けをするときの優先順位付けにはほぼ役に立たない。コストの要素によって、他の項目よりも、大きな賭けとなりうる項目の価値のスコアが下がってしまいがちなのだ。
■60秒ビジネスケース
シニアプロダクトマネジャーのジェイソン・ブレットは、プロダクトに関するビジネス上の意思決定に役立つ興味深いモデルを提案した。彼はそれを「60秒ビジネスケース」と呼んでいる。
あるプロダクトの意思決定がもたらすインパクトを理解するために、組織内での迅速なコミュニケーションを促進するためのフレームワークを開発することがジェイソンの目標だった。「60秒ビジネスケースは、全員の意見を一致させ、より効率的かつ効果的に作業の優先順位をつけるための非常に強力なツールとなるだろう」と彼は書いている。
彼が開発したフレームワークは、「戦略的整合性」、「業務上の必要性」「収益」「顧客体験の向上」、「イノベーションの価値」、「コストの削減」という一連の鍵となる変数に基づいている。これらの異なる尺度のそれぞれに重みをつけ、プロダクトマネジメントの優先順位を加えて、合計100点とするというものだ。
このフレームワークの変数に基づくと、プロダクトチームは、ある取り組みが「高」「中」「低」、さらには「ゼロ」のいずれのランクであるかを評価できる。例えば、「戦略的整合性」のランクが高い開発項目は、企業ミッションをサポートし、プロダクトのビジョンを推進するものだ。また、で上位にランクされる項目は、そのプロダクトがすぐに意味のある収を生み出すことを示す。
ジェイソンは次のように述べている。「私たちは、これらのビジネス尺度を個別に計測する方法を見出しており、それぞれの尺度はコミュニケーションを通じて素早く支持を得ることができる。特定のプロダクトや機能、施策を実行したい場合には、スプレッドシートを見ながら、「それは高い戦略的整合性を持っているから重要なのだ』と言うことができるだろう」。
こうしたランキングは、ほとんどの場合、チームからの情報に基づいた主観的なものだ。また、組織の優先順位の変化に応じて、時間の経過とともに変化することもある。目標が、収益やコストの削減ではない場合もある。目標が、新しいことを学んだり、市場やプロダクトについてのインサイトを得るというシンプルなものかもしれない。何か新しいことを始めるときには、検証された「学び」を得ることに焦点を当てた実験を行うのが一般的だ。この概念は、エリック・リースの「リーンスタートアップ」で広く知られるようになった。「Why」とは、実験を通じて得たい学びのことだ。効果的な実験を行う方法については、第3章「顧客データをインサイトに変える」で詳しく説明する。
■運用目標の設定：プロダクトを導くガードレール
・リリースのその先
・プロダクトの利用状況
・機能の定着状況
・感情
・コンバージョン
・顧客維持
■プロダクトのビジョンがしっかりと根拠のあるものであることを確認するための３つの質問
１全員がプロダクトビジョンを理解しているか？
２改良できる余地があるか？
３ワクワクしているか？
■まとめ
プロダクト開発の旅に出るときは、まず「終わり」を考える必要がある。そのプロダクトで何を達成したいのか、なぜ時間とお金をかける意味があるのか。このような質問に答えるための最初のステップは、成功したかどうかを判断するための3つの異なる目標、つまり戦略上の目標、運用目標、顧客目標を組み合わせた目標を定義することだ。目標が定まれば、次の章で説明する目標達成に向けた進捗状況を計測するためのさまざまなメトリクスを定する準備が整っているといえるだろう。
CHAPTER２ 測るもので決まる
■戦略上のメトリクスとビジネスメトリクス
・収益、ARR(Annual Recurring Revenue)、MRR(Monthly Recurring Revenue)
・コンバージョン率
・CAC
・LTV
・NRR(Net Revenue Retention)
・売上総利益
・収益性
・Winレート：プロダクト開発と市場投入の投資に対する利回り。
■運用指標
・時系列での利用状況
・粘着度
・機能の定着率
・機能継続状況
・広さ、深さ、頻度
広さ：顧客の中でプロダクトを利用しているユーザーの数；顧客の過去30日におけるアクティブユーザー数
深さ：顧客が「定着」の鍵となる機能を使っているかどうか；顧客維持の先行指標となる５〜８つの主要機能の利用状況
頻度：顧客がどのくらいの頻度でプロダクトにアクセスしているか；顧客の過去30日間における、全ユーザーのログイン回数
・プロダクトのパフォーマンス
・プロダクトの不具合
・タスク完了状況
■定性的なメトリクス
・リッカート尺度
・ネット・プロモーターズ・スコア
・顧客満足度スコア
・カスタマー・エフォート・スコア
・システム・ユーザビリティ・スコア
・プロダクト・マーケット・フィット・メトリック
■まとめ
設定したプロダクトの目標を達成するためには、目標達成の進捗状況を正確に計測するためのメトリクス群が必要だ。本章では、プロダクトの影響を収集し計測するための、戦略上、運用、顧客中心的なメトリクスの選択肢をいくつか提示した。次の章では、収集したデータや情報をどのように実用的なインサイトに変えるかを説明する。
CHAPTER３ 顧客データをインサイトに変える
■まとめ
本章では、顧客から収集したデータや情報を、プロダクトを進化させ続けるためのインサイトに変えるさまざまな手法について説明した。このセクションの最初の2つの章で、プロダクトの実行可能性を確かなものにする方法として、目標とメトリクスを計測することの重要性を強調したが、この章はその旅の続きであった。次の章では、ユーザーの感情など、定性データを計測する方法について掘り下げていく。
CHAPTER４ 感情の測り方
■まとめ
本章では、ユーザーとの関わりを持つことの重要性と、ユーザーがプロダクトに対してどのように感じているかを計測する方法を見つけることの重要性について学んだ。次のセクションでは、計測した顧客の情報を活用して、顧客をプロダクト体験の中心に据える方法について説明する。
CHAPTER５ プロダクト主導型のマーケティング
■まとめ
プロダクトの認知度を高める営みは、まずプロダクトを通じてユーザーを惹きつけることから始まる。プロダクト主導型の世界では、マーケティングはプロダクトの中で行われるのだ。これには、顧客にレビューを作成してもらったり、リファラルしてもらうことで、プロダクトの認知度を高めることも含まれる。また、新規ユーザーをプロダクトに引き込むための最良の方法の1つは、無料トライアルを通じてプロダクトを使ってもらい、プロダクト自体でユーザーのコンバージョンを促進する方法を見つけることだ。もちろん、最終的な目標は、ユーザーをプロダクト体験の中心に据え、ユーザーを魅了する方法を見つけることだ。それができれば、無料ユーザーを有料ユーザーにする機会も増えるだろう。それが次の章のテーマだ。
CHAPTER６ ユーザーを顧客に変える
■まとめ
リードを顧客にするためには、営業チームが不可欠であることに変わりはないが、プロダクト主導型企業では、ユーザーのコンバージョンを促進するためのプロダクト自体の力も認識する必要がある。ユーザーの行動を計測し、顧客化を促す自動化されたトリガーを開発することで、プロダクト自体を営業エンジンに変えることができる。しかし、いったん顧客を獲得したら、あるいは既存顧客から新規ユーザーを獲得したら、ユーザー体験を最大化するために、できるだけ早くプロダクトを使いこなせるようにすることが不可欠だ。この「オンボーディング」が次のトピックだ。
CHAPTER７ オンボーディングでベストなスタートを切らせる
■CareCloudのチームによるオンボーディングの要点
・ユーザーが必要としている機能を提供して関心を持ってもらう
・ユーザーの成果を認める
・体感をゲーム化する
■まとめ
この章では、ユーザーにプロダクトをすぐに使ってもらうための方法と、ユーザーがプロダクトの使い始めでベストなスタートが切れるように、オンボーディング体験をパーソナライズする方法を説明した。次の章では、これらの学びをもとに、顧客がプロダクトをより深く使いこなすために妨げとなるものを特定して、取り除く方法を掘り下げる。これらの戦略により、顧客はプロダクトが真の価値をもたらしてくれると感じるだろう。
CHAPTER８ 価値を届ける
■摩擦の特定 : 離脱やボトルネックを特定する
ユーザーにとってより直感的な体験をデザインする上での第一の目標は、新規ユーザーが、何度もリピートしてくれる機能への道筋を見つけられるように、その道中の摩擦を取り除くことだ。摩擦とは、社会科学者が「認知的「負荷」と呼ぶ余計なステップや、体験の中で気持ちが悪かったり直感的でない部分と考えることができる。認知的負荷とは、他のことから気をそらすような、脳内の活動のことだと考えて欲しい。わずかな摩擦でも認知的負荷を与え、ユーザーをプロダクトから遠ざけてしまう。
これは、よくあるわかりやすい摩擦のポイントの1つは、登録フォームへの入力とプロダクトへのログインの間にある、Eメールの検証ステップだ。セルフサービス型のトライアルやフリーミアムモデルでよく見られ、Webサイトの匿名の訪問者をプロダクトのユーザーにコンバージョンしようとする時に起きる。
このステップには、連絡先の情報の質と整合性を確保するという、間違いなく有用な目的がある。偽のEメールアドレスだと、プロダクトから離脱したユーザーを呼び戻すことが非常に難しくなる。しかし、このステップを追加するとコンバージョン率が50%も低下しうる。なぜだろう。それは、ある画面やアプリケーションから別の画面に移動するというコンテキストの切り替えが必要になり、ユーザーの認知的負荷が増えるからだ。この大事な瞬間に差し込まれる魅力的なコンテンツが目に入り、ユーザーがそちらに気を取られることはよくあることだ。
どのようなユーザー体験にも、摩擦は必ず存在する。大事なことは、それを完全になくすことではなく、どの摩擦ポイントがコンバージョンに至る動線での離脱や、時間の経過による離脱につながっているのかを理解し、それらを厄介なバグと同じように潰すことだ。そして、ユーザーが自分の道筋を見つけやすいように体験をデザインし、ユーザーの背景に沿ったガイダンスを重ねていく。
■まとめ
顧客がプロダクトに何を求めているのかを理解し、プロダクトを使うことで大きな価値を得ていると感じてもらうことは、極めて重要だ。この章では、カスタマージャーニーについて説明し、顧客が自社プロダクトをどのように使用しているかを計測して把握することで、顧客にさらなる価値をもたらせあることを説明した。そのためには、顧客がどこで「摩擦」や不満を感じているかを把握し、プロダクトを通じて自動的に、または顧客体験チームの協力を得て、その摩擦を取り除くことが鍵となる。しかし、プロダクト主導型の世界でカスタマー体験を向上させるためのもう1つの要素は、プロダクトを利用しながら、顧客自身が疑問に答え、顧客自身が課題を解決できる機会を与えることだ。これを次の章で取り扱う。
CHAPTER９ 顧客のセルフサービス
■まとめ
一言で言うと、あらゆる顧客は助けを求めることが嫌いだ。こうしたことは煩わしく、イライラし、必ずしも満足できるものでもない。また、恥ずかしい思いもするだろう。これでは、顧客のプロダクトに対する満足度は上がらない。だからこそ、プロダクト主導型の世界では、外部のサポートチームに頼るのではなく、プロダクトの中で顧客がセルフサービスで解決できる方法を見つけることが極めて重要なのだ。ヘルプメトリクスを使用し、重要な問題が広がる前に特定することが不可欠だ。また、顧客がプロダクトの使い方を自分で学び、その体験からできるだけ多くの価値を引き出す方法を提供することも不可欠だ。これらの学びを踏まえ、さらに発展させることで、新規顧客を獲得するだけでなく、既存顧客を生涯にわたって維持するための道筋を作ることができる。それが次章のテーマだ。
CHAPTER 10 契約更新と拡大で生涯顧客を作る
企業が「生涯顧客」を作りたいと言っているのをよく耳にする。しかし、それは本当は何を意味していて、どうすればいいのだろうか?この章では、プロダクトが顧客を惹きつけるだけでなく、長期的に顧客を維持するために、いかに重要な装置であるかを説明した。顧客維持の方法を理解するためには、考え方を変え、顧客の満足度が反映されるヘルススコアなどの先行指標に目を向ける必要がある。このようなデータに基づいたインサイトが得られれば、顧客のエンゲージメントと顧客維持を高めるための新たな方法を見出すことができる。自社の提供するあらゆるプロダクトをクロスセルし、アップセルするようなことだ。しかし、顧客に生涯にわたって満足してもらうためには、プロダクトを進化させ、再構築することで、顧客が継続的に価値を得られるようにしなければならないという、もう1つの要因にも触れておかなければならない。この課題については、第3部で取り扱う。プロダクト主導型の世界でプロダクトを提供するための新しい方法についてである。
CHAPTER11 プロダクト主導型デザイン
■まとめ
プロダクトをデザインする方法は、これまでとはまったく異なっている。プロダクトマネジャーが直感や経験だけを頼りに、ユーザーが何を求めているかを判断していた時代は終わった。今の時代、デザインにアジャイル思考を取り入れる必要がある。顧客の課題を解決する最も影響のあるプロダクトデザインを提供するには、プロトタイピングの速さと、チーム間のコラボレーションを最優先にする必要がある。次の章では、プロダクトをリリースし、ユーザーに定着させる方法を見直す際に、この原則をどのように適用できるかを説明する。
CHAPTER 12 ローンチと定着の促進
■まとめ
本章では、プロダクトを成功裏にローンチし、顧客に使ってもらうことを確かなものにするための方法を説明した。次の章では、話の方向性を大きく変え、プロダクト主導型企業が、機能やプロダクトを撤退する時期をどのように決定するかを見ていく。
CHAPTER 13 手放すというアート
■まとめ
プロダクトや機能の廃止について語るのは、最初は直観的ではないと感じるかもしれない。ほとんどのプロダクトマネジャーの心は開発者なのだから。プロダクトや機能の廃止は、より良い顧客体験を届けるための極めて重要な戦略になるのだ。昔から言われている「少ない方が豊か」という言葉は、プロダクトに関してもよく当てはまる。コードや機能を無視することは、プロダクトマネジメントを複雑にするだけでなく、顧客の体験を不明瞭なものにしてしまうという代償につながる。しかし、機能を削除する際には、推測や直感に頼るのではなく、ユーザーが実際に何をしているのかをデータで確認する必要がある。また、ユーザーがプロダクトに何を求めているかを真に理解することも同様だ。それが次に取り組むトピックだ。
CHAPTER 14 ユーザーが求めるもの
■まとめ
プロダクトマネジャーが直面する永遠の課題の1つは、ユーザーとつながり、ユーザーのフィードバックを価値を生み出す行動に変えるための効果的な方法を見つけることだ。こうしたことを大規模に行おうとすると、さらに困難が待ち受けている。しかし、テストの実施、ボランティアやカスタマーアドバイザリーボードからのフィードバックの収集、機能要望管理の自動化など、さまざまなアプローチがあることは良い話だろう。いずれも顧客体験をプロダクトの中心に据えることが目的だ。この目標を達成するためのもう1つの要因は、次の章で説明するように、ダイナミックなロードマップの実を取り入れることだ。このロードマップは、ユーザーやプロダクト主導型組織が、未来のどこに向かっているのかを知る助けとなるだろう。
CHAPTER 15 ダイナミックなロードマップ
■まとめ
プロダクトマネジャーの最も重要な仕事の1つは、プロダクトの将来像を描くことだ。その仕事を具体化したものが、組織のプロダクトロードマップだ。これは、企業と顧客が将来進みたい方向を示すものだ。ロードマップは、すべての人が目指す全体像だ。しかし、データに基づいたダイナミックなロードマップの作成は、外部のステークホルダーを整合するだけではなく、組織内のチームを共通のビジョンのもとに集結させるのだ。だからこそ、プロダクトマネジャーは、組織全体の賛同を得ることが重要となる。また、ロードマップの作成には完成はなく、終わりもないことも忘れてはならない。ここで、最終章のテーマであるプロダクトオペレーション(プロダクトOps)の台頭と、プロダクト主導型企業における新たなプロダクトチームを構成する話につながる。プロダクトオペレーションチームは、企業が顧客に最高の体験をもたらす手助けとなる。
CHAPTER 16 モダンなプロダクトチームを作る
■プロダクトOpsの台頭
プロダクトオペレーション(プロダクトOps)という概念は、必ずしも新しいものではないが、一般的とも言えない。そして実際に、この役割を担う人がいることよりも、プロダクトチームでこうした仕事が確実に行われることが重要だ。今のところ、この仕事はある人の仕事の10分の1、別の人の仕事の5分の1ほどの時間が割かれている、といったところだろうか。プロダクトOpsは、成功するプロダクトチームの運営に必要な重要事項にオーナーシップを持つ役割と人を特定することに焦点を当てる。規模を拡大しているテクノロジー企業にとっては、成長を成し遂げることができるか、成長の痛みが増してしまうかの分かれ目になる。それは(営業オペレーションにおける徹底的な効率性を研究開発部門に応用するという意味で)斬新であると同時に、実は身近なものでもある(成功している企業でオペレーション機能を持たない企業はないだろう)。
プロダクトOpsは、マーケティングオペレーション(Marketing Ops)や営業オペレーション(Sales Ops)、あるいはそれらを統合したレベニューオベレーション(RevOps)ほど、頻繁に耳にすることはないだろう。また、DevOpsについても、テクノロジー業界では広く行き渡っている。しかし、こうした流れは変わるだろうと考えている。プロダクトOpsは、すでに一般的になった上記の先行する考え方と同等に受け入れられるだろう。プロダクトOpsは、プロダクト、エンジニアリング、カスタマーサクセスが交わるところに存在する。プロダクトのフィードバックループを強化し、プロダクトの開発とローンチを体系化し、プロダクトに関する知識を全社的に拡大するために、研究開発チームと市場開拓に関連するチームをサポートすることを目指している。明確な役割としてプロダクトOpsが置かれる場合、一般的にはプロダクトマネジメントチームに所属するか、プロダクト責任者をレポートラインとする隣接した部門に所属する。
企業によっては、プロダクトOpsを1つの役割として採用すべきと考えるかもしれない。一方で、プロダクトの専門家であれば誰でも磨ける(磨くべき)スキルセットであると考える企業もあるだろう。私はその両方だと考えている。プロダクト主導型組織では、プロダクトOpsに責任を持つ人を決めるべきで、同時にプロダクトチームのメンバー全員がオペレーションの考え方を身につけるべきだ。
Pendoが毎年実施しているプロダクトマネジャーを対象とした調査によると、半数以上のプロダクトチームが、専門のプロダクトオペレーション機能を持っている。より良いプロダクトの意思決定をサポートするためにデータを管理し、社内外のローンチやコミュニケーションを調整し、プロダクト内でユーザーへの適切なメッセージや体験を統合するためだ。また、プロダクトチームの52%がこうした機能をすでに構築しており、さらに19%がこうした機能の構築を計画している。また、プロダクトOpsを共有の責任としてチームに残しておくことを期待しているチームは30%にも満たない。おそらく驚きはないだろうが、データからは独立したプロダクトOps部門の存在と、企業規模に強い相関関係があることが示されている。売上高10億ドル以上の企業の96%がプロダクトOpsの専任リソースの存在を報告しているのに対し、売上高2,500万ドル未満の企業の場合はわずか17%だ。調査によると、プロダクト主導型企業の利益率は同業他社を527%上回っており、プロダクト主導型企業は、プロダクトOpsのリーダーもしくは、プロダクトOpsチーム全体を雇っている可能性が非常に高いことが明らかになっている。
ここでは、プロダクトOpsチームが実現する各機能について見ていこう。「最適化」、「整合(アラインメント)」、「フィードバックループ」、「インフラとレポート」だ。
■まとめ
これまでの章では、組織が最適な顧客体験を提供するには、ユーザーとの関係を進化させる必要があることを説明してきた。そして、その目標を達成するために使える多くのツールやテクニックについて説明してきたが、プロダクトを中心に据えるように組織も進化させなければならない。そのオーケストレーターがプロダクトOpsだ。プロダクトが組織の中で果たす役割を再考し、ビジネスの他のすべての機能領域をどのように結び付けるかを考えることで、プロダクト主導型組織への変革を始めることができる。
CHAPTER17 行動への呼びかけ
プロダクト主導型のムーブメントは、プロダクト、エンジニアリング、マーケティング、営業、カスタマーサクセスの境界線を曖昧にしている。かつて、プロダクトチームの責任は機能をリリースすることに限られていた。しかし今では、営業やマーケティングと協力してプロダクトを顧客獲得ツールとして再構築したり、カスタマーサクセスと協力してプロダクトをオンボーディングや顧客維持のための手段としたり、役員が戦略的な意思決定を行う際に収益データと一緒にプロダクトの分析結果を見られるようにしたりすることも、プロダクトチームの肩にかかっている。
Posted by ブクログ
本書は、★『プロダクトは顧客体験そのものである。』という強いコンセプトのもと、プロダクトがどんな価値を顧客へ提供し、どう計測し、フィードバックしてプロダクトを成長させ、継続的な最適化の基礎を築いていくか？：つまりプロダクト主導型にしていくための実践的なガイドとなっています。
昨今のプロダクトでは、ユーザーがどのように利用しているか、どういった機能は使われていて、どんな機能はユーザーにも知られていない・活用されていない、ということがデータでほぼすべてわかるということを軸として構成されています。 つまりスマホやブラウザを介して、ユーザーはどのような顧客体験をしているかが提供者側にはすべて見えていて、それに対する高速な追加機能提供を継続することにより、プロダクトは価値を提供し続けられる、と主張しています。
プロダクトといっても、私共が提供するようなインフラを支えるサービスも一つのプロダクトであるから、こういった観点は当てはめにくいよね、というような議論もあるけれど、確かにここ数年で圧倒的ボリュームとなったスマホアプリの概念から考えると、本書で述べられている考え方は相当しっくりくるのかもしれません。
「プロダクト・レッド・オーガニゼーション」：プロダクト主導型組織を作っていくにはどうしたらよいのか？どのような点を意識すべきか、という意味では非常に実践的で参考になる本だと思います。 適用領域という議論は必要かもしれませんが。
ざっと感想とは以上として、以下、「刺さった言葉たち」ほか引用抜粋です。
＝＝＝＝＝＝＝＝＝＝＝
■0．まえがき・プロダクト主導型の戦略
・P5 「そもそも「何を作るのか」を決断する点では、全然うまくいっていないのである。」
（中略） 「顧客にとって適切なものを作るという達成し難い課題へのフォーカスの変化だ」
・P6 彼らは普通の人とは少し違った思考を持っていて、何かを作り、作ったものをより良くすることに夢中になる。「ここはとても情熱的に物事に取り組んでいる人たちのコミュニティだ」といった感覚があるからかもしれない。
・P8 「正しいもの」を作る、つまり顧客に確実に価値をもたらすものを作る難しさは、それが一度やれば終わりではない点にある。作るべきものを選んで、作る、というような単純なものではない。 プロダクトに終わりはなく、進化し続けるものなのだ。これは同時にプロダクトマネジャーも進化し続けなければならないことを意味する。
・P17 重要なのは、そのプロダクトが実際に存在する課題を解決することである。そして、ユーザーが楽しめる方法で実現することだ。これが、プロダクト主導型アプローチの最も重要かつ累積的な利点となる。プロダクトを単なる売り物としてではなく、顧客の生活をより良くする手段とみなすように、組織を変革していくのだ。
・P23 プロダクトマネジメントやソフトウェア開発に関する書籍は数多くあるが、プロダクト主導型組織を構築するという、ますます求められている運営上の課題を解決するコンテンツはほとんどない。
（中略）
本書は、プロダクト組織における計測、フィードバック、継続的な最適化の基礎を確立するため、つまりプロダクト主導型になるための実践的なガイドとなっている。
■１．データを活用して優れたプロダクトをつくる
・P36 プロダクト開発の初期段階では、「Who」をドキュメントに落とし込むことは極めて重要だ。
（中略）
顧客を正しく理解し、共感することでイノベーションが生まれる。
（中略）
鍵となるのは、顧客が本当に求めているものを、データやメトリクスを使って探し出し、見極めることだ。
・P66 すべてのプロダクトチームは、自分たちがリリースした機能が顧客に定着するよう望んでいる（もしくは、期待している）。しかし、残念ながら、そうなるとは限らない。80%以上の機能が、ほとんど、あるいはまったく使われていないことを思い出そう。これらの機能に関するコスト（そして機会損失）を考えると、こうした気づきがビジネスに与える影響は驚異的だ。 だからこそ機能の定着率を計測し、目標に設定することが重要なのだ。
・P87 定性と定量の完璧な融合によって、チームは顧客の全体像を把握し、顧客のニーズを深く理解することができると考えてほしい。同様に、最も価値のあるインサイトは、顧客が明示的に語ることと、顧客の行動で示されることが交差する部分にあることが多い。
■２．プロダクトは顧客体験の中心にある
・P112 従来は各部門が顧客体験の一部をそれぞれが受け持っていたが、現代の消費者はプロダクトを通して企業と100%関われることを期待している。
・P131 ユーザーがやりたいことを可能な限り早く、シンプルな方法で正確に示せば、ユーザーは価値を見出し、定着してくれるということだったのだ。
・P141 初めてのユーザーは、「見知らぬ土地に来た見知らぬ人」ではなく、「ワクワクするような新しい場所に迎え入れられた人」であるべきだ。このような体験をきちんと届けるためには、細部にまで気を配る必要がある。
（中略）
オンボーディングが正しくできれば、プロダクトの拡大は必然となる。
・P188 一方、中立的な顧客は、最も時間をかけるべき顧客である。中立的な顧客は満足してはいるが、「未開拓」である。ちょっとした気配りで、最大のアドボケイトになってくれる可能性がある。
・P191 顧客に生涯にわたって満足してもらうためには、プロダクトを進化させ、再構築することで、顧客が継続的に価値を得られるようにしなければならない
■３．プロダクトデリバリーの新たな方法
・P205 ソフトウェアの開発プロセスが進化するにつれ、プロダクトのバージョンを定義するという考えがほとんどなくなった。この考えはさらに一歩進んでおり、最近の多くのプロダクトデリバリーチームでは、「プロダクトリリース」という概念さえもなくなり始めている。代わりに、プロダクトは流動的で急速に進化する機能の集合体となり、ユーザーのために独自に組み上げられるようになりつつある。
・P232 機能要望をどのように管理するかにかかわらず、フィードバックを提供してくれた人との間で、必ずコミュニケーションをきちんと決着させよう。ユーザーの声を単に分析するだけでは不十分で、ユーザーの声が届いていることを、ユーザーに知ってもらわなければならない。
・P262 本書のここまでで提案したことを一度にすべて実行する必要はない。少しずつ始めればよい。そして、まずはデータから始めよう。計測していないものは改善できないことを忘れてはならない。いくつかの指標やベンチマークを設定し、それを「Why」や「どこに向かいたいか」に結び付けよう。（中略） 今こそ、あなたが行動する時だ。
＝＝＝＝＝＝＝＝＝＝＝
以上
Posted by ブクログ
PLGに関して網羅的にまとめてある本。
具体的な施策というよりも、様々な状況下での思考法のあたりが書かれていた印象。
今の利用状況の計測が何よりも大事、定量的、定性的両面からの判断が大事なのだなあと改めて感じました。
Posted by ブクログ
ププロダクト系の本を重ねて読んでいくと大体おんなじこと書いてあるので知識吸収としては完了、自分に足りないのは実践なので、これからは実践あるのみかと。
メモ
プロダクトのターゲットを決める時、業界のセグメントを切ったあとに価値のセグメントできる
大口顧客はあなたを金持ちにするが、小口顧客はあなたを偉大にする
あらゆる顧客は助けを求めることが嫌いだ
Posted by ブクログ
プロダクト中心の組織経営についての思想や価値観など。プロダクトマネージャーの役割までは明細化されてはないし、具体的な活動や指標のヒントを得るのは難しいと感じる。
Posted by ブクログ
あまり楽しむことができなかった。
プロダクトマネジャーのロールにアサインされるにあたり、自分はどういう心構えでどうプロダクトを育てどう組織をリードしていくのか、についての知見を得たかったのだけれど、コンセプトというか抽象的な発想によっているように感じた。
とはいえ得られた内容で行くと、
- 顧客はプロダクトを雇用して何（どんなジョブ）をさせようとしているのかを定義する（それに合わせてプロダクトを育てていく）
- フィーチャートグルによって主要機能以外を無効にしたり、サブページにあまり使われていない機能を持って行くことで複雑性を減らす
- プロダクトの定着を測り、それを改善するためのアクションを取る
- 機能の定着には時間がかかるので、定着の幅（どれだけの人が使っているか）、定着までの時間（どれくらい時間がかかっているか）、定着期間（どれだけ長く使ってくれているか）といった側面を考慮する
- ロードマップで開発の優先順位を整理しチーム内で合意する、このロードマップはアート（経験基づく見込み）とサイエンス（データが示す確らしさ）を融合した現実的な未来像とする
といったあたりが重要ということを学ぶことはできた。
