Minimum Worthy Product

As I rebuild ResumeGeni’s public surfaces, I keep running into the same uncomfortable line. The version that technically works is not always the version I will put in front of a job seeker. The parser runs. The output loads. The flow completes. And yet something about the experience spends trust instead of earning it. I sit with it for an hour, rebuild the surface, and the feeling goes away, but the clock does not.

The tension is the essay. Two forces pull against each other: shipping soon enough to get the product into the world, and refusing to ship a product that spends user belief. Most builders resolve the tension by picking one side and defending it. MVP culture picks speed. Perfectionism picks polish. Both answers fail, because the tension is the point.

Minimum Worthy Product is a different standard — ship the smallest product that earns belief, not the smallest product you can defend as functional. Worthy is the floor, not the ceiling. Minimum is a scope constraint, not a quality discount. The MWP builder cuts features until the product can ship and holds every remaining surface to a bar the user can feel. The MVP builder too often does the opposite: cuts quality to protect scope. The substitution is what users feel in the data.

TL;DR

MVP was supposed to be a learning tool: the smallest artifact that tests a real hypothesis with real users. The degraded version became permission to ship weak work. Minimum Worthy Product restores the missing constraint. Validate cheaply, then build the smallest product that earns belief. Minimum cuts scope. Worthy holds the remaining surface to a standard the user can feel.

What MVP Got Right

The original MVP idea did not give permission to ship weak work. It gave founders a way to stop spending months building the wrong thing.¹

Eric Ries wrote The Lean Startup to address a specific failure mode: engineers building elaborate products for markets that did not exist. The MVP was a learning instrument. You built the smallest artifact that could test a specific hypothesis with real users, ran the experiment, measured what happened, and updated your understanding of whether the hypothesis survived contact with reality. The “minimum” in MVP meant scope collapse in service of learning, not quality collapse in service of shipping.

The original framing holds up. I use it. My startup validation sequence (problem, solution, channel, revenue, scale) is downstream of Ries. The case for testing cheap-to-validate assumptions before investing in code is the same case for MWP downstream of validation: every stage’s instrument should fit its stage. Landing pages and interviews are MVPs for desirability. Prototypes and spikes are MVPs for feasibility. MWP is the standard you apply when the validation evidence is already in hand and you are building the first real thing real users will trust.

So I am not arguing against MVP. I am arguing against what MVP became in practice.

Where MVP Culture Went Soft

Somewhere along the way, “learn fast” became “ship whatever,” and the substitution did real damage.

Three translations broke the original idea:

1. “If you’re not embarrassed by the first version of your product, you’ve launched too late” (Reid Hoffman’s line⁴) became permission to be embarrassed by the craft, not the scope. The original claim is about feature count: ship so few features that your future self will be embarrassed by how little the product did. The degraded version is about workmanship: ship so rough that your future self will be embarrassed by how the product looked and felt. Those are not the same sentence.

2. “Ship fast” replaced “learn fast” as the measurable outcome. Learning is a slow, annoying process that produces qualitative insight. Shipping is a fast, legible process that produces a dated artifact. When you cannot distinguish the two, the artifact wins by default. Teams ship every week and stop learning entirely, because no one measures what the team learned.

3. The venture pattern (raise, grow, exit) rewards shipping anything over shipping right. If your job is to demonstrate momentum to the next check, a watered-down product at least clears the bar of “we shipped.” A delayed worthy product looks identical from the outside to a stalled team. The incentive gradient points down.

None of these degradations are MVP’s fault as originally written. They are what MVP became in the mouths of people who needed a defense for shipping weak.

Users feel the result. You feel it in the data. The onboarding completes but the second session never happens. Users open the signup email and never click the link. Support tickets cluster around tasks the product claims to handle. The churn curve decays toward zero instead of flattening into a core. These outcomes are not edge cases. They are the central cost of building to a standard the user cannot believe in.

Minimum Does Not Mean Unfinished

Minimum is a scope constraint, not a quality discount.

Operationally: define the user. Define the one outcome the product claims to deliver. Remove every feature not required for that outcome. Then hold the remaining surface to the full quality bar. Minimum cuts scope until the product can ship. Minimum does not cut the standard so the product can ship sooner.

Worked example. ResumeGeni’s promise is an ATS-ready resume that gives a job seeker a real shot at getting past applicant tracking systems. The minimum version of the promise can exclude:

