👋 Hey, I’m Lenny and welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career.

Next in my special paternity-leave guest series, I’m excited to bring you an incredible post by Adam Judelson. Adam spent seven years at Palantir, where he led product for their flagship Gotham data platform. Below, Adam shares his most lasting lessons from his time at Palantir.

After Palantir, Adam went on to lead product at Slingshot Aerospace, built a startup for Deloitte, and then served as president at mePrism, where he grew their data privacy marketplace from zero to 100 million data points protected. Adam is also a two-time founder and advisor to businesses ranging from scrappy drone startups to space and satellite companies to large private-equity-backed firms. These days, he runs First Principles, a product agency focused on helping companies achieve their world-changing visions.

You can find Adam on LinkedIn and Twitter, and definitely check out his Product Principles newsletter, where he shares lessons from the best emerging tech product leaders.

The CTO of Palantir Technologies, Shyam Sankar, in April 2023 testified before the U.S. Senate that “we must spend at least 5% of our [defense] budget on capabilities that will terrify our adversaries.” Shyam and CEO Alex Karp’s unwavering commitment to strengthening our country motivated me to resign from the civil service and permanently defer attending a top law school so I could join what was then Palantir’s small band of engineering mavericks. Our mission was simple: revolutionize the way the world’s largest and most important organizations answer their hardest questions. Fast-forward a decade, and Palantir is a public company whose alumni have gone on to build nine unicorns, from Anduril to Handshake to Amplitude, and over 100 additional venture-backed companies.¹  

At Palantir, we didn’t believe in heavy processes, because we felt that formulas and playbooks tacitly give people permission to stop thinking for themselves. Nonetheless, as I reflect on the experiences we had together and as I now partner with new startups looking to learn from Palantir’s experience, I feel compelled to compile and share my unofficial list of learnings.² While the company has at times been a lightning rod for public speculation, the secrecy and misinformation surrounding its missions often prevent the amazing product lessons it forged from spreading the way they deserve. Not every lesson will work for every startup or innovation team, but I hope these ideas will catalyze others to consider unconventional approaches to doing the impossible and encourage the creation of more world-changing technologies.

A playbook of first principles: To disrupt an industry. . .

1. Forward-deploy your engineering

Product thought leaders tend to extol the value of talking to users, but most are barely scratching the surface. At Palantir, one of the largest teams was called Forward Deployed Engineering.³ This is the team I joined when I first got hired, and we were responsible for making our early product live up to the vision. Our main goal was creating product solutions for issues blocking customer adoption, or that could unlock new growth. The golden nugget in this philosophy is that you don’t worry about how to ask users the right questions or obsess over “interviewing” them. Instead, you are literally there, in the shit with them, getting involved in what is happening. In the early days at Palantir, this meant flying to war zones carrying a bunch of laptops to where U.S. forces actually engaged the enemy. In a commercial context, it didn’t mean jumping on the phone with the fraud specialists at a major bank. It meant going and spending the next three months in customer operations centers, working the same leads as the customer. Anduril, where many Palantir alumni have gone next, continues a similar practice, and I’ve met numerous excellent PMs who work this way even when it’s not a part of the company culture.⁴

It’s not just getting downrange that matters. You have to be the user to unlock this concept. I don’t mean that spiritually as in “think like the user”; I mean literally do their same job with your product as an extended member of their team and see what you learn. You don’t embed for 20 minutes, either. A lot of the real aha moments come after you’ve been in the customer’s shoes for an extended period of time. Work with your product long enough that the customer is impressed that you’ve accomplished something real for their business that they couldn’t. In the early days of one of our most successful engagements that led to an over $100 million deal, the customer had no users of our product for the first 6 to 12 months. We formed a small team that was given direct access, integrated their data into our existing product, built prototype solutions for the unique problems this engagement taught us about, and then performed the analysis and briefed it directly to a top worldwide CEO.

Some financial market analysts have judged Palantir harshly for this sort of embedded dedication, attempting to cast the company as a services organization or consultancy. They completely miss the point that this process is how to learn which problems matter the most and how to build compelling solutions; it is not a permanent state but rather a tool for the vanguard as it approaches a new use case. Further, when innovating in emerging technology applications, often the customer doesn’t yet have a conceptualization of how they will work in the future, so by being one of them, you can establish the first patterns for doing that work excellently. Instead of spending years iterating based on a loose understanding of the customer, we completely understood what mattered and executed immediately, driving real value an order of magnitude faster with superior results.  

Lessons:

1. Go fully inside the customer’s environment.

2. Don’t just empathize with the user; be the user.

3. Do real customer work long enough to have full empathy and inspire.

2. Hire the best absolute greatest people who exist

