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における「最小限」とは、学習のためのスコープ圧縮を意味しており、リリースのための品質圧縮ではなかったのです。

元々の枠組みは今も通用します。私自身も使っています。私のスタートアップ検証シーケンス（問題、解決策、チャネル、収益、スケール）はRiesの下流に位置します。コードに投資する前に検証コストの安い仮定をテストするという主張は、検証後のMWPに対する主張と同じです。各段階の計器は、その段階に合っていなければなりません。ランディングページとインタビューは、望ましさを問うMVPです。プロトタイプとスパイクは、実現可能性を問うMVPです。MWPは、検証のエビデンスがすでに手元にあり、実際のユーザーが信頼を寄せることになる最初の本物を構築する段階で適用する基準です。

つまり私はMVPそのものに反論しているのではありません。実際の運用のなかでMVPが何になってしまったか、に反論しているのです。

MVP文化が軟化したところ

どこかの時点で、「速く学ぶ」は「とにかくリリースする」に置き換わり、その置き換えは本当にダメージを与えました。

3つの翻訳が、本来のアイデアを壊しました。

1. 「自分のプロダクトの最初のバージョンを恥ずかしいと思わないなら、リリースが遅すぎる」（Reid Hoffmanの言葉⁴）は、スコープではなく、クラフトマンシップを恥ずかしく思う免罪符になりました。本来の主張は機能の数に関するものです。将来の自分がプロダクトの機能の少なさに気恥ずかしくなるほど、少ない機能でリリースしろ、という意味です。劣化したバージョンは仕事の質に関するものになっています。将来の自分がプロダクトの見た目や体感のひどさに気恥ずかしくなるほど、粗いままリリースしろ、という意味になってしまったのです。同じ文章ではありません。

2. 「速くリリースする」は、測定可能な成果として「速く学ぶ」に取って代わりました。学習は遅くて面倒なプロセスで、定性的な洞察を生みます。リリースは速くて目に見えるプロセスで、日付の入った成果物を生みます。両者を区別できなくなると、成果物がデフォルトで勝ちます。チームは毎週リリースし、学習を完全に止めてしまいます。誰もチームが何を学んだかを測らないからです。

3. ベンチャーのパターン（資金調達、成長、イグジット）は、正しいリリースよりも何でもいいからリリースすることを報酬で評価します。次の小切手に向けて勢いを示すのが仕事であれば、水で薄めたプロダクトでも少なくとも「リリース済み」のバーは超えます。遅延しているふさわしいプロダクトは、外から見れば停滞しているチームと見分けがつきません。インセンティブの勾配は下を向いています。

これらの劣化はいずれも、本来のMVPの書かれ方の責任ではありません。弱くリリースすることへの擁護を必要とした人々の口のなかで、MVPが変わってしまった結果なのです。

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

Minimumは未完成を意味しない

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

運用の面ではこうなります。ユーザーを定義する。プロダクトが提供すると謳っている1つの成果を定義する。その成果に不要な機能はすべて取り除く。そのうえで、残された面をフルの品質バーに保つ。Minimumはプロダクトがリリースできるまでスコープを削ります。プロダクトをより早くリリースするために基準を削るのではありません。

2つの基準を並べてみましょう。

軸	MVP（実践されている姿）	MWP
ゴール	動きを証明するために何かをリリース	ユーザーの信頼を獲得するために何かをリリース
スコープ	機能するものとして擁護できる最小の成果物	検証された約束を届ける最小の面
品質バー	動かせるほどには動く	ユーザーが感じ取れる基準
ストップルール	「リリースした」	2つのテストが通る。3回の再構築が失敗したら、ブリーフを再構築する
成功シグナル	変更履歴の日付	信頼の5つの代理指標：2回目の成功、D30/D1比率、コホート形状、オーガニック紹介、品質摩擦
失敗モード	弱い第一印象がユーザーの信頼を焼き尽くす	磨き込みが隠蔽になる

具体例で考えましょう。ResumeGeniの約束は、applicant tracking systemをクリーンに通り、求職者が採用担当者に届く現実的なチャンスを手にできる、ATS対応レジュメです。約束の最小バージョンから除外できるものは次のとおりです。

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

最小バージョンから除外できないもの。元のレジュメの正確なパース、ギャップの正直な評価、求人記述に本当に合致する具体的なリライト、Wordでクリーンに開けるエクスポート、求職者が安心できるフロー。テンプレートなしでもリリースできます。しかし、曖昧なアドバイス、壊れたエクスポート、弱い立場のユーザーを騙される側として扱うようなコピーのままではリリースできません。

Minimumは、プロダクトバックログに振るうナイフです。Worthyは、残された面に振るうナイフです。

Worthyは床である

ふさわしいプロダクトは、あなたが想像するすべてを含んでいる必要はありません。含んでいるすべてが、ユーザーを敬わなければならないのです。

