本当に作るべき機能リクエスト（そしてその見分け方）

あなたは、悪い機能リクエストに「ノー」と言う方法を知っています。スコープの肥大化と中核機能を見分けられるようになりました。あなたは製品の境界線を守っています。

でも今、あなたは別の窮地にいます。テストをすべて通過するリクエストが12個あるのです。どれも自分のアプリ向け。どれも妥当。どれもユーザーが実際にほしがっているもの。でも、作れるのは3つだけ。

どの3つか？

ここで、ほとんどの製品判断が間違った方向へ進みます。起業家は、いちばん見栄えがよく聞こえるもの、いちばん儲かりそうなもの、あるいはいちばん重要な顧客から来たものを選びます。正しいこともあります。たいていは間違っています。

重要なシグナル

シグナル1：頼んでいないのに繰り返される

3人の別々のユーザーが、互いに話していないのに同じものを求めたら、それはシグナルです。彼らは示し合わせていません。みんなが、ただそれぞれに思いついたのです。5人が求めたら、それは偶然ではありません — 本物のニーズです。

逆もまた重要です。一人のユーザーが求め、他に誰も求めていないのにそれを作れば、あなたは今や、他の誰も使わない機能を抱え込んだことになります。しかもそのユーザーですら満足しないかもしれません（少しずれた形で作ってしまったから）。

作る前にリクエストを数えましょう。いちばん声の大きい顧客や最大のクライアントからのものではなく — 頼んでいないのに繰り返されるものを数えるのです。独立した2、3人のユーザーが同じものを求めることは、一人の重要な顧客が5つのものを求めることよりも、はるかに強いシグナルです。

シグナル2：回避策が物語る

ユーザーがいて、しかも残ってくれているのに、その機能が欠けているなら、彼らは回避策を見つけています。アプリの外でやっているのかもしれません。手作業でやっているのかもしれません。並行して別のツールを使っているのかもしれません。

でも彼らは残っている。つまり、アプリを使うためにその機能は必要ないということです。彼らがそれを必要とするのは、アプリをもっとうまく使うため。それは「使えなくする障害」とは違います。

最も重要な機能は、人々がアプリをそもそも使えなくしているものです。あったらいい機能は、人々が回避しているものです。

どのリクエストが障害なのかに注意を払いましょう。誰かが「これができるまで使えない」と言うのと、誰かが「Xがあったらいいな」と言うのとでは違います。その区別は金です。

シグナル3：その機能がビジネスモデルとセットになる

機能の中には、まったく新しい稼ぎ方を解き放つものがあります。「顧客に請求書を送る」は、請求機能に課金するビジネスモデルを解き放ちます。「Salesforce へエクスポート」は、連携収益を解き放ちます。「リセラー向けのホワイトラベル」は、パートナーチャネルを解き放ちます。

でも、ここにコツがあります。そうしたモデルが機能するかどうかは、すでに出荷し始めてみるまで分かりません。それらを軸に計画を立てることはできません。出荷したあとに、人々が実際に使うかどうかを見て、ようやく気づけるだけです。

最も成功する機能追加は、その機能を出荷することで、存在を知らなかった市場が明らかになるものです。あなたはエクスポート機能を作った。すると、企業がそのエクスポートを自社のワークフローに組み込みたがると分かった。今や、計画していなかった連携のストーリーが手に入ったのです。

機能はユーザーが必要としているから作りましょう。それから、ユーザーが新しいビジネスを生むような形でそれを必要としていないか見守るのです。先にビジネスモデルを予測しないこと。

シグナル4：手伝いの申し出

ユーザーが何かを作ってほしいと頼んだら、それはリクエストです。ユーザーが何かを作れるかどうかを尋ね、テストを手伝うと申し出たら、それは違います。

テストを手伝うと申し出る人は、その結果に投資している人です。彼らは機能を丁寧に使います。バグを報告します。それが本当に自分の問題を解決するかどうかを教えてくれます。

ただ頼むだけの人は、頭の中で想像しているものを、あなたが魔法のように作ってくれることを願っている人です。作れることもあります。作れないことの方が多いです。

まずはテスターと一緒に作りましょう。それ以外はすべて二の次です。

「箔がつく機能」を作りたい誘惑

どの製品にも、出荷すればより見栄えよく聞こえる機能が一つあります。スケジューリングアプリなら Calendly との連携。タスクアプリなら Slack との連携。誰もがそれが何かを知っています。誰もがそれをほしがります。

でも、ここがポイントです。誰もが、それを他の誰かからも手に入れているのです。あなたの機能が、最高で最も簡単な Slack 連携でないなら、あなたを有名にすることなく、ただアプリに複雑さを足すだけになります。

あなたを有名にする機能は、特定のユーザーの問題を誰よりも深く理解しているからこそ、あなただけが作れる立場にあるものです。それは「箔がつく機能」ではありません。本物の人々の本物の問題を解決する、地味な機能です。

Slack 連携は見栄えがします。ユーザーが特定の一つのことを、Slack が考えたよりもずっと速くできるようにするツールは、価値があります。

では、実際にどう決めるか

「これはスコープ内か？」のテストをすべて通過した機能リクエストの束を抱えたら、次の基準でランク付けしてください。

何人のユーザーが（独立して）求めたか？ 多いほどよい。
これは障害か、あったらいいものか？ 障害ほど緊急。
ユーザーは今これを回避できるか？ できないなら、より重要。
誰かがテストを手伝ってくれるか？ くれるなら、まず作る。
これは新しい市場を明らかにするか？ たぶん、なら、それはおまけであって理由ではない。

そして、その順番で作りましょう。見栄えよく聞こえる順ではなく。最大の顧客の順でもなく。アプリを使っている人々からの、本物のシグナルの順です。

（まだ）作らない機能

選から漏れるリクエストも出てきます。「いつか作る」と取り繕わないこと。ユーザーにこう伝えましょう。「今はそれを作りません。理由はこうです。代わりに作ろうとしているのはこれです。あなたに合うかもしれない代替案はこちらです。」

その正直さは、あなたが思う以上に重要です。ユーザーは、6か月待ち望むよりも、あなたがそれをやらないと知る方を選びます。

そして時には、あなたが「ノー」と言ったあとで、ユーザーが回避策を見つけたり、別のツールを使ったり、別のやり方で問題を解決したりします。それでいいのです。すべての人にとってのすべてになることはできません。

勝つ製品は、自分の仕事をうまくこなし、ユーザーが本当に必要としているものに注意深く耳を傾けるものです。すべてになろうとして結局何者でもなくなる製品ではありません。