Everyone says “talent is everything” and “it’s all about the people,” but many executives who I’ve encountered have never worked with the absolute best on the planet. As a result, it’s not obvious to them when they have hired someone who is decent, pretty good, or even downright average. Just because someone saves your butt doesn’t mean they are “amazing” or a “rock star.” Sure, we say that and are appreciative, but that’s not what we mean. We aren’t talking about “the top 1%.” We are talking about the literal one best person for the job who exists on Planet Earth. I cannot stress this difference enough. FAANG companies are the backup plan for this cohort.

Early in our days engaging with military customers at Palantir, we hired directly from special forces, for example ex-Navy SEALs. The SEALs are the créme de la créme in a military context, but we didn’t stop there. We hired some of the most decorated and well-known Navy SEAL commanders alive today. I distinctly recall telling customers who I was bringing to the meetings, and people who had never met either of us would instantly know that individual’s reputation and nickname, and what he was known for. Last year, a space and AI startup I was advising set a great example for this lesson. They wanted to build a first-of-its-kind satellite fabrication facility. The person they hired for the job is an engineer who has built more satellites that are in the sky today than any other human. That’s hiring the absolute best.

Hiring this way is crucial for two reasons. First, the best are, well, better, at the specific work they’ve been asked to tackle. But the less-understood reason why this is so high-leverage is because the world opens doors for people at the very top of their respective fields. The best AI engineers in the world, for example, attract media attention, top VC attention, and top founder attention. As a result, they are better connected and have disproportionately more access to the other best people in the world. This accelerates their learning and dramatically improves their ability to make the impossible happen. The difference between the #1 and the #50 in the world in terms of skills is practically indistinguishable, but as a result of being #1, that individual likely has access to an order of magnitude more knowledge, opportunity, and talent. This problem cascades down the organization through hiring generations, which is one of the reasons why the best startups are orders of magnitude better than the next tier down.

Prof. Lambeau: “You’re right, Will. I can’t do this proof. But you can, and when it comes to that, it’s only about. . . it’s just a handful of people in the world who can tell the difference between you and me. But I’m one of them.” 

—Good Will Hunting, 1997

But the top people aren’t always obvious or famous, so that cannot be our only means for identifying them. One of my favorite new startups is Quindar Space. The Quindar team is easily one of the best teams in the world for the problem they are solving. They focus on every piece of software technology required for satellite spaceflight that is not directly a part of the satellite—for example, software for determining when to maneuver, tracking onboard issues, and finding ground stations on Earth that satellites can beam data down to. The founders all built this type of software together at multiple prolific satellite companies, including OneWeb (the company with the second-most satellites in orbit after SpaceX), before they became founders at Quindar. Almost no one has more experience or skill in standing up these systems, giving them an enormous advantage. Sometimes these individuals are well known and other times they have been buried in a bureaucracy, and sometimes they don’t even know that they are the world’s best at a particular problem.

Lessons:

1. For each discipline on the critical path to success, hire the world’s #1.

2. To be sure, ask others in the community if those people are the best.

3. Look in unexpected places for the talent—it’s the experience, not the fame.

3. Hire no salespeople—instead have engineers do sales

At Palantir we broke most business rules. Not for the sake of it, but because we valued thinking from first principles, or the art of getting to the core of what is true multiple layers beneath the surface of the problem. For example, one of our most controversial early decisions was to put people like me and engineers in front of customers, instead of a formal sales team.⁵ Why exactly is a salesperson necessary to sell a product? Is that the best way to handle the situation? Sometimes it is, but for a complex mission-driven sale, we realized that we could disrupt the old model in a positive way. Instead of forcing our government customers into opportunistic pitches from professional relationship brokers, we could put former operators and engineers in the room instead. As a result, we could speak intelligently about the mission and our product from firsthand experience. We didn’t try to hide the skeletons or answer questions “the right way.” Rather, we spoke to our clients like normal people would. Without formal sales training, we were forced to find ways to create value in sales settings and not waste time. Put in the extreme, if what you are building is incredibly compelling, and if someone truly wants to buy it, then the customer doesn’t require a person with a sales background to ask closing questions to scope the engagement and deliver the product.

I was shocked when, fresh out of working in government, I was told to take point on all inbound sales inquiries through the Palantir website while simultaneously taking responsibility for some of our earliest customer engagements. The demanding customer implementation schedule meant that time spent “doing sales” was time I couldn’t spend working on the missions that compelled me to join Palantir in the first place. Potential customers and partners didn’t get true attention from me unless I personally believed that we could help them achieve something meaningful for the mission. Instead of golf, steak dinners, and boxes at sporting events (which aren’t allowed in government contracting anyway), I would ask questions to partners like, “How will you make your money on this?” and to prospects, “How fast can you get us integrated into your mission so we can have an impact?” It’s exceedingly difficult to get that sort of authentic motivation and customer connection out of traditional sales teams that are incentivized by commissions and who come from backgrounds in sales rather than the work itself. 

Lessons:

1. Evaluate who the customer needs to hear from to believe, and put those people in the right places at the right times.

2. Delay hiring professional salespeople for as long as possible.