運用上の意味でのWorthyは、検証された問題をプロダクトが十分に解決しており、ユーザーが次のインタラクションへと信頼を持ち込む、という状態を指します。あなたが何を作っていたかが見えて、これから先もあるのだと信じる。最初のセッションは耐え忍ぶ試練ではなく、2回目の扉を開く握手になります。ふさわしいプロダクトは信頼を積み上げます。半分ふさわしいプロダクトは信頼を消費します。

信頼を偽装することはできません。ユーザーが既に知っているプロダクトが、あなたのプロダクトに期待するものを形作ります。⁵ あなたのプロダクトがその期待を下回ると（反応しないボタン、及び腰のコピー、途中で放り出すフロー）、ユーザーは言葉にする前にそのギャップを記録しています。去り、戻らず、どのリテンションメールも、彼らがすでに見切ったセッションを救うことはできません。

それはふさわしいか？という問いは、趣味の問いではありません。信頼の問いです。ユーザーの答えは、行動として現れます。

検証が先、ふさわしさは次

MWPに対する最も強い反論は、ふさわしさは作り手の確信ではなく、ユーザーとの接触によって決まる、というものです。そのとおりです。MWPはユーザーの判断を置き換えるものではありません。MWPは、最初の実際のユーザーが判断する機会を持つ前に、検証済みの信頼を燃やしてしまうのを防ぐのです。

ユーザーとの接触は検証の領分です。構築する前に、問題が本物か、提案する解決策がそれに対応できるか、ユーザーに到達できるか、彼らが支払うか、を検証します。エビデンスはランディングページ、インタビュー、コンシェルジュテスト、プロトタイプ、ウェイトリストから得られます。このシーケンスについては詳しく書きました。関門を生き延びた仮説は、構築される資格を得たのです。

MWPは検証のあとに始まります。検証は、約束を欲しがる人がいるかを問います。MWPは、リリースされる面が、検証がすでに獲得した信頼にふさわしいかを問います。リテンション、紹介、品質摩擦のデータが、その判断が持ちこたえたかどうかを決めます。

検証を飛ばして結果をMWPと呼べば、誰も尋ねていない問いへの美しい答えが生まれます。MWPを飛ばして結果をリーンと呼べば、検証がすでに獲得した信頼を損なう、水で薄められたプロダクトが生まれます。

正しいシーケンスはこうです。実際のユーザーで安く検証し、そのうえで検証された約束に対して最小のふさわしいプロダクトを構築する。両方をやる。どちらも飛ばさない。

2つのテスト：ジローとスティーブ

プロダクトは、私が完成と呼ぶ前に、2つの異なるテストを通過しなければなりません。

ジローテストは、仕事が正しいかどうかを問います。プロダクトが動作するというエビデンス。プロダクトがエッジケースを処理している。目に見えないディテールが保たれている。主張は具体的な証拠を引用している。及び腰はなく、I believeはエビデンスではない。ジローテストはクラフトと願望を分けます。AIエージェントに適用する規律としてジロー品質哲学について書きましたが、同じ規律はあらゆるプロダクト面に適用されます。Evidence Gateは、コードレポートでこのテストを運用する方法です。

スティーブテストは、仕事が存在するに値するかを問います。観点が見える。ホール・ウィジェット（全体としての製品）の一貫性がある。面がユーザーの尊厳を守っている。手を振って曖昧に語るのではなく、読者が特定できる形の喜びや明晰さのメカニズムがある。スティーブテストはプロダクトと在庫を分けます。リリースされたものが自動的にふさわしいものになるわけではありません。技術的システムとしての審美眼の完全な議論は別のエッセイにあります。本記事では、上記の運用上の定義が重荷を担います。

両方のテストが通過しなければなりません。ジローが失敗したら、止めて修正する。スティーブが失敗したら、再構築する。両方が失敗したら、問題はブリーフの上流にあります。

判断が不確かなときの実務的な問いは、スタックの中で最もシンプルなものです。私はひるむことなくこれに名前を署名できるか？ 答えがノーなら、その仕事はまだふさわしくありません。

足元にある証明：blakecrosley.com

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

Reactはありません。Tailwindもありません。webpackも、Vite も、バンドラーも、ビルドステップもありません。FastAPIがサイト全体を直接配信しています。HTMX、Alpine.js、Jinja2、そしてプレーンなCSSのみで、その間には何もありません。2026年4月17日のビルドでは、初期ページ転送は45～60KBに収まり、Lighthouseはパフォーマンス、アクセシビリティ、ベストプラクティス、SEOのすべてで100点満点中100点を報告しています。³ サイトは10言語で動き、新しいガイドやブログコンテンツは1回のgit pushでエンドツーエンドに配信され、リポジトリ内のどこにもnode_modules/を持ちません。

