Minimum Worthy Product

ResumeGeniの公開面を再構築する中で、同じ不愉快な境界線に何度もぶつかっています。技術的には動作するバージョンが、必ずしも求職者の前に出すバージョンとは限らないのです。パーサーは動きます。出力は読み込まれます。フローは完了します。それでも、その体験のどこかが信頼を勝ち取るのではなく、信頼を消費しているのです。1時間向き合い、その面を作り直すと、その感覚は消えます。しかし時計は止まりません。

この緊張こそが本エッセイの核心です。2つの力が互いに引っ張り合っています。製品を世に出すために十分早く出荷することと、ユーザーの信頼を消費する製品を出荷することを拒否することです。ほとんどのビルダーは、どちらか一方を選んで擁護することで、この緊張を解消します。MVP文化はスピードを選びます。完璧主義は磨き上げを選びます。どちらの答えも失敗に終わります。なぜなら、この緊張こそが本質だからです。

Minimum Worthy Productは異なる基準です。機能的と弁護できる最小限の製品ではなく、信頼を勝ち取る最小限の製品を出荷するのです。 Worthyは最低ラインであり、上限ではありません。Minimumはスコープの制約であり、品質の割引ではありません。MWPのビルダーは、製品が出荷できるようになるまで機能を削り、残ったすべての面をユーザーが感じ取れる基準にまで引き上げます。MVPのビルダーはあまりにも多くの場合、その逆をします。つまり、スコープを守るために品質を削るのです。この置き換えこそが、データにユーザーが感じていることです。

TL;DR

MVPは本来、学習のためのツールでした。実際のユーザーで実際の仮説を検証する最小限のアーティファクトです。その劣化したバージョンが、弱い仕事を出荷するための許可証となってしまいました。Minimum Worthy Productは、失われた制約を復活させるものです。安価に検証し、それから信頼を勝ち取る最小限の製品を構築します。Minimumはスコープを削ります。Worthyは残った面をユーザーが感じ取れる基準まで引き上げます。

---

MVPが正しく捉えていたこと

元々のMVPのアイデアは、弱い仕事を出荷する許可を与えるものではありませんでした。それは、創業者が間違ったものを何ヶ月もかけて作ることをやめるための方法を与えたのです。¹

Eric Riesが『The Lean Startup』を書いたのは、特定の失敗パターンに対処するためでした。つまり、存在しない市場向けに手の込んだ製品を作るエンジニアたちに対してです。MVPは学習のための道具でした。特定の仮説を実際のユーザーでテストできる最小限のアーティファクトを構築し、実験を実行し、何が起きたかを測定し、その仮説が現実との接触を生き延びるかどうかについての理解を更新するのです。MVPにおける「minimum」が意味したのは、学習のためのスコープ崩壊であり、出荷のための品質崩壊ではありませんでした。

元々のフレーミングは今でも有効です。私も使っています。私のスタートアップ検証シーケンス（問題、解決策、チャネル、収益、スケール）はRiesの下流にあります。コードに投資する前に安価に検証できる仮説をテストする根拠は、検証の下流でMWPを適用する根拠と同じです。各段階の道具は、その段階に適合すべきなのです。ランディングページとインタビューは望ましさを検証するMVPです。プロトタイプとスパイクは実現可能性を検証するMVPです。MWPは、検証の証拠がすでに手元にあり、実際のユーザーが信頼する最初の本物を構築するときに適用する基準です。

ですから、私はMVPそのものに反対しているのではありません。MVPが実践の中で変わってしまったものに反対しているのです。

MVP文化が軟弱になったところ

どこかの時点で、「fast learn」が「ship whatever」となり、この置き換えは実害をもたらしました。

3つの翻訳が元のアイデアを壊してしまいました。

1. 「If you’re not embarrassed by the first version of your product, you’ve launched too late」（Reid Hoffmanの言葉⁴）は、スコープではなくクラフトを恥じるための許可証になってしまいました。元の主張は機能数についてのものです。つまり、将来の自分が製品の機能の少なさを恥じるほど、少ない機能で出荷せよということです。劣化したバージョンは職人技についてです。つまり、将来の自分が製品の見た目や感触を恥じるほど、粗く出荷せよということです。両者は同じ文ではありません。

