Most B2B products should start from one recurring workflow that costs a specific buyer time, money or risk. How to find it, test it in a few weeks, and grow from it.
A market size slide tells you how big the prize could be if everything goes right. It tells you nothing about why a specific person would change how they work next Tuesday. B2B products that get traction usually start somewhere much smaller: a recurring task that someone with a budget dislikes, does by hand, and gets blamed for when it goes wrong. If you are choosing where to start, pick that task first and let the market follow.
This is not an argument against ambition. It is an argument about sequence. A big market is a good place to end up, but it is a bad unit of design. You cannot build for "mid-market finance teams". You can build for the controller who spends the first four days of every month matching payouts to invoices in a spreadsheet and still has to explain the gaps to an auditor.
Top-down sizing feels rigorous because it has numbers. Take the number of companies in a segment, multiply by an assumed price, apply a modest share, and you get a figure large enough for a pitch. The trouble is that every input is an assumption about demand you have not observed. The slide assumes the buyer has the problem, knows it, has budget for it, and prefers you over doing nothing. Doing nothing is the competitor that wins most B2B deals.
A workflow, by contrast, can be observed. It happens on a schedule, it has inputs and outputs, it has an owner, and it has a cost you can estimate by watching it. When you start from a workflow you start from evidence. Market size becomes something you compute bottom-up later: how many people run this workflow, how often, and what each cycle costs them.
Painful workflows rarely announce themselves in interviews. People describe their jobs in terms of goals, not chores, so you have to look for the residue that chores leave behind. Four places are reliable.
Follow the spreadsheet. Any spreadsheet that is emailed around, versioned by filename, or owned by one person who "knows how it works" is a workflow that existing software failed to cover. Ask to see it. The columns tell you the data model, the colour coding tells you the exceptions, and the tab named "DO NOT TOUCH" tells you where the risk sits.
Follow the manual reconciliation. Whenever two systems disagree and a human decides which one is right, there is a workflow. Payouts against invoices, inventory against orders, CRM against billing, timesheets against payroll. Reconciliation is attractive territory because it recurs, it is measurable in hours, and errors in it are expensive and visible.
Follow the compliance deadline. Regulated work has dates that cannot move and consequences that land on named people. As an ISO 27001 lead auditor I can say that evidence gathering before an audit is often the least loved week in a team's year, and the person who owns it will take a meeting about anything that makes it shorter. Deadlines also hand you a natural buying moment.
Follow the escalation queue. Tickets bounced to a specialist, approvals waiting on one manager, exceptions that need a phone call. Escalations show you where the default process breaks, and they usually come with a frustrated owner and a backlog someone is measured on.
Take a hypothetical B2B invoicing tool for agencies. The market framing would be "small and mid-sized service businesses that send invoices", which is large and tells you nothing. The workflow framing starts by asking what happens after the invoice goes out.
Suppose conversations with agency finance leads show a pattern: clients pay late, pay partially, or settle several invoices in one bank transfer with a vague reference. Someone spends hours each week matching incoming payments to open invoices, then chasing the unmatched ones by email. That person is usually the finance manager, the cost is several hours a week plus slower cash, and the risk is a wrong balance that irritates a client. That is a workflow: weekly, owned, measurable, and currently done in a spreadsheet next to the bank portal.
The first product is not "invoicing for agencies". It is "match incoming payments to open invoices and draft the chase emails for the rest". It is narrow enough to build in weeks, the before and after are measurable in hours, and the buyer can tell within a month whether it works. If it does, invoicing itself becomes an easy expansion, because you already hold the data.
You do not need a survey of hundreds. For a single workflow, 10 to 15 conversations with people who actually run it are usually enough to see whether the pain is shared and consistent. Fewer than that and you are hearing individual quirks. Many more and you are often postponing a decision.
Anchor the conversations on the last time it happened, not on opinions. Ask them to walk you through the last cycle: what triggered it, which tools were open, where they got stuck, how long it took, who checked it, and what happened when it went wrong. Ask to see the artifact, whether that is a spreadsheet, a ticket or an email thread. Ask what they have already tried. People who have tried and abandoned two tools have a real problem. People who have never looked for a solution may not.
Halfway through, build a prototype. A working prototype that handles real, anonymised data is now a few days of work. I build mine myself with AI coding agents, and the speed changes what you can afford to test. Put it in front of the remaining people and ask them to run their last cycle through it. Watching someone use their own data in your prototype tells you more than any interview, because they stop being polite and start being specific.
Most founder interviews end with "this is interesting, keep me posted". That sentence is worth roughly nothing. The signals worth counting are the ones that cost the buyer something:
Polite interest looks different: enthusiasm about the vision, vague answers about frequency, "we would need to involve IT", and no artifact. A simple decision rule: if fewer than a third of the people you spoke to offer something costly (time on live data, an introduction, money), move on to the next candidate workflow. That is a useful result, and far cheaper to reach in week three than in month nine.
The first workflow is a beachhead, not a ceiling. Once you own it, you have things that competitors starting from a market slide lack: trust from a specific buyer, the data flowing through that workflow, and a clear view of what happens just before and just after it.
Expansion usually goes upstream to the step that produces your inputs (in the example, creating the invoices), downstream to whatever consumes your outputs (cash forecasting, collections), or sideways to the same workflow for an adjacent buyer. The best next workflow shares your data, your buyer, or both. If it shares neither, it is a new company wearing your logo.
Timing matters too. Expand when the first workflow is retained without heroics, meaning customers keep using it without you running weekly rescue calls. Expanding to escape a first workflow that is not sticking just spreads the same weakness across more surface.
There are real cases where starting broad is correct. Horizontal infrastructure, where the value lies in being the same everywhere (a database, an identity layer, a messaging protocol), cannot be designed around one buyer's chore. Products with strong network effects may need breadth early, because each new user makes the product better for the others. And right after a platform shift or a regulation that touches every company in a sector, speed of coverage can matter more than depth for a short window.
There is also an honest cost to narrowness. A tight first workflow can trap you in a small niche if it connects to nothing adjacent, and investors who think in market slides will push back on a story that starts small. I wrote a book on niching down, and I still would not defend a niche that leads nowhere. The answer is to choose a first workflow that sits at a junction, where the data or the buyer opens the door to the next few workflows. Then the narrow start is a sequencing decision you can defend, not a lack of ambition.
This advice also assumes you can reach the people who run the workflow. If your buyers are only reachable through a large field sales motion, you may need a broader, brand-led entry. Even then, the product inside the pitch should still solve one workflow well.
Write down one workflow in a single sentence: who runs it, how often, what they use today, and what it costs them when it goes wrong. If you cannot fill in all four parts, you do not have a starting point yet, you have a market. Spend the next two weeks in other people's spreadsheets until you can.
Written by
Ratomir Jovanovic
Generic AI features lose ground with every foundation model release. Durable AI products win on one painful workflow, proprietary context, trust and distribution in a single segment. Here is how to score and pick that niche.
2 October 2026
Enterprise buyers do not just buy an AI product, they buy one their security team can approve. What reviews actually ask, why late answers stall deals, and how to build the evidence into the product.
4 November 2026
AI makes producing specs, designs and code cheap, but judgment, review and integration stay expensive. How roles, rituals and hiring change on a small product team, and where it still breaks.
21 October 2026