広告なしで10,000社に広がった設計の話
LinearはJiraの直接の競合です。プロジェクト管理ツールの市場で、Jiraは圧倒的なシェアを持つ。それでもLinearは、マーケティングチームを持たずに10,000社以上に使われるようになりました。
理由は一つ。使ったエンジニアが「これ、チームに入れます」と言い続けたからです。
「Opinionated Product（意見のある製品）」——そう呼ばれる設計哲学があります。LinearやFigmaが使った4つのステップは、再現できます。別途公開予定のケーススタディ「Linearが広告ゼロ・マーケチームなしで10,000社に使われるまでの構造」と合わせて読むと理解が深まります。
なぜOpinionated Designが口コミを生むのか
製品に意見を持ち込むとは、「この使い方が正しい」「この機能は不要」「スピードは妥協しない」という判断を設計に焼き付けることです。
Jiraを使ったことのあるエンジニアは多いですが、「Jiraが好き」と公言する人はそれほど多くない。Linearはその不満に「我々もそう思う」と答える製品を作りました。すると何が起きるか。不満を持っていたユーザーが、自分の価値観を代弁してくれる製品を見つけた感覚になります。布教したくなる。
「全員に使ってもらえる製品」を目指すと、機能は増え、選択肢は増え、製品はどんどん無個性になります。口コミは「これしかない」と感じさせる製品から生まれます。
始める前に確認すること
このアプローチには前提条件があります。コアユーザーが既存のプロダクトやワークフローに対して具体的な不満を持っていること。「Jira疲れ」「Slack疲れ」「Excel疲れ」のような、言語化できる不満が出発点です。
チームとしては、機能を削ることへの覚悟が必要です。「この機能を外すとユーザーが離れるかもしれない」というプレッシャーに対して、設計判断を通せるかどうか。ここが一番難しい部分です。
ステップ1: 最大不満を言語化して、逆張りメッセージに転換する
最初にやることは、退会理由と競合乗り換え理由の収集です。Cannyでフィードバックを集めるか、Typeformで退会時にアンケートを送る。「何が嫌だったか」ではなく、「なぜそれが嫌だったか」の構造を掘ることが目的です。
LinearはJiraの「複雑さ」を不満として見つけました。ただし、そのまま「シンプルです」とは言わなかった。「速い。ものすごく速い。それがすべて」というメッセージに転換しました。不満の根にある価値——速さ・集中・クリアさ——を言語化して、製品ポジションに組み込んだわけです。
退会インタビューを5人行うだけでも、繰り返し出てくるキーワードが見えます。その言葉を使って「我々はこれを解決するために存在する」という一文を書いてみてください。それがOpinionated Productの起点です。
ステップ2: 体験品質を数値目標で定義する
「速い」と言うのは簡単ですが、計測しなければ劣化します。LinearはUIの応答時間に厳格な基準を持っていて、PRごとにLighthouseでパフォーマンスを回帰テストしています。感覚ではなく数字で管理することで、「速さ」という価値を維持し続けました。
自分の製品で同じことをするなら、まずWeb VitalsのLCP（最大コンテンツ描画）とINP（次のペイントまでの待機時間）を計測します。Lighthouse CIをGitHub ActionsのCIに組み込んで、コードを変更するたびに自動でスコアを確認する仕組みを作る。
数値目標の具体例はLCP 2.5秒以下、INP 200ms以下、Lighthouse Performanceスコア90以上です。これを下回るPRはマージしない、というルールを作るだけで品質は維持されます。設定自体は1〜2日で終わります。その後は自動で回り続けます。
ステップ3: 選択肢を削って「意見」を持ち込む
「追加するか、削除するか」の判断基準をNotionなどに文書化します。Figmaが参考になります。Figmaは「ブラウザで動くデザインツール」というポジションを選んだとき、ローカルインストール版を作らないと決めました。当時は批判もありましたが、その判断がチームコラボレーションという強みを生んだ。
判断ルール文書に含めるべきは三点です。製品が解決しようとしている最大の不満は何か。その不満を解決しない機能はスコープ外にする。コアユーザーが「これはいらない」と言ったら削除を検討する。
Superhumanはメールの「雑音」を消すために、メール以外の機能を一切入れませんでした。Raycastはランチャーの速さのために、UIをキーボード操作に特化させた。共通しているのは「何をしないか」を決めていることです。週に一度、製品に入っている機能リストを見て「これは本当にコアユーザーに必要か」と問い直す習慣を作るだけで、判断の質が変わります。
ステップ4: 「転換体験」を設計してシェアされる瞬間を作る
転換体験とは、ユーザーが「これが正解だった」と感じる最初の瞬間のことです。LinearならIssue作成からCloseまでを30秒でできる体験。この体験を初回セッションで必ず味わわせることが、口コミの出発点になります。
Mixpanelでシェアイベントと紹介起点のサインアップを追跡します。「どのユーザーが他の人を呼んでいるか」と「呼んだユーザーが最初に何をしたか」を見ると、転換体験がどこにあるかが分かります。
設計の手順は三段階です。まず転換体験の候補を3つ特定する（「初めてこの機能を使ったとき」「チームで初めて共同作業したとき」など）。次にMixpanelでそのイベントとその後の紹介行動を計測する。最後に、転換体験までのステップ数を減らすようにオンボーディングを改修する。2週間のスプリントで一サイクル回せます。
ツールをどう選ぶか
メインで使えるスタックはCanny（フィードバック収集）＋Mixpanel（行動計測）＋Lighthouse CI（パフォーマンス管理）の3つです。このセットで4つのステップすべてをカバーできます。
代替として、フィードバック収集にTypeform、行動計測にAmplitude、フロント計測にVercel Analyticsを使う構成もあります。どちらのスタックも月2〜3万円程度で始められます。
まだ製品が小さい段階なら、ツールは後回しでいいです。Googleフォームで退会時アンケートを送り、5人にユーザーインタビューをする。ツールは計測すべきことが明確になってから導入する方が無駄がありません。
向いている製品・チーム、向いていない製品・チーム
このアプローチが機能するのは、コアユーザーが既存の何かに強い不満を持っている場合です。「Jira疲れ」「Gmail疲れ」のような言語化できる不満があること。そしてチームとして、機能を削ることを価値として信じられること。
逆に、「すべてのチームに使ってもらいたい」「業界シェアを取りたい」という目標の製品には合いません。Opinionated Designは意図的に対象を絞ります。全員に刺さらなくていい、10人に強く刺さればいいという割り切りが前提です。機能追加で競合との差別化を図ろうとしているチームも難しい。そのモードだと選択肢を削る決断ができないからです。
まず10人に「これしかない」と言わせる
Opinionated Productは、全員に好かれようとしないことから始まります。「この人たちの、この不満だけを解決する」と決める。そこまで絞れると、メッセージが鋭くなり、製品の判断基準が明確になり、転換体験が設計できるようになります。
まず10人に「これしかない」と言わせる。その10人が100人を呼ぶ。Linear・Figma・Superhuman・Raycastがたどった道は、規模こそ違いますが、同じ設計原則の上にあります。退会インタビューの5人から始めてみてください。
AI編集部コメント
製品に意見を持ち込むというのは、聞こえはシンプルですが、実際には「何をしないか」を決め続けることです。そこが難しいし、そこが差になる。
リサーチを通じて気づいたのは、LinearもFigmaもSuperhumanも、「競合の名前を出してポジションを取る」という手法を使っているということ。「Jira疲れ」「Photoshop疲れ」——その疲れに共感することが口コミの最初のトリガーになっています。不満の言語化は、メッセージだけでなく製品判断の基準にもなります。
退会インタビューを5人やるだけで見えてくるものが変わります。ツールより先に、その5人から始めてみてください。