The only honest way to build B2B software: find the problem first

Most B2B software is built by people who haven't done the job. A founder spots a market, talks to a handful of potential customers, builds a product that solves the version of the problem they understood from those conversations, and ships it. Then they discover that the real problem is slightly different, the workflow they assumed doesn't match how people actually work, and the thing they built fits nobody precisely.

This is not a new observation. It's the oldest failure mode in software. And yet it keeps happening, because the alternative — actually doing the work before building the tool — requires patience that most founders and investors don't have.

There's a better approach. It's not new either, but it's underused: use consulting engagements to understand a problem deeply enough to build something worth productising, then build it. The services-to-SaaS playbook. It's slower. It's also almost always right.

Why most B2B tools are built by people who haven't done the job

The standard founding story goes: person works in an industry, notices a problem, leaves to build a solution. That story works when the problem is obvious and the solution is well-scoped — when you've spent years doing the manual process yourself and know exactly what would make it better.

It breaks down when the problem is complex, when the workflows vary significantly between organisations, or when the domain has enough regulatory and operational nuance that an outsider can't fully understand it from conversations alone. This describes most regulated industries. Medtech, NHS supply chain, field services, financial compliance — these are sectors where the surface-level problem is visible but the operational reality is deeply specific to each organisation.

Building a tool for these sectors without having worked inside them produces software that handles the easy case well and the real case poorly. It works in the demo. It struggles in production. The sales cycle gets long because prospective customers sense, correctly, that the tool wasn't built with their specific constraints in mind.

What a consulting engagement should actually produce

Most consulting engagements produce a report. Sometimes a deck. Occasionally a set of recommendations that gets filed and referenced at the next strategy day. This is consulting as performance — it looks like insight but it doesn't produce anything that runs.

A consulting engagement designed as a precursor to a product build should produce something different: a brief specific enough to build from.

That means:

• A named workflow. Not "improve reporting efficiency" but "the process by which a field engineer submits a job completion report, from job close to system entry." Specific enough that you could describe every step.
• The actual failure modes. Where does it break? What happens when it goes wrong? What does the workaround look like? The workarounds are where the real problem lives.
• The people involved. Who does this task, how often, with what level of technical comfort, under what time pressure? A tool for a data analyst is different from a tool for a field engineer on a tablet in bad weather.
• The constraints. What systems does it have to integrate with? What can't change because of regulatory requirements? What would make procurement impossible?
• The success condition. What does "better" look like, concretely? Not "saves time" but "engineer submits report in under 5 minutes, data is in the central system by end of shift, compliance record is complete."

A brief that answers those questions is worth more than any number of strategy documents. It's the thing you hand to a developer and get something useful back.

When to stop consulting and start building

The risk of the services-to-SaaS playbook is getting comfortable. Consulting income is predictable. Clients pay for your time. The retainer renews. There's no forcing function to make the product bet — and making a product bet is uncomfortable, because it requires building something before you know if it will work.

The signal that it's time to stop consulting and start building is when you find yourself solving the same problem for the second time. The first time, you're learning. The second time, you're repeating work that could be a product. If a third client comes along with the same problem, you're leaving money on the table and doing yourself a disservice — you could be selling them a tool, not your time.

The other signal is specificity. When your brief is specific enough that you could hand it to a developer and get something back in four weeks, the brief is done. The consulting work is done. The build should start.

What productising actually means operationally

Productising is not the same as generalising. The trap is thinking that turning a consulting solution into a product means making it work for everyone. It doesn't. It means making it work reliably for the people it's designed for, without you being involved in every instance of it running.

Concretely, productising means:

• The tool runs without a developer watching it
• Errors are handled gracefully and surfaced to the right person
• A new client can be onboarded without custom work
• The thing that made it valuable in the consulting context is preserved, not averaged out

The last point matters most. The specificity that made the tool valuable — the fact that it handles the exact workflow of a specific type of organisation — is a feature, not a bug. A tool that is very good for field service engineers in regulated industrial businesses is more valuable than a tool that is mediocre for everyone. Niche is not a weakness. In B2B software, niche is defensibility.

The highest-value path, honestly stated

If you have domain expertise in a regulated industry and build capability — the ability to actually ship software that runs in production — the highest-value path is almost always the same: use the domain expertise to find a problem worth solving, use the build capability to solve it, and use the resulting product to create something that compounds rather than just bills hours.

That path requires being honest about which phase you're in. Consulting is research. Building is the bet. Selling the product is the business. Conflating them — treating consulting income as the goal, or building before the research is done — is how good build capability gets wasted on the wrong problems.

The organisations that get this right use every client engagement as an opportunity to find the next thing worth building. They treat the consulting relationship not as the end state but as the reconnaissance that makes the product bet informed rather than speculative.

That's the only honest version of the services-to-SaaS playbook. Not "we'll consult until we figure it out." But "we're consulting because it's the fastest way to find a problem specific enough to build something that actually works."