MVPバージョンのサイトなら、2026年のデフォルトのアドバイス（Next.js、Tailwind、Vercel）に従っていたでしょう。週末でリリースできていたはずです。問題なかったはずです。あなたはここに着地し、ページはそれなりの時間でロードしたはずです。違いは能力ではなかったでしょう。違いは審美眼だったはずです。完璧なLighthouseスコアが実際にどう作られるかについて書きました。要約すると、読者がダウンロードしないペイロードの1KBずつが、敬意の一形態だということです。

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

見えないクラフト。読者は決定を見ません。読者は摩擦の不在を感じ取ります。摩擦の不在がメカニズムなのです。

カスタマーに向けた証明：ResumeGeni

ResumeGeniはバーを上げます。ユーザーは閲覧しているのではないからです。インタビューにたどり着けるかを左右するかもしれないドキュメントを、改善しようとしているのです。

ResumeGeniの検証はクリーンな結果を返しました。ランディングページ、ウェイトリスト、RedditとLinkedInでの的を絞った投稿で、2週間で340件のメール登録、プロダクトがいつ開くか尋ねる12件の直接の問い合わせ、早期アクセスに支払うという3件の自発的な申し出が集まりました。⁷ 検証シーケンスは、構築しろと告げました。構築すること自体は簡単な判断でした。どう構築するかが難しい判断であり、そこでMWPが実際の仕事をしたのです。

2種類の削減がありました。1つ目は機能です。テンプレート、コラボレーション、アナリティクス、数十種類のエクスポートバリアント、求人ボード連携。すべて削除。どれも約束の一部ではありません。

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

MVPバージョンなら、10ステップのウィザード、汎用的なアウトプット、最良の瞬間での課金壁、削られたすべてを約束するロードマップページをリリースしていたでしょう。機能していたはずです。一部のユーザーを1度コンバージョンさせたかもしれません。そしてそれは、最初のコホートにプロダクトを信じるなと教え、そのレッスンは、弱い立場のユースケースにとって悪い基盤となります。

MWPバージョンは、私が望むよりも小さいです。削ったすべての機能を、取り戻したくなるでしょう。バーは、ユーザーが降り立つプロダクトが彼らを敬っていること。その基盤こそ、私が構築する方法を知っている唯一のものなのです。

ユーザーが実際にあなたに伝えること

ユーザーが私は今このプロダクトを信じると言うことは、めったにありません。しかし、彼らの行動は痕跡を残します。⁶

私が注視する5つのシグナルを、ビルダー向けに調整して紹介します。

1. 2回目の成功率。 アクティベートされたユーザーのうち、自然な利用ウィンドウ内に戻ってきてコア成果を2回目に完了した割合。信頼は1回目ではなく2回目の成功で育ちます。定期的に使われるプロダクトでは、2回目の成功率が30%未満を再構築シグナルとして扱います。エピソード的なプロダクトでは、30日ウィンドウを強制するのではなく、次の自然な利用サイクルで測定してください。

2. D1アクティベーションに対するD30リテンションの比率。 再エンゲージメントメールは生のリテンションをごまかせます。しかし比率はごまかせません。週次または月次利用のプロダクトでは、この比率がアクティベーションが信頼だったのか一度きりの好奇心だったのかを教えてくれます。0.25未満を警告、0.15未満を判決として使っています。

3. コホートリテンションカーブの形状。 ふさわしいプロダクトは初期の落ち込みのあと平坦になります。弱いプロダクトは減衰し続けます。カーブを描いてください。形状が、平均値が隠す物語を語ります。カーブが決して平坦にならないなら、実際にプロダクトを信頼するユーザーのコアは存在しないということです。

4. 非インセンティブ型オーガニック紹介シェア。 有料チャネルやリファラルプログラムの賄賂ではなく、直接紹介、共有されたアウトプット、口コミを通じて到達する新規アクティベート済みユーザーの割合。ユーザーはふさわしいプロダクトについて話します。ユーザーは弱いプロダクトを忘れます。カテゴリーに自然な共有の瞬間があり、オーガニック紹介が新規ユーザー獲得の10%未満にとどまっているなら、そのプロダクトは推薦を獲得していません。

5. 品質摩擦率。 返金、怒りのクリック、サポートチケット、失敗したエクスポート、手動修正を、アクティベート100人あたり、コホート別に追跡します。この率は、プロダクトが仕えると謳っているユーザーに与える痛みです。プロダクトが成熟するにつれて、率は下降傾向を示すはずです。率が平坦もしくは上昇傾向なら、問題はサポートプロセスではなくプロダクトです。

どれも虚栄指標ではありません。どれも偽装が困難です。どれも、信頼を獲得したか失敗したかの実際のユーザー体験に紐づきます。5つすべてについて特定コホートの数字を言えないなら、自分のプロダクトがふさわしいかどうかをまだ知らないということです。

