PdMをもっと深く知る_#10_細かくスピーディーなデプロイを計画的に
これまで
第1部「データを活用して優れたプロダクトをつくる」
第2部「プロダクトは顧客体験の中心にある」
について理解を深めていきました。
プロダクト主導型組織は、
その名の通りプロダクトから取得できるデータを
全てのステークホルダーが共有してビジネス課題を解決する組織です。
これからの変化の激しいビジネスを勝ち抜くには不可欠な組織像と思います。
ただ商社やコングロマリット企業には無理なので、一つの確固たるコアコンピタンスを有するSaaS型企業と相性が良いと思います。
逆に言うと商社やコングロマリット企業は今後どう成長しながら生きていくのだろうか・・・という疑問は湧いてきています。
さて今回からは、いよいよ最後の第3部に入っていきます！
文字数：約4,100
参考図書
第3部 プロダクトデリバリーの新たな方法
・プロダクトデリバリーとは、開発したソフトウェアのデプロイを通じて、プロダクトを市場や顧客のもとに届けること
・顧客が本当に求める機能やプロダクトを特定し、デザインし、デプロイする方法をどのように見極めるかについて見ていく
・PdMがプロダクトロードマップ作りのダイナミックな手法についても掘り下げる
・プロダクトデリバリー戦略には顧客、チーム、チーム内でのコラボレーションが必要
・プロダクト主導型組織は、デザインとデリバリーに対する新しいアプローチを見直す方法を学ばなければならない
・デジタルの時代において、企業は聞き上手になる必要があり、そのために新しいスキルセットが必要
・それはプロダクトを利用している顧客の声に耳を傾け、顧客をより良い成果に導く
・顧客のエンゲージメントに効くポイントを理解し、全面的に定着してもらうことが不可欠
・ビジネスモデル、エンジニアリング手法、テクノロジーの急速な進歩によりPdMは進化を余儀なくされている
・どのようにチームを編成し、顧客とコミュニケーションし、フィードバックを管理するかという課題を突きつけられている
・実際に顧客から得た情報を基に、うまく行っていることに労力を注ぐことができる
・利用状況の改善と自社リソースにも良い判断ができるようになる
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P23、24、194
11．プロダクト主導型デザイン
■仮説と検証をスピーディーに実行する
・MVPを開発するための計画とリソースを正式に決定した途端、発散的な思考をやめてしまいがち
・正式なプロジェクトになると、UXを前面に押し出す機会を作るよりも、開発者のリソース確保や要件定義、スプリント計画について気を奪われやすい
・大切なことは早期にフィードバックを集め、最適ではないかもしれないソリューションを作って多くの時間を費やすことを避けること
・社内外からの多様なフィードバックの利点は
①プロダクトの利用状況を隅々まで考慮し、より包括的に把握できる
②後戻りなくプロダクトチームが最初から正しいプロダクトをリリースし、*イテレーションに集中できる
・検討やテストには顧客に参加してもらい、開発者に見てもらい、顧客との直接の対話を通じて感情移入してもらう
◼️デザインを大規模に運用する
・デザイン負債とは、プロダクトにおいて、再利用できず一貫性のないスタイルや慣習が過剰に存在すること
・デザインを実践する運用を成熟させることは、デザイン負債を減らし、プロダクト開発のライフサイクルに恩恵をもたらす
・デザインシステムとは企業やプロダクトにおけるデザインに一貫性を持たせ、同時に効率化を図るためにデザインの「コンセプト」「原理と原則」「スタイルガイド」「アイコンやUIコンポーネントのライブラリ」をまとめたもの
・デザインシステムは誰もがすぐに使いこなせるデザイン言語であり、デザイン負債を減らしプロセスを加速させる
・デザインシステムの適用の促進において「デザイナー」「開発者」「その他のステークホルダー」の3つの対象者を考慮する
*イテレーション（iteration：反復、繰り返し）は必要十分に短い期間で繰り返し行うことで良いフィードバックの収集やアイデアの検証を行うこと
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P195～P199
12．ローンチと定着の促進
◼️著者の経験からの学び
・近年では戦略的にプロダクトをローンチできるようになった
・著者の大きな学び
①SaaSの出現により変更を即座に届けることができるようになった
・リリースサイクルが早くなる＝より頻繁にフィードバックを収集できるようになり顧客のニーズに沿ったプロダクトを提供できるようになった
②デリバリーするためのアプローチの変化
・従来はプロダクトの構想を練る→エンジニアが構築→エンドユーザに出荷するなど、いくつかの工程が連なった「ウォーターフォール型」
・ウォーターフォール型の欠陥は、前もって多くの想定をプロダクトに埋め込んでしまう
・つまり古い要求に基づいてリリースしていた
・今はビジネスの都合でプロダクトを無理やり提供するのではなく、プロダクトがビジネスを引っ張ってくれるようにする
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P200～P203
◼️細かいロールアウトが主流
・ロールアウトとは新しいプロダクトや機能をユーザーか利用できるように公開開始すること
・ソフトウェアの場合、一部のユーザーに公開し徐々に対象を広げていく段階的なロールアウトも多い
・まだ完成していないプロダクトをローンチし、特定のユーザーにプロダクトの進化を助けてもらう考え方
・アジャイルが開発フェーズにおける迅速なイテレーションの世界を形作る中で、デザインフェーズにも適用するプロダクトチームが増えている
・近年ではプロダクトデリバリーチームから「プロダクトリリース」という概念すら無くなり始めている
・ユーザーにとってバージョンは関係なく最新でさえあれば良い
◼️なくてはならない機能フラグ
・機能フラグとはリリース時に機能のオン/オフを切り替えるための仕組みでアルファテストやベータテストの構成要素になる
・機能フラグにより、限られた顧客に特定の機能を展開し、より段階的なテストができる
・一方で多くの機能フラグを持つコードの維持は持続可能性のなさや管理のしにくさにつながる
・プロダクトマネジメントにおいて、機能フラグによって次のことが可能となる
①本番環境でのテスト
・新機能が顧客の間にどのように広がるかを把握するための安全で効率的な方法
②新機能の安全なロールアウト
・機能を殺す発想は、緊急修正などのためにエンジニアに依存しなくて良くなる
③継続可能なアプローチを持ち込む
・機能フラグの操作がPdMに移ったことでPdMはアクティブユーザー、コンバージョン率など高いレベルのビジネスKPIに焦点を当てて計測を行うことができる
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P203～P208
◼️作っても気づいてもらわないと意味がない
・プロダクトマネジメント組織は、実験によって開発の努力が顧客体験に与えた影響を正しく計測できる
・すべてのプロダクトチームは、顧客に価値をもたらす機能を構築したいと考えているが、そのためには「顧客からの効果的なフィードバック」「適切な計測」「新しいアップデートに気づいてもらうための能力」が必要
・新機能ができたことを伝えるには関係する人が多いため大きな課題となる
・まずは顧客、そして社内のサポートチーム
◼️プロダクトの成功が機能の定着に依存する理由
・顧客が新機能を認識し活用すれば、新機能は付加価値を生むことになるが、使われていない機能が悪影響を及ぼす可能性もある
＜機能の定着の計測時に考慮すべきこと＞
①定着の幅
・ユーザー全体やターゲットとするセグメントにどれだけ広く定着しているかを見る
・新機能の初期における魅力度がわかる
②定着までの時間
・定着までの時間からユーザーのモチベーションを知ることができる
③定着期間
・ユーザーに真の価値をもたらしているかを示す重要な尺度
◼️機能リリースの促進
・機能を告知する方法に万能な手はないが、検討事項はいくつかある
①関連性
・ユーザーは自分にとって重要な告知に反応しやすい
・適切なユーザーセグメントに合わせた告知が有効
・その新機能が既存ユーザーだけでなく将来の顧客に関係しているかも告知戦略に影響する
②ユーザーにどんな行動をとって欲しいか
・機能の告知や宣伝をアプリ内のモーダルやツールチップの形で配信することでユーザーがプロダクトを利用しているときに、関連性の高いタイミングで告知できる
・重要な行動はその機能を試すこと
■機能の定着の向上
・機能の定着を把握するにはプロダクトチームは「機能の定着の幅」「時間」「期間」を計測し、それらの計測値と機能に関するユーザーからの直接的なフィードバックバックを組み合わせる必要がある
→定量データと定性データの組み合わせ
・新しい機能の気付きやすさも機能の定着に大きな役割を果たす
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P209～P208
＜#10_細かくスピーディーなデプロイを計画的にの所感＞
第1部、第2部でも実用的な内容が続き、参考になると感動していましたが、第3部はよりPdM目線での話になっています。
これはかなり読み応えありです。
Ａ）多くある顧客要望をどう整理するか
Ｂ）それをどうエンジニア部門に作ってもらうか
Ｃ）デザイナーとも計画のすり合わせ
Ｄ）特にデザイナーとはどう告知する必要があるかを議論する
のうちＤを深く理解できました。
残りのＡ～Ｃも意識しながら、次に進んで行きたいと思います。