フィードバックから収益へ

多くのプロダクトチームは、フィードバックを一つのツールで捉え、ロードマップを別のツールで管理し、収益を三つ目のツールで追跡している。これらのシステムが決してつながらない場合、あらゆる経営陣が問う質問——作ったとしたらどの要望が実際にビジネスを動かしたのか——に信頼できる形で答える方法はない。ZendeskのチケットとStripeの拡大イベントの間のギャップは、タグ付け、エクスポート、突き合わせといった実際の作業であり、通常はまったく行われない。

フィードバックから収益へとは、そのギャップを意図的に閉じるという規律である。これを実践するチームは、要望の具体的なクラスター、その修正がリリースされたスプリント、そしてその後に拡大したかチャーンが減ったアカウントのコホートを指し示すことができる。追跡がなければ優先順位付けは意見にすぎない。あればそれは根拠になる。

最小限のループには4つのステップがある——キャプチャ（すべてのチャネルからのフィードバックを一箇所に集める）、リンク（各要望をその背後にあるアカウントと収益に結びつける）、優先順位付け（投票数だけでなくビジネスへの影響でロードマップを重み付けする）、そしてクローズ（デリバリーを記録し、その後の収益変化を測定する）。各ステップ自体は単純だが、難しいのは顧客データ、プロダクト作業データ、収益データがリアルタイムで結合可能である必要があることだ。

顧客の記録、収益、フィードバック、PMボードを単一の共有データ基盤上に保持するプロダクトオペレーティングシステムは、このループを自動的に実行できる。例えばAIOProductOSは、StripeやIntercomといったソースからのコネクタデータを、PMボードとそのInsightsフィードに結びつけているため、フィードバックの項目はその背後にある有料アカウントを表面化させ、手作業での再入力なしに優先順位付けへと流れ込むことができる。その結果、収益加重はトリアージの時点で発生し、四半期ごとの表計算作業の中で発生することはなくなる。

収益を重み付けせずに投票だけを数えることが、最も一般的な誤りである。50人のフリーミアムユーザーからの要望が、10倍のARRを持つ単一のエンタープライズアカウントからの要望を上回ってしまうことがある。フィードバックから収益へは、要望を出した人数だけでなく、誰が要望を出しているのかを知ることを要求する。

二つ目の失敗パターンは、リリース後にループを閉じないことだ。リリース後にチャーンが下がったか拡大が増えたかを測定し直しに戻らないチームは、自分たちの優先順位付けのロジックが正しかったかどうかを学べない。この信号がなければ、今後のあらゆる優先順位付けの判断は、同じ検証されていない前提の上に立ち続けることになる。