Lenny's Newsletter · Product & Work
TIER 5 2023-06-13
Next in my special paternity-leave guest series, I’m excited to bring you an incredible post by [Adam Judelson](https://www.linkedin.com/in/adam-judelson-25441583/). 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](https://slingshotaerospace.com/), built a startup for [Deloitte](https://www2.deloitte.com/us/en.html), and then served as president at [mePrism](https://meprism.com/), 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](https://www.firstprinciples.la/), a product agency focused on helping companies achieve their world-changing visions. You can find Adam on [LinkedIn](https://www.linkedin.com/in/adam-Judelson/) and [Twitter](https://twitter.com/Ajuggles), and definitely check out his [Product Principles newsletter](https://judelson.substack.com/), 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.[1](#footnote-1) 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.[2](#footnote-2) 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.[3](#footnote-3) 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.[4](#footnote-4)  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émein 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](https://www.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.[5](#footnote-5) 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](https://peregrine.io/), 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](https://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 How could anyone possibly build a product company without a product team? As a product coach and fractional CPO, I get a lot of blank stares from CEOs when I sometimes advise them not to replace me with a full-time CPO. Here’s what’s going on: at its core, doing great product work is about surfacing great problems to solve and great solutions for those problems. The more people in a company who are responsible for product, the more this information has to play telephone, going from the customer to the CPO to the product manager to the CEO and back. These communication and customer-sensing pathways are already lossy—lossy in fidelity about the actual customer’s needs, lossy in terms of holding the founder’s vision across team members, and lossy in terms of how easily the best engineering ideas get applied to the problems, and so on. We didn’t use traditional titles when building Palantir, but the company’s first chief product officer was a brilliant engineer who ran product for a decade and never had a product title. However, make no mistake, startups cannot succeed without people working to fulfill the responsibilities of product (finding value, experimenting, building, aligning, making it work for the business, etc.), but centralizing that responsibility under a single person isn’t a necessary condition for success. Many Palantir product initiatives were run by people who would later become formal product leaders, founders, and CPOs in their next gig, but few were formally called that inside Palantir, at least not in the early days. A reductionist summary of our approach could be “Put the best engineers in front of people experiencing the problems, and magic will happen.” No product people needed. Of course, what I now appreciate is that those engineers were in fact acting at least part-time as product people. For example, they were showing up in the right places at the right times because of savvy product discovery work that we didn’t have a good name for. My practical guidance for startups and innovation teams is to be cautious when adding a first product role. Adding a product manager who isn’t tethered to value or, worse, a scrum master, product owner, or project manager masquerading as a product manager, not only isn’t guaranteed to accelerate your journey but might actually stall it.[6](#footnote-6) As the founder with the vision, you’re often better off getting some coaching on product in the early phases than delegating this responsibility, at least until after you’ve achieved product-market fit. If your product is successfully gaining user and monetary traction without a product person, you can probably forgo one until you hit a scale crunch point, but if those pathways are lagging, you either need product coaching or a strong, value-driven product person. I find that this leaner model more commonly adds efficiency in emerging technology companies, where the technical bar for understanding the problem is sufficiently high that those lossy communications problems are magnified, but this guidance can apply to any venture in any industry working on any problem set. **Lessons:** 1. Empower people to do the work of product, but don’t feel compelled to have a product organization in the early days. 2. Be possessive of the CPO role, but don’t pretend you know how to do it just because you are the founder. 3. Put great engineers (and other creative disciplines and experts) as close as possible to the actual problems, and make space for something great to happen. 4. Where product is already working organically, don’t insert more product people to have a neater organization chart. ### 7. Solve the hardest problems first People are obsessed with low-hanging fruit. Solving for these was not the Palantir way. The Palantir way was to find the biggest, hairiest, and most difficult problems facing a major organization or industry and work hard on those. We literally worked on problems like finding the next terrorist and where to drill for oil. Perhaps the part of being a Palantir alumnus that makes me the most proud is that almost every company emerging from our network is focused on extremely difficult, world-changing problems. A good litmus test is as follows: if the problem you are solving doesn’t show up in the news or annual report, then it’s probably not a big enough challenge. “Impossible” challenges are opportunities in disguise. Each “unsolvable” problem you can solve becomes intellectual property that separates you from your competition and helps you establish a market of your own. When Congress publicly demanded[7](#footnote-7) after 9/11 that the U.S. Intelligence Community find ways to share sensitive data across agencies while protecting civil liberties, Palantir built Nexus Peering.[8](#footnote-8) The capability was a first-of-its-kind product that prioritized multi-directional sharing from one organization to another without divulging sensitive sources or neglecting the audit trail.  Palantir CEO Alex Karp has frequently argued that society doesn’t have to make a choice between doing good and doing well. He is an inspiration, and part of what I learned from him is that it is good business to solve missions first. Palantir didn’t employ any sort of SaaS-style upsell mechanisms or psychological tricks to gain customer attention. We didn’t spend months or years obsessing over every piece of our customer funnel. The reason is that we were always laser-focused on mission value and hiring people who cared more about solving for those missions than money. We learned early and often that the most important piece of customer engagement is first the impact it has and then the access it affords product to the real problems, which then drives more impact. Once access is established, the product can create value. Once value for the mission is proven, contracts are easy to close, and you get growth. In every company I have advised or worked for since, it’s painfully obvious when this mission and value chain is reversed. Those companies try to push sales and their way of thinking onto customers, who react like someone who wants to leave a blind date as early as possible.  **Lessons:** 1. Embrace the hardest problems in your market. 2. Actively say no to solving the easy ones. Let someone else handle them. 3. Put your customer’s mission and your product vision first. 4. Generate product wins, and then get paid. ## Closing thoughts As with any guidance, it’s important for each reader to decide if and when each of these ideas will work in your situation. I learned a lot that was unconventional at Palantir, and in the years since, I’ve gained much perspective on which of these concepts worked well for us and which did not. Palantir is a hugely valuable (and likely dramatically undervalued) company, but it’s also true that each of these concepts worked as both an innovative plan to be emulated and also at times as challenges to overcome. I want you to be armed with these tools, but also the ability to recognize that each of them must come with balance and be used in the right circumstances. They are phase-driven and environment-driven. When well understood, they can make a company generationally powerful in shaping its environment and driving positive impact in the world. *Thank you, Adam! For more, find Adam on [LinkedIn](https://www.linkedin.com/in/adam-Judelson/) and [Twitter](https://twitter.com/Ajuggles), and check out his [Product Principles newsletter](https://judelson.substack.com/).* *Have a fulfilling and productive week 🙏* **If you find this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already. Check out [group discounts](https://www.lennysnewsletter.com/subscribe?group=true) and [gift options](https://www.lennysnewsletter.com/subscribe?gift=true).** Sincerely, Lenny 👋 [1](#footnote-anchor-1) https://www.protocol.com/newsletters/pipeline/palantir-pack-mafia and https://seekingalpha.com/article/4601938-why-palantir-is-my-top-holding [2](#footnote-anchor-2) These are my views about what made Palantir tick, and my views alone. Palantir did not review any drafts, nor was it involved in the production of this article. [3](#footnote-anchor-3) To learn more about the role of a Forward Deployed Engineer, see https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1 [4](#footnote-anchor-4) https://blog.anduril.com/the-problem-solver-lindsay-trice-85c4fdb6437d [5](#footnote-anchor-5) https://www.nationalreview.com/the-agenda/ashlee-vance-palantir-reihan-salam/ [6](#footnote-anchor-6) For a detailed explanation of why these roles are almost always unhelpful, see Marty Cagan’s blog post: https://www.svpg.com/revenge-of-the-pmo/ [7](#footnote-anchor-7) https://thehill.com/news-by-subject/defense-homeland-security/99497-ten-years-after-9-11-report-details-gaps-in-intelligence-networks/ [8](#footnote-anchor-8) Palantir explains Nexus Peering: https://www.youtube.com/watch?v=IX55r1WhUWM