2. 「Ship fast」が、測定可能な成果として「Learn fast」に取って代わりました。学習は遅く、煩わしく、質的な洞察を生み出すプロセスです。出荷は速く、わかりやすく、日付の付いたアーティファクトを生み出すプロセスです。両者を区別できないとき、アーティファクトがデフォルトで勝ちます。チームは毎週出荷し、学習を完全にやめてしまいます。なぜなら、誰もチームが何を学んだかを測定しないからです。

3. ベンチャーパターン（資金調達、成長、イグジット）は、正しく出荷することよりも、何かを出荷することを報奨します。あなたの仕事が次の小切手に勢いを示すことであれば、薄めた製品でも少なくとも「出荷した」というバーをクリアします。遅れて出荷された価値ある製品は、外から見ると停滞しているチームと同じに見えます。インセンティブの勾配は下向きを指しています。

これらの劣化はどれも、元々書かれたMVPの責任ではありません。これらは、弱いものを出荷する弁護を必要とする人々の口でMVPが変わってしまった姿です。

ユーザーはその結果を感じます。データの中でそれを感じるでしょう。オンボーディングは完了しますが、2回目のセッションは起こりません。ユーザーはサインアップのメールを開きますが、リンクをクリックすることはありません。サポートチケットは、製品が処理すると謳っているタスクの周りに集中します。チャーン曲線はゼロに向かって減衰し、コアに平坦化することはありません。これらの結果はエッジケースではありません。ユーザーが信じることができない基準で構築することの中心的なコストなのです。

Minimumは未完成を意味しない

Minimumはスコープの制約であり、品質の割引ではありません。

運用上は、ユーザーを定義し、製品が提供すると謳っている1つの成果を定義します。その成果に必要でないすべての機能を取り除きます。そして、残った面を完全な品質バーまで引き上げます。Minimumは、製品が出荷できるようになるまでスコープを削ります。Minimumは、製品がより早く出荷できるように基準を削ることではありません。

具体例で考えてみましょう。ResumeGeniの約束は、ATS対応の履歴書であり、求職者に応募者追跡システムを通過する実際のチャンスを与えるものです。この約束の最小バージョンでは、以下を除外できます。

• カスタムテンプレート
• チームコラボレーション
• アナリティクスダッシュボード
• LinkedIn、Indeed、求人ボードとの統合
• バージョン履歴
• 1つ以外のエクスポート形式

最小バージョンが除外できないものは、ソース履歴書の正確なパース、ギャップの誠実な評価、求人票に実際に合う具体的な書き直し、Wordでクリーンに開けるエクスポート、そして求職者が安心できるフローです。テンプレートなしで出荷することはできます。曖昧なアドバイス、壊れたエクスポート、脆弱なユーザーを製品が騙しているように感じさせるコピーで出荷することはできません。

Minimumは製品のバックログに当てられたナイフです。Worthyは残った面に当てられたナイフです。

Worthyは最低ライン

価値ある製品は、あなたが想像するすべてを含む必要はありません。含まれているすべてのものが、ユーザーを尊重していなければなりません。

運用上の意味でのWorthyとは、製品が検証された問題を十分に解決しており、ユーザーが次の相互作用に信頼を持ち込むことを意味します。あなたが何を作っていたかをユーザーは見て、もっと来るものがあると信じるのです。最初のセッションは耐えるべき試練ではなくなり、2回目への扉を開く握手になります。価値ある製品は信頼を蓄積します。半端に価値ある製品は信頼を消費します。

信頼を偽ることはできません。ユーザーは、すでに知っている製品によって形成された期待を持って到着します。⁵あなたの製品がその期待を下回ると（反応しないボタン、曖昧にするコピー、途中でユーザーを見捨てるフロー）、ユーザーはそのギャップを言語化する前に認識します。彼らは去り、戻ってこず、すでに諦めたセッションをリテンションメールが救うことはありません。

これは価値があるか？という問いは、趣味の問題ではありません。これは信頼の問題です。ユーザーの答えは行動として現れます。

検証が先、価値はその次

MWPに対する最も強い反論は、ユーザーが接触を通じて価値を決定するのであり、作り手の信念で決めるのではないというものです。その通りです。MWPはユーザーの判断を置き換えるものではありません。MWPは、最初の実ユーザーが判断する前に、検証された信頼を焼き尽くすことを防ぐものです。

