そうです、ロードマップの効果は過大評価されています。私たちは、この見解に固執しています。
製品ロードマップは、製品開発における包括的な福音と見なされることが多い。あえて言うなら、ロードマップの文化だろうか。しかし、ロードマップは創造性、柔軟性、そして古き良き時代のイノベーションを殺してしまう。
私たちは、あなたが今抱えている製品管理に関する危機や怒りが収まるまで待ちます。さて、あなたは座って本当にそれについて考えたことがありますか？なぜ製品ロードマップが必要なのでしょうか？なぜ製品ロードマップが重要なのでしょうか？
ここtl;dv で、我々はあなたが成功するために望んでいる。私たちは、あなたが私たちのオンライン会議記録ソフトウェアについてであるように、超誇るために製品を作るためにしたいと思います。
今すぐ製品ロードマップを捨てるべき（かもしれない）7つの理由
ロードマップは顧客のためではなく、経営者のためにある
顧客は常に正しい」と言われます。しかし、ロードマップに関しては、実際の顧客ではなく、経営者を念頭に置いて作成することに、しばしば罪悪感を覚えます。
@tldv.io 二度とそんなこと言わないでください。#プロダクトマネージャー #プロダクト #テック #pm #tldv
オリジナルサウンド - tldv.io - Meeting Recorder
製品は常に顧客第一であるべきですお客様にとって何が重要かを考え、その機能を何よりも優先させなければなりません。そうすれば、誰もが得をするのです。役員も喜ぶし、何より顧客が喜ぶのです。
しかし、私たちはしばしば、社内の人々を幸せにすることを第一に考えることがあります。他部署の人が入ってきていじったり変更したり、エゴや意見で機能を動かしたり、みんなの意見を聞いてスケジュールを伸ばしたりします。
ロードマップを顧客第一主義にするためには、まず、顧客が誰で、何を必要としていて、なぜそれが顧客にとって重要なのかを明確に理解することから始める必要があります。そうすることで、作成時に最も重要な機能について、率直な会話ができるようになります。
では、次にロードマップを作成するときは、自分に問いかけてみてください。この機能は誰のためにあるのか？この機能は、顧客にとって重要なものなのか、それとも単なる見世物なのか？
ブリッジと一体になる
ロードマップに固執すると、製品チームは決められた仕事のやり方に縛られることになります。そうなると、変化する顧客のニーズや需要に適応することが難しくなります。また、市場の変化に迅速に対応することも難しくなります。
アジャイルワークフロー？どちらかというと "アジャイルワーク-NO!" ですね。
吊り橋とその構造を考えてみる。まるで自分が吊り橋になったかのように、製品開発に取り組む必要があるのです。暑いときも、風が吹いているときも、雨が降っているときも、状況に応じて柔軟に対応できるようにしなければなりません。
あなたは強く、安定していますが、弾力性があります。何かが変化したとき、あなたはそれに対応する準備ができています。そうすることで、成功への道を切り開くことができるのです。
ロードマップがあっても、柔軟でオープンな姿勢を保つことが重要です。
ピボット、ピボット、ピボット！
渋滞が発生するとナビがルートを再計算するように、新しいインサイトが発見されたら、たまには方向転換する必要があります。
あの超厳格な、絶対に動く余地のないロードマップ？ええ、それは助けになりません。
必要に応じて戦略を調整できる柔軟性を持たせないと、大変なことになります。特に、プロジェクトやビジネスの意思決定を左右しかねない、データに裏打ちされた意思決定を行う場合には、その傾向が顕著です。
ですから、データを収集し、仮説を立てる際には、すぐに判断を始めないように注意してください。誤った仮定や研究の偏りを追って、時間や資源を無駄にしたくありません。データの持つ力を信じて、当初の予定から外れた判断を下すようにしましょう。そしてもちろん、PIVOTを忘れないでください。
Visionary Shmisionary
製品チームの中に、自分をスティーブ・ジョブズだと思っている人が一人はいるに違いない。タートルネックを何本も持っていて、自分のことを「先見の明がある」と言うに違いありません。また、ロードマップへの素晴らしいインプットを真っ先に口にするのもその人たちでしょう。
真のビジョナリーとは、そのほとんどが手探りである。幸せな偶然に絶えずつまずきながら、「自分のパンツで」というような雰囲気です。
実は、一部のプロダクトマネージャーだけは、最初から何が出てくるかわからないのです。
そして、あなたは知っていますか？それでいいんだ！
実際、史上最高傑作と呼ばれる名品の中には、最初はまったく別のものだったというものもあります。
ポスト・イット・ノート- OGの課題は、航空宇宙産業用の接着剤を作ることでした。
Play-Doh- 子供の愛すべき人気者!いや、壁紙掃除グッズ!
ウスターソース- ある顧客のために作ったが、その顧客は戻って来ず、樽のまま地下室に2年間放置された。世界中のブラッディメアリーが、その忘れっぽさに感謝している。
スーパーグルー- 第二次世界大戦中に、透明な銃の照準器を作る方法を見つけるために発明された。超粘着性があり、本来の目的には適さないが、その結果、どれだけの花瓶が壊されずに済んだことだろう。
スリンキー- 文字通り、船の上で物事を安定させるために作られました。その船は順風満帆ではなかったかもしれませんが、プロダクトマネージャーはその後、楽な道を歩んだに違いありません。
これらに共通する2つのことは何でしょうか？
- 彼らは毎年、数百万ドル...いや、数十億ドルを稼ぎ出しているのです。
- 当初の製品ロードマップにはなかったし、実際、全部投げ出してしまったんです
ロードマップはサイキックのためにある
新製品の場合、計画を立てるのは非常に難しく、不可能に近い。新商品には、比較する基準もなければ、データや事実に基づいたタイムラインもありません。マイルストーン？この時点では、それは夢物語です。
プロジェクトの期限を設定することは、100％可能です。しかし、本格的なロードマップはどうでしょうか。ロードマップを作成したら、宝くじの当選番号を教えてもらいましょう。
UXリサーチャーやマーケティングチームにとって、ロードマップを作るのは大変なことです。常に、まだ存在しないものを予測し、判断材料にしようとしているのですから。
ここで必要なのは、現実をしっかり認識することです。ロードマップを作ることよりも、製品やサービスを柔軟に管理し、その都度適応していくことを考えましょう。
人生（そして製品開発）において唯一確かなことは、変化することだと私たちは皆知っています。ですから、今度ロードマップを求められたら、サイキックが必要であること、少なくとも水晶玉を大量に見る必要があることを先見性を持って伝えましょう。🔮 🧙♂️ 🔮
ロードマップの成功の定義は最悪だ
プロダクトマネジメントの成功は、どのように測ればいいのだろうか？それが100万ドルの質問だ。
一般的には、当初のロードマップに記載されたマイルストーンを達成できたかどうかで成功を判断する、という答えが返ってきます。しかし、これでは成功の尺度として適切ではありません。また、成功やブレークスルー、そして学習と適応の過程で生じる「おお、神よ！」という瞬間も考慮されません。
製品管理における成功の定義は、単に納期を守ることだけではないので、再定義する必要があります。
成功とは、納期を守り、顧客が製品やサービスに対して実際に何を求め、何を必要としているかを理解することです。フィードバックに素早く対応し、迅速に適応していくことです。
最初に設定したマイルストーンから外れたものは、失敗とみなされる可能性があるのです。しかし、製品管理の世界では、このようなことは許されません。
プロダクトマネージャーとして、私たちは顧客の成功に焦点を当てるべきであり、マイルストーンのリストにチェックを入れて「成功した！」と言うべきではありません。確かに、OKRやKPIのようなものもありますが、それらも制限されることがあります。
私たちが目指すべきは、最も重要なこと、すなわち顧客体験と、それを提供する上で私たちの製品やサービスがどれだけ成功したかを測定することです。
それが、製品を作り、管理する際に重要視されるべき成功の定義なのです 
The A-Z Of Somewhere Else, aka The Sunken Cost Fallacy (サンクン・コストの誤り)
さて、あなたがロードマップを完全に窓から投げ捨てるつもりはないことは知っています。しかし、もしロードマップを持つことにこだわるのであれば、それは正しい種類のロードマップであるべきです。
間違ったロードマップは、ディズニーワールドの地図をコピーして上海に持っていくようなものです。地図のように見え、地図のような匂いがし、地図のような味がする...それは正しい地図ではないのです。
私たちはしばしば、ロードマップを良いものよりも悪いものに変えてしまい、しかもそれに固執してしまいます。これは、「沈没コストの誤謬」によるものです。これは、明らかに自分が望んでいないことであっても、それを放棄することはできないという心理的な罠です。
私たちは、すでに費やした時間とリソースの膨大な投資を正当化するために、プロジェクトにさらにエネルギーを注ぎ込んでしまうのです。
では、実際にロードマップを作成する際、どのようにすれば「埋没コストの誤謬」を回避できるのでしょうか？
あなたの製品や空間の歴史を分析してください。過去に何が起こったのか、なぜそうなったのかをよく見てください。そうすることで、避けるべきパターンを特定することができます。例えば、物事がうまくいかなかったのは、あまりにも硬直したロードマップに固執したためでしょうか？
重要なのは、製品で何を実現しようとしているのかを理解し、それを軸にロードマップを構築することです。プロジェクトがうまくいかない既存の構造に無理やりはめ込もうとしないことです。また、途中でユーザーからのフィードバックを得ることで、自分たちが取り組んでいるものが実際に役に立つかどうかを知ることも大切です。
製品ロードマップの迂回路のアイデア
ロードマップを破棄することは、何も見えなくなってしまうということではありません。ここでは、製品を正しい方向に進めるために使える別のアプローチをいくつか紹介します。
- スプリントサイクルを短く設定し、達成可能な小さな目標に集中する
- 各スプリントにおいて、全員が同じ重要な目標に合意していることを確認する。
- 何がうまくいき、何がうまくいかないかを見つけるために、継続的にテストと学習を行う環境を醸成する。
- 達成すべきカスタマー・サクセス・メトリクスを全員が明確にする。
- 現在の顧客ニーズとデータに基づく洞察に基づき、製品の機能と調整の優先順位を決定する。
- 新しい洞察を発見したら、必要に応じてプロセスを適応させる。
- もう一度、ユーザー調査に戻って聞き直す
- 前回のスプリントを振り返って、学んだことを今後の意思決定に役立てる。
結局のところ、製品開発を進める上で最も良い方法は、ロードマップを逐一追うのではなく、顧客に焦点を当て、そのニーズにダイナミックに対応することです。そのためには、柔軟性と俊敏性を備え、チームがお客様の声をリアルタイムで反映できるような環境を整えるしかありません。それが、優れた製品を生み出す方法なのです。だからこそ、製品ロードマップは過大評価されるのです。
これはロードマップの死なのでしょうか？
そうではないかもしれません。でも、書いてあることを、書いてあるときに全部やらなければならないのでしょうか？そんなことはありません。だから、あまり通らない道を選んで、それがどこにつながるか見てみたらどうでしょう？後悔はしないはずです。
ロードマップは、製品開発と市場投入において常に重要な位置を占めています。計画なしに何かをしようとするのは意味がありません。しかし、ロードマップは流動的で柔軟なものであるべきで、決められたものではないことを忘れてはならない。ロードマップは、実験的な試みを抑制したり、イノベーションを抑制したりするために使用すべきではありません。ロードマップは構造を提供するものですが、チームが協力して顧客のために最高の製品を作り上げることを妨げてはならないのです。
重要なのは、ロードマップを最終目標ではなく、出発点として使うことです。
製品チームは、常に新しいアイデア、フィードバック、顧客の洞察にオープンであるべきで、それは、当初ロードマップで計画されたものとは異なる道を導くかもしれません。また、このことは、製品チームだけでなく、全社的に理解されなければならないことです。Cレベルの幹部は、この反復プロセスが、たとえ当初のロードマップから外れることになっても、顧客にとって素晴らしいものを作る最良の方法であることを理解する必要があります。
結局のところ、ロードマップは製品開発の道具箱の中の1つのツールに過ぎないのです。しかし、アジャイルであり続け、顧客からのフィードバックを受け入れることで、チームは顧客のニーズを満たす優れた製品を作ることができるようになります。
tl;dv ロードマップの束縛からの解放を支援する方法
製品開発を成功させるためには、共同作業、リアルタイムのフィードバック、そして顧客ニーズの重視が不可欠です。ここtl;dv で、私たちのオンラインミーティングソフトウェアは、製品開発で使用されるツールとして完璧です。このソフトウェアは、チームが会話を記録し、共有することで、全員が常に最新の情報を得ることができます。また、オンラインミーティングソフトウェアを使用することで、チーム内の会話を記録し、共有することができます。
さらに、ミーティングを照合して保存することで、意思決定やアイデアに役立つ洞察やデータが豊富に詰まったレポジトリを手に入れることができます。これにより、チームはロードマップの不確実性から解放され、顧客のニーズに沿った製品をリアルタイムで作成することができます。
tl;dv もう、メールの海に迷い込んだり、会話を誤解したりすることはありません。さらに、いつでもどこからでも録音にアクセスでき、中断したところから再開することができます。
tl;dv ロードマップの束縛から解き放たれるお手伝いをさせてください。
