There is a strong bias in startup culture against services. Services do not scale, the margins are worse, investors discount the revenue, and a company that does too much of it risks never becoming a product company at all. All of that is true. And in the startup I founded, services were the reason we survived long enough to find product-market fit, and the reason we eventually knew what to build.
What actually worked before the product did
Our early success was consulting and implementation work around data and machine learning. Enterprises had a real, funded, immediate need for people who could make their data usable and get models into production. They did not yet have a need for our platform, largely because we did not yet know precisely what our platform should be. So we sold the work, and the work paid us.
The revenue mattered, but it was not the most valuable thing we got. Delivering that work put us inside the problem repeatedly, across different organisations, with the unglamorous parts fully visible — the integration pain, the schema drift, the fact that the hardest part of getting a model live was almost never the model. You cannot buy that understanding, and you certainly cannot infer it from a market report. We were being paid to acquire the exact knowledge we needed in order to build something worth buying.
That is what eventually converged into product-market fit for us: a platform for distributed data integration and MLOps. It was not a guess that happened to land. It was the repeated pattern we had been paid to solve by hand, enough times to know which parts generalised.
The same pattern, renamed
The AI wave has rediscovered this and given it a more flattering title. Forward-deployed engineering — putting your own engineers inside the customer to build the thing with them — is the current expression of exactly the same idea. It is treated as a novel go-to-market motion for AI companies. It is the motion a great many data companies ran a decade ago, for the same reason: the technology is capable, the buyer’s problem is specific and messy, and nobody yet knows which parts of the solution are general.
I find this genuinely reassuring rather than derivative. It suggests the motion is not a workaround for an immature category; it is what you do whenever capability arrives before anyone understands the shape of the problem. Which is to say: every wave.
The trap, stated plainly
Services can also quietly end your company, and the mechanism is not the one people warn about. The danger is not that services revenue is low-margin. It is that services revenue is comfortable. It arrives, it grows, it responds to effort in a predictable way, and it can conceal the fact that you have not yet found a product anybody will buy without your people attached. A services business that believes it is a product business is a genuinely difficult thing to notice from the inside.
The distinction I would use now is whether each engagement is teaching you something you have not already learned. The first several times you solve a problem by hand, you are buying knowledge. The tenth time you solve the same problem by hand and have not productised any of it, you are not learning — you are just doing the work, and the pattern you needed has already been in front of you for months.
Rules I would actually apply
Choose engagements for what they teach, not only for what they pay. Early on, an engagement that pays less but sits squarely in the problem you intend to own is worth more than a larger one that pulls you somewhere you will never build.
Productise the repeated part immediately. The moment something has been built by hand three times, it should become an asset the next engagement uses — a component, a connector, a deployment pattern. That accumulating library is the bridge from services to product, and it only exists if you deliberately build it while the services revenue is paying for the time.
Refuse bespoke work that cannot generalise. This is the hardest rule to follow when a customer is offering money and you have payroll. But bespoke work that will never become product is a pure trade of runway for revenue, and it competes directly with the thing that would make you a product company.
Watch who owns the resulting artifact. If everything you build in an engagement belongs entirely to the customer, you have taken payment and given away the compounding asset. Contract terms around reusable components matter far more early than they feel like they do.
Not a detour
I would push back on the idea that services are a phase to be embarrassed about and exited as fast as possible. Framed correctly, they are how a startup buys the domain knowledge that becomes a product, funded by the customers who have the problem, without diluting to do it. The failure mode is not doing services. The failure mode is doing services without converting what you learn into something that stands up on its own — and being comfortable enough that you don’t notice.
I’ve Seen This Wave Before — a five-part series on two technology waves
- I’ve Seen This Wave Before
- Start With the Problem, Not the Wave
- Being Early Is Not an Advantage
- Services Before Product-Market Fit — you are here
- When Your Partner Ships Your Product
Related: Service-as-Software — What the Hypergrowth AI Startups Figured Out.
Leave a Reply