ユーザー接触は検証に属します。構築する前に、問題が実在するか、提案した解決策がそれに対処するか、ユーザーに到達できるか、そしてお金を払ってくれるかをテストします。証拠はランディングページ、インタビュー、コンシェルジュテスト、プロトタイプ、ウェイトリストから得られます。このシーケンスについては詳しく書きました。この関門を生き延びた仮説は、構築される権利を獲得したのです。

MWPは検証の後に始まります。検証は、誰かがその約束を望むかどうかを問います。MWPは、出荷された面が、検証がすでに獲得した信頼に値するかどうかを問います。リテンション、紹介、品質摩擦のデータが、その判断が持ちこたえるかどうかを決定します。

検証を飛ばして結果をMWPと呼ぶと、誰も尋ねていない質問への美しい答えが生まれます。MWPを飛ばして結果をleanと呼ぶと、検証がすでに獲得した信頼のコストを伴う薄められた製品が生まれます。

正しいシーケンスは、実際のユーザーで安価に検証し、それから検証された約束のために最小限の価値ある製品を構築することです。両方を行ってください。どちらも飛ばしてはいけません。

2つのテスト：JiroとSteve

製品は、完了と呼ぶ前に2つの異なるテストに合格しなければなりません。

Jiro Testは、仕事が正しいかどうかを問います。製品が動作する証拠。エッジケースの処理。目に見えない細部の仕上げ。主張は具体的な証拠を引用します。曖昧にしない。I believeは証拠ではありません。Jiro Testはクラフトと願望を区別します。私はJiroの品質哲学について書きました。これはAIエージェントに適用される規律ですが、同じ規律がすべての製品面に適用されます。Evidence Gateは、コードレポートでこのテストを運用化する方法です。

Steve Testは、仕事が存在するに値するかどうかを問います。視点が見える。全体としての一貫性。ユーザーの尊厳が保たれる。手を振って誤魔化すのではなく、読み手が特定できる喜びや明快さのメカニズム。Steve Testは製品と在庫を区別します。出荷されたものが自動的に価値あるものになるわけではありません。技術的システムとしての味の完全な議論は別のエッセイにあります。この投稿では、上記の運用上の定義が重みを担います。

両方のテストに合格しなければなりません。Jiroが失敗したら止めて修正します。Steveが失敗したら作り直します。両方とも失敗したら、問題はブリーフの上流にあります。

判断が不確かなときに効く質問は、スタックの中で最もシンプルなものです。ひるむことなくこれに自分の名前を署名できるか？ 答えがノーなら、その仕事はまだ価値がないのです。

足元にある証拠：blakecrosley.com

あなたが今読んでいるこのページは、私の道なき道の移行における小さな実験として始まりました。それはまた、この議論の一部でもあります。

Reactはありません。Tailwindはありません。webpack、Vite、バンドラー、ビルドステップもありません。サイト全体はFastAPI、HTMX、Alpine.js、Jinja2、そして普通のCSSで動作し、直接提供されます。現在のビルドでは、初回描画は45～60KBに収まり、Lighthouseはパフォーマンス、アクセシビリティ、ベストプラクティス、SEOのすべてで100点満点中100点を報告しています。³ このサイトは9つの言語で動作し、新しいガイドとブログのコンテンツを単一のgit pushでエンドツーエンドに出荷し、リポジトリのどこにもゼロのnode_modules/を抱えています。

このサイトのMVPバージョンは、2026年のデフォルトのアドバイスに従っていたでしょう。Next.js、Tailwind、Vercelです。それは週末に出荷されていたでしょう。それは問題なかったでしょう。あなたはここに到着し、ページは妥当な時間で読み込まれたでしょう。違いは能力ではなかったでしょう。違いは味だったでしょう。私はLighthouseの完璧なスコアが実際にどのように構築されるかについて書きました。短く言えば、読み手がダウンロードしないペイロードの1KB1KBが、敬意の一形態なのです。