MVPまたはプロトタイプが依然として正しい動きとなる場合

MWPはあらゆる成果物に対して正しい基準というわけではありません。

MVPやプロトタイプのロジックが依然として正しい3つのケースがあります。

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

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

• ネットワーク効果ベータ面。 マーケットプレイス、コミュニティプロダクト、ネットワーク効果ツールは、誰かが判断できるようになる前に実際のユーザーベースが必要です。したがって、正しい成果物は、コホート計装を伴う、明確にラベル付けされたベータです。ベータをリリースすることは、ふさわしいバージョンの代替ではありません。ベータをリリースすることが、ふさわしいが何を意味するかを発見する唯一の方法なのです。面を正直にベータとラベル付けしてください。v1に見せかけてはいけません。

MWPは、最初の実際のプロダクト面に対するものです。面の上流（学習、テスト、発見）にいるなら、正しいツールはシーケンスのさらに後方にあります。

再構築の上限

ストップルールのない高い基準は、回避になります。

あらゆる非自明な仕事に私が適用するドクトリンは、3回の正直な試行という再構築の上限を持っています。² 正直な試行とは、失敗した軸を特定し、具体的な是正の動きに名前を付け、アプローチを実質的に変え、両方のテストに対して仕事を再評価した、という意味です。同じ磨き込みパスを3回繰り返しても、3回の試行にはなりません。その繰り返しは、1回の失敗した試行が3回繰り返されただけとしてカウントされます。

ふさわしいプロダクトを生み出せない正直な再構築が3回続いたなら、問題はクラフトではありません。問題は上流（フレーミング、スコープ、ブリーフ、チーム）に住んでいます。面を再構築するのをやめて、前提を見てください。約束が、現実的に基準に保てるスコープに対して大きすぎた場合もあります。検証が思っていたより弱かった場合もあります。プロダクトの問題ですらない場合もあります。

再構築の上限は、2つの反対の失敗を解決します。弱い仕事を祝福することを拒み、磨き込みが隠蔽になるのを止めるのです。ターゲットは完璧さではありません。ターゲットはふさわしく、リリースされていることです。純粋で、永遠に保留ではありません。

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

重要なポイント

創業者およびソロビルダー向け： - コードを書く前に安価に検証する。MWPは市場適合を検証が確認したあとに適用されます。 - 機能を積極的に削る。残された面をフルの品質バーに保つ。 - ふさわしい状態でリリースする。再構築は3回で打ち切る。そのあとはブリーフをエスカレートする。

プロダクトリーダーおよびPM向け： - 信頼の代理指標を直接測定する。2回目の成功率、D30対D1リテンション比率、コホートカーブ形状、オーガニック紹介シェア、100ユーザーあたりの品質摩擦率。 - スコープの会話と品質の会話を分ける。スコープ削減は交渉可能。品質削減は交渉不可能。 - 最初のコホートの体験を守る。弱い立場のユーザーへの劣化した第一印象は、回復に何年もかかります。

エンジニアリングリード向け： - リリースするすべての面について、ジローゲートとスティーブゲートに名前を付ける。両方が通過しなければならない。 - 見えないクラフトのために予算を取る。「動く」と「ふさわしい」の違いは、たいてい誰も指差さないディテールに宿ります。 - 完璧主義が磨き込みとして隠れるのを止めるために、プロセスに再構築の上限を組み込む。

デザイナー向け： - 観点は装飾ではない。プロダクトを認識可能にするメカニズムです。 - ふさわしい面は、目に見える形で何かを拒絶している。チームが何も拒絶しなかったなら、スコープが間違っています。 - 曖昧さにおける実務的なテスト：ひるむことなくその決定に名前を署名できるか？

結び：信頼を獲得したときにリリースせよ

プロダクトにおける支配的な問いは、完成したか？ではありません。支配的な問いは、存在するに値するか？です。

答えがイエスならリリースしてください。答えが「まだだが、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回目の成功率（アクティベートされたユーザーのうち、コア成果を2回目に完了する割合）、D1アクティベーションに対するD30リテンション（絶対値ではなく比率）、コホートリテンションカーブ形状（平坦 vs 減衰）、非インセンティブ型オーガニック紹介シェア、品質摩擦率（アクティベート100人あたりの返金、失敗したエクスポート、サポートチケット）。ふさわしいプロダクトは5つすべてで強さを示します。弱いプロダクトは少なくとも1つ、しばしばすべてで示します。

---

The Worthy Gate

このフレームワークを自分の仕事に適用するための判断ツールです。5つのインプット、続いて3つのドクトリンレールを順に通ります。スコアなし、ゲーム化されたメーターなし。軸と次の動きを名指す判定です。

---

References