Be Your Own First Customer: Internal Tools to Product
Turn the ugly tools your team builds to serve customers into the product — most of the value is below the waterline
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 88%
Palantir's services-to-software transition ran on a specific mechanism: the forward deployed engineers kept building internal tools to create value for customers, becoming their own first customers, and eventually those tools were productized. A hard mandate forced every deployment to put a real customer on the internal tooling within months, which injected the rigor that turned crash-prone internal scripts into Foundry. The underlying insight: in any large organization, 95% of the work is accessing, cleaning and joining data — only 5% is analysis — so productizing that painful 95% is where the durable product lives.
Origin
Qureshi's account of how Foundry emerged over a ~3-4 year period at Palantir. He credits Shyam Sankar (President) with mandating that every customer deployment get a customer using the internal tools within a set window.
Core principles
- 01Be your own first customer: build the tools your team needs, then productize them.
- 02The value iceberg: analysis is the tip (~5-10%); the hidden 95% is access, cleaning, joining and normalizing data.
- 03A forcing mandate (put a real customer on it by month N) supplies the rigor internal tools lack.
- 0480%+ margins prove you are a product company; ~20-30% margins mean you are still consulting.
- 05Living inside customer organizations reveals 'secrets' outsiders cannot see — the true painful problems.
How to run it
- 1
Build tools to serve customers, and dogfood them
As you deliver value in the field, keep building the internal tooling that makes your own delivery faster. Treat your delivery team as the product's first users.
Watch out Early internal tools built for Silicon Valley engineers will be unusable and crash-prone for real customers — expect that.
- 2
Find the unified version
Have your strongest people ask: what is the single, generalizable product hiding inside this set of internal tools? Extract the common primitive across engagements.
- 3
Mandate real customer usage on a deadline
Force every deployment to get an actual customer using the internal tools within a fixed window (Palantir used ~3 months). The pain of real usage drives performance and reliability rigor.
Pro tip The mandate feels horrible in the moment — debugging Spark errors in front of customers — but that pressure is what forges the product.
- 4
Productize the 95%, not the 5%
Aim product effort at the hidden bulk of the work: data ingestion (a universal adapter that reads anything), pipeline-building, cleaning, and letting non-technical users join tables. The analysis layer is the small visible tip.
Pro tip Watch your margins: crossing into 80%+ is the signal you have genuinely become a product, not a 'sparkling Accenture.'
Watch out If you keep needing a from-scratch build per customer, you have productized nothing — revenue-per-engineer will stay flat.
In the wild
Early forward deployed engineers were armed only with Jupyter notebooks and primitive data-integration stuff. The team kept building tooling for themselves, then Shyam Sankar mandated every deployment put a customer on those tools within months. Over ~3-4 painful years of reliability and performance work, Foundry emerged.
→ A crash-prone set of internal engineer tools became Foundry, which Qureshi calls the best data platform in the world, with 80%+ margins.
Embedding in corporations, the team saw that increasing sales starts with querying the sales database — but you wait 6-8 weeks just for access, then the data is not queryable. The analysis is the last 5-10%; the 95% before is gaining access, cleaning, joining and normalizing.
→ Palantir aimed its product primitives (a universal data adapter, non-technical join tooling) at that 95%, creating white space competitors had not addressed.
Common mistakes
Building product for the analysis layer only
Teams focus on the visible 5-10% (the analysis and dashboards) and ignore the 95% of pain in accessing, cleaning and joining data. The durable, differentiated product lives in that hidden bulk; skipping it means you solve the easy part everyone can already do.
Never forcing internal tools in front of real customers
Internal tools built for your own engineers stay unusable and crash-prone until real customers depend on them. Without a hard mandate to put a customer on them by a deadline, they never acquire the reliability and performance rigor needed to become a sellable product.
Is it for you?
Best for
Services or forward-deployed businesses trying to make the leap to a scalable software product
Not ideal for
Teams whose internal tooling is genuinely one-off per client with no common primitive to generalize
From the transcript
“we were our own first customers”
“wait what if we take our internal tools and we let our customers use them”
“he just mandated like okay every every customer deployment you have to have a customer using this within you know 3 months or whatever it…”
“the actual analysis is actually just the tip of the iceberg. It's kind of the last five or 10% and the 95% before that is…”
From the episode
How Palantir built the ultimate founder factory
Nabeel S. Qureshi (founder, writer, ex-Palantir)