前職で初出勤の日に会議室に入り、ホワイトボードにリスト化された、たくさんの機能のリストを見ました。全部で20ほどあったのですが、その横にはいくつかの走り書きがあって、実際には20以上の機能が追加されるように見えました。他のPMからは、機能リストは前年のプロダクトロードマップにあった項目だが、すべてを開発する時間がなくなってしまったと説明されました。開発チームは、これらの機能を完成させて顧客にリリースするために、年初の数週間を費やしていました。リストの機能の中には不要なものもあり、もっと重要な仕事があるように思えましたが、すぐに多くのクライアントがこれらの機能を契約書に記載しているのがわかりました。私は、プロダクトロードマップの次のフェーズが始まる前にプロダクトを出荷するために、バグだらけのコードを修正したり、失敗したリリースに取り組んだりしながら、チームが過酷なスケジュールと戦うのを、1ヶ月半の間見守っていました。
さて、今回のケースは、「Product Roadmaps Go Wild」（テレビシリーズ？誰かしっていますか？）の非常に極端な例でしたが、決して珍しいことではありません。非現実的なロードマップがチームや良いプロダクトを破壊するのを何度も何度も見てきました。プロダクトロードマップをハイレベルなガイドではなくガント・チャートと考えるのをやめれば、多くの問題は解決できるかもしれませんが、従来のプロダクトロードマップの作り方では、チームが革新的で成功することを妨げています。その理由は以下の通りです。
推定はおもいつき
機能開発にかかる時間を見積もると、たいていは推測の域を出ません。もっとひどいことに開発者の意見を聞かずにプロダクトロードマップが作成されるのを見たことがあります（注意：これは最悪のアイデアです）。一般的に、どの機能を構築するかというハイレベルな概要を開発者は聞き、その機能を構築するのに、どれくらいの時間がかかるかを示す何らかの値を割り当てます。これらのプロダクトは、タイムスロットに入れられ、そのすぐ後ろに 「ガントチャート」のように何か他のプロダクトが配置されます。
さて、チームがX週間の終わりから2週間が経過し、プロダクトが完成しないことが明らかになったとき、2つのことが起こります。一つは、開発期間が過ぎてしまい、次の製品が延期されてしまいます。これは通常、「締め切りを逃した」「優先順位を正しくつけなかった」などと、経営陣から多くの悲鳴が上がる結果となります。あるいは、締め切りに間に合うように、そして非難を避けるために、持っているものは何でもリリースしようと急いでしまいます。
2つ目はさらに大きな問題です。バグだらけのコードがプッシュされ、テストがほとんど行われないという結果になることが多くあります。プロダクトを修正するための作業が増えていきますが、プロダクトロードマップが一杯で、次の大きなプロジェクトを開始しなければならないため、修正は不可能になります。これで、プロダクトはバグだらけの王様になりました。
大きな仕事の塊を見積もるには、機能を計画して考え抜かなければほぼ不可能ですが、これはロードマップをかなり前から計画するときには行わないことです。この記事の最初の例をみてください。
検証や研究の時間が予算化されることはほとんどありません。
優れたプロダクトを開発するには、広範な調査、製品戦略、優れたUX、堅実な開発、豊富なテスト、そして顧客からのフィードバックが必要です。ロードマップの見積もりでは、大抵、これらのうち少なくとも2つ、テストとリサーチが省かれています。企業がプロダクトにどれくらいの期間がかかるかを見積もるとき、通常、ワイヤーフレームとデザインのために最初に1～2週間を追加します。リサーチがほとんど行われていないため、ユーザーの問題を解決しないプロダクトを作ることになってしまうことがよくあります。プロダクトロードマップの次のプロダクトに取り組むまで、このことに気づくことはありません。ロードマップが一杯になってしまったため、前のプロダクトに戻って修正するための時間が確保されることはほとんどありません。これが次の問題を引き起こします。
変更の余地はほとんどありません。
ロードマップで割り当てられた時間の100%を開発へ注いでしまうと、フィードバックに基づいて対応したり、既存の機能を改善する時間がなくなってしまいます。プロダクトをリリースするたびに、顧客の問題点や不満、好き嫌いについて新情報を得ます。これらの情報は、プロダクトをより良いものにするために反映されるべきですが、多くの場合、フィードバックを受けた時点で次のプロダクトに移ってしまっているため、そうならないことが多いのです。
また、このようなフィードバックセッションの中で、取り組むべき大きな問題があることに気づくこともあります。方針変更で計画したロードマップが台無しになることを恐れて、通常の対応は「ロードマップをもう一度見直したときに、それをスロットインする」というものです。残念ながら、ほとんどの企業は年に2回から4回ロードマップを見直しますが、これは変化に素早く対応するには頻度があまりにも低すぎます。
私が上記で述べた問題の多くは、ロードマップを常に見直し、見積もりを正しく行い、優れたUXの実践をしていれば、緩和・軽減できます。私はこれらのことを実行し、成功を収めている企業をいくつか知っています。しかし、プロダクトロードマップには、これらのプロセスでは修正できない致命的な欠陥が1つあります。
プロダクトロードマップは、ソリューションと機能のみに焦点を当て、問題を無視しています。
プロダクトロードマップでは、「エピック」と呼ばれる大規模な機能セットを長期間にわたって構築する計画を立てます。ロードマップは事前に計画しているため、エピックを開始する頃には、通常、構築するものについての最新のリサーチや情報はほとんどありません。無関係だったり、問題が解決されていなかったりすることもあります。しかし、これらの機能を廃止することはほとんどありません。なぜでしょうか？
ユーザーの問題を解決するために機能を構築するというポイントを完全に見落としているからです。このような精巧な機能を計画し、仕様化に集中するあまり、そもそも、なぜ機能を構築するのかを私たちは忘れてしまうのです。エピック の仕様策定フェーズが始まると、ロードマップを計画した時点では明白だった問題が、まだ関連性のあるものかどうかを分析することにあまり時間を割くことはありません。残念ながら、問題を慎重に分析せずに解決策を考えるという性質のもので、機能セットの豪華絢爛さに夢中になってしまうと、本来の問題が何かを解決しようという動機よりも噂の域を出なくなってしまうのです。
プロダクト機能
これは、特に若い企業に移行しつつあるスタートアップ企業にとっては大きな問題だと思います。彼らは、より多くのプロセスを導入して拡張性を高めようとしていますが、それでも競争力を維持したいと考えています。これらのスタートアップ企業がプロダクトロードマップの実装を始めると、問題解決モードから機能過多の状態に陥ってしまいます。これは、私の知る限り、最も早くイノベーションを阻害する可能性があります。チームがユーザーのために価値を生み出すよりも、会社のプロセスや納期を守ることに集中している場合、そのチームは問題を抱えていることになります。
では、イノベーションを止めずに、チームに構造と方向性を与えるにはどうすればいいのでしょうか？
問題解決のためのロードマップ
私が一緒に仕事するチームには、プロダクトロードマップをプロブレムロードマップとして扱うことを提案しています。開発すべき機能に焦点を当てるのではなく、解決すべき問題に焦点を当てるのです。
問題解決のためのロードマップは、自分のビジネスに適した方法で、どのような期間でも計画できます。私の例では、テストと解決策を検討するのに十分な時間を確保するために、Quartersを使用しています。これは2つのフェーズに分かれています。「発見と実験」と「構築と検証」です。
各クロスファンクショナルチームは、期間中に解決すべき問題に取り組んでいます。チームの目標は問題を解決することです。問題が正常に解決されたかどうかを示すKPIを各チームに割り当てます。
「発見と実験」フェーズでは、チームは顧客調査と問題の存在確認の検証に注力します。十分な調査を集めたら、市場でテストするためのMVPの構築を開始します。このプロセスは、迅速に、しかし慎重に、広範囲の顧客と対話をしながら行う必要があります。MVPの成功が証明された後、チームは「構築と検証」の段階に進みます。
「構築と検証」フェーズでは、チームはユーザーの核となる問題を解決するための最低限のソリューション（機能セット）に焦点を当てます。チームは常に顧客に向けてリリースし、フィードバックを受け取ります。チームは、必要不可欠で有用な機能を維持しながら、時間内に何を構築できるかを計画します。フィードバックがあれば、より多くの機能を追加して反復します。
期間終了時にをより多くビルドアウトする必要がある場合は、優先順位の高い問題に追加し、メトリクスを使って解決する必要のある他の問題と比較して重み付けをします。これらの機能を開発が優先度が高い場合は、「構築と検証」フェーズを継続できます。
プロブレムロードマップの作成方法
- チーム/会社として、顧客が今直面している問題の上位をリストアップしてください。
- 問題のリストに優先順位をつけ、強いものから順に並べる。
- 各クロスファンクショナルチームに、その四半期に取り組むべき問題と、問題解決の進捗状況を測定するためのKPIを割り当てます。
- 各チームは、その問題がまだ顧客にとって強力な問題かどうかを検証する責任があります。問題が問題でなくなった場合は、リストの次の問題に移り、その問題を検証します
- 問題が検証されると、チームは顧客と直接対話しながら問題の調査を行います。
- チームは、初期調査と市場でのテストを経て、MVPの開発を開始します。
- MVPが検証されたら（チームが設定した目標を達成したら）、チームは残された時間内にできるソリューションの構築を開始します。チームは必要最低限の機能セットに焦点を当て、必要なものだけを提供する。チームは、顧客からのフィードバックやイタレーションのために頻繁にリリースすることに注力します。
- 四半期の終わりには、初期段階で顧客からのフィードバックを受けた後、チームはソリューションの追加にさらなる投資が必要かどうかを決定することができる。ロードマップはそのために調整されます。
- 次のサイクルの初めには、このプロセスを繰り返します。問題のリストを再検討し、顧客のニーズに基づいて優先順位を付け直したり、新たな問題を追加したりします
このプロブレムロードマップでは、上記の課題の大部分を解決しています。機能で考えるのではなく、顧客の問題を解決することで、いかに顧客に最も価値を提供できるかを考えます。顧客からのフィードバックを迅速に得るために、短期間で構築してリリースできる最低限のソリューションに焦点を当てているため、複雑な機能セットの見積もりは必要ありません。問題は常に評価されているため、ロードマップは柔軟性があり、無関係な問題は各サイクルの初めに潰されます。問題を解決できるかどうかわからないソリューションにコミットすることなく、取り組む予定の問題をチームと顧客に伝えられます。
引用元
Rethinking the Product Roadmap
