Current Alternatives and the Build Opportunity

The Current Alternative Is the Real Competitor

The first competitor is rarely the company that appears in a market map. It is the thing the customer already hired to get through the work: a spreadsheet, inbox, assistant, consultant, agency, internal tool, incumbent product, manual checklist, or the decision to tolerate the pain for another quarter.

That alternative has evidence your idea does not yet have. It has survived contact with the customer’s calendar, budget, approval process, habits, and exceptions. It may be ugly, slow, and irritating, but it is already embedded in the workflow.

The build opportunity comes from studying that survival. A solo founder does not need a first product that beats every alternative everywhere. The first product has to beat the current workaround on one dimension the customer already cares enough about to change behavior.

The Workaround Is a System

Customers often name only the official tool. The real alternative is usually a stack.

A sales manager may say the team uses a CRM, but follow-ups happen in personal inboxes, renewal reminders live in spreadsheets, approvals happen in team chat, and the most trusted forecast is a weekly call. The CRM stores history. The inbox carries the conversation. The spreadsheet exposes the state the CRM fails to show. The call resolves uncertainty. Removing any one piece may make the work worse.

Start with the last real episode and name every object, person, and habit involved. Look for the bought product and the spreadsheet beside it; the email thread, chat channel, and calendar reminder; the assistant or analyst who repairs the process; the consultant who supplies judgment; the internal script; the meeting where ambiguity is resolved; the manual checklist; and the work everyone agrees should happen but keeps postponing.

Do not sanitize this inventory. The boring pieces often contain the specification. They reveal what people can edit, what they trust, where judgment enters, who has authority, and which exceptions the official system cannot absorb.

Doing nothing belongs in the inventory too. It has no setup, training, migration, or political cost. When a customer repeatedly tolerates the problem, ask what keeps winning: low urgency, an absent owner, a small consequence, unavailable budget, or fear that change will create a larger risk. Sometimes the answer is a sharper trigger or segment. Sometimes it is no product.

Ask What Each Piece Has Earned

Bad workarounds survive because they do at least one thing well. A spreadsheet may be awkward, but it is editable, inspectable, portable, and familiar. Email routes work across company boundaries without an implementation project. Manual labor absorbs exceptions. A consultant carries judgment and accountability. An incumbent arrives with permissions, integrations, history, procurement, and trust already settled.

Treat these advantages as design constraints. If editability is why the spreadsheet survives, rigid automation may lose even when it is faster. If review is how the customer controls risk, an unexplained answer is not an improvement. If the incumbent is approved and integrated, a sidecar that accepts an export may be more credible than a replacement that demands migration.

This changes the tone of discovery. Do not ask only where the workaround fails. Ask what would be lost if it disappeared. Which columns change when an exception appears? Who notices a bad result? What does the weekly call settle that the software cannot? Why does an experienced coordinator still touch every case? The answer may expose a capability the first product must preserve, or judgment it should not automate yet.

A Better Product Can Still Be a Worse Choice

A customer can believe your product is better and still decline to try it. The comparison includes every burden the new product creates: learning a workflow, exposing data, asking for permission, changing a team habit, trusting a small vendor, surviving a migration, and discovering too late that the product handles the happy path but not the exception that matters.

Switching cost is therefore part of the product, not a sales objection to handle afterward. A credible first version often enters beside the current alternative. It may accept forwarded email rather than require an integration, produce a reviewable draft rather than claim autonomous correctness, export to the existing spreadsheet, or let the founder absorb a messy handoff during a bounded pilot.

The relevant question is not simply whether you can build something better. It is whether the improvement is strong enough, and the first trial safe enough, to interrupt a system that already works after a fashion.

Follow One Failure Until the Product Shrinks

Consider a fictional composite. A founder wants to build a lighter CRM for boutique recruiting firms. Recruiters complain about their applicant-tracking systems, so the replacement first appears straightforward.

The alternative inventory makes it much larger. The official system stores contacts, roles, candidate history, and pipeline state. Personal inboxes hold client feedback. A shared spreadsheet gives the team a flexible view of follow-ups. Calendar reminders prompt individuals. Friday pipeline calls force reconciliation. The owner trusts the history, and years of edge cases sit inside the current arrangement.

Replacing that stack means contacts, companies, roles, candidate records, stages, email sync, notes, tasks, permissions, reporting, imports, exports, migration, duplicate detection, and every exception that has accumulated around them. A solo founder would be competing with mature systems on the dimensions where maturity wins.

One failure, however, repeats across recent episodes. Client feedback lands in email, while the follow-up state lives in a spreadsheet or in a recruiter’s memory. Candidates sometimes wait because nobody can see that feedback has arrived without a next action. The switching trigger is painfully concrete: a client asks, “Did we ever get back to that candidate?”

