PdMをもっと深く知る_#11_やらないことを決める勇気を持つ
前回はプロダクトのデリバリーの方法とそれを早く実施する方法について見てきました。
一方で早さを生むには何か犠牲が必要です。
ムダなことはもちろんですが、いまやるべきことを明確にする必要があります。
今回は、簡単そうで実はかなり難しい機能やプロダクトの撤退方法について見ていきます。
文字数：約5,300
参考図書
第3部 プロダクトデリバリーの新たな方法
・プロダクトデリバリーとは、開発したソフトウェアのデプロイを通じて、プロダクトを市場や顧客のもとに届けること
・顧客が本当に求める機能やプロダクトを特定し、デザインし、デプロイする方法をどのように見極めるかについて見ていく
・PdMがプロダクトロードマップ作りのダイナミックな手法についても掘り下げる
・プロダクトデリバリー戦略には顧客、チーム、チーム内でのコラボレーションが必要
・プロダクト主導型組織は、デザインとデリバリーに対する新しいアプローチを見直す方法を学ばなければならない
・デジタルの時代において、企業は聞き上手になる必要があり、そのために新しいスキルセットが必要
・それはプロダクトを利用している顧客の声に耳を傾け、顧客をより良い成果に導く
・顧客のエンゲージメントに効くポイントを理解し、全面的に定着してもらうことが不可欠
・ビジネスモデル、エンジニアリング手法、テクノロジーの急速な進歩によりPdMは進化を余儀なくされている
・どのようにチームを編成し、顧客とコミュニケーションし、フィードバックを管理するかという課題を突きつけられている
・実際に顧客から得た情報を基に、うまく行っていることに労力を注ぐことができる
・利用状況の改善と自社リソースにも良い判断ができるようになる
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P23、24、194
13．手放すというアート
■捨てる美学
・自分が作ったものに感情移入し過ぎないことが大切
・機能が追加されるたびにメンテナンスやトレーニングが必要となり、ユーザー体験も煩雑になってしまう
・プロダクトにおいて「少ない方が豊か（Less is More）」
・PdMにとって重要な責務の一つは「使われていない、あるいは価値のない機能の廃止」
・まずはエンジニアチームと廃止できそうな機能の候補について議論する
・捨てる際の最も重要なインサイトは、まだ使っているユーザーの理解
＜機能を捨てるテクニック＞
①ペインをテストする
・ユーザーに削除してよいかと聞けば、必ず「いいえ」と言われる
・例え使われていない機能でも、人は変化を嫌う
・1つの方法は実際に削除してみてユーザーがどれだけ悲鳴をあげるかを実際に見てみること
・機能を削除する際にもメトリクスが必要。例えばある機能がSMEsに人気がある一方でエンタープライズには全く無視されているなど貴重な情報となる
②ビジョンの確認
・削除する機能がプロダクトにとって過去か未来のものかを考える
・今後大企業をターゲットとするのであれば、SMEs向けの機能は削除候補になるかもしれない
・顧客に削除する機能について聞いてみることも重要だが「この機能についてどう思いますか？」でなく「もしこの機能がなくなったら、代わりに何をしますか？」と質問をする
・機能削除のもう一つの目的は「顧客の共感を得ること」
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P216～P219
■書き換えの課題を克服する
・ソフトウェアのコードの書き換えは、「新しいもの」と「古いもの」が競合するため、書き換えは難しい作業
・ユーザーに古い機能からの脱却を促すもの難しい
・コードの書き換えを余儀なくされた場合の選択肢
■事例① Basecamp（捨てずに並走させる）
＋すでに人気のアプリだったが、新しい機能追加のために既存ユーザーが仕事を中断することを嫌がった
＋そこで別バージョンのアプリをもう一つ作成し、特に告知もせず新プロダクトに興味のあるユーザーに提案するにとどめ、旧プロダクトも引き続きサポートした
＋特筆すべき特徴は「変化を好まないユーザーは不利益を被ることなく、プロダクトの限界に直面している人は新しいアプリを選ぶことができる」点
＋一方でソフトウェアの維持にコストがかかるし、新プロダクトを積極的に開発できるリソースを持っている必要がある
■事例②Google Inbox（人気のあるものだけ残す）
＋Inboxは廃止したが、Inboxで人気のあった一部機能をGmailに移植した
＋既存ユーザーを大きく混乱させることなく、古い機能を廃止し、新しい機能を導入した例
・未来のイノベーションのために元のプロダクトの価値を必ずしも捨てる必要はない
・すべての人に新しいものを作る、という考え方は誤り
・重要なことはコンバージョンしやすそうな一部のユーザーのために新しい機能をつくる
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P219～P222
14．ユーザーが求めるもの
■適切なユーザーフィードバックを得る方法
・機能を削除する際、推測や直感に頼るのではなく、ユーザーが実際に何をしているのかをデータで確認することが必要で、プロダクトに何を求めているのかを理解することも必要
・プロダクトを成功させるには顧客のフィードバックが不可欠
・最も質の高いフィードバックを得るには、ユーザーの行動を把握した上でターゲット/セグメントを絞った働きかけを行うことが重要
例）ある機能の改善にはその機能を利用しているユーザー、オンボーディングプロセスに関するフィードバックは初めて利用するユーザーなど
■価値の高いユーザーテストの実施
・ユーザーテストは非常に価値があるので、プロダクトチームはできる限り頻繁に行うべき
・ユーザービリティテストには質の高い候補者が不可欠
・ユーザーの全体像を把握するために自分の視野に入っていない最適な対象者（サイレントマジョリティ）を探す
・プロダクトの利用時間、顧客歴の長さ、部門、契約プランなどプロダクトデータを駆使して質の高い参加者を絞り込む
■テスターの募集方法
・ユーザーテストを開始する前に「どのようなタスクを含めるのか」また「収集する必要のあるメトリクスは何か」を考える
①電話やメール
・最も一般的であるが、反応率が低い傾向がある
②カスタマーアドバイザリーボードやグルーブインタビュー
・カスタマーアドバイザリーボードとは、主要な顧客で構成されるグルーブ
・より良いフィードバックを得ることができる反面、主張の強い参加者と弱い参加者がいる点は注意
・アプリ内で参加者を募るのは良い方法
③1 on 1 インタビュー
・最も信頼性の高いフィードバックを得る
・準備に時間がかかりデータが古くなりがち、学びをプロダクトチーム全体に共有するのが難しいなど課題がある
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P223～P226
■次世代のフィードバック
■既存のフィードバック方法とのギャップ
＜新しいフィードバック戦略＞
①アプリ内でのフィードバック調査や投票
・特定部分に焦点を当てた具体的な質問ができる
・プロダクト利用中の調査であるため高い回答率を得る
②アンケートツールの活用
・より詳細な情報を収集できる（ただし質問がうまいことが前提）
・仮説の証明だけでなく、新たなインサイトも得る
③NPS
・顧客がプロダクトをどれだけ気に入っているかを理解できる
・スコアの変動 ＝ コア機能の見直し時期の示唆
④カスタマーアドバイザリーボード
・長期的な関係を構築し、プロダクトの未来をデザインする
・アドボケイトを生み出すにも最適
⑤即時共有の仕組
・Googleスプレッドシートなどで営業＆カスタマーサクセスチームが定期的にプロダクトのフィードバックを共有できる
＜PdMがフィードバックに対して認識しておくべき問題点＞
①社内のチームは優れた直感を持っている。しかしプロダクトチームにとっては、誰がそれを求めていて、実際に何と言っているのかを理解できないと納得できない
②ユーザーは自分のフィードバックがどれだけ求められているか、そのフィードバックがプロダクトの決定にどのように影響するのか知らない
③ユーザーの要望する機能は、解決方法を前提にした話になってしまっている。より価値のあるフィードバックはユーザーが解決したい問題や「Why」にある
④プロダクトチームは複数のスプレッドシートに書かれたフィードバックを管理したり、何千ものフィードバックを整理して実用的なインサイトを見つけるのに苦労している
■次世代のフィードバック
・NPSの回答、ベータ版の評価、プロダクトのギャップを埋めるための要望などあらゆる定性的なデータを1つの格納場所で管理している
・理想的な管理方法は
①顧客やカスタマーサクセスチームがいつでも入力できる
②チームがフィードバックを特定の領域・要望、またはロードマップにマッピングできる
③追加の質問や変更をチーム内に簡単に共有できる
・フィードバックデータベースを作るにはSalesforce、Airtable、Pendo、UserVoiceなどのツールを使うことで解決できる
・理想的なPdMはフィードバックを統合的に分析することで
「顧客Aから最も多く発せられているフィードバックは何か」
「機能Aでなく機能Bを選択した場合の潜在的な収益への影響は何か」
という質問に答えることができる
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P226～P230
■熱心な企業ほど熱心な顧客を生み出す
・プロダクトへの要望が途絶えることはない
・こうした要望は構造化されておらず、さまざまなチャネルを経由して届くため、ユーザーからのフィードバックが無視されることもある
・PdMが小さな提案も含めてすべて精査することは必ずしも重要ではない
・プロダクト主導型組織は、いくつかの要望をマッチングして、最も密度の高いところに時間を投資する
・重要なことは顧客との双方向のコミュニケーションを作ること
■機能の優先度付け
・顧客と市場の両方を考慮する
「シンプルな投票」：ユーザーが希望する項目に希望するだけ投票する
「重み付け投票」 ：ユーザーが割当てられた投票数分だけ価値を割り振る
「ペアワイズ投票」：2つのアイデアを提示し、どちらが良いか問う
・PdMの目的は最優先事項を決めること
・ユーザーの声を単に分析するだけでは不十分で、ユーザーの声が届いていることを知ってもらうためにも、双方向のコミュニケーションを決着させる
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P230～P232
■プロダクトのパフォーマンスを計測する
・受け取ったフィードバックにはバグも含まれる
・バグを避けることはできないので、どう対処するかが重要
＜バグへの対処方法＞
①機能別内訳の把握
・バグの多い部分を特定し、リソースを割くことができる
・対処するバグの優先度は、利用状況と掛け合わせることも重要
②バグ数の比較
・報告されたバグ、解決したバグ、残っているバグを記録する
・プロダクトの品質を測定することができる
・いまのユーザーはプロダクトが当然のごとく機能し、速く動くことを期待している（特にSaaSで顕著）
・プロダクトのパフォーマンスをチームの最優先事項とするためには、ユーザーの操作に対して、どれだけ早くレスポンスできるかという目標値を設定する
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P232～P236
＜#11_やらないことを決める勇気を持つの所感＞
よりPdMの実践術になってきたのでINSPIREDの内容でも見てきたことが増えてきた印象です。
PdMの最大の責務は優先度決める事とありましたが、これすなわち
いまのリソースと技術で、やらないことを決める
と言い換えることができます。
管理職になってさまざまな部門と折衝するようになると、やらないことを決める現実に直面します。
しょうもない社内調整と分かっていながらも部下のパフォーマンスをよくするために戦う必要もあります。
現場で走っている頃は、とにかく言われたことをやる真面目さとユーザーの声をしっかり伝える真面目さが必要です。
やらないことを決める最初の辛さは「嫌われること」でした
PdMは語弊はあるかもしれませんが、「敵」との闘いで如何に部下を疲弊させずに早く走りきるか、だと思いました。