4. Experimenting with live products

I’m going to make just about every single well-trained product person grumble here. For anyone who learned product formally, you learned to experiment cheaply, meaning not with expensive engineering time and code. We’re supposed to use designs, value tests, landing pages, and all sorts of other lightweight methods to measure the value of a product before we build it. Well, at Palantir, we often used working products as the iterative units of value. When we learned about new customer needs, we didn’t spend a lot of time standing back and designing product experiments or running extensive discovery sprints. We designed and built instead. Then we shared with customers. Then we’d subtract and add and build again, and then we’d share again, and so forth. We did full-scale product iteration with real working code. To supercharge velocity, we sent our designers forward too, and generally worked in daily cycles.

I won’t belabor the disadvantages of this style, as they are pretty obvious (wasting lots of time and money on code no one uses), but the advantages when it works are so powerful as to be nearly unfair. For starters, to customers it is magical to see their feedback incorporated into the product nearly instantaneously. This creates insanely strong advocates. Perhaps more importantly, though, it takes the guesswork out of trying to understand if users will care. If they don’t care, they won’t use the product, and you’ll know that immediately. That’s a clear signal to go back to the drawing board. If they do care, they will use the new features and create tons of value with them in less time than it takes typical product teams to review feedback, much less build something. There is also nothing lost in translating their desire into a product—you can be entirely clear with them about how you are solving their problem, and they can be entirely clear on what they are getting. This creates a huge amount of trust and avoids the mental gymnastics sometimes required to test difficult assumptions, especially with hard-to-reach users.

This is not something that only Palantir can do; however, it is something that only teams with very strong engineers can do. Teams without engineers who can make serious, meaningful improvements to products in less than 24 hours should skip this strategy and focus on delivering validated product solutions as quickly as they can using traditional discovery and validation techniques. Effectively, what we did that was novel was to use skill and experience to make writing code cheaper than typical teams can run most experiments. Particularly in the earlier days, when running frequent experiments in secure facilities would have been extremely difficult because of how few users we could access in these rarified environments, this worked great.

Lessons:

1. Consider using working products to iterate with users instead of designs and concepts.

2. Acknowledge that most of what you show won’t have value, but what value is there will grow rapidly if you focus.

3. Honestly assess who in your company has the skill to participate in this model, and do not impose it on everyone.

4. Keep using traditional discovery and validation techniques for high-risk endeavors, but consider blending working prototypes more frequently in the mix.

5. Build features that magnify value over time

We want to solve customer problems, but we also want to solve them in ways whereby the next user or customer is better off because of what the first user did. This can manifest as (1) a growing data asset, for example more valuable records or an increasingly well-trained machine learning model, or (2) network effects from user and customer interactions with one another. At Palantir, we focused on both. One key value proposition in our Gotham platform was its ability to find unknown connections across large data sets, for example between a terrorist financier and a bomb builder. Finding and disrupting a connection like this can save lives. The system already integrated key data sources, but before AI could “read” well, computers were horrible at identifying these sorts of connections in textual reports written about suspects. One of our stickiest features addressed this challenge: we called it “tagging.” If you read a document that said that John Smith was a terrorist suspect using the telephone number “123-456-7890,” you could select that text and effectively write it back to the system as a new structured entity. This information, part of the growing data asset, would then link to the other existing structured records. The next user would find evidence of John Smith, see the source referencing him as a suspect, and then easily surface connections through that telephone number, without having to first read the report. If the system previously had a billion records that made it compelling to users, it now had a billion and one, plus possibly dozens of new, unexplored connections. Further, users could leave their own analytic remarks after pouring hours into an investigation, helping the next user start from the last user’s end point. Now imagine one organization with thousands of users each tagging and commenting thousands of times per year. As each user contributes more to the data asset and interacts within the network of each other’s content, the entire product’s value grows at a rate higher than the linear growth in users because more value exists than in the previous generation.

Peregrine, another Palantir-alumni-founded company, nails this same concept. They focus on helping public safety organizations collaborate on real-time information. One of their compounding value features is the ability for different public safety organizations to form software-defined sharing arrangements, where authorized records can be shared without requiring someone to pick up the phone first. Agencies can share a living report with organizations that have the right to access the data but who aren’t customers, and through this pathway, the new agency can see an easy pathway to joining the collective. When they do, the sharing becomes even more compelling for the original members, increasing product stickiness for all. 

To build features like these, you don’t need to solve different problems than your product is already solving—you simply need to put more thought into how to solve them in ways that draw in or add value for others. Repl.it does a great job here too, in that each new public template coding project can act as a starter project for a new or existing user to build upon, drawing in people who might not have gotten started if they had to begin with a blank screen.

Lessons:

1. Identify ways to solve problems in the product that increase value over time for the nth user.

2. Supercharge those cycles by streamlining usability, and call attention to them with new users.

6. Don’t build a PM organization too early...