Guillermo Flor recently shared something that caught my attention: "From day one, Palantir paired software with forward-deployed engineers on-site, wiring messy data, building workflows with users, and turning custom work into reusable product." He also called it "High-friction, expensive, looked unscalable" and yet it became "one of the stickiest enterprise businesses ever."

That combination of "this should not scale" execution and ruthless productization is one of the most useful go-to-market lessons for B2B software right now, especially as AI pushes more teams back toward services: implementation, workflow design, and change management.

In this post, I want to expand on Guillermo's core point: the winners will not be the ones with the best demo. They will be the ones who can land inside a real organization, deliver a fast win, and then turn what they learn into a repeatable product.

The Palantir origin story: software built to survive reality

Guillermo frames Palantir's early years (2003-2013) as a response to intelligence failures. That matters because it explains why Palantir did not start with a clean SaaS playbook.

When the problem is fragmented data, conflicting definitions, brittle legacy systems, and high-stakes decisions, you cannot win by shipping a generic dashboard and asking users to adapt. You win by meeting customers in their environment, connecting to what they already run, and shaping workflows with the people doing the work.

Key idea from Guillermo Flor: pair product with forward-deployed execution, then productize the custom work.

This is not consulting bolted onto software. It is a product strategy that uses services as the fastest feedback loop.

Why the hybrid model looked unscalable (and why it worked anyway)

Palantir's model was "high-friction" for real reasons:

On-site presence is expensive.
Integrations with "messy data" are slow.
Workflow change is political.
Security and compliance add latency.
Early deployments are never cookie-cutter.

Most startups avoid this because it breaks the neat CAC-to-LTV spreadsheet. But Palantir gained something that low-touch SaaS rarely earns in regulated, complex enterprises: deep embeddedness.

Once your software becomes part of an operational workflow (not just reporting), switching costs become real. Not because the UI is sticky, but because the organization has reorganized work around your system.

A practical way to think about it is this:

Low-touch SaaS sells features.
Forward-deployed software sells outcomes.

Outcomes create internal champions, budget justification, and long-term renewals.

"Forward-deployed engineers" as a product function, not a services department

Guillermo highlights Palantir's use of forward-deployed engineers on-site. The important nuance is what those engineers are doing.

In a classic services model, delivery teams implement what product already is.

In Palantir's early playbook, forward-deployed teams:

Translate the business problem into data and workflow requirements.
Build the first working version with users in the loop.
Identify what is repeatable across deployments.
Feed those patterns back into the product.

That fourth step is the difference between "we do custom projects" and "we build a platform." The goal is not to scale hours. The goal is to scale learnings.

The productization loop you can copy

If you are building an enterprise AI product (or any workflow software), a simple loop looks like this:

Deploy: embed with a narrow team and pick one workflow that matters.
Win: deliver measurable impact fast (days or weeks, not quarters).
Distill: document the repeatable parts (data connectors, prompts, evals, approvals, UI patterns, permissions).
Ship: turn those parts into product defaults.
Repeat: sell the next deployment with less bespoke work.

The model is only "unscalable" if you stop at Deploy and Win.

Client acquisition and onboarding: sell the wedge, not the platform

Guillermo's outline calls out early client acquisition and onboarding. In practice, hybrid models win when they are disciplined about the initial wedge.

Enterprises do not adopt "platforms" quickly. They adopt solutions to urgent problems.

So the right sequence is:

Pick a high-value workflow where data fragmentation causes pain.
Offer a credible implementation path, not just a demo.
Commit to a short time-to-value with clear success metrics.
Use the first win to expand into adjacent workflows.

This also changes what you pitch. Instead of "buy our software," the message becomes:

"We will get this workflow live with your data, in your environment, with your constraints."

That is exactly why services and change management come back into the picture.

Metropolis and Foundry: the enterprise pivot is really a repeatability pivot

Guillermo mentions Metropolis and Foundry as part of the pivot to the enterprise. The deeper story is about abstraction.

Early on, your team solves problems by brute force: custom ETL, one-off permissions, bespoke dashboards, manual QA.

To scale, you must abstract:

Common data integration patterns become connectors.
Common governance needs become role-based access controls.
Common workflow steps become templates.
Common deployment constraints become productized infrastructure.

Foundry (in particular) represents the moment where the accumulated lessons of forward-deployed work become a system other teams can use.

If you are an AI startup, this is a helpful warning: model quality is not your product. The product is the operational system around the model, including data, governance, evaluation, and workflow integration.

Culture and internal workflows: you cannot fake the operating system

Guillermo also points to Palantir's internal workflows and culture in the early days. Hybrid delivery requires a company that treats deployment as a first-class capability.

A few cultural traits that matter:

Product and delivery are on the same team, not siloed.
Learning from the field is rewarded, not dismissed.
Shipping improvements from deployments is fast.
Security, permissions, and auditability are baked in early.

Without this, services becomes a dumping ground for "whatever product cannot do," and the organization never climbs the productization curve.

Why this playbook matters even more in the AI era

Guillermo's line that "AI is pushing startups back into services" is spot on. AI adds new sources of friction:

Outputs are probabilistic, so stakeholders demand evaluation and monitoring.
Data access is harder, especially across teams and systems.
Risk, privacy, and compliance reviews slow everything down.
Workflow change is required to realize value, not optional.

So when Guillermo says, "The winners won't be the ones with the best demo," I read it as a direct challenge to AI theater.

A great demo can be built on perfect data and a single happy-path prompt.

A great business is built when:

the model works on messy real data,
the workflow fits how teams actually operate,
the system is governable and auditable,
and the customer can repeat the win across departments.

A simple checklist for founders adopting the Palantir-style hybrid model

If you want to apply the lesson without accidentally becoming a pure services shop, here is a tight checklist:

Define one workflow outcome (not "platform value").
Price and scope for speed: a paid pilot with a clear success metric.
Staff forward-deployed talent that can do product thinking, not just implementation.
Instrument everything: adoption, time saved, error reduction, cycle-time improvements.
Write down every repeated request and turn the top 3 into product within one quarter.
Make governance part of the product from day one.
Create a post-deployment expansion plan before you start the deployment.

If you do this well, the hybrid model stops being a cost center and becomes your unfair advantage.

Closing thought

Guillermo Flor ended his post with "Comment "Palantir" and I'll send you the link," because he researched the early model and wrote a full breakdown. The bigger takeaway is not just "Palantir did services." It is that Palantir used services as the fastest route to product truth, then built repeatable software from it.

This blog post expands on a viral LinkedIn post by Guillermo Flor, Angel Investor | Founder Product Market Fit. View the original LinkedIn post →