The 2×2
Two axes decide the whole go-to-market: how technical the thing you sell is, and how technical the buyer is. Three quadrants have well-worn motions — DevRel, self-serve, sales-led. The fourth, a deeply technical platform sold to a non-technical buyer, is where forward deployed engineering lives. Twenty years later a team standing the function up from scratch draws the grid again, and one of its axes is a position rather than a property.
Software engineers are some of the last people who should be customer-facing — ask any of them. So the idea at the heart of forward deployed engineering sounds ridiculous on arrival: take your engineers and send them to the forefront, into the customer's building, into the customer's problem. Palantir didn't do this because it was charming. It did this because of where it sat on a 2×2 that every software company sits on, whether it knows it or not.
The two axes
Axis one: what you sell. Is it a configurable tool, or a technical platform meant to be developed on? Axis two: who buys it. Is your buyer technical enough to absorb the complexity, or not?
Three of the four quadrants are solved problems:
- Technical product, technical buyer — GitHub, Datadog. Incredibly complicated software, but the ICP is a CTO or CIO and the users are software engineers. They take the complexity and use it, because it's part of their job. Your motion is DevRel and developer engagement.
- Configurable tool, non-technical buyer — Rippling, Jira, Slack. These tools might be complicated, but they're configurable, not developed upon. Selling them to a non-technical buyer is fine. Your motion is sales-led.
- Simple tool, technical buyer — self-serve. Swipe a card. Nobody needs hand-holding.
The quadrant with no playbook
You only need FDE in the weird, unique situation Palantir found itself in: selling something very technical to a non-technical buyer.
Why was Palantir stuck there? Foundry — a platform for centralizing an organization's data into an ontology and building applications on top — is inherently uninteresting to the big tech companies. Google and Meta have great engineers who can build whatever apps the org needs. The customers who need Foundry are the Fortune 500 in oil and gas — companies whose pipelines carry fluorocarbons, not data. They have no engineering depth to develop on your platform, and no reason to build any.
Place some familiar names on the grid: GitHub and Datadog sit in the DevRel quadrant. Jira, Slack, and Rippling sit in sales-led SaaS. Palantir's Foundry defined the FDE quadrant — and today's "agent for insurance / legal / logistics" platforms are moving into it in bulk, mostly without realizing they've changed quadrants.
The same shape, drawn from inside a live team
Twenty years after Palantir, someone standing up the function from scratch reaches for a 2×2 too — and picks different axes. Pauline Brunet leads forward deployed engineering globally at Cursor, and her opening advice to anyone considering the motion is a pair of things to go and find out: "understand your customers, or at least the target market that you're going after and where they are in their transformation journey. And then… understand your own product. What are you offering to those folks? How customizable is it?"
Read against the grid above, one axis is nearly the same and one is genuinely different.
01The product axis
Bai's axes
How technical is the thing — a configurable tool, or a platform meant to be developed on?
Brunet's axes
How customizable is it — login-and-go SaaS, or highly configurable?
02The customer axis
Bai's axes
How technical is the buyer — can they absorb the complexity or not?
Brunet's axes
How far along is the customer's transformation — do they have the engineers, and can they hire them?
03What the axis is
Bai's axes
A property. A CPG company does not become an engineering org.
Brunet's axes
A position. Customers move along it, so the reading has a date on it.
That last row is the substantive difference and it is worth not smoothing over. Bai's customer axis is a fact about an industry; Brunet's is a snapshot of a journey, which means a customer can walk out of the FDE quadrant while you are still serving them that way. Neither reading is wrong — they are answering slightly different questions. Bai's asks whether the motion should exist at your company at all. Brunet's asks which customers, this quarter, are worth sending the team to.
What the other three quadrants get
Her routing is more specific than "not FDE", and the specificity is the useful part:
- Mature customer, low customization — "provide your product in a self-service fashion, create great documentation." The FDE team can help them extend the application and carry the feedback loop back to product, but that is the ceiling.
- Low maturity, low customization — "this is like a traditional SAS deployment… you can picture the waterfall project going through." Configuration and extension, nothing more.
- Mature customer, highly customizable product — "here, you're going to have crazy adoption", and the FDE role is advisory: accelerate them, then get out of the way. "They can do a lot of their work for them and you don't want to be like a solution architect."
- Low maturity, highly customizable product — the embedded transformation. This is the quadrant that needs people in the building, and it is the same corner Palantir found itself in, arrived at from the other direction.