「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」を読んだ

製品開発に失敗する根本的な原因

製品開発が失敗する根本的原因

• 結局はウォーターフォールになる製品開発

• エンジニアの多くは、設定された大きなウォーターフォールプロセスの中でできるだけ素早く仕事をしようとしているにすぎない。

• このモデルにおけるプロダクトマネジメントの役割はプロダクトマネジメントとは呼べない。

• このモデルでの役割は、エンジニアのために要求事項を集めて文書化することが中心になっている。

• この点において、現代のITプロダクトマネジメントの実像とは180度違っていると言わざるを得ない。

• このモデルが最もタイミングを失しているのは、おそらくエンジニアの仕事を導入するのが遅すぎる点

• もしあなたがプログラムを書かせるだけのためにエンジニアを使っているなら、エンジニアの価値の半分ほどしか生かせていない。

• 製品開発の小さな秘密は、エンジニアはいつも最も優れたイノベーションの源

• それなのにエンジニアはこの議論プロセスのパーティーに招かれることすらない。

• 古いウォーターフォールプロセスの最大の欠点は、今も昔もすべてのリスクが最後に来る点。つまり顧客実証がおこなわれるのが遅すぎるということ。

• リーンの鍵となる原則は、無駄を減らすこと。

• その無駄の最たるものが、ある機能や製品をデザインし、ビルドし、テストし、デプロイしたあげく、それが必要とされていなかったとわかること。

皮肉なことに多くの開発チームが自分たちはリーンの原則を採用していると信じている。だが実際は、今説明した基本的なプロセスをたどっているのだ。そこで私は忠告してあげたい。あなたがたは、知り得るかぎり最も費用と時間がかかる方法でアイデアを試しているのだ

製品に関する２つの不都合な真実

• 少なくとも私たちのアイデアの半分はうまくいかないということ

• 可能性があることが証明されたアイデアでさえ、ビジネス上必要な価値を持つところまで実装を進めるには、通常いくつかのイテレーションが必要だということ

リスクには最後ではなく最初に取り組む。

• リスク？

• 価値のリスク（顧客が購入するかどうか）

• ユーザビリティーのリスク（ユーザーが使い方をわかるかどうか）

• 実現可能性のリスク（エンジニアが、持っている時間とスキルとテクノロジーで必要なものを作れるかどうか）

• 事業実現性のリスク（ソリューションが、販売、マーケティング、財務、法律など、ビジネスのさまざまな分野でも問題がないかどうか）

MVPはプロトタイプであって製品ではない。

知識を得るために実際の製品と同じ品質のものを作るのは、たとえ最小限の機能に抑えたとしても相当な時間と費用の浪費であり、言うまでもなくリーンとは対極にある。

• P → Productの「P」ではなく、Prototypeの「P」。

プロダクトマネージャーとして成功するために

• あなたのユーザーや顧客の専門家になることから始める。

• 学んだことは、良いことも悪いことも積極的に開発チームで共有する。

• 顧客に関しては、質的にも量的にも、あらゆることの理解において開発チームや企業で頼られる人になる。

• 重要なステークホルダーやビジネスパートナーとの間に強固な関係を作るように努める。

• そうした人々に２つのことを確信してもらう。

1. あなたは目に見えないところで課されている制約を理解している。

2. あなたはそうした制約の下で実行できると考える解決策だけを提案する。

• 自分の製品や業界に関して誰もが認める専門家になる。

• これについても広い心で積極的に知識を共有する。

• 最後に、自分の製品開発チームと強固な協力関係を築き、育てるように懸命に努力 する。

ロードマップに変わるもの

• 重要なのはアウトカム。アウトプットではない。

• ロードマップの項目を、解決できるかどうか不明な機能やプロジェクトではなく、解決すべきビジネス上の課題によって記述する。

• 製品開発チームを、機能をビルドするだけのチームから、ビジネス上の問題を解決するチームにステップアップさせる。

• アウトカムベースのロードマップを使うことは、OKRのようなビジネス目標ベースのシステムを使うことと本質的には、同じ。

OKRの基本理念

1. どうやるかを指示してはならない。何をすべきかを指示すればいい

2. パフォーマンスは結果で測る。

• 製品開発チームは望む機能を何でもリリースできるが、それがビジネスの根本的な問題を解決できなければ、実際には何も解決したことにならない、という考え方

製品発見の原則

• 重要なリスクに対応すること。

• 顧客はこれを買ったり、これを使うことを選んでくれるだろうか？（価値のリスク）

• ユーザーはこれの使い方がわかるだろうか？（ユーザビリティーのリスク）

• 私たちはこれを作れるだろうか？（実現可能性のリスク）

• このソリューションは私たちのビジネスに貢献するだろうか？（事業実現性のリスク）

• 特に開発チームは、最も取り組みやすいタイプのリスクに引き寄せられがち。

• 先走って、技術のリスク（性能や規模のリスク）に取り組もうとする開発チームと、ユーザビリティのリスクに的を絞る開発チームが多い。