MWPバージョンはもっと時間がかかりました。MWPバージョンでは、HTMXパターンをゼロから書き、タイポグラフィを手作業で調整し、フォントをセルフホストし、Cloudflare D1経由でi18nパイプラインを実行し、ビルドツールの不在を機能として扱う必要がありました。MWPバージョンは、デフォルトのスタックより技術的に優れているわけではありません。MWPバージョンはより意図的なのです。その意図は、読み手が気付く継ぎ目が少ないという形で現れます。

目に見えないクラフト。読み手は決定を見ません。読み手は摩擦の不在を感じるのです。摩擦の不在がそのメカニズムです。

顧客向けの証拠：ResumeGeni

ResumeGeniはバーをさらに上げます。なぜなら、ユーザーはブラウジングしているのではないからです。ユーザーは、面接を得られるかどうかを決めるかもしれない文書を改善しようとしているのです。

ResumeGeniの検証はクリーンに戻ってきました。ランディングページ、ウェイトリスト、RedditとLinkedInでの標的投稿、2週間で340件のメール登録、そしていつ製品がオープンするかを尋ねる12件の返信。⁷ 検証シーケンスは構築せよと言いました。構築は簡単な判断でした。構築がどのように見えるかこそが難しい判断であり、MWPが実際の仕事をする場所でした。

カットには2つのカテゴリーがありました。最初のカテゴリーは機能でした。テンプレート、コラボレーション、アナリティクス、数十のエクスポートバリアント、求人ボード統合。すべてカット。どれも約束の一部ではありません。

2つ目のカテゴリーは、残ったものに対して私が維持するつもりの基準でした。基準はカットされません。パーサーが弱くてはいけません。アドバイスが曖昧ではいけません。エクスポートが壊れていてはいけません。コピーが脆弱なユーザーをコンバージョン指標として扱ってはいけません。ハッピーパスだけが私に時間があったものだという理由で、フローが誰かをプロセスの途中で見捨ててはいけません。

MVPバージョンでは、10ステップのウィザード、一般的な出力、最高のタイミングでのサブスク壁、そしてカットされたすべてを約束するロードマップページが出荷されていたでしょう。それは機能的だったでしょう。一度は一部のユーザーをコンバートしたかもしれません。それはまた、最初のコホートに製品を信頼しないことを教えていたでしょうし、この教訓は脆弱なユースケースにとって悪い基盤となります。

MWPバージョンは、私が望むよりも小さなものです。私がカットしたすべての機能を、私は取り戻したくなるでしょう。バーは、ユーザーが到着する製品が彼らを尊重することです。基盤は、私が構築する方法を知っている唯一のものです。

ユーザーが実際に教えてくれること

ユーザーはI believe in this product nowと言うことはほとんどありません。しかし彼らの行動は痕跡を残します。⁶

私が監視する5つのシグナル、ビルダー層向けに較正されたもの。

1. セカンド成功率。 アクティブ化したユーザーのうち、自然な使用ウィンドウ内で戻ってきてコアな成果を2回目に完了する割合。信頼は最初の成功ではなく、2回目の成功で構築されます。繰り返し使用する製品では、セカンド成功率が30%未満であれば再構築シグナルとして扱います。エピソード的な製品では、30日ウィンドウを強制するのではなく、次の自然な使用サイクルを測定します。

2. 1日目のアクティブ化に対する30日目のリテンション。 再エンゲージメントメールは生のリテンションを偽装できます。比率は偽装できません。週次または月次で使用される製品の場合、この比率がアクティブ化が信頼だったのか、一度きりの好奇心だったのかを教えてくれます。私は0.25未満を警告として、0.15未満を判定として使います。

3. コホートリテンション曲線の形状。 価値ある製品は、初期の落ち込み後に平坦化します。弱い製品は減衰し続けます。曲線をプロットしてください。形状は平均が隠している物語を語ります。曲線が決して平坦にならない場合、製品を実際に信頼するユーザーのコアは存在しません。

4. インセンティブなしの自然紹介シェア。 有料チャネルや紹介プログラムのわいろではなく、直接紹介、共有された出力、口コミを通じて到着する新しくアクティブ化されたユーザーの割合。価値ある製品は話題になります。弱い製品は忘れられます。そのカテゴリーに自然な共有の瞬間があり、それでも自然紹介が新規ユーザー獲得の10%未満であれば、その製品は推薦を獲得していません。