• Custom templates
• Team collaboration
• Analytics dashboards
• Integrations with LinkedIn, Indeed, or job boards
• Version history
• Export formats beyond one

What the minimum version cannot exclude: accurate parsing of the source resume, honest assessment of the gaps, concrete rewrites that actually fit the job description, an export that opens cleanly in Word, and a flow that makes the job seeker feel safe. You can ship without templates. You cannot ship with vague advice, broken exports, or copy that makes a vulnerable user feel like the product is treating them as a rube.

Minimum is a knife applied to the product backlog. Worthy is a knife applied to the surface that remains.

Worthy Is the Floor

A worthy product does not have to contain everything you imagine. Everything it does contain has to respect the user.

Worthy in the operational sense means the product solves the validated problem well enough that the user carries trust into the next interaction. They see what you were building and they believe there is more to come. The first session stops being an ordeal to endure and becomes a handshake that opens the door to the second. Worthy products accrue belief. Half-worthy products spend it.

You cannot fake trust. Users arrive with expectations shaped by the products they already know.⁵ When your product sits below those expectations (buttons that do not respond, copy that hedges, flows that abandon them halfway), users register the gap before they articulate it. They leave, they do not return, and no retention email will rescue the session they already wrote off.

The question is it worthy? is not a taste question. It is a trust question. The user’s answer appears as behavior.

Validation Comes First, Worthiness Comes Next

The strongest objection to MWP is that users determine worthiness through contact, not maker conviction. Correct. MWP does not replace user judgment. MWP prevents you from burning validated trust before the first real users get to judge.

User contact belongs to validation. Before you build, you test whether the problem is real, whether your proposed solution addresses it, whether you can reach the users, and whether they will pay. The evidence comes from landing pages, interviews, concierge tests, prototypes, and wait-lists. I have written about the sequence in detail. A hypothesis that survives the gauntlet has earned the right to be built.

MWP begins after validation. Validation asks whether anyone wants the promise. MWP asks whether the shipped surface deserves the trust validation already earned. Retention, referral, and quality-friction data decide whether the judgment held up.

Skipping validation and calling the result MWP produces a beautiful answer to a question nobody asked. Skipping MWP and calling the result lean produces a watered-down product that costs the trust validation already earned.

The right sequence: validate cheaply with real users, then build the smallest worthy product for the validated promise. Do both. Skip neither.

The Two Tests: Jiro and Steve

A product has to pass two different tests before I call it done.

The Jiro Test asks whether the work is correct. Evidence that the product works. Edge cases handled. Invisible details finished. Claims cite concrete proof. No hedging; I believe is not evidence. The Jiro Test distinguishes craft from aspiration. I wrote about the Jiro quality philosophy as the discipline applies to AI agents; the same discipline applies to every product surface. The Evidence Gate is how I operationalize the test in code reports.

The Steve Test asks whether the work deserves to exist. Point of view visible. Whole-widget coherence. User dignity preserved. A delight or clarity mechanism the reader can identify, not hand-wave about. The Steve Test distinguishes product from inventory. A shipped thing is not automatically a worthy thing. The full case for taste as a technical system lives in a separate essay; for this post, the operational definition above carries the weight.

Both tests must pass. If Jiro fails, stop and fix. If Steve fails, rebuild. If both fail, the problem lives upstream in the brief.

The operative question when judgment is uncertain is the simplest one in the stack: would I sign my name to this without flinching? If the answer is no, the work is not worthy yet.

The Proof Under Your Feet: blakecrosley.com

The page you are reading started as a small experiment in my pathless transition. It is also part of the argument.

There is no React. There is no Tailwind. There is no webpack, no Vite, no bundler, no build step. The entire site runs on FastAPI, HTMX, Alpine.js, Jinja2, and plain CSS, served directly. On the current build, first paint lands at 45 to 60KB and Lighthouse reports 100 out of 100 across performance, accessibility, best practices, and SEO.³ The site runs in nine languages, ships new guide and blog content end to end in a single git push, and carries zero node_modules/ anywhere in the repository.

The MVP version of the site would have followed the default 2026 advice — Next.js, Tailwind, Vercel. It would have shipped in a weekend. It would have been fine. You would have landed here, the page would have loaded in a respectable amount of time. The difference would not have been capability. The difference would have been taste. I wrote about how a perfect Lighthouse score actually gets built; the short version is that every KB of payload the reader does not download is a form of respect.