• それらのチームは、それぞれのリスクに対応することが、自分たちのワークフローの複雑化を伴うことを理解している。

• だからそれが心配になって先走り、すぐにそのリスクに取り組みたくなってしまう。

両方とも妥当なリスクだが、私の経験では、概して取り組みやすいリスクである。

プロトタイプの基本的な目的

• 製品発見においていくつかの製品リスク（価値、ユーザビリティ、実現可能性、事業可能性）に取り組むこと。

• もう１つのメリットとして、エンジニアや他ステークホルダーに「なにをビルドするのか」を伝えることができること。

良い開発チーム・悪い開発チーム

• 良い開発チームは人を魅了する製品ビジョンを持っていて、伝道師のような情熱でそれを追求する。悪い開発チームは傭兵である。

• 良い開発チームがひらめきや製品のアイデアを得るのは、自分たちのビジョンや目標からであり、顧客が苦労している様子を見ることや、自分たちの製品を使うことで顧客が生み出すデータを分析すること、実際の問題を解決するために常に新しいテクノロジーを適用しようとすることからである。悪い開発チームは販売部門や顧客から要望を集める。

• 良い開発チームは重要なステークホルダーが誰と誰かを知っていて、ステークホルダーが負っている制約を理解し、ユーザーや顧客に役立つだけではなく、ビジネスの制約を守ったソリューションを考え出すことに全力を注ぐ。悪い開発チームはステークホルダーから要望を集める。

• 良い開発チームは多くのテクニックに熟達していて、製品のアイデアを迅速に試し、どれが本当にビルドする価値があるかを判断する。悪い開発チームは会議を開き、優先順位を付けたロードマップを作成する。

• 良い開発チームは会社中の頭の切れる第一人者やリーダーとブレーンストーミングをするのが大好きである。悪い開発チームは、チーム外の人が何かするように助言すると不機嫌になる。

• 良い開発チームは、製品開発、デザイン、エンジニアリングの各担当者が並んで座っていて、職能間のギブアンドテイクや、ユーザーエクスペリエンス、実現技術を活用する。悪い開発チームはそれぞれのサイロに閉じこもり、自分たちの協力が欲しい場合は文書の形で要望したり会議を設定したりするように求める。

• 良い開発チームはイノベーションのために常に新しいアイデアを試しているが、必ず収益とブランドを守るように配慮している。悪い開発チームはテストをする許可が出るのをひたすら待っている。

• 良い開発チームは、強力な製品デザインといった、成功する製品を生み出すのに必要なスキルセットをチームの中に持っていると胸を張る。悪い開発チームはプロダクトデザイナーが何をする人かすら知らない。

• 良い開発チームは、製品発見においてエンジニアが毎日プロトタイプを試す時間を確保し、製品をより良くする方法について自分たちの考えを提案できるようにする。悪い開発チームはスプリントプランニングのときにエンジニアにプロトタイプを見せるので、エンジニアは推測するしかない。

• 良い開発チームは、毎週エンドユーザーや顧客と直接関わって、顧客をよりよく理解し、自分たちの最新のアイデアに対する顧客の反応を見る。悪い開発チームは自分たちが顧客だと思っている。

• 良い開発チームは、自分たちが気に入っているアイデアの多くが、結局、顧客の役に立たないことを自覚していて、役立ちそうなものでも、望んだようなアウトカムを生み出すところに到達するには何回かのイテレーションが必要になると考えている。悪い開発チームはロードマップにあるものをビルドするだけであり、予定の期日に間に合い、品質を確認できれば満足する。

• 良い開発チームはスピードが必要であり、イテレーションがどれくらい速くできるかがイノベーションの鍵だと理解しており、そのスピードは強制からではなく、適切なテクニックから生まれることを知っている。悪い開発チームは、自分たちの仕事が遅くなるのは同僚が一生懸命働かないからだと愚痴をこぼす。

• 良い開発チームは、要望を評価し、顧客にもビジネスにも有益で実行可能なソリューションができたことを確認したあとで、ハイインテグリティーコミットメントを作成する。悪い開発チームは、自分の会社は販売主導だと不満を言う。

• 良い開発チームは、自分たちの製品がどんなふうに使われているかを知るために製品に計装し、データに基づいて調整する。悪い開発チームは、分析と報告は、あればいいが、なくてもかまわないと考えている。

• 良い開発チームは、小さなリリースをコンスタントに続ければ、顧客に、より安定したソリューションを提供できることがわかっているので、継続的にインテグレーションをおこなってリリースする。悪い開発チームは、骨の折れるインテグレーション段階の最後に手動でテストをおこない、すべてを１度にリリースする。

• 良い開発チームはリファレンスカスタマーにこだわる。悪い開発チームは競争相手にこだわる。

• 良い開発チームは業績に大きく貢献したときに祝う。悪い開発チームは最終的に何かをリリースしたときに祝う。

Copy of 「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」を読んだ。