Now there is a build opportunity smaller than a CRM: reduce missed follow-ups after client feedback. A first version could let recruiters forward relevant threads to a shared address, extract the candidate, client, role, last feedback, and required action, and produce a daily risk list. The founder could review uncertain cases manually. Completed actions could return to the existing spreadsheet.

This product must beat the workaround on missed follow-ups and time to next action. It can be worse at contact management, reporting, permissions, and pipeline customization because none of those capabilities creates the first value moment. It can enter without a full migration and leave the trusted system of record intact.

The refusal defines the product. The founder is not building a smaller CRM. The founder is attacking one expensive leak in the system around it.

Separate a Flaw From an Opportunity

Every alternative has flaws. The useful weakness is not the one the founder finds irritating; it is one customers already route around, pay people to repair, or suffer consequences from.

Name the failure in operational language. “The incumbent is clunky” offers no scope. “Client feedback arrives without a visible next action, and candidates wait” does. Then name the event that makes the failure urgent: a complaint, missed deadline, billing error, compliance review, handoff failure, repeated exception, or customer-visible mistake. Finally, name the earliest outcome the product could improve without replacing the surrounding workflow.

A build opportunity should survive four challenges:

• Repeated: Does the failure appear across customers or episodes rather than once?
• Consequential: Does it cause delay, lost money, rework, embarrassment, risk, or harm?
• Reachable: Can the founder access the input, user, workflow, and buyer without heroic effort?
• Switchable: Will a customer accept some real cost—time, access, changed behavior, a pilot, or payment—to escape it?

An annoying but rare failure may become a feature later. A consequential problem behind inaccessible data may require another entry point. Repeated complaints without willingness to try, share, pay, or change are evidence of dissatisfaction, not switching intent.

Write the Alternative-to-MVP Card

Before writing MVP scope, put the argument on one page. Begin with the specific customer and the complete alternative stack. Record why each important part survives, then finish these lines:

• The alternative fails when…
• The consequence is…
• The customer cares now when…
• The first version must beat it at…
• The first version can safely be worse at…

Then add the minimum trust required for a trial, the earliest observable value, and the lowest-friction way the product can enter beside the current system. End with a stop rule: the behavior or evidence that would show this weakness is not worth building around.

For the recruiting example, the card would name boutique recruiters using an applicant-tracking system, inboxes, a shared spreadsheet, reminders, and a Friday call. The stack survives because it preserves history, flexibility, personal context, and owner confidence. It fails when client feedback has no visible next action. The product must reduce missed follow-ups; it may be far worse at general CRM work. A forwarded-email pilot with human review supplies a trial path. If firms will not forward real threads, use the daily list repeatedly, or involve the people responsible for follow-up, the founder should stop or revise the wedge before building integrations.

The “can be worse” line is a scope boundary, not permission to ship carelessly. An early product may have manual imports, limited roles, founder-assisted onboarding, or weak reporting only when those omissions leave the promised value and minimum trust intact. A reminder product still needs identity matching good enough to avoid sending an embarrassing alert about the wrong candidate.

Decision Gate

The scope is ready when one or two weaknesses are supported by recent customer behavior, carry a consequence customers recognize, and produce a trial lighter than full replacement. You can state what the alternative does well, what the first version must beat, what it may do worse, and what the customer must risk to try it.

Narrow when the product tries to reproduce the incumbent, demands migration before value, or absorbs an entire workflow to fix one leak. Add a capability only when the first value moment cannot occur without it. Delay the build when trust, procurement, regulatory exposure, unavailable data, low urgency, or one-person support burden still defeats a credible trial.

Pay particular attention to spreadsheets. Their untidiness may encode years of changing rules, exceptions, and local vocabulary. Mine that knowledge before promising to replace it. Likewise, a manual reviewer may be the control that keeps a rare error from becoming an expensive one. The alternative teaches you where software can help and where it should remain modest.

Exercise

Choose one target customer and reconstruct the current alternative from a recent episode. Include the official product, side spreadsheets, messages, people, meetings, and non-action. Beside each piece, write the advantage that keeps it in place.

Choose one weakness and write three lines:

1. “The current alternative fails when…”
2. “The first version must beat it at…”
3. “The first version can safely be worse at…”

Now add the trial path and the evidence that would make you stop. If the lines remain vague, if the trial requires a platform, or if the customer will not accept even a small switching cost, keep discovering. The next chapter will ask you to compare evidence across customers; this chapter has done its job when each alternative yields a precise claim that can survive that comparison.