Choosing a Wedge You Can Build Alone

The First Request Can Swallow the Product

Suppose a founder wants to build a customer-success platform for small B2B software companies. The imagined product has health scores, CRM and support integrations, renewal forecasts, playbooks, alerts, dashboards, and automated emails. Then an early prospect describes a smaller, sharper problem: every Thursday, before renewal calls, she wants to know which accounts need attention and why.

The founder can already see the useful first result. He can also see the trap. If he responds by promising live CRM data, configurable health scores, team permissions, and an executive dashboard, the prospect’s urgent Thursday question disappears inside the platform he hoped to build someday.

A wedge prevents that disappearance. It is a narrow entry promise made to a specific customer at a consequential moment. It must be valuable enough to change behavior and small enough for one person to build, deliver, support, and revise. Most important, it must create evidence about what deserves to come next.

That makes a wedge different from a small feature. A CSV importer is a feature. A weekly account-risk digest, prepared from one billing export and a support-tag export before renewal calls, is a possible wedge. The feature describes software behavior; the wedge describes who receives what result, when it matters, and how the founder will make the promise true.

Name the Moment Before the Product

Broad ideas encourage broad nouns: reporting, compliance, operations, productivity. A useful wedge begins with a scene that can actually occur. Someone is trying to complete a job. A deadline, handoff, failure, obligation, or decision makes the outcome urgent. The current alternative costs enough time, money, risk, or attention that change is plausible.

For the customer-success idea, the scene is not “a startup needs analytics.” It is a founder preparing for renewal and customer check-in calls without a reliable view of recent payment trouble, support friction, or stalled engagement. She currently assembles clues from exports, inbox searches, and memory. An account missed until after a failed renewal has a visible cost.

The first value moment is equally concrete: she opens the digest, recognizes an account that needs attention, understands the evidence, and changes what she does before the call. “The dashboard loads” is not a value moment. Neither is “the model produces a risk score.” Those events belong to the product. Value appears in the customer’s work.

A niche does not provide this precision by itself. “Seed-stage SaaS founders” identifies people, but not the moment in which they care. An MVP does not provide it either. An MVP is the version used to gather evidence; without a wedge, it can become a small bundle of unrelated features. The strategic choice comes first: enter through this customer, this moment, this result, and this route to the customer.

A clear first promise might read:

For founder-led B2B SaaS companies with twenty to one hundred paying accounts, produce a weekly account-risk digest from a billing export, support tags, and a short founder note, in time to prepare renewal and customer check-in calls.

The sentence is not positioning copy. It is a design constraint. It tells the founder whom to contact, what input to accept, what cadence to support, and what successful use looks like.

Work Backward from the Result

Now trace the shortest honest path to that value moment.

The customer needs named accounts, the evidence behind each warning, and a plausible next action. The first version therefore needs a secure way to receive two supported exports and a short note. It needs enough processing to connect the records, surface anomalies, and draft explanations. Because a false warning or a missed account can waste a sensitive conversation, the founder reviews the output before sending a weekly email.

It does not yet need live CRM synchronization, custom health-score formulas, multi-seat permissions, executive dashboards, automated outreach, or an always-on prediction service. Those capabilities may become useful. None is necessary to learn whether the digest changes preparation and whether customers will repeatedly supply the data for it.

Manual work is legitimate here because it keeps the learning loop close to the founder. It becomes dishonest when the customer believes the product is automatic, the labor makes delivery uneconomic, or every account requires a different private procedure. The founder should record the review time, the corrections made, and the exceptional inputs. Repeated corrections reveal product logic. Unrelated exceptions reveal that the wedge may still contain several businesses.

This backward trace is stronger than beginning with an architecture. Architecture invites the founder to prepare for imagined variety. The first result asks a harder question: what must be true for this particular promise to be useful next Thursday?

Narrow Where Uncertainty Is Expensive

There are many ways to narrow, but they are choices about risk rather than a catalog to complete.

Choosing one persona reduces disagreement about who owns the pain and judges the result. Choosing one use case or workflow keeps discovery around a repeated job instead of a category of features. An industry or geographic boundary can make language, regulation, trust, and customer access more consistent. An integration boundary holds the first implementation to one source system; a data boundary limits the inputs and claims the product must support.

Automation can be narrowed too. An AI wedge should automate one inspectable step, with a person able to judge its output, rather than promise autonomous operation. A service-to-software wedge lets the founder deliver a result manually while discovering which decisions repeat. An internal tool becomes a wedge only when customers outside the founder’s own situation show the same pain and will change behavior to solve it.

The account-risk digest combines a persona, a weekly workflow, and two data boundaries. That combination is useful because each choice removes a different source of early variation. Adding “for healthcare companies in Nairobi using a particular CRM” would not automatically make it better. Every extra adjective should eliminate a burden or strengthen access; otherwise specificity becomes costume.

Put the Boundary in the Customer Conversation

Scope written only in a product document is easy to abandon. A real boundary must survive contact with a prospect.

