Most MVP advice is written for founders who don't yet know what to build. The canonical guidance — narrow the scope, test your assumptions, validate before you build — exists because most founders are guessing. They've identified a market, formed a hypothesis, and are trying to test it as cheaply as possible before committing.
If you're an operator building in a vertical you've spent years inside, the discovery problem is mostly solved. The risk isn't building the wrong thing. The risk is building too much of the right thing before you've tested whether customers will actually use it day-to-day.
That's a different problem, and it requires a different build sequence.
What the operator MVP is not
It's not the full product — not the software you would have wanted when you were still in the industry. That version has 15 years of edge cases baked in and will take 18 months to build. It will also probably miss what your customers need today, because the problem you experienced five years ago may be meaningfully different from the version they're living with now.
It's also not a landing page or a survey. Some founders hear "lean MVP" and build a Typeform to see if people express interest. Interest and willingness to pay are completely different signals. Neither a landing page nor a survey tells you whether the product actually improves the workflow.
The operator MVP is one workflow, working end-to-end, running live with a real customer. That's it.
How to scope it
Go back to the specific workflow you identified — the one that causes downstream damage every time it fails. Break it into steps. There are usually five to eight.
Now find the step where the failure rate is highest. Where people make the most errors. Where the workaround takes the most time. Where things fall through the cracks most consistently.
Build just that step. Not the step before it. Not the output reporting for it. The step itself.
This constraint feels artificial until you've done it. The product you want to build wants to include the surrounding context. Resist that. The surrounding context can be added once the core step works for a real customer. Every week you spend building context before proving the core is a week of risk you didn't have to carry.
The five-user rule before you write a line of code
Get on calls with five users who have this problem right now. Not investors. Not former colleagues who'll be supportive. Current operators in your target vertical who are dealing with this problem this week.
You already know what the problem is — that's the operator advantage. The calls are not to validate the problem. They're to calibrate the product on three things.
One: what does the current process look like step by step? Walk through it with each user. Your mental model of the workflow matches theirs in broad strokes and differs in specific details. Those details matter and will show up in your product decisions.
Two: what does failure look like, in their words? The language matters. The words they use to describe the pain are the words your product needs to use when it surfaces that same situation.
Three: what would they pay to make this step not fail? Don't ask "is this interesting?" Ask a specific money question. The answer is more useful than any satisfaction score.
Build for one user, not five
Build for one real user first. Not five. Not a hypothetical persona.
This sounds counterintuitive if you've been told to think at scale. It's the right move. Building for one real user forces clarity that building for a hypothetical user never does. You will discover things you didn't know to ask in the interviews. The user will do things you didn't anticipate. The edge cases appear immediately instead of after you've shipped to a hundred people.
Keep it manual where you can. If the step involves extracting data from a spreadsheet, build the logic that processes the spreadsheet first. Automate the data source connection later, once you know the logic is right. Don't spend engineering cycles on integrations before the core workflow is validated.
Plan for the first build to take four to eight weeks. If it takes longer, the scope is wrong.
What to do when it doesn't work on the first user
It won't be perfect. The question isn't whether there are problems — there always are. The question is which type.
If the user can't figure out how to use the tool, that's a UX problem. Fixable without rethinking the concept.
If the user uses it but it doesn't solve the workflow step, that's a scoping problem. You built the wrong step or the right step in the wrong sequence. Go back to the workflow breakdown and find the actual bottleneck.
If the user uses it and it solves the step but they don't want to pay — that's a prioritization problem. The step you built isn't causing enough downstream damage to motivate payment. Go back to the five-user calls and find the step they said they'd pay to fix.
After the first user
Extend to the second user. Then the third. Each new user pressure-tests different parts of the product. The goal is five paying users with a product all five of them use without hand-holding.
At that point, you have a product — not a finished product, but something that works for a specific workflow, with customers paying for it and enough feedback to build confidently toward the next scope expansion. That's the foundation the seed round conversation should start from.
If you're at the "I know the workflow, now I need to build it" stage, we work with operator founders from first line of code to first institutional raise. Tell us what you're building.