[和訳]プロダクトロードマップを計画する前に Inside Intercom

はじめに

本記事は、Intercom(インターコム)の和訳記事になります。対象の記事はこちら。

記事和訳

すべてのユーザーはすべての機能を使っていますか？もちろんそうではないです。それについて話をしてみましょう。

あなたがロードマップを考える時、そしてチームが時間を消費する中で、よく問われます。「何人が実際にそれぞれの機能を使っていますか？」これがプロダクトマネージメントの基礎で、もしかしてSQLで時間を使うかもしれません。もしくはIntercomで一瞬で。これを簡単にビジュアル化する方法は、２つの軸で全ての機能をプロットする事です。どれくらいの人々がその機能を使っているか、どれくらいの頻度で使っているか。あなたは以下のような傾向を見る可能性が高い。

あなたのコアプロダクトは右上のプロット覆われます。なぜならそれがユーザーがそのプロダクトを使っている理由だからです。※アカウント作成やパスワード設定などのアドミン機能は除く。これらはここでは関係ありません。はじめにプロダクトを手に入れるシンプルなコストだからです。

もし左上に機能があるなら、うまく採用されていないサインか、エンタプライズプランの機能です。エンタプライズ機能の場合はそれは検討されているし、問題ないです。しかしあなたは全てのエンタプライズカスタマーが実際にそれを使っているかどうか評価すべきです。

それについて考える簡単な方法はこうです。それぞれの機能にアダプトしているユーザーは何割なのか？あなたはシンプルな棒グラフで示すことが可能です。以下に示されているのは、夢のようなプロダクトでこれは私たちがPhotoshopを開く時に考えてデザインするものです。みんなは使おうとして、全てを愛そうとします、よね？

全てのプロダクトマネージャーは知っている通り、プロダクトの汚れた現実はほとんどが以下です。

どうやってこれに行き着きますか？あなたはしっかりしたメッセージング、ファイル、文章編集機能を備えたプロダクトを作ります。それらの重要な昨日はサイトにハイライトされて、素晴らしいスクリーンショットと共に明確にドキュメント化され、チュートリアルに組み込まれます。

しかし成功はひどい教師になりうる。あなたは間違っていないことをしましたし、より多くのものを作り上げたと信じます。

なのであなたはチャットルーム機能を追加しましたが、それはうまくいかず開始に失敗してしまったようです。そしてあなたはカレンダー機能を追加しましたが、失敗しました。誰もこれ以上イベントを作成せず、サイト上で言及すらせれません。現在あなたはトラッキング機能を人気機能の一種として作ってますが、それは一部のユーザーのためのものです。これはあなたのプロダクトで、あなたはこれを改善する必要があります。

もしあなたがこれらの機能の種類を考えているなら、一つの特定のワークフローに関して優れたプロダクトを持っていますが、誰も使用していない他の機能に対して全て追加している事がわかります。私はしばしばGoogle+の中のHangoutに関して考えます。例えばこれやMicrosoft Wordの中にある古いドキュメント編集機能に関してです。

これらの場合あなたはその混乱さに対して攻撃されやすいです。誰かが一つの目的に絞った一つの重要な機能にフォーカスした、シンプルなプロダクトを作る事ができ、あなたは苦労するでしょう。

私は機能の検査のために何をするでしょう？

限られた中の許されるいくつかの機能に対してあなたは4つの選択肢を持っています。

・削除する（敗北を受け入れ、その機能をプロダクトから排除する）

・使用率を向上する（より多くの人に使ってもらう）

・使用頻度を上げる

・慎重に改善する（ユーザーにとって定量的に優れたものにする）

ラフにあなたはそれを以下のように表現する事ができます。

なぜ機能が使われないのか理解します

より多くの人に使ってもらうために、使用を妨げる問題を評価して解決します。これは便利な「なぜ」を深堀する手法です。レポート機能が使われないシチュエーションに遭遇するかもしれません。なぜでしょう？ユーザーは価値を感じていないかもしれない。なぜでしょう？ユーザーはボスにそれを示す事ができないかもしれない。なぜでしょう？適切な良いフォーマットになっていないかもしれない。なぜでしょう？私たちのレポート機能は不十分なのかもしれない。なぜでしょう？APIが良いデータを生み出さないかもしれない。もしあなたが何度も「なぜ」を繰り返すならば、あなたは根本原因に行き着く事ができるでしょう。

普段の状況はこれよりもっと複雑なので、一人のユーザーに対して考えるだけではいけません。上の図のような何度も何度もパターンをドリルダウンする図を見つけるでしょう。そして、あなたは、プロダクトの使用を妨げている重要で根本的な問題を解決できるようになるでしょう。

これはFish or cut baitで、その機能を無くすか、より多くの人に使ってもらうか、という事だけです。

使用頻度を上げる

使用頻度の向上は別物です。それは既存のユーザーからより多くのユーセージを獲得する事です。あなたはユーザーがよりその機能を利用できるような改修案を特定する必要があります。

LinkedInの推薦機能は全く良いことをしました。彼らはワンクリックで複数の推奨機能を実現しました。あなたは簡単に突発的に4人の友人が持っていないスキルを推奨する事ができ、結果として新たな4人の人々と繋がります。これはより多くの推奨やログインを実現します。

彼らがフォローしているのは、Nire Eyalによって説明されたパターンです。彼はHookedの著者で、週間は4つの重要な要素をもつ繰り返されるパターンによって形成されています。

トリガー（プロダクトに目が向く理由）

アクション（期待できる報酬のための行動）

リワード（アクションから得る報酬）

インベストメント（今後の可能性を作る）

例として、NirはPinterestのフックに対して、以下を指摘しました。

現実を見ると、Feature Auditは退屈なものです。Lean Feature Analysis Hackとしてリブランディングする事は、それをより今風のものにできるでしょう。Feature Auditはパワフルなツールです。どの開発チームもリソースはありません。アダプションか頻度を上げる繰り返される取り組みは、結果を簡単に計測でき、価値のない行動を避ける事ができます。

より成熟した企業にとって、それは誰も欲していない機能に対する早期の警告されたシステムとして提供され、より焦点を絞った競合に対する対抗策になるでしょう。

さいごに

翻訳は以上になります。翻訳のニュアンスなどは一部異なったところもあるかもしれません。ご指摘ある場合はコメント頂ければ幸いです。