5. 品質摩擦率。 返金、ラージクリック、サポートチケット、失敗したエクスポート、アクティブ化されたユーザー100人あたりの手動修正、コホートごとに追跡されます。この率は、製品が仕えると主張するユーザーに製品が与える痛みです。製品が成熟するにつれて、この率は下がっていくべきです。この率が横ばいまたは上昇しているなら、問題はサポートプロセスではなく製品にあります。

これらのシグナルのどれも虚栄の指標ではありません。それぞれが偽装するのが難しいものです。それぞれが、信頼を獲得したか、獲得できなかったかの実際のユーザー体験を追跡します。5つすべてで特定のコホートの数字を名指せないなら、あなたはまだ自分の製品が価値あるものかどうか知らないのです。

MVPやプロトタイプが正しい動きである場合

MWPはすべてのアーティファクトに対して正しい基準ではありません。

MVPやプロトタイプの論理が依然として正しい3つのケース。

• 検証の前。 ランディングページ、インタビュー、コンシェルジュテスト、クリック可能なプロトタイプ。目標は学習であり、クラフトではありません。仮説をテストする醜いバージョンを出荷してください。今日出荷してください。検証シーケンスがここでの正しい戦術書であり、MWPではありません。

• 実現可能性スパイク。 未知のものが技術的であるとき（モデルは私が必要とするレイテンシでこの種のクエリに答えられるか？ APIは負荷を処理できるか？ パーサーは実際の入力のロングテールで動作するか？）、質問に答える最小限の使い捨て道具を構築します。それを価値あるものにしようとしないでください。真実のものにしてください。

• ネットワーク効果のベータ面。 マーケットプレイス、コミュニティ製品、ネットワーク効果のツールは、誰かが判断できるようになる前に実際のユーザーベースを必要とするため、正しいアーティファクトはコホート計装を備えた明確にラベル付けされたベータです。ベータを出荷することは、価値あるバージョンの代替ではありません。ベータを出荷することが、価値あるものが何を意味するかを発見する唯一の方法です。その面を正直にベータとしてラベル付けしてください。v1として飾り立てないでください。

MWPは最初の実製品面のためのものです。まだ面の上流にいる（学習、テスト、発見）のであれば、正しいツールはシーケンスのさらに後ろにあります。

再構築の上限

停止ルールのない高い基準は、回避になります。

私が非自明な仕事ごとに適用する教義には、3回の誠実な試みという再構築の上限があります。² 誠実な試みとは、失敗した軸を特定し、具体的な是正措置を指名し、アプローチを大幅に変更し、両方のテストに対して作業を再評価したことを意味します。同じ磨き上げパスの3回の繰り返しは3回の試みとは数えません。その繰り返しは、3回繰り返された1回の失敗した試みとして数えます。

価値ある製品を生み出せない3回の誠実な再構築の後、問題はクラフトではありません。問題は上流、つまりフレーミング、スコープ、ブリーフ、チームの中にあります。面を再構築するのをやめて、前提を見てください。時には、約束が、現実的に基準まで維持できるスコープには大きすぎたことがあります。時には、検証があなたが思っていたよりも柔らかかったことがあります。時には、問題がまったく製品の問題ではないこともあります。

再構築の上限は、2つの正反対の失敗を解決します。弱い仕事を祝福することを拒否し、洗練が隠れ蓑になることを止めます。ターゲットは完璧ではありません。ターゲットは価値があり出荷されたです。純粋で永遠に保留中ではありません。

完璧主義は勇気のないクラフトです。もし同じ面の4回目の再構築を行っているなら、あなたは製品を作るのをやめて、プロジェクトを隠れる場所として使い始めているのです。

重要なポイント

創業者とソロビルダー向け： - コードを書く前に安価に検証します。MWPは検証が市場適合を確認した後に適用されます。 - 機能を積極的にカットします。残った面を完全な品質バーまで引き上げます。 - 価値あるレベルで出荷します。再構築を3回で打ち切ります。その後はブリーフをエスカレーションします。

