プロダクトを作るとき、どの機能を作り、どの機能を手放すかの線引きが難しいことがあります。この線引きがうまくいかないと、「フィーチャー・ブロート（Feature Bloat）」という、プロダクトが遭遇する最も恐ろしい用語に行き着くことになります。
フィーチャークリープ、フィーチャーファイト、フィーチャーオーバーロードとも呼ばれるように、機能が多すぎることは、すべてのチームが気をつけなければならないことです。顧客離れ、複雑すぎるプロダクト、そして予期せぬ技術的負債につながる可能性があります。
このような罠を回避し、目的を持って機能を構築する方法について、以下にいくつかのヒントをまとめました。
ポイント
- 問題を解決しようとするときは、常に「何を」「なぜ」と問うこと。
- チームが機会を特定するのに役立つプロダクト問題テンプレートを使用する。
- フィードバックを重視し、リクエストを実行に移さないことで、偏りを避ける。
- 目的を念頭に置き、ロードマップの優先順位を決める。
- 光り物よりもユーザビリティを優先する。
▼本記事の内容
- 機能の「何を」「なぜ」作るか
- プロダクト問題テンプレート
- 検証をやめ、無効化を始める
- フィードバック vs リクエスト
- すでに知っていることを検証しない
- ロードマップの優先順位をつける
- ユーザビリティを優先する
この記事は「How To Avoid Feature Bloat」を翻訳したものです。
著者: Andrea Saez
翻訳者: 渡辺圭祐
機能の「何を」「なぜ」作るか
次に何に注力すべきかを考えるとき、プロダクトマネージャーは常に2つの重要な質問をする必要があります。
- 私たちが解決しようとしているのは、どんな問題なのか？
- なぜ、それを解決しようとするのか？
これにより、チームはアウトプットや解決策ではなく、プロダクト戦略に集中することができます。言い換えれば、最終結果ではなく、目的にフォーカスを置くということです。
これにより、チームは適切な発見を行い、仮説を立て、実験を行い、アイデアを進める価値が実際にあるかどうかを理解することができるようになるのです。
プロダクト問題テンプレート
手始めとして、プロダクト問題のテンプレートを使用することから始めるとよいでしょう。このテンプレートは、チームの誰もが新しいアイデアを提案するときに使うことができます。
- どのような問題を解決しようとしているのか？
- 仮説
- ユーザーにとってどんな価値があるのか？
- 私たちの会社にどんな価値をもたらすか？
では、実際に誰かが送ってきそうなアイデアを例にとって考えてみましょう。
顧客のための社内コミュニティを作ろう。
なぜ、これが問題提起ではなく、解決策なのかわかりますか？
上の提案は、「××をしよう」という一点だけに焦点を当てています。理由を説明しておらず、単に何かをするための生の発言です。
代わりに、チームにテンプレートに記入してもらうことができます。上の例をとると、次のようなものになるでしょう。
- どのような問題を解決しようとしているのか？
私たちは、顧客とより密接に関わり合いたいと考えています。
- 仮説
もし、ユーザーとのより良い関わり方を見つけることができれば、彼らの知識を活用し、より多くの質問をし、より多くの実験を行い、より良い関係を築くことができるようになるはずです。これがあれば、解約を減らし、初期ユーザーを適用させることができるのです！
- ユーザーにとってどんな価値があるのか？
当社とのコミュニケーションと透明性が高まります。
- 私たちの会社にどんな価値をもたらすか？
より多くの顧客と話し、発見し、彼らの問題を理解することができる。
上記のようなシンプルなテンプレートがあれば、チーム全体が成果や解決すべき問題について考えるようになります。「Xをやろう」という会話から、「この問題を解決するにはどうしたらいいか」という会話に変わり、組織全体でプロダクトシンキングを確立することができるのです。
この時点で初めて、オーディエンス（コミュニティもその一つかもしれません）を巻き込む方法に焦点を当て、最終的な解決策のためにあらゆる可能性を模索することができるのです。
検証をやめ、無効化を始める
機能追加を評価する際、プロダクトマネージャーはしばしば顧客の声を参考にします。
しかし、多くのチームが2つの重大な間違いを犯しているのを私はまだ見ています。
- 「要件」と「新機能のリクエスト」を集めようとする。
- すでに知っていることを検証しようとする
これこそが、多くのプロダクトチームが不要な機能のループに陥っている原因です。
ここでは、その対策について説明します。
フィードバック vs リクエスト
プロダクトマネジメントとは、フィードバックを受けることであり、リクエストを受けることではありません（もちろん、代理店で働いている場合は別ですが）。
その会話を変え、「機能リクエスト」という言葉を捨てましょう。
代わりに、これらの機能リクエストを「顧客フィードバック」と呼ぶようにしましょう。
これは、リクエストに基づいて新しい機能を構築するのではなく、お客様のフィードバックに基づいて機能追加を慎重に検討することを意味します。これにより、質問をして問題を理解し、顧客とプロダクトに利益をもたらす解決策を実行することも可能になります。
覚えておいてほしいのは、顧客は自分の現在の経験に基づいて機能追加を依頼する傾向があるということです。彼らは問題があることを知っていますが、最善の解決策は何かを定義するのはあなた次第なのです。
すでに知っていることを検証しない
フィードバックを分析し、すでに知っていることに基づいて質問をすると、自分自身を牽制することになり、まったく何も学べません。
そうではなく、今までとは違うアプローチで、自分が知っていることを無効にするような質問を始めてみてください。そうすることで、プロダクト機能を追加することを避けることができるかもしれません。悪い機能は、偏見や狭い視野から生まれることが多いのです。
適切な顧客調査によってこのサイクルを断ち切り、現在の仮説がいかに間違っているかを理解することができます。
ロードマップの優先順位をつける
明確なロードマップを持って、ファネルの一番上の意思決定プロセスから始めることで、作る必要があると思われるものの半分に優先順位をつけることができます。
ロードマップの作成には、遅延によるコストの分析、マーケットリサーチ、競合他社の分析など、多くのことが必要ですが、シンプルで堅実なスタート地点は、明確な目標を設定することです。
この目標を設定することで、組織全体が集中力を維持し、実際にプロセスの早い段階で機能の肥大化を避けることができます。
つまり、もしあなたが作ろうと思っているものが、現在その目的に合っていなければ、すぐに選択肢として捨てることができるのです。
ユーザビリティを優先する
新しいプロダクトをデザインする場合、機能を増やしたからといって、ユーザーが幸せになるとは限りません。
顧客にとっての使いやすさを優先することで、ソリューションの複雑さをある程度取り除いてください。
言い換えれば、あなたは、世界中のすべてのベルとホイッスルと魔法のユニコーンをデザインすることができますが、それはあなたがそれを構築する必要があることを意味するものではありません。
実際に役立つものを最も現実的で本質的な形で作り、顧客に提示し、次のイテレーションで再評価を行います。
これを「構築、測定、学習」のループと呼びます。
構築、測定、学習のループ
- あなたのユニコーンの最小限の愛すべきバージョンを構築する。
- 作ったものの成功を測定する。
- その経験から学習する。
そして、必要であれば、その上にさらに構築することができます。多くの場合、人々が欲しがっていると考えていた光り輝くものの半分が、そもそも必要でなかったことがわかります。
おめでとうございます！あなたのチームは機能の肥大化を避けることができました。
– – – – –
原文はUserpilot Blogに掲載されています。
フォローして最新記事をチェック！
共有:
PM Library 