Alternative-to-MVP Translation Sheet

Begin With the Thing That Already Works

The current alternative is not a product category. It is the arrangement the customer already trusts enough to use: perhaps an incumbent system, a spreadsheet beside it, messages that repair its gaps, a person who catches exceptions, and a meeting where somebody finally decides what is true.

That arrangement may be slow or unpleasant, but it has survived the customer’s budget, habits, permissions, deadlines, and awkward cases. A first product does not earn adoption by looking more modern. It earns a trial by relieving one consequential weakness without destroying the reasons the workaround survives.

Use this sheet after mapping one real workflow occurrence and before choosing an MVP, manual service, landing-page promise, or prototype. Complete it for one customer segment and one recurring failure. Combining several segments or pains will produce a vague product with an impressive feature list.

Bring the workflow map and the evidence behind it: notes, permitted screenshots or work products, observed delays, mistakes, escalation stories, spending, switching concerns, and trust requirements. Mark any statement that still rests on the founder’s inference. The sheet can expose a hypothesis; it cannot turn one into customer evidence.

Name the Whole Alternative

At the top of a blank page, record the customer, the recent occurrence, and the outcome they were trying to produce. Then describe the alternative as a working stack:

• System of record: the product, database, document, or paper trail that holds the official state.
• Side tools: spreadsheets, inboxes, chat threads, calendar reminders, exports, scripts, and personal notes.
• People and rituals: the assistant, operator, consultant, reviewer, approval, meeting, or chase that makes the process finish.
• Non-action: the work delayed, tolerated, abandoned, or done only after a trigger makes it urgent.

Use names and actions from the occurrence. “Operations manager checks promised follow-ups with the service manager” is useful. “Manual process” is not. If the customer named only an incumbent product, ask what happened outside it during the last difficult case.

Now write what each important part has earned. A spreadsheet may preserve flexibility and visible formulas. Email may cross organizational boundaries without setup. A reviewer may carry judgment and accountability. An incumbent may supply history, permissions, integrations, procurement approval, and a familiar recovery path. Doing nothing avoids migration, training, vendor risk, and another monthly bill.

Do not praise the workaround in the abstract. Attach each strength to evidence from the episode:

The service manager reviews every external update because a plausible but unsupported promise can damage the client relationship.

This sentence describes a trust control. Calling the review “inefficient” and removing it would make the proposed product faster and worse.

Follow One Failure to Its Consequence

Choose one moment when the stack failed, strained, or demanded repair. Reconstruct it closely enough that another person could see the event, the workaround, and the consequence.

Complete these lines:

• The alternative fails when [specific event or condition].
• The customer currently responds by [observable workaround].
• This causes or risks [delay, cost, rework, lost revenue, embarrassment, harm, or other visible consequence].
• The problem becomes urgent when [deadline, complaint, exception, review, loss, or trigger].
• Evidence that it repeats is [episodes, frequency, behavior, spending, or repeated repair].

“The spreadsheet is clunky” does not identify a build opportunity. “Three blank technician outcomes force the operations manager to chase replies before Friday’s client call” does. The second statement names an input failure, an actor, a repair, a deadline, and a consequence that can be tested.

Before translating the failure into product scope, challenge it:

• Repeated: Has it appeared in more than one relevant occurrence or customer?
• Consequential: Does the customer recognize a cost or risk beyond annoyance?
• Reachable: Can a first version obtain the input and reach the user without a platform-sized integration?
• Switchable: Will the customer accept some real change—sharing data, trying a workflow, involving a reviewer, spending time, or paying—to escape it?

A weakness can be real and still be a poor wedge. Rare pain may not sustain use. A severe failure behind inaccessible data may need a different entry point. Repeated complaints with no willingness to change describe dissatisfaction, not adoption.

Translate the Failure Into a Product Boundary

The translation should be deliberately uneven. The first version must win at the chosen weakness, preserve the strengths that make the current stack trusted, and concede everything that does not create the first value moment.

Write the boundary in this order:

Must beat. Name the result in customer behavior or workflow terms, with an observable standard where the evidence supports one. Prefer “show which completed jobs lack a usable outcome before the weekly report is drafted” to “use AI to improve reporting.” The technology is a possible means; the first statement is the promise.

