A useful vertical AI startup wedge serves one role, completes one recurring job and makes exceptions easy for a responsible person to review. Begin with a narrow outcome you can evaluate, rather than offering a whole industry an unspecified AI transformation.
Vertical means the product understands a particular working context. It does not mean adding an industry's name to a general chat interface. The context includes how a task starts, the information available, who can act on it and what happens when an answer is wrong.
Describe the job without the technology
Write the customer's job as a sentence: when a particular event occurs, this role needs to produce this result, so that a named next step can happen. If the sentence requires a paragraph of AI terminology, it is probably not yet a clear job.
Strategyzer's official Value Proposition Canvas distinguishes customer jobs, pains and gains. The useful move here is to choose one job before assembling a feature list.
A property maintenance coordinator might need a reviewable summary of an incoming service request before assigning it. A production assistant might need to check whether a delivery packet includes required files. These are different jobs with different buyers, inputs and error costs, even if both use text extraction.
Use the role, job, boundary and exception card
Create a card with four sections.
Role: Name the person doing the work and the person responsible for its outcome. They may differ. Record who can authorise a trial and who must approve data access.
Job: Identify a repeatable trigger, a concrete output and the next action the output enables. Avoid a job that only happens during a rare annual event unless its economics justify the wait.
Boundary: State which inputs the product reads, which systems remain authoritative and what actions it cannot perform. Make the initial result reversible where practical.
Exception: List the cases that must go to a person, how that person receives context and what happens while they decide. An empty exception section is a sign that the workflow has not been studied closely enough.
Complete the card through observation. A founder's proposed answer belongs in a different colour from an operator's demonstrated behaviour.
A hypothetical service-request wedge
Imagine a founder exploring software for a small equipment rental business. This example is hypothetical. The initial idea is an AI operations manager. After observing intake, the founder narrows the task to preparing a service-request brief from customer emails and attached photographs.
The brief identifies the equipment reference, the stated issue and the missing information. It does not diagnose safety problems, promise a repair time or contact the customer without approval. An employee compares the brief with the source and decides what to do.
That narrow boundary allows a useful test. Select past requests with permission, include ambiguous cases, and ask the operator what would make each brief usable. Count corrections that affect the next action separately from cosmetic edits. A fluent paragraph is not success if it omits the equipment identifier.
Put review costs inside the product question
A system that needs the user to recheck every input may not save time. Record how long review takes, what people must look up and whether an error can be spotted from the supplied evidence.
Anthropic's 2024 agent guidance distinguishes predefined workflows from systems where models direct their own tool use. That historical distinction remains useful for scoping: a fixed intake workflow does not become better merely because it gains open-ended autonomy.
For the rental example, routing known input types and flagging missing fields may be sufficient. Adding authority to schedule technicians creates a different product with additional operational responsibilities. Treat that as a new hypothesis requiring its own evaluation.
Check whether the wedge can become a business
A wedge needs enough repeated use to justify acquisition and support. Ask how often the task occurs, whether the buyer already has an adequate feature in another tool, and whether one account's configuration can be reused elsewhere.
Also ask who owns the source information. A persuasive demo built on clean sample data can conceal weeks of permission requests and identifier cleanup. Delivery friction belongs in the commercial assessment before you quote an easy monthly subscription.
Keep a list of adjacent jobs but do not build them to make the roadmap look larger. The first job should stand on its own value. Expansion is earned when users repeatedly complete the initial task and ask for a related outcome you can responsibly deliver.
Reasons to choose another route
Some vertical problems need specialised credentials, costly implementation or extensive human coverage. A founder with relevant experience and partners may pursue them. A solo founder without that access should not interpret a compelling demo as evidence that the operating burden has disappeared.
Stop or narrow the wedge when you cannot evaluate output quality, no one accepts responsibility for exceptions, or review takes as much work as the original task. The strongest starting point is a job whose improvement can be seen in a real working session, with clear limits on what the software decides.