Imagine the first customer asks for live CRM synchronization. The founder can ask what fails without it. If uploading the export takes three minutes and the digest still arrives before the call, the integration is not blocking first value. If the export is inaccessible to the person doing the work, or if its delay makes the warning useless, the request exposes a flaw in the wedge rather than an item for the long-term roadmap.

The same test applies to manual service. The founder may correct a mismatched account name during the first few deliveries because the correction teaches how the records join. He should not quietly become the customer’s data-cleaning department. The promise includes the supported files, delivery cadence, review step, and recovery path. It excludes unsupported sources, bespoke analysis, immediate alerts, and decisions made on the customer’s behalf.

Support is part of this design, not an afterthought. One founder must be able to onboard the customer, explain an uncertain warning, correct a delivery, and learn from the failure without abandoning sales and product work. A narrow interface with unbounded exceptions is not a narrow product.

Expansion Has to Be Earned

The larger vision can remain large. It simply cannot spend engineering effort yet.

Keep an expansion note beside the wedge, but write each possibility as a hypothesis with required evidence. Live CRM synchronization may be justified when several paying customers repeatedly use the digest, the export blocks or delays them, and the same integration would remove the friction. Suggested playbooks may be justified when customers consistently identify the same next actions. Team routing may be justified when the digest succeeds but ownership becomes the constraint.

Requests alone are weak evidence. A prospect can ask for a familiar feature without valuing the result beneath it. Stronger signals arrive after use: customers provide data again, act on the digest, pay for another cycle, refer a similar company, or ask to extend the same result into an adjacent workflow. Expansion should follow repeated pull from the chosen segment, not the founder’s desire to make the product look complete.

A wedge can also be too narrow. If the painful event is rare, the buyer has no budget or authority, the result changes no behavior, or success opens no adjacent workflow or spending, then the founder has selected a convenience rather than an entry point. Smallness is not the aim. Concentrated value is.

Write the Solo Wedge Canvas

Use one page. Plain sentences are more revealing than scores.

• Customer: Name the first user and buyer closely enough that you can find real examples.
• Urgent moment: Reconstruct the deadline, handoff, failure, obligation, or decision that makes action plausible.
• Current alternative: Describe the spreadsheet, inbox search, vendor, manual service, habit, or tolerated loss that survives today.
• First value: State the observable result in the customer’s work, not the screen or model output.
• Reach path: Name the manual route to the first ten relevant conversations.
• Input and implementation: Record the least code, bought capability, borrowed tool, and visible manual work needed to deliver honestly.
• Operating boundary: Name the customers, workflows, data, integrations, promises, exceptions, and support hours excluded from the first version.
• Evidence: Choose behavior that would support the wedge: repeated use, payment, data supplied again, a changed decision, referral, or expansion pull.
• Stop signal: State what would make you narrow again or abandon the wedge.
• Earned expansion: Name one adjacent capability and the customer behavior required before building it.

Finish with two sentences: the promise and the refusal.

We produce a weekly account-risk digest for founder-led B2B SaaS companies before renewal and customer check-in calls, using two supported exports and a short founder note.

We do not yet provide live integrations, custom scoring, team workflow, automated outreach, or immediate alerts; we will revisit one of those boundaries only when repeated paid use shows that it blocks the result.

Now write three wedges for the idea that survived your filter. Change the narrowing axis in each version, then follow each promise backward to its required inputs, code, manual work, support, and exclusions. Choose the version whose customer pain is strongest and whose first result one person can deliver without pretending the future platform already exists.

Decision Gate

The wedge is ready to test when a reachable customer faces a specific painful moment, the current alternative is understood, and the first value can be observed in the customer’s work. One founder must be able to deliver that result, explain the promise without qualifications hidden in fine print, recover from likely failures, and support the first users inside explicit boundaries.

It must also be capable of losing. If compliments, demo reactions, or one successful delivery are the only possible evidence, the wedge is too vague to guide a product. Name the repeated behavior that would justify continuing and the result that would cause another narrowing move.

Failure Modes

Platform-first scope is the obvious failure: accounts, settings, permissions, integrations, billing, and dashboards arrive before one result has earned them. Feature-first scope is quieter; the founder polishes a capability that belongs to no urgent workflow. Everyone-first positioning avoids the discomfort of choosing and produces a different roadmap in every conversation.

Other wedges fail outside the code. A channel-blind wedge names customers the founder cannot reach. A budget-blind wedge attracts grateful users who cannot buy or prioritize it. A support-blind wedge calls every custom request learning until the founder is operating a private service for each account. A dead-end wedge is easy to ship and pleasant to use but reveals nothing about a larger habit, workflow, buyer, or budget.

The right wedge feels smaller than the vision because it carries a different burden. The vision has to inspire possibility. The wedge has to survive contact with one customer’s week. Once the promise, delivery, support, and evidence fit inside one founder’s hands, the remaining question is whether the market around that customer can support the company those hands are trying to build.