Must preserve. Name the flexibility, context, control, accountability, history, or compatibility the customer cannot lose during a trial. This line often determines whether the product should assist a person, produce a reviewable artifact, or remain beside the system of record.

Can be worse. Name the incumbent capabilities the first version may omit without breaking its promise: broad reporting, customization, native integrations, autonomous handling, many roles, migration, or an end-to-end workflow. “Can be worse” is not permission to be unreliable at the chosen job.

Must not attempt. Refuse the systems, decisions, downstream actions, sensitive data, and exceptional cases that would enlarge the product before the wedge is proven. A useful exclusion is concrete enough to stop a feature request.

Lowest-friction entry. Describe how the product enters the existing workflow: an upload, forwarded message, export, founder-assisted setup, manual service, sidecar view, or bounded pilot. Prefer an entry the customer can reverse without damaging the system they already trust.

First visible value. State what the customer can see, decide, send, avoid, or finish before a full replacement or integration exists.

Minimum trust. Record the sources, review, approval, correction, refusal behavior, security, or reversibility required before the customer can use that result safely.

Manual learning boundary. Keep uncertain classification, cleanup, exception handling, or judgment with a person while the founder learns its shape. Manual work is acceptable when it buys evidence; it is dangerous when hidden labor makes an unscalable promise appear automatic.

Stop rule. Name the behavior that would invalidate the wedge. Examples include customers refusing to supply the input, reviewers repeatedly rejecting the output, the failure occurring too rarely, or use disappearing once founder assistance ends.

Only after these lines are coherent should you decide what to build, buy, borrow, fake, or defer. Start with the behavior the customer needs, then choose the least elaborate implementation that can test it honestly.

Worked Translation: The Friday Account Update

Suppose a small field-service company prepares weekly client updates from technician close-out notes. Its stack consists of a scheduling system, a spreadsheet export, messages to technicians, the operations manager’s knowledge, and a service-manager review. It survives because the scheduling system holds job history, the export is portable, people can repair ambiguous notes, and a named manager remains accountable for what leaves the company.

The stack fails when completed jobs contain blank or contradictory outcomes. The operations manager chases technicians, checks work orders, and rewrites internal language while a Friday client call approaches. The painful weakness is not exporting records. It is finding which records cannot yet support a trustworthy update.

The completed boundary might read:

• Must beat: expose missing, contradictory, or unsupported outcomes before the operations manager drafts the client update.
• Must preserve: source visibility, editable wording, and service-manager approval.
• Can be worse: native scheduling integration, historical reporting, automatic technician follow-up, and general workflow management.
• Must not attempt: resolve ambiguous field notes silently, promise follow-up work, or send anything to clients.
• Lowest-friction entry: accept the export the manager already creates and return a source-linked draft with flagged gaps.
• First visible value: the manager begins review with the uncertain jobs identified instead of reconstructing the whole week.
• Minimum trust: every draft statement links to its source; low-confidence cases are refused or flagged; a person approves the result.
• Manual learning boundary: the founder or operations manager classifies unfamiliar note patterns during the pilot.
• Stop rule: stop or revise the wedge if managers will not use real exports, the flags miss consequential gaps, or review effort does not fall after several weekly cycles.

This is not a smaller scheduling system. It is a narrow intervention beside one. The exclusions are part of its credibility: they keep the product away from the decisions where local knowledge and accountability still beat automation.

Write the MVP Claim

Compress the sheet into one claim:

For [customer in a specific situation], the first version uses [reachable input and entry path] to [must-beat behavior], while preserving [strength or trust control]. It will not [major exclusions]. We will continue only if [observable adoption and outcome evidence].

Read the claim against the workflow map. If it requires data the first version cannot obtain, removes a control the customer depends on, or promises value only after migration, the translation has exposed a scope problem. Narrow the entry point or return to discovery.

The sheet is ready when a skeptical reader can see why the current stack survives, where it fails in real work, what the first version must beat, what it may safely concede, how a customer can try it, and what evidence would make the founder stop. The next memo can then decide whether that argument deserves a build, a manual test, another discovery cycle, or rejection.