Notes — Nabeel Qureshi on Palantir and Forward Deployed Engineering

Four questions [Adler frame]

Q1 — What is it about?
Nabeel Qureshi makes a structural claim about why Palantir produces so many founders: the forward deployed engineer model is a deliberate founder-training loop, not just a delivery mechanism. The episode also explains Palantir’s core product insight (data integration is the 95% no one sees) and its organisational bets (no titles, murder boards, distinctive hiring signal). Nabeel treats Palantir as a case study in how talent development and product strategy can be co-designed.

Q2 — How is it argued?
Primarily through first-hand testimony — Nabeel spent nearly eight years at Palantir and lived in France for 1.5 years to work at Airbus. The Airbus case study is the anchor for the FDE argument: a specific production ramping problem (4x in a year), a specific data problem (SAP tables in alien language), a specific solution (Asana-like work-order tracking), and a specific outcome (4x production achieved, Ontology born). Statistics from Lenny’s PM alumni research provide external validation for the founder-production claim.

Q3 — Is it true?
The 30% founder rate among Palantir PM alumni is an extraordinary stat, and Lenny’s methodology (LinkedIn data) is reasonable though not rigorous. Nabeel’s explanation (FDE as compressed startup cycle) is plausible and internally consistent. The alternative explanation — selection effect only — cannot be ruled out: Palantir may simply recruit people who would have become founders anyway. Nabeel acknowledges this but argues the training effect is real. The Airbus Ontology origin story is the strongest evidence: a product feature with hundreds of millions of dollars of value originated directly from one FDE engagement. [?] The claim that AI coding tools will lower the effective cost of FDE-style work (making it viable at lower ticket sizes) is a thesis, not yet well-evidenced, but structurally plausible.

Q4 — What of it?
The Forward Deployed Engineers concept page captures the model. The data-integration insight (95% of the work is before the analysis) echoes Jensen Huang on Nvidia's Supply Chain Moat, TPU Competition, and Selling to China‘s argument that the binding constraint is always infrastructure, not the headline capability. Palantir’s no-titles policy is the clearest implementation of the anti-Goodhart principle Nabeel describes. The FDE model’s economics depend on large ticket sizes; as AI reduces the cost of custom software, the viable ticket size may fall, making the model more broadly applicable.

Glossary

Forward deployed engineer (FDE) — Palantir’s term for an engineer who works at the customer’s site (Monday–Thursday on-site), builds new software in response to the customer’s real problems, and iterates with the customer in near-daily cycles. Not a solutions architect or consultant — empowered to ship net-new product. [§ Forward Deployed Engineers]

Murder board — Palantir’s project kick-off practice: write a two-page plan (vision, goals, 3-month tactics, principles), invite three or four senior people who know nothing about the project, and ask them to tear it apart. A good principle for the board to reject should be contestable — “move fast” is not a good principle because no one can disagree; a real principle creates tension. [§ How it works]

Ontology (Foundry) — Palantir Foundry’s data-model layer: a set of human-legible concepts (Aircraft, Work Order, Station) mapped to the underlying database tables, enabling non-expert users to query complex operational data without knowing table schemas. Originated directly from the Airbus Asana-like work-order tracking app Nabeel’s team built. [§ The Airbus case study]

Product leverage — Palantir’s internal metric: revenue per engineer. High product leverage means each marginal customer is served largely by the existing platform; low product leverage means each customer requires bespoke engineering. The tension between FDE-generated bespoke solutions and platform generalisation is what the company managed for 20 years. [§ How the FDE ratio changes]

Distinctive bad signal — Palantir’s (and Peter Thiel’s) thesis on hiring: the best hiring signals turn some people off. Palantir’s “Save the Shire” / Western civilisation framing attracted a specific type of person and repelled another. The clarity of the repulsion was the feature, not a bug. [§ Culture and hiring]

Big hire moment — (shared with Robby Stein on Google AI Mode, Instagram Stories, and Relentless Improvement): the first event that caused a user to adopt a product. The job-interview analogue for products. [§ connection to JTBD]

Key sections

Why FDE is a founder-training loop [§ Why it produces founders]

The FDE model is unusual because it generates operational experience at the pace of consulting but with the ownership of a founder. In a typical enterprise job, you observe problems and propose solutions; someone else owns the outcome. In a typical consulting job, you diagnose and recommend; the client implements. The FDE does both: go in, discover, build, ship, measure — in a single week’s cadence.

Nabeel estimates five such engagements across five different contexts provides the full founder skillset. The cross-domain aspect is important: each domain (aerospace, healthcare, finance, government) has a different set of “business secrets” — non-obvious truths about how the organisation operates that only become visible when you are working alongside the people. These secrets are the raw material of product insight.

The implication for this wiki: companies that want to develop founders internally should structure roles that include all three phases (discovery, building, and ownership of outcomes), not just one. Claire Vo on OpenClaw makes a parallel argument about management skills: the skills that transfer to agent management are the whole-cycle skills (onboarding, scoping, outcome management), not any individual phase.

The data-integration insight [§ The data-integration insight]

Palantir’s core finding — that the analysis is the last 5–10% and data access, cleaning, and normalisation are the first 90–95% — explains why the company built infrastructure rather than analytics. If you go into an enterprise and find that the actual analysis takes one day but getting trustworthy data takes six weeks, you build a product that eliminates the six weeks.

This is structurally identical to Jensen Huang on Nvidia's Supply Chain Moat, TPU Competition, and Selling to China‘s supply-chain moat argument: the headline capability (AI chips, data analysis) is less scarce than the enabling infrastructure (supply chain, data pipelines). The player who solves the infrastructure problem first accumulates an advantage that compounds because the infrastructure problem also gets harder as the headline capability scales.

The Airbus case study as product-methodology example [§ The Airbus case study]

The Airbus A350 production-ramping problem is a worked example of the full FDE cycle:

1. Problem definition by outcome, not specification. Airbus did not ask Palantir to upgrade their data infrastructure; they said “help us 4x production in a year.”
2. Physical presence revealed the real bottleneck. The real problem was not visible from a requirements document: work orders and parts status were stored in SAP tables with names like S3_F1_Z, legible only to SAP specialists.
3. Data mapping as the solution. Translate SAP tables into human concepts (Aircraft, Station, Work Order, Part). Build a UI that answers the question “what does Station 31 need to do today and where are the parts?” — essentially a factory-floor Asana.
4. General principle extracted. The mapping-tables-to-concepts approach became Foundry Ontology. One customer problem → platform layer used by every subsequent customer.

The lesson for founders: a deep single-customer solution is not anti-product if you correctly identify which parts are generalisable. The error is building something generalisable too early, before you have enough domain evidence to know what the right level of abstraction is.

No titles as anti-Goodhart design [§ No titles]

Palantir’s elimination of titles was a direct application of Goodhart’s Law: once a metric becomes a target, it ceases to be a good metric. Titles create status competition; status competition produces gaming (launching new products to claim them, rather than improving existing ones). By removing titles, Palantir forced status to be earned through actual contribution to outcomes.

The downside Nabeel acknowledges: status competition moved from titles to proximity to key decision-makers. Every organisational structure creates a power dynamic; removing one totem shifts competition to another. The question is which form of competition is most productive for the company’s actual work.