プロダクトリーダーとPM向け： - 信頼のプロキシを直接測定します。セカンド成功率、30日対1日のリテンション比率、コホート曲線の形状、自然紹介シェア、100ユーザーあたりの品質摩擦率。 - スコープの会話と品質の会話を分けます。スコープのカットは交渉可能です。品質のカットは交渉不可能です。 - 最初のコホート体験を保護します。脆弱なユーザーに対する劣化した第一印象は、回復に何年もかかります。

エンジニアリングリード向け： - 出荷するすべての面にJiroゲートとSteveゲートを指名します。両方とも合格しなければなりません。 - 目に見えないクラフトに予算を付けます。「動作する」と「価値がある」の違いは、通常誰も指差さない詳細の中に存在します。 - 完璧主義が洗練として隠れるのをやめさせるために、再構築の上限をプロセスに組み込みます。

デザイナー向け： - 視点は装飾ではありません。それは製品を認識可能にするメカニズムです。 - 価値ある面は目に見えて何かを拒否します。チームが何も拒否しなかったなら、スコープが間違っています。 - 曖昧さの中で効くテストは、ひるむことなくその決定に自分の名前を署名できるか、です。

結び：信頼を勝ち取ったら出荷する

製品における支配的な問いはこれは完了したか？ではありません。支配的な問いはこれは存在するに値するか？です。

答えがイエスなら、出荷してください。答えが「まだだが、3回の誠実な再構築以内にそうなる」なら、作業を続けてください。答えがノーで、3回の試みの後もノーのままなら、面ではなくブリーフを再構築してください。

このアプローチは、私が名前を付けるすべての製品を構築する方法です。MVPマインドセットはサイクルのために最適化します。MWPマインドセットは作品体に複利として積み重なります。

あなたが尊重できる最小限の製品を出荷してください。それ以前に出荷しないでください。それを超えて待たないでください。MinimumとWorthyは同じ指示であり、同時に保持されるものです。

---

FAQ

Minimum Worthy Productとは何ですか？

Minimum Worthy Productとは、検証された製品の最小限の公開バージョンであり、ユーザーの信頼を消費するのではなく獲得するものです。Minimumはスコープがコアの約束にまで削られていることを意味します。Worthyは残った面がユーザーが感じ取れる品質バーを満たしていることを意味します。実際のユーザーが目にする最初の本物は、単に機能するだけでなく、彼らの信頼に値しなければなりません。

MWPはMVPとどう違いますか？

元々書かれたMinimum Viable Productは学習のための道具でした。つまり、特定の仮説をテストする最小限のアーティファクトです。実践では、MVPは弱い仕事を出荷するための許可証へと劣化しました。Minimum Worthy Productは、失われた制約を復活させます。検証は、誰かがそれを望むかどうかをカバーします（MVP、ランディングページ、インタビューの仕事です）。MWPは、検証が確認したものの最初の実バージョンを構築するときに維持する基準をカバーします。

チームはいつMWPの代わりにMVPを使用すべきですか？

Minimum Viable Productやプロトタイプの論理が依然として適用される3つのケース：検証の前（ランディングページ、インタビュー、コンシェルジュテスト、クリック可能なプロトタイプ）、実現可能性スパイク中（レイテンシや品質をテストする使い捨てコード）、そしてチームが価値を定義できる前に実際のユーザーでラベル付けされたベータを必要とするネットワーク効果製品の場合です。MWPは最初の実製品面に適用されるのであり、その上流のすべてのアーティファクトに適用されるわけではありません。

製品が価値あるかどうかをどのように測定しますか？

虚栄の指標ではなく、5つの行動的信頼プロキシを通じてです。セカンド成功率（アクティブ化したユーザーのうちコアな成果を2回目に完了する割合）、1日目のアクティブ化に対する30日目のリテンション（絶対値ではなく比率）、コホートリテンション曲線の形状（平坦か減衰か）、インセンティブなしの自然紹介シェア、そして品質摩擦率（アクティブ化ユーザー100人あたりの返金、失敗したエクスポート、サポートチケット）。価値ある製品は5つすべてで強さを示します。弱い製品は少なくとも1つで、しばしばすべてでそれを示します。

---

The Worthy Gate

このフレームワークを自分の仕事に適用するための決定ツールです。5つの入力を通り、それから3つの教義レールを通ります。スコアなし、ゲーミフィケーションされたメーターなし。軸を指名し、次の一手を示す判定です。

---

References