The MWP version took longer. The MWP version required writing the HTMX patterns from scratch, tuning the typography by hand, self-hosting the fonts, running the i18n pipeline through Cloudflare D1, and treating the build tool absence as a feature. The MWP version is not technically more capable than the default stack. The MWP version is more intentional. The intention shows up as fewer seams for the reader to notice.

Invisible craft. The reader does not see the decisions. The reader feels the absence of friction. The absence of friction is the mechanism.

The Customer-Facing Proof: ResumeGeni

ResumeGeni raises the bar, because the user is not browsing. The user is trying to improve a document that may decide whether they get an interview.

ResumeGeni’s validation came back clean: landing page, waitlist, targeted posts on Reddit and LinkedIn, 340 email signups in two weeks, and a dozen replies asking when the product would open.⁷ The validation sequence said build it. The build was the easy call. What the build would look like was the hard call, and where MWP did the actual work.

Two categories of cuts. The first category was features: templates, collaboration, analytics, dozens of export variants, job-board integrations. All cut. None of them are part of the promise.

The second category was the standard I was willing to hold for what remained. The standard does not get cut. The parser cannot be weak. The advice cannot be vague. The exports cannot be broken. The copy cannot treat a vulnerable user as a conversion metric. The flow cannot abandon someone mid-process because the happy path was all I had time for.

The MVP version would have shipped a wizard with ten steps, generic output, a subscribe wall at the best moment, and a roadmap page promising everything that was cut. It would have been functional. It might have converted some users once. It would also have taught the first cohort not to trust the product, and the lesson becomes a bad foundation for a vulnerable use case.

The MWP version is smaller than I want it to be. Every feature I have cut I will want back. The bar is the product users land on respects them. The foundation is the only one I know how to build on.

What Users Actually Tell You

Users rarely say I believe in this product now. But their behavior leaves tracks.⁶

Five signals I watch, calibrated to a builder audience:

1. Second-success rate. The percentage of activated users who return and complete the core outcome a second time within the natural usage window. Trust builds at the second success, not the first. For recurring products, I treat second-success below 30% as a rebuild signal. For episodic products, measure the next natural usage cycle instead of forcing a 30-day window.

2. Day-30 retention relative to day-1 activation. Re-engagement email can game raw retention. The ratio cannot. For products with weekly or monthly use, the ratio tells you whether activation was trust or one-time curiosity. I use under 0.25 as a warning and under 0.15 as a verdict.

3. Cohort retention curve shape. Worthy products flatten after the early drop. Weak products keep decaying. Plot the curves; the shape tells the story the averages hide. If the curve never flattens, there is no core of users who actually trust the product.

4. Non-incentivized organic referral share. The percentage of new activated users arriving via direct referral, shared output, or word-of-mouth, not paid channels, not referral-program bribes. Worthy products get talked about. Weak products get forgotten. If the category has a natural sharing moment and organic referral is still under 10% of new-user acquisition, the product is not earning recommendation.

5. Quality-friction rate. Refunds, rage clicks, support tickets, failed exports, manual corrections per 100 activated users, tracked by cohort. The rate is the pain the product inflicts on the users it claims to serve. The rate should trend down as the product matures. If the rate trends flat or up, the problem is the product, not the support process.

None of these signals are vanity metrics. Each one is hard to fake. Each one tracks to a real user experience that either earned belief or failed to. If you cannot name a specific cohort’s numbers on all five, you do not yet know whether your product is worthy.

When MVP or Prototype Is Still the Right Move

MWP is not the right standard for every artifact.

Three cases where MVP or prototype logic remains correct:

• Before validation. Landing pages, interviews, concierge tests, clickable prototypes. The goal is learning, not craft. Ship the ugly version that tests the hypothesis. Ship it today. The validation sequence is the right playbook here, not MWP.

• Feasibility spikes. When the unknown is technical (can the model answer this kind of query at the latency I need? does the API handle the load? will the parser work on the long tail of real inputs?), build the smallest throwaway instrument that answers the question. Do not try to make it worthy. Make it truthful.

• Network-effect beta surfaces. Marketplaces, community products, and network-effect tools need a real user base before anyone can judge them, so the correct artifact is a clearly labeled beta with cohort instrumentation. Shipping a beta is not a substitute for the worthy version; shipping a beta is the only way to discover what worthy means. Label the surface honestly as beta. Do not dress it up as v1.

MWP is for the first real product surface. If you are still upstream of the surface (learning, testing, discovering), the right tools live further back in the sequence.

The Rebuild Cap

A high standard without a stop rule becomes avoidance.

The doctrine I apply to every piece of non-trivial work has a rebuild cap of three honest attempts.² An honest attempt means you identified the failed axis, named the specific corrective move, changed the approach materially, and re-evaluated the work against both tests. Three repetitions of the same polish pass do not count as three attempts. The repetitions count as one failed attempt repeated three times.

After three honest rebuilds that fail to produce a worthy product, the problem is not the craft. The problem lives upstream, in the framing, the scope, the brief, or the team. Stop rebuilding the surface and look at the premise. Sometimes the promise was too big for the scope you can realistically hold to standard. Sometimes the validation was softer than you thought. Sometimes the problem is not a product problem at all.

The rebuild cap solves two opposite failures. It refuses to bless weak work, and it stops refinement from becoming hiding. The target is not perfection. The target is worthy and shipped. Not pure and pending forever.

Perfectionism is craft without courage. If you are on the fourth rebuild of the same surface, you have stopped making a product and started using the project as a place to hide.

Key Takeaways

For founders and solo builders: - Validate cheap before any code. MWP applies after validation confirms market fit. - Cut features aggressively. Hold the remaining surface to the full quality bar. - Ship at worthy. Cap rebuilds at three. Escalate the brief after that.

For product leaders and PMs: - Measure trust proxies directly: second-success rate, day-30-to-day-1 retention ratio, cohort curve shape, organic referral share, quality-friction rate per 100 users. - Separate scope conversations from quality conversations. Scope cuts are negotiable. Quality cuts are not. - Protect your first-cohort experience. A degraded first impression on vulnerable users costs years to recover.

For engineering leads: - Name a Jiro gate and a Steve gate for every surface you ship. Both must pass. - Budget for invisible craft. The difference between “works” and “worthy” usually lives in the details no one points at. - Build a rebuild cap into your process so perfectionism stops hiding as refinement.

For designers: - Point of view is not decoration; it is the mechanism that makes the product recognizable. - A worthy surface refuses things, visibly. If the team refused nothing, the scope is wrong. - The operative test in ambiguity: would you sign your name to the decision without flinching?

Close: Ship When It Earns Belief

The governing question in product is not is it done? The governing question is does it deserve to exist?

If the answer is yes, ship. If the answer is “not yet, but it will be within three honest rebuilds,” keep working. If the answer is no, and it stays no after three attempts, rebuild the brief, not the surface.

The approach is how I build every product I put my name on. The MVP mindset optimizes for cycles. The MWP mindset compounds into a body of work.

Ship the smallest product you can respect. Do not ship before that. Do not wait beyond it. Minimum and worthy are the same instruction, held simultaneously.

FAQ

What is a Minimum Worthy Product?

A Minimum Worthy Product is the smallest public version of a validated product that earns user belief rather than spending it. Minimum means the scope is cut to the core promise. Worthy means the remaining surface meets the quality bar the user can feel. The first real thing real users see has to deserve their trust, not just function.

How is MWP different from MVP?

A Minimum Viable Product as originally written was a learning instrument: the smallest artifact to test a specific hypothesis. In practice, MVP degraded into permission to ship weak work. A Minimum Worthy Product restores the missing constraint. Validation covers whether anyone wants the thing (a job for MVPs, landing pages, and interviews). MWP covers the standard you hold when you build the first real version of what validation confirmed.

When should teams use an MVP instead of MWP?

Three cases where Minimum Viable Product or prototype logic still applies: before validation (landing pages, interviews, concierge tests, clickable prototypes), during feasibility spikes (throwaway code that tests latency or quality), and for network-effect products that need a labeled beta with real users before the team can define worthy. MWP applies to the first real product surface, not to every artifact upstream of it.

How do you measure whether a product is worthy?

Through five behavioral trust proxies, not vanity metrics: second-success rate (percent of activated users who complete the core outcome a second time), day-30 retention relative to day-1 activation (ratio, not absolute), cohort retention curve shape (flat versus decaying), non-incentivized organic referral share, and quality-friction rate (refunds, failed exports, support tickets per 100 activated users). A worthy product shows strength across all five; a weak one will show it in at least one, and often all of them.

The Worthy Gate

A decision tool to apply the framework to your own work. Walk through the five inputs, then the three doctrine rails. No score, no gamified meter. A verdict that names the axis and the next move.

References