Finding Pull Instead of Pushing: Rob Snyder's Step-by-Step Guide to Product-Market Fit
Lenny's PodcastRob Snyder, author of The Power of Pull and the newsletter The Physics of Startups, says his approach came from failure. As a founder, he spent two years pushing a product nobody wanted. He then pivoted almost by accident, the business took off, and friends began asking for help taking their own startups from zero to one. Host Lenny Rachitsky notes that Snyder has since helped around 50 startups grow from zero to over $1 million in ARR. Two members of Lenny's paid community independently asked for him to come on the show after finding his book unusually useful.
The conversation centers on one question: what actually causes a customer to pull a product out of your hands? Snyder's answer is that it isn't pain points, value propositions, or differentiation. It's a specific kind of priority. The episode then follows a startup's early stages through that lens: coming up with an idea, getting the first conversations, running a sales call, closing a deal, retaining customers, and building something repeatable.
Why pain points and value props weren't enough
Snyder describes his first startup as a case where he did everything the standard advice recommends. He found "hair on fire" pain points and big problems. He offered a differentiated solution that provided real value. He even had design partners using the product every day. By that checklist the company should have succeeded. Instead, he says, he "got smashed into a wall for 2 years," pivoting aimlessly without understanding why nothing worked.
After the pivot that finally took off, he concluded that customers can agree a product solves their problems and offers a lot of value and still not buy, because they won't drop their existing priorities to do so. What matters, in his view, is a particular kind of priority. The person is trying to get something done right now, it's on their to-do list, and they can't do it with their existing tools, methods, or options. Someone in that position is like "a coiled spring." When you show up with something that unblocks them, they rip it out of your hands.
He frames the goal as finding a person for whom it would be weird not to buy. Most people, most of the time, are fine. Given their to-do list and their options, it would be weird if they bought. A person with pull is the opposite case.
The PULL acronym
Snyder spells out the framework as four letters:
- P – Project. There's a project on the person's to-do list. He compares it to a job to be done and credits Bob Moesta. A project is not "I want to buy recruitment software." It's "I want to hire more employees."
- U – Unavoidable. There's a reason it has to happen now rather than later.
- L – List of options. The options the person is considering for the project. These might be hiring someone, using the existing team, using tools they already have, or buying something on the market.
- L – Limitations. Why those options aren't good enough to get the project done.
Lenny observed that the first two letters amount to a concrete definition of a hair-on-fire problem, and asked why the last two matter so much. Snyder used a product team as an example. A team may have an important, mandated feature to build, a real and unavoidable project, but if they plan to build it themselves, they won't buy anything. They only buy when their existing options, whether doing it in-house or using a category leader, fail them. The person has to be genuinely stuck.
He also described what happens when only some of the elements are present. If you find a project without urgency, even when existing options fall short, people "will complain and they won't buy." If you find a project and urgency but the options are good enough, they'll say something like, "Yeah, that's exactly what we're doing right now and working with Claude Code on it. We're going to figure it out." All four have to be true at once.
The Jump example, and the insurance agents who didn't fit
Snyder's main illustration is Jump, an AI notetaker for financial advisors run by friends of his. He says they went through the same struggle he did, spending about 18 months hitting a wall before finding pull.
Applied to Jump, the framework goes like this. The project is minimizing the time financial advisors spend taking notes on client meetings and entering them into their CRM. It's unavoidable because if they don't take those notes and record them, they could go to jail. The options were generic AI notetakers, and those fell short because they didn't integrate with financial advisor CRMs and it wasn't clear whether they complied with SEC regulations. When Jump showed up, Snyder says, advisors ripped the product out of their hands. One person reportedly said it must be how Alexander Graham Bell felt when he invented the telephone, which Snyder points out is an odd thing to say about software for financial advisors.
The counterexample also came from Jump. The team reasoned that insurance agents also meet with clients constantly, so they might be a natural next market. Insurance agents did share the project of minimizing time spent on meeting notes. But they aren't required to put notes into a CRM, so the "unavoidable" element was missing. Their existing option was simply not taking notes, which they were already doing, and the framework didn't fill out.
Lenny asked whether something as general as "save time on notes" really counts as a to-do item. Snyder said advisors probably didn't literally write it down. It was something they did all the time as part of their workflow, and while doing it, their intention was to spend as little time as possible on the annoying task. He distinguishes the action on the calendar from the project, which is the intention behind it.
Pull is discovered, not created
Snyder described one realization as "super liberating." He used to think he was simply bad at convincing the market to want his product. He now believes pull, meaning a project on someone's to-do list, exists before and independently of the founder. The job is to find it, not to persuade people to have it. He said he hasn't figured out how to create pull and suspects it's very hard, if it's possible at all.
The sign that you've found it is how the conversation sounds. With pull, it goes something like: "Wait a second, you can do what? Okay, how do we get started? Does the product exist yet?" Without pull, the conversation can be anything else, including enthusiastic and flattering ("That's amazing... that's totally the future of our industry... I can see how that would save us so much money"). What's missing is "I need this right now."
He added a correction he says people often need: pull belongs to a person, not a company. Even in enterprise sales you aren't selling to SpaceX. You're selling to the head of legal at SpaceX, who has a project they can't do themselves. Saying "we sell to mid-market private equity firms" misses this. You sell to a specific partner or operating partner at that firm who is trying to do something specific.
Coming up with ideas: firsthand experience over brainstorming
Snyder admits he keeps a notebook of product ideas that "all sound unhinged" (his example: "an API for APIs"), and that he can't tell good ones from bad ones at the product level. He sees the PULL framework as sitting upstream of the product idea. It turns an idea into a claim that a specific person is stuck on something right now and would be weird not to buy. You then test that claim by talking to those people and seeing whether they try to buy, even before a product exists.
He has strong opinions on where these hypotheses should come from. He thinks founders don't take this stage seriously enough: if your life depended on it, you wouldn't do ten 30-minute Zoom interviews. You'd go all out, go in person, and do the job alongside potential customers so you feel the problem firsthand. Lenny connected this to Nan Yu, formerly head of product at Linear, who said he wants to feel a person's pain the way they feel it.
Snyder's main story is about a school friend who had no product idea at all, only a liking for small businesses. The friend listed industries that seemed interesting and shadowed businesses in each one, riding along for days at a time. He started with solar panel installers, and "he hated them and they hated him." He eventually reached independent physical therapists. He liked them and they liked him, so he spent days watching over their shoulders. He even tried to buy a physical therapy franchise, which let him see the P&L, and he seriously considered going through with it. Through that process he noticed that they were trying to do something specific and were stuck.
Snyder gave two reasons this matters. First, insights like that don't come from a whiteboard, and it's unclear whether they would surface in an interview either. His friend found something he could see only by observing. Second, a more philosophical reason: a company exists to serve a kind of person, and without firsthand experience you can't make the thousands of decisions needed to serve them well.
Asked to break down the roughly 50 companies he's worked with, Snyder estimated about 10% got their idea from their own experience and 90% from deliberately going out to get firsthand experience. Some in the second group learned what the right product was by selling the wrong one first. He added that the method doesn't strictly matter; the secret could come to you at an ayahuasca retreat. But getting your hands dirty and learning from reality is what tends to work. Lenny tied this to the "earned secret" concept he attributed to the VC firm Floodgate.
Testing a pull hypothesis with two slides
Once the physical therapy insight came into focus, Snyder's friend wrote it up as a pull hypothesis. Snyder couldn't remember the exact details, but it was roughly this: physical therapists were trying to cut a specific cost on their P&L, it was unavoidable for particular reasons, and hiring a consultant wasn't good enough because it was too expensive or too slow. The step Snyder considers crucial came next. The friend showed it to the therapist and asked, "Is this you?" The answer was yes. He asked whether they would buy something that helped with it, and they said yes. Then he said he needed to talk to five more physical therapists to make sure it repeated. It did, which confirmed he wasn't building a product for just one person.
Snyder recommends two slides for this. The first restates the pull hypothesis in plain language, without showing the framework itself, which he says nobody would understand: "Here's what I hear. You're trying to do X right now because of Y, and you've considered this, but it's not good enough for this reason. Do I have that roughly right?" The second gives a conceptual overview of how you might help, for example a way to cut that line item faster than a consultant. On the first slide you're hoping for "Oh my god, yes." On the second, you're hoping for "How does it work? How do we move forward?"
The signal that counts is that they actually try to buy. Snyder told a story about a friend who had pivoted around for a while and knew he'd found pull when a pharma executive said, before any product existed, "If you can do that, I will pay you right now." What doesn't count is what he calls "leaned out enthusiasm": "tell me more," "we'll think about it," "could you send more information so our team can review." In his view, anything short of "how do we move forward" isn't worth your "life force." He calls the right response a "pull-shaped action." A remark like "I could totally see us using this in Q4" pushes the decision into the future instead of pulling the product toward the buyer.
Solving your own problem, consumer products, and the Hail Mary
Snyder's position on "solve your own problem" is that it works when the problem is one you would have paid someone to solve. His example is Emily Choi-Greene of Clearly AI, who worked in security engineering at AWS, found something there she would have paid for, and found that nobody offered it. The advice falls flat when you've merely run into something you think should exist but wouldn't have paid for yourself. He admits he has built things like that.
He works mostly in B2B but said he's been surprised by how many consumer founders use the framework. Someone sent him the story of Spanx, whose founder sold one-on-one, watched how people reacted, and worked out the pieces of the product that way. Lenny added that the Spanx origin was itself a case of solving one's own problem.
Snyder then introduced the "Hail Mary." Most conversations won't produce instant enthusiasm. When one turns lukewarm, he asks an open-ended question: is there anything on your to-do list that you'd pay me, or anyone, to take off your plate right now? He says he has seen several startups pivot and take off from this question. One was trying to sell an applicant tracking system to governments. A contact found it only mildly interesting, but in response to the Hail Mary said what they would actually pay for was help with job descriptions. That became the company's first contract, and Snyder says it has grown very fast since.
He also uses the Hail Mary as a way to reframe sales. As a "mega introvert and overthinker," he found selling stressful because it felt like he had to convince people. Treating a call as simply checking whether someone needs help with something they're stuck on, and being fine if they don't, changed how he approaches sales.
Traps: building first and design partners
Asked about common traps at the idea stage, Snyder named two. The first is feeling you have to build the product before showing it, because it isn't "ready for prime time" or people need to see it to get it. He said AI might let founders get that out of their system in a couple of weeks rather than months, but the principle is to "face the cold wind of reality as soon as possible" and not delay the conversations where you can find pull.
The second is design partners, which he knows goes against standard advice. He allows that they might help in some context but says he has yet to see it. What he sees almost every time is a partner who "buys into your vision," gives lots of feedback, and never buys. The feedback turns out to be the partner "playing Steve Jobs" and helping a startup, rather than someone trying to get something done. People with a truly important project, he argues, don't want to be design partners. They just want the thing done.
Getting the first conversations: "founder magic" outreach
Snyder's target is two to three conversations a day with potential customers. Setting aside warm intros, he focused on cold outreach through LinkedIn or email. He dismisses the usual templates ("Do you have XYZ pain points? Would you like to buy our game-changing solution?") as only producing replies like "leave me alone."
What he recommends instead is what he calls "founder magic" outreach, which amounts to "you're interesting, I'm interesting, let's chat." One startup he helped sent something like: "Snoop Dogg invested in us and I thought you'd find it interesting too. Would you be open to chat?" Other versions he's seen include "I dropped out of my PhD and I'm now working on something for content marketers" and "I was Sam Altman's chief of staff." The logic is that pull already exists on the prospect's to-do list, so the message doesn't need to sell anything. It only needs to get the meeting. He cautioned that it has to fit the audience. An HVAC company won't care about Sam Altman's chief of staff, but a line like "I worked at my family's plumbing company in high school" might land. The messages are short, a sentence or two.
He hasn't seen AI personalization work at this stage. It usually tells recipients something they already know about themselves and reads like Claude wrote it. He also doesn't think personalization matters much here. Something like "I'm going to X conference, would you be open to chat?" can be enough.
He usually starts on LinkedIn, because the people he and Lenny tend to talk to have interesting profiles that do much of the work. His benchmarks: add 100 to 150 people per week (around 20 a day) and message them when they accept. Roughly 30–40% should accept, 30–50% of those should reply, and most of the replies should agree to talk. Low acceptance may point to your profile, since people look at you and decide you aren't someone to accept. If acceptance is fine but replies are low, the message is the problem.
Running the first sales call
Snyder splits the call into two parts: pull discovery, then a conceptual pitch of how you might help. His premise is that if the person has pull, they'll convince you to let them buy, so he goes in "leaned back" and curious, not "wired up" to persuade.
His opening is specific. After thanking them, he asks: "I'm sure you get a bunch of people reaching out to you. Why did you take the call with me today?" Ideally they lay out the whole pull framework in their answer ("you mentioned AI agents and I've been thinking about this..."), and he follows up from there. More often they say something like "I don't know, you reached out to me." Either way, he uses whatever they said to propose an agenda and gets their agreement. Then he asks permission: "Before we get to those items on our agenda, do you mind if I ask you a few questions to better understand your context?" Earning the right to ask questions keeps it from feeling like an interrogation. If it feels like one, he says, they won't tell you anything.
His discovery questions carry the framework inside them, for example: "Is there anything as it relates to your QA process that you're trying to do but you've been unable to do with your existing tools, methods, team?" A prospect might answer that they've been trying to automate end-to-end testing and their tools can't do it. Some founders, he says, keep the framework open in a doc and fill it in live. Then come the harder questions: is there a reason this has to happen now? Have you looked at other options, and are they good enough? He admits the last one is the scariest, because the answer may be "we can do it ourselves." But that answer keeps you from pushing a product the market doesn't want. He joked that there's a reason he looks 60 at 35.
Once pull has surfaced, he says the pitch should be small and simple, not a grand product vision or a theory of the problem. Using a hypothetical person who wants a website but finds point-and-click builders too much effort, the pitch is just: "It sounds like you're looking for something to make a website without all the hassle. Is that roughly it?" If they start pulling more information out of you, you're onto something.
Practical details: calls are almost always booked for 30 minutes, because in his experience shorter blocks get overlooked and people don't show. Demos are uncertain. Very early on there may be nothing to show, and later a very short demo might fit into a first call. Lenny noted that Jen Abel advises holding the demo back, and Snyder agreed that applies to enterprise sales rather than this early hypothesis-testing stage. A call is a success if you come away with either a filled-in pull framework or a clear understanding of why this person doesn't have pull.
How many calls before moving on
Snyder has no hard rule, but suggests checking in after about five calls. If all five people were leaned back and you learned nothing, something is wrong. He has watched people do hundreds of calls without that reflection. In one recent case, a startup did five calls into banking and "felt nothing." One contact suggested defense companies instead. The team knew nothing about defense, but in their first defense conversation the person reacted with something like "Holy, are you serious?", and they revised their hypothesis. His summary of the stance is that you're selling to learn, not to push. If they don't try to buy, you've learned something. If they do, see whether it repeats. Feeling like you're pushing or convincing is itself a red flag.
Is "10x better" the right bar? Linear versus Jira
Lenny raised the common claim that a product must be 10 times better than the alternatives. Snyder said the idea "doesn't quite register" for him. Using Jump again, he argued that if generic notetakers don't get the job done and your product does, you're "infinitely better," because you unblock something. The real question is how stuck people are and how they respond when you show up.
Lenny asked about Linear, which, as he understands it, often wins over Jira on the strength of a better-crafted experience. Snyder said that under his framework, it would have to be true that some kind of person doing issue tracking was blocked by Jira's experience in a way that made Linear's better experience relevant. He then described his own mistake with this analogy. He tried bringing much better UX into HR software and found the experience didn't matter to the buyer. They didn't care that their systems looked like they still ran on COBOL, so the project element was missing. He later gave a sharper version: you could offer him a printer 100 times better for his house and he wouldn't buy it, because he isn't blocked.
On whether stronger pull means faster growth, Snyder said he's seen many startups grow extremely quickly because they found "pockets of pull." With AI products, prospects sometimes see a pitch and buy almost instantly. He described watching an enterprise deal close in about two weeks, compared with the 18 months he was used to.
Closing the deal, services-shaped offerings, and pricing
After a call that surfaces pull, Snyder recommends coming back with a concept and a plan. He returned to the pharma founder, who had thrown a Hail Mary on an intro call. The executive described how slow and poor their current market research was. With no slides, the founder summarized the need, confirmed it, and offered to come back in a couple of days with a mockup. He vibe-coded a rough layout, got feedback, and then asked whether there was anything else the executive needed to know to decide whether to bring it into the organization. The answer was, essentially, "What's the price?"
For pricing, Snyder says the framework sets the bounds. You can look at the value of getting the project done, or at the cost of the alternatives from the Ls. If the pharma company was paying consultants about $50,000 a year, proposing the same price gives the customer an intuitive frame. Early on, he says he cares more about willingness to transact than willingness to pay. When a founder does want the largest possible first deal, for instance one company wanted a big number before demo day, he suggests presenting a range drawn from what others have done instead of a direct proposal. Something like: "Sometimes it's been a small project for 80,000, other times up to a million, a lot of people wind up in the middle. How are you thinking about it?" The idea is to have both sides look at an example together and let the buyer react to it.
Beyond fit, closing is project management. For small deals the CEO may simply say "send me the Stripe link and we'll schedule onboarding." For enterprise deals, after the champion decides they want it, there may be many demos and committee reviews, and he pointed to Lenny's episodes with Jen Abel for that part. His main tactic is to ask the champion when the project needs to show results. If the answer is Q1 next year, you work backward to lay out every step required to be live by then, and that date becomes the forcing function for the whole process.
He's firmly against offering free design partnerships at this point. It turns "I need to solve this right now" into "now I'm helping you build your product," which he sees as a negative signal to people who have pull and a positive one to people who don't. He's equally against proactively offering pilots or proofs of concept, though if a buyer says that's how their organization buys, that's fine. What he does endorse is selling something more service-shaped when the platform isn't ready, such as "an AI product manager that does XYZ, delivered by us for now while it works behind the scenes." This sets realistic expectations while you validate pull and learn what to build, delivering through a mix of manual and automated work. He acknowledged that you can get stuck running a services business, but said "everything has downsides."
When it doesn't work: revising the hypothesis and "goblin mode"
Snyder says he has seen the first hypothesis prove right "maybe once or twice," and that getting it right the first time makes you feel like a hero. Usually the people you expected to be weird not to buy turn out to be people who would be weird to buy. His advice is to review the calls, ask whether anyone actually had pull, write a new hypothesis, and run it again. If you're badly off track, a few Hail Mary questions can point you somewhere new.
When that isn't enough, he describes "goblin mode," which he compares to a dog getting the zoomies. It means going all out and doing somewhat unhealthy, crazy things to find out who will buy something from you right now, then building a hypothesis from that. One friend went to a conference, scheduled 20 meetings, and effectively asked people to tell him what to build. Another example is getting on a plane tonight because a conference in Europe has the customers you can't otherwise reach. He calls it "break glass in case of emergency." Some founders work this way all the time, while he can only manage it occasionally. His most unusual example was Teero, a dental hygienist staffing company, whose founder's parents went door to door to dental offices to get people to talk to him, and it worked.
He justifies the intensity with the cost of staying stuck. Being in "this pain cave of zero to one" is, in his words, the worst time of your life, and there's no reason to prolong it.
After the sale: find the moment when churning becomes weird
Snyder said he used to have no model for what happens after a sale. He felt like "the dog who caught the car," throwing software over the fence. He has since learned the hard way that retention matters a great deal and isn't obvious. His current model is that every customer is guaranteed to churn until they reach some point X, after which they'd be weird to churn. All delivery work is about identifying X and designing "a bullet train" that gets every customer there.
X is almost never "they're using the product" or "they have a high NPS." He compared it to the leading-indicator idea associated with Slack, where a team that sends a certain number of messages in its first stretch is unlikely to leave. At his own startup, which sold retention software to restaurants, the moment came when a restaurant received, within its first two weeks, a notification that an employee was likely to quit and was able to prevent it. Restaurants would "go insane" and tell their friends, so the company designed onboarding around that moment. His advice is not to send a login and pray, but to deliver to the first customers yourself and keep asking whether they're about to churn until you find the point where they can't live without it.
If 90% or more of customers are churning, he says it is "unacceptable" not to find out why, while acknowledging it feels terrible ("you wake up at 4 a.m. every morning just sweating"). The cause is often a mix of what you're doing and who the customers are. One horizontal AI workflows startup found that one or two kinds of customers kept using it while everyone else left. Freight forwarders were using it for one specific workflow, and the company pivoted entirely to them, going from a low-priced horizontal product with heavy churn to a premium product for freight forwarders.
Lenny added that uncertainty never fully goes away. He recalled the Databricks founder telling him that even at $100 million in ARR, they weren't sure the business would last.
The case study factory
Snyder calls this the most important idea of all, while admitting people's "eyes glaze over" when he explains it and he hasn't yet found a good way to present it. His point is that a founder needs a conceptual model of the startup in order to grow it as fast as possible.
The model goes like this. When you find someone with pull and give them something they grab, the story ("they were trying to do X, their options weren't good enough because of Y, we offered Z that unblocked them") is a case study. The founder's job is not to produce a hundred different case studies, which doesn't scale, but to find one where the customer says "hell yes" before and after buying, and repeat it as many times as possible. In his framing, a startup is "a thing that repeats one case study infinite times," and everything else is building a factory to do that.
The factory has three stages: pipeline (getting people to talk to you), sales (turning prospects into customers), and delivery (getting customers to the point where churning would be weird). Borrowing the theory of constraints from manufacturing, he suggests finding the single bottleneck, whether that's not enough pipeline or a low close rate, and treating it as the only thing that matters until it's fixed, then moving to the next one. The case study also becomes a sales tool. You can show it to prospects to ask whether it's relevant to them, and you can disqualify people who don't match because serving them would be a lot of work and probably a poor fit. Lenny compared it to working backward from the press release, applied to sales. Snyder's line was, "We don't make software here. We make case studies." He added that if you have the pull framework filled out, writing the case study is easy.
"Hell yes customers," in his terms, are people who pull the product out of your hands before buying and use it "as if it is addictive" afterward, so the whole process is driven by their pull rather than your push. The job then is to find more people who are essentially clones of them.
Inside established companies
Snyder said the approach also applies to larger companies. He is helping a couple of companies launch second products, where the founders are "running it back," taking the approach to existing customers for upsells and selling new features before building them. A product leader at another company, which he didn't name, told him that every idea that had worked there came from sales calls where customers asked whether the product could also do some other thing for them. The ideas they had whiteboarded never worked. He said founders ideally do this selling. When that isn't possible, non-founders doing zero-to-one work should focus on selling and learning through selling, because "there's a lot of ways to get lost in zero to one."
Closing thoughts: a metal detector, not a spoon
Asked what he most wanted listeners to take away, Snyder stressed simplicity: write a pull hypothesis, show it to people, see if they pull. He said founders tend to overcomplicate things and try to solve every variable in their heads in advance, and that thinking less and selling more will get you there. His metaphor is that the framework is a metal detector on a beach. You might not find metal where you're looking, but at least you aren't searching the sand with a spoon.
In the lightning round he recommended Christopher Alexander's four-volume The Nature of Order. His favorite films, rewatched often, are the most recent Pride and Prejudice and Penguins of Madagascar. He mentioned using Muse, saying that if it works for him it can work for anyone. His motto is "life is what you make of it." Asked about "tarpit ideas," the term Lenny attributed to former YC partner Dalton Caldwell, Snyder named going after a space with a clear winner without any theory of being different. His example was a founder seeing a bootstrapped sales automation tool grow fast and building nearly the same thing. Unless you've found a kind of customer who is still blocked and are building something different for them, he said, those ideas almost always fail, and the founder ends up feeling like they're going crazy because it worked for the other company.
He described the framework as still in development. He feels he's only "scratching the surface" and expects this to be his work for the next 10 to 20 years, and he asked listeners who find ways to improve it to tell him.
The theory behind a sales call is if you have pull, you're going to rip the thing out of my hands. So I have a very specific structure of a sales call for getting into discovery and then transitioning out of discovery.
How can people use this framework to help them come up with ideas that are more likely to actually be successful?
One of the main mistakes people make is thinking that pull is a thing that a company has. It's a thing a person has. You're not selling to SpaceX. You're selling to the head of legal at SpaceX who has a project on her to-do list that they can't do themselves.
You have this idea of the Hail Mary approach. You're talking with people and they're like, "Oh my gosh, this is exactly what I need."
A lot of the time that's not going to happen. That's also an opportunity to what I call throw the Hail Mary, which is, "Is there anything on your to-do list that you would pay me to do right now?" We're seeing if they try to buy. If they don't, cool. We've learned something. We can keep iterating from there. If they do, okay, great. Now we might have something. Let's see if it repeats.
Say you actually found something, something that is pulling and people are like, "I need this now." What comes next?
Retention is super important and it's not obvious. And so what I recommend is...
Rob, thank you so much for being here and welcome to the podcast.
Hello. Thank you.
You are the author of The Power of Pull. I've got the book right here. You have a newsletter called The Physics of Startups. I don't think I told you this, but the way I learned of you is a very unusual way. I have this Slack community for my paid subscribers. And in the Slack, just in the past month, two different people started threads where they're like, "Lenny, you need to get Rob on the podcast. I have been reading his book and it's extremely useful to what I've been doing." And these are some founders, some product people, and I'm just like, "Well, who is this guy? I got to find out." And so I reached out and that's how this came to be.
Essentially, what you've written in this book and what you do in your newsletter is you've basically created a very pragmatic guide to finding product-market fit and basically going from zero to one and then one beyond. And to give people a reason to believe you, other than what I've already said about people saying how useful this has been, I know you've helped something like 50 different startups get from zero to over a million in ARR. Speak to just where this insight and advice comes from.
Yes. I did not expect to be writing a book or doing anything like this. I got punched in the face as a founder trying to go zero to one and then randomly figured it out. And then a bunch of my friends started pulling me in to help their startups go zero to one and just got obsessed with this stage. It's super interesting, super weird. I feel like there's not a lot of good stuff written about it, and so I've just gotten strangely obsessed with doing zero to one as many times as possible.
I love that. I'm going to read a couple quotes actually from my community to reinforce the things you just said, of what people have been saying about what you've done. And this is really unusual. Even though you just said there's not a lot, there is a lot of content for founders. Here's how to find an idea. Here's how to find product-market fit. So it's a big signal to me if people are saying this is in particular extremely useful to them, more than anything else out there.
So a few things that people told me in my community. One: "I remember reading the first chapter of his book and feeling the weight lifted off my shoulders that I'm not some silly, clueless outlier and that this is a normal part of the process."
Another: "Besides all the very tactical stuff, personally, I found him normalizing just how painful, lonely, weird it is to go through finding product-market fit."
Finally: "We ran into the same zero-to-one traps Rob describes, building based on what prospects said they wanted rather than what actually got them to say yes."
Wow. You have very nice people in your community.
That's true.
That's super kind.
That's true. That's true. All right. Anyway, so there you go. Just to give people, "Okay, let's pay attention." Okay, give us an overview of the PULL framework.
The PULL framework describes a person who will pull your product out of your hands, someone who's weird not to buy your product. So we know what pull feels like. It's the thing that's written about with startups, the startups that take off. Your newsletter had insane pull. You grew like that, right? And everybody wants that. And most of us are in the situation where it feels like we are pushing. We're trying to convince people to care or convince them to buy, and it's kind of maybe working.
And so pull describes a person who would be weird not to buy. The question is just what causes somebody to pull a product out of your hands. And for that, I found a lot of the traditional descriptions of things, like when I was a founder, I went out and found hair-on-fire pain points, big problems, offered a differentiated solution that provided real value. We had design partners using our product every single day. And so I was like, "Okay, cool. Check, check. This thing's going to the moon." And then tried to sell it and just got smashed into a wall for two years, pivoting around aimlessly, having no clue why.
And then we randomly pivoted. It took off and I realized that wasn't the thing that causes people to pull a product out of your hands. It's not pain points or value props or things like that, because I realized that people can basically just say, "Yeah, great. It's great that your product solves our pain points, problems, offers a ton of value, but I'm not going to drop my priorities to buy it."
And so I realized it's about priorities, a certain kind of priority where somebody's trying to do something. They got a project on their to-do list, trying to do it right now, but they can't do it with their existing tools, methods, or options. In that case, they're like a coiled spring, right? Trying to do something, stuck, and you show up and just offer something that gets them unstuck, that helps them get that priority done. That's when they rip it out of your hands. And the PULL framework is just an acronym for that.
This episode is brought to you by our season's presenting sponsor, WorkOS. What do OpenAI, Anthropic, Cursor, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by WorkOS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by large companies. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS.
Literally every startup that I'm an investor in that starts to expand upmarket ends up working with WorkOS. And that's because they are the best. Whether you are a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise-ready and unblocking growth. It's essentially Stripe for enterprise features. Visit workos.com to get started or just hit up their Slack, where they have actual engineers waiting to answer your questions. WorkOS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to workos.com to make your app enterprise-ready today.
Let's talk through the acronym of PULL because that goes deeper into this idea.
So, acronym PULL. There's a P, project. They have a project on their to-do list. You can think of a project like a job to be done. Bob Moesta, you've had him on. He's amazing. Project is not like, "I want to buy recruitment software." It's, "I want to hire more employees," kind of thing.
U, the second one, is unavoidable. This is a thing that I have to do right now. Why now? Why not later? There's some reason why you have to do it now.
First L is list of options I consider for doing the project. Could be, again, hiring somebody. Could be having our existing team do it. Could be using the tools I already have or the tools out on the market. And the second L is limitations. Why are those options not good enough for getting my project done?
Amazing. So the first two are really important there, and it's interesting, the second two feel less important. I'm curious why they're so important. So the first two are essentially like, "I have a problem. I need to solve a job to be done, and this is an urgent problem." So in a sense, this is the hair-on-fire problem very concretely defined. Here's what hair on fire looks like: I have a to-do my boss is waiting for me to do, and it needs to happen now. It's not just a general thing that I need to solve.
Yes.
Why are the second two so important? This idea of other options and why those are not working.
You can imagine a case where a product team, for example, they have a really important thing that has been mandated down. They have a really important feature they need to build or something. That's an unavoidable project on their to-do list, but they're going to do it themselves. So they don't need anything. They won't buy anything unless their existing options aren't good enough.
And so it really, really is important that it's not just, "I'm trying to do something and I can do it myself, or I can do it with a category leader. I can do it with whatever tool is out there." It has to be something where my existing options are not good enough. So I am stuck. I'm blocked.
Let's do an example to make this even more real. What's a product or a company that gives us a sense of what I basically use this as a template? It's like a Mad Libs-y thing where it's just like PULL and you fill it out. So give us an example.
My friends are at a company called Jump, which is an AI notetaker for financial advisors. Very interesting space. They did the same thing I did, by the way. They spent 18 months just hitting their head against the wall, and then finally found pull, tried to sell, and figured it out.
But what they found was that financial advisors have a project on their to-do list that is to minimize the amount of time they spend taking notes for client meetings and putting those notes into their CRM. It's a project on their to-do list. The U, the unavoidable, is if they don't take notes and put them into their CRM, they could go to jail. So they have to take those notes, but when they're taking the notes, they don't want to be doing that. And so they want to minimize the amount of time because they don't enjoy doing that. It's just not a fun thing.
So the list of options they considered to minimize the amount of time were a generic AI notetaker. There's a list of all of those out there, but those AI notetakers were not good enough because they didn't integrate with the financial advisor CRM, and it wasn't clear if they were compliant with the SEC's regulations on this. And so there's a list of options they really couldn't use. And so when Jump showed up and found that pull, people ripped the product out of their hands. I think one person literally said, "This must be how Alexander Graham Bell felt when he invented the telephone." That's a weird thing to say about a product for financial advisors.
Amazing. That's a great testimonial to stick on their website.
Yeah.
Okay. What would be a bad version of this? What would it look like if there wasn't pull?
Fun conversation with the Jump team. They said, "Okay, cool. Financial advisors. They have this project. You know who else meets with clients all the time? Insurance agents. So maybe we just go and talk to them." And it turns out they also have the project on their to-do list of minimizing the amount of time they spend taking meeting notes. But the U isn't there because they don't have to. They're not required to put meeting notes into their CRM. So their existing options, the first L, are not taking meeting notes, which they were already doing. And so you can see the framework kind of doesn't fill out for them, or the force isn't there. They're fine.
That unavoidable piece, I see why that is so important. And this is an example. Basically you need all four here.
Yes.
So that's a good lesson here, is all four need to exist for real pull. In the first example, that to-do to me doesn't feel like it's a to-do that you just wrote down. It's kind of this general to-do, just generally save time. Is that an okay P for a project, or was this specifically on every financial advisor's to-do list?
So it was a thing that I wouldn't say it's actually something they wrote down on their to-do list, but it was a thing they were doing all the time. It was a part of their workflow, and while they were doing it, they were trying not to do it. I think there's the action I'm doing right now on my calendar, and then the project is my intention while I'm doing it. And so while I'm doing it, the project on my mental to-do list was, "Spend the least amount of time doing this annoying thing."
Got it. And so if a founder or product team is listening to this and they're struggling with their product, it's probably one of these four is not there.
Yeah. You need all four at once. If you find P without U and the L's, so you find something that somebody's trying to do, kind of, but they're not actually trying to do it right now and their existing options aren't good enough, what they'll do is they'll complain and they won't buy. If they have P and U, but their L's are good enough, they're going to say, "Yeah, that's exactly what we're doing right now and working with Claude Code on it. We're going to figure it out."
Something along these lines that you talk about is that this pull exists. It's this thing that's already there, and you're just kind of this hunter looking for the pull and discovering it. Talk a bit about that.
This was super liberating when I realized this because I always thought that I was incompetent. I wasn't good at convincing the market to want my product. And it was from that perspective of, "Okay, I'm building something that's really valuable and people aren't buying. How do I convince them to want it, to buy?" And it turns out this pull, this project on their to-do list, exists before and independent of me, which means I just have to go out there and find it. I don't have to convince people to have pull. I haven't quite figured out how to do that, but I think it's very, very hard to do, if it's possible at all.
That feels very familiar, just trying to convince people, "Look, this is so great. It's going to solve so many of your problems." And I love how very specific and concrete it makes all of these general pieces of advice around finding product-market fit, coming up with ideas. It just tells you exactly, here's what it looks like.
Something else you talk about, you mentioned this earlier, this idea that it needs to feel weird for them not to buy it. That's the sign that this is right, that it's weird. Why aren't you buying this? Talk a bit about that.
Most people most of the time are fine. It would be weird if they bought our product given what's on their to-do list, given what they have, given their options. So it'd be weird if they bought. But a person with pull is weird not to buy. They should actually pull the product out of your hands because they are like that coiled spring. And so if you talk to somebody who has pull, the conversation should basically go like, "Wait a second, you can do what?"
Okay, how do we get started? Does the product exist yet? How do we get on board? Where basically every other conversation you have with somebody who doesn't have pull can have anything other than that. They can be enthusiastic and nice and say, "Wow, that's amazing. That's super interesting. That's totally the future of our industry. Wow, I can see how that would save us so much money," but they're not saying, "I need this right now." And that's how you know they actually have pull.
Those conversations sound very familiar. Okay. So before we get into the whole journey of the startup process and how you can use this framework in that journey, anything else around just the general idea of the pull framework that's important to share?
One of the main mistakes people make is thinking that pull is a thing that a company has. It's a thing a person has. Even if you're selling enterprise software, you're selling not to the company. You're not selling to SpaceX. You're selling to, just going to your Jen Abel conversation, you're selling to the head of legal at SpaceX who has a project on her to-do list that they can't do themselves.
That is really useful. So it's not like SpaceX needs this. It's like, say, Jen needs this. And you're saying that that's often a mistake people make. They don't think about the specific person with this need.
Yeah. It's super common to say we sell to mid-market private equity companies. It's like, you don't. You sell to a partner or an operating partner in there who's specifically trying to do X, Y, and Z.
Awesome. Okay. So through the lens of this framework, let's go through the key moments of an early-stage startup finding product-market fit. I want to talk about coming up with an idea, getting your first sales call, closing your first deal, and then scaling from there. So let's start with coming up with an idea. How can people use this framework to help them come up with ideas that are more likely to actually be successful?
As a founder, I have a notebook of ideas that are all like, "What if we built an API for APIs?" They're all these product ideas, and the product ideas all sound unhinged. And so I can never tell between product ideas what's a good idea and what's a bad idea. Well, fortunately, the pull framework is a thing that's upstream of your product idea that says, "I believe there is a person who is trying to do X right now," who basically, weird not to buy. And so what I found to be helpful is to use the pull framework to stake out a claim and say, "I believe, for whatever idea I have, I believe this specific person is stuck. And so I'm going to go and talk to them and see, do they try to buy from me even before we have a product?"
And so for me, the idea of the pull framework is to come up with a hypothesis of who has pull and then go and test that. And then the question becomes, okay, how do you find this pull idea, this pull hypothesis? What do you do for that? I have some fairly strong opinions on this. I don't think we take this stage seriously enough. If your life depended on it, would you be doing 10 customer interviews for 30 minutes on Zoom? No. You would go all out. You would go in person. And I have a couple stories of friends who have done crazy things to go and do the job with the potential customer to feel it firsthand, to find that pull firsthand. And they've either built something that they would buy themselves, or they've embedded with people to find that moment when someone is trying to do something and stuck.
Amazing. So the advice here is don't sit around and brainstorm. Don't just look for big markets and figure out where there might be something massive. What you're saying here is almost this lens of, if your life depended on it, how would you find a problem that is likely to have real pull? And what I'm hearing here is get in the weeds, get your hands dirty, get in the way. This reminds me of a quote. Nan, who is the head of product at Linear, now he just went to OpenAI, described what he looks for when he's trying to find opportunities. He describes, "I want to feel the pain of the person the same way they feel the pain."
Yeah. Yeah.
And what you're saying is the way to do that is get in there with people building the thing. Is there an example of doing that?
Yeah. So a friend from school, he had no idea what he wanted to build. He had no product idea. He didn't have my notebook. He didn't have any of that. He just said, "I like serving small businesses. I like small business. I'd like to just find somebody I like to serve, and I'll figure out the idea from that." And so he wrote out a list of industries that he thought might be interesting. And then he went and shadowed them and worked with them, rode along with them for days at a time.
And so he started with solar panel installers, and he hated them and they hated him. So he moved on to the next one. He eventually worked his way to independent physical therapists, and he went and spent days with them. He loved them. They loved him. And it was like, okay, cool. What is the pull here? What should I do? And so he watched over their shoulder days on end. He even tried to buy a physical therapy franchise, was able to see the P&L and was actually considering it. And in that process, he came up with something like, "Wait a second, it looks like you're trying to do X and are stuck there." And so firsthand experience is what you should do there.
Awesome. So live it yourself and live it. And is the reason you need to do that, is it because people would have discovered it if it was easy? Basically somebody else would have found the idea. Why do you think that is so important, approaching it this way?
Yeah, I'll give two reasons. One is these things don't really emerge from a whiteboard. It would be weird if his idea that he eventually wound up finding came to him from brainstorming. Think of how many different ideas he could have come up with. And it was something he saw only by observing, where it's unclear that that would have emerged in an interview either. But I'd say the second thing is more of a philosophical thing, which is you're building a company to serve this kind of person. The whole point of building a company is to serve somebody, to help them do something. And so if you don't have firsthand experience, how are you going to make the thousands of decisions it takes to actually build something that serves them?
And is the idea, once you have this insight, say with this physical therapy company, you write it out through the pull framework to kind of pressure—is that, you call it the pull hypothesis? Is that right?
Yep.
So talk about that. Say you have this insight, and I'm curious what he actually found with his physical therapy business and how to start to think about it through the pull framework.
Yeah. So you then take that and say, okay, this is the kind of idea. I believe this kind of person, this physical therapist, is trying to cut some specific cost on their P&L. I can't actually remember what it was. Unavoidable for XYZ reasons, and their existing options of getting a consultant to come in and do this wasn't good enough for some specific reason. It was too expensive. It was too slow. Wrote out that pull hypothesis, and then what he did next was super important, which was he showed it to that person, said, "Is this you?" Person said, "Oh my God, yeah, that's exactly the thing." Said, "Okay, great. Would you buy something if I helped you get this done?" "Yeah, totally." "Okay, great." And then he said, "I need to go talk to five other physical therapists and just make sure this repeats."
And then he did that, and they also pulled, which was the really important thing to make sure he wasn't just building a product for one person.
What is it that he showed these companies? The four bullet points with here's the project, here's why it's unavoidable, or is it something else?
Yeah. So I actually recommend having two slides. One slide is basically the pull framework. You don't have to show them the pull framework because no one's going to understand it. You can just say, "Here's what I hear. You're trying to do X right now because of Y, and you've considered this, but it's not good enough for this reason." You say, "Do I have that roughly right?" And then the second slide is a conceptual overview of how I can help. "So it sounds like you're looking for a way to cut this line item that's faster than a consultant. We could offer that for XYZ. Does that kind of fit what you're looking for?" And you're looking for, the first slide, them to say, "Oh my God, yes." And the second slide, "Yeah, how does it work? How exactly do we move forward?"
What I love about your stuff is it's very plug-and-play, pragmatic. So we'll actually show a slide of the actual template you have people use to fill this out. So the phrasing, I'll read it from this slide too. This is the project in your to-do list, and it's unavoidable right now because of this, and options you looked into are this, and they're lacking for this reason. Amazing. I love this. So the idea is you have this little slide that you just create to run by people, and the idea is this is the hypothesis. And what does it look like when there's pull once you show it to them? Is it like they're ready to send you money? Is it their pupils dilate? What do you look for?
Yeah, you look for a couple things. The thing that really, really matters is that they actually try to buy. They say, "Okay, cool. How do we get started?" And they will do that. I have a friend who was selling into—he pivoted around for a while, but he knew he found pull when someone, an exec in pharma, before he had a product, said, "If you can do that, I will pay you right now." So okay, that's the signal you are looking for. What you're looking for as well is they're leaning in, "Wait a second, you can do what?"
What you're not looking for is leaned-out enthusiasm. "Okay, well, tell me more. We'll think about it. Could you send more information so our team can review that?" Any of those kinds of things. Anything that is not like, "Okay, how do we actually move forward on this?" is just not worth your life force going after.
It's interesting how much body language and just the physical experience of getting excited about an idea is a sign that it is good. I just had Josh Woodward on the podcast, head of Google Labs, and he's similarly like, you see a twinkle in their eyes, and their eyes just light up. And it's so interesting that that's a sign of pull.
Yeah. What you're seeing is, is it weird for them not to buy right now? Are they behaving as if it's weird for them not to buy?
There's the "I will buy this" idea, they say they will buy it, versus a sign they will actually buy it. Is it the body language? How do you know they're serious about it?
So I call it a pull-shaped action. Not a good term, but a pull-shaped action is like, "I need this right now. I am pulling it out of you. How do we move forward right now?" It is not like, "Oh, I could totally see us using this in Q4," kind of thing. That's not pulling towards me. That's pushing out into the future.
Like the urgency of, "I need this now." There's always this advice of solve your own problem, which is different from what you described. Is that a path you recommend, or would you recommend against that?
So a friend, Emily at a company called Clearly AI, she was in security engineering at AWS, and she found something there that she would have paid somebody to solve, but there was nobody out there. And so in that case, it's solve your own problem. Yes, 100%. Where the solve your own problem falls kind of flat a lot of times is it's a thing that you wouldn't have paid somebody to do for you, but you just think should exist, right? And so you have to be honest with yourself. I have done things where I've built things that, "Oh, I think the world needs this. I ran into this problem," but if I looked myself in the mirror, I wouldn't have said, "Yeah, I'd buy this right now."
Along those lines, is this advice mostly for B2B SaaS software, or is this applicable to, say, a consumer app?
So I am mostly in the B2B space, but I have seen quite a few people. I've been kind of surprised that a lot of people from the consumer space have used this as well. And someone sent me the story of Spanx, which was basically she did the same thing of selling one-on-one with people, seeing how they reacted to figure out all the different pieces of what became Spanx.
Yeah. And she solved her own problem, famously.
Yes. Just tore off her pantyhose. I think that's the story. Just because she needed it now.
I think it was like, yeah, she's going to an event. So that's a cool example. We're going to talk more about this, but you have this idea of the Hail Mary approach. Talk about that.
So the Hail Mary, we've been talking about the happy path here. You find something, you're talking with people, and they're like, "Oh my gosh, yeah, this is exactly what I need." A lot of the time that's not going to happen. You're going to get that kind of lukewarm feel. And so what I've tended to find is that's also an opportunity to what I call throw the Hail Mary, which is, "Okay, this doesn't seem to be a thing. Is there anything on your to-do list that you would pay me to do right now, that you would pay somebody to take off your plate?" And that's just an open-ended Hail Mary.
I've actually seen quite a few startups totally pivot and take off from the Hail Mary, which has been really interesting. There's one startup, they were trying to sell an applicant tracking system into governments, and they had a call with somebody, and the person was like, "Yeah, that's kind of interesting." But after the Hail Mary question, "Yeah, what I'd actually pay you to solve is this job description thing right now." And that became their first contract. That became their first customer, and they've grown super fast since then.
That's awesome. So the advice here is just sometimes feel free to just ask, "What problem can we solve for you?"
Yeah. And that leads to how to think about sales. I'll just give a little, and we can dig into this if it's interesting, but I always was kind of nervous to sell as a mega introvert and overthinker. It just feels like a lot of pressure. I need to convince you to buy. And so that question feels uncomfortable. But if you reframe it in your own head of, "I'm just seeing if they need help with anything that they are stuck on. And if they don't, that's fine. But if they do, cool. We can explore if I can help," then it kind of changes your orientation towards sales.
I am in the same boat as you, and that's a really nice way of thinking about it. I'm just trying to solve someone's problem. Why is it so hard? Before we get to the next step, which is getting your first sales call, basically finding someone to talk to that you don't already know, are there any anti-patterns or signals or traps people fall into when they're coming up with ideas?
Yeah, they're infinite, but the main ones that I have seen that are really, really brutal are feeling like you need to build it yourself first. So you come up with an idea and you're like, "I don't think this is ready for prime time," or, "I think people have to see it to get it," and then
You go heads down and build it. Now with AI, you can get that out of your system in hopefully a couple weeks instead of months or not. But you want to face the cold wind of reality as soon as possible. And so don't delay the customer conversations where you can actually find pull.
You're also not a fan of design partners, which is okay. Say more, because this is typically very standard advice, to find design partners.
Yeah. I don't know, maybe in some context it's helpful. I have yet to see it be helpful. What I've seen basically every single time I've seen somebody with a design partner is that you recruit a design partner who, quote unquote, buys into your vision for the product, and they give a bunch of feedback and never buy from you. They never buy, and you realize that all of their feedback was just them playing Steve Jobs. They're like, "I'm going to help this startup," versus, "I have something I'm actually trying to get done." And if you think about it, the people who actually have something really important they're trying to get done, they don't want to be a design partner. They just want that thing done.
I love that. Okay, so your advice is don't set up a bunch of design partners, and we'll go through the process you actually recommend. Okay, so I guess just to think about this coming up with an idea step, the core moment is some insight based on being hands-on, living with the people that you will be helping. The term I've heard to describe this idea, I think it was a VC, Floodgate, that uses this: you're basically looking for an earned secret.
Yes.
And your advice here is the way to find that earned secret, either you have lived it at a company, say Amazon, gave this AWS example, or you're on the ground working side by side with the people dealing with it and just looking for problems that they have.
Yeah. And the method kind of doesn't matter. It might come to you in an ayahuasca retreat. You could get that secret from anywhere, but the things that are most likely to actually work are getting your hands dirty and learning it from reality versus from theory.
So just to follow that thread, say there's a pie chart of the, say, 50 companies you've worked with, where their idea came from. What would be the biggest chunks of the pie chart?
I would say 10% own experience, 90% going and getting firsthand experience. And within that, it's been a bit of some of them sold the wrong product to figure out what the right product was. But most of them actually go and do the thing firsthand.
And then what percentage ayahuasca retreat? There's no room for that.
100%. That's mandatory as part of me advising you. That's the pull hypothesis.
Okay, sweet. Okay, so say at this point you've got a pull hypothesis. There's signs that maybe there's something really good here. The next phase in my eyes is finding someone to talk to and sell it to. So basically landing a first sales call. Talk about how you go about landing that call and what happens, and then we'll talk about actually running the call. But before we get there, just finding people to talk to.
Yeah, this is a fun one. So my goal is actually, I want to have two to three conversations per day with potential customers. But to get there, you have to first get your first conversation. So you can do warm intros, you can do all that kind of stuff. We'll just talk about if you don't have any of that and you need to get people to talk to you cold.
The way I typically recommend founders start is to just reach out to your potential customers on LinkedIn or via email, and it's with a very specific kind of message that is not a, "Hey, do you have XYZ pain points? Would you like to buy our game-changing solution?" No template you get online is going to get you any responses except for, "Leave me alone." And so I call it founder magic kind of outreach at this stage, which is basically, "You're interesting, I'm interesting. Let's chat and see."
And this is totally acceptable. One of the startups that I helped, their message was, "Hey, Snoop Dogg invested in us, and I thought you'd find it interesting too. Would you be open to chat?" That's a fun message. Everyone has their own version of that. Everyone who listens to this or everyone who's a founder has an interesting message you can send, and you don't have to convince them in the message to buy your product. You just get them to talk with you. This pull exists out there on their to-do list. And so the message doesn't do anything about that. It's just to get them to talk to you. So just say something interesting to cause them to meet with you.
Okay, this is really helpful. So your advice here is don't craft a whole value prop pitch, problem identification. Don't tell them how much pain you're going to solve. It's just get their attention with something interesting.
Yes.
The Snoop Dogg example is awesome. Any other examples? Any other ways of thinking about what might be interesting to someone?
There's been a variety of ones that I've seen. Random ones that are like, "Hey, I dropped out of my PhD, and I'm now working on something for content marketers," right? Something that's just interesting enough there that's not super magical. There's a variety of different things I've seen, from, "I was Sam Altman's chief of staff," right? If anybody sends that message, that will work quite well. It doesn't matter what the rest of the message says. "I thought you'd be interesting and open to chat." And so it's finding something interesting that's worth a conversation with them.
Yeah. What I'd say is it really depends on your end customer too, because if you're doing outreach to, for example, HVAC companies, saying, "Hey, I'm Sam Altman's former chief of staff. Thought you might find it interesting," they're going to say, "Buddy, I have no idea what the words in this message mean." So it could be, "Hey, I worked at my family's plumbing company in high school, and now I'm working on this kind of interesting thing. Thought you might find it interesting. Would you be open to chat?"
An implicit element of this is keep it very short. Sounds like it's just a sentence or two.
Yeah.
Okay. And then what's your take on AI emailing a bunch of people versus individually reaching out and thinking about some unique message per person?
I have not seen AI personalization work at this stage. Usually what it does is it tells them something they already know about themselves, and they're like, "That looks like Claude wrote it." And so I don't usually recommend that. I also haven't seen personalization be super important here. These messages, I said the entire message that I would send. You don't need to actually have a ton of personalization in it, or, "Hey, I'm going to X conference. We're going to be pitching. Would you be open to chat?" Something like that can be good enough without any personalization at all.
All the examples you shared are very simple and don't have anything to do with them and just say something interesting, basically. And what you don't recommend is basic... Yeah, the idea, you're not trying to sell them immediately. You just want to have a call.
Yeah. And on the call, we'll see if you have pull. If you do, you're going to turn it into a sales call. If you don't, nothing I do is going to change that.
Okay. How many emails slash LinkedIn posts should you start with? Say you're just getting started to try to find some calls.
Yeah. So I tend to start on LinkedIn because the kind of person who you and I talk to, they have interesting LinkedIn. And so if you're reaching out to someone, they're going to say, "Oh, okay." So that's going to do a lot of lifting. You can just get started. And so you can add 100, 150 people on LinkedIn per week. Go for that. Add 20 a day and then message them when they accept the connection request.
And if you're connecting with, I don't know, let's say you connect with 100 people per week or you send 150, my typical targets for that are 30 to 40% of them should accept your connection request. And then of them, 30 to 50% should reply, and a subset of them should say yes. The majority of them should say, "Yeah, sure, why not?"
Okay, that's an awesome benchmark. So if you're not at that level, basically your interesting email is not working. You should find something more interesting.
It could be your profile if people aren't accepting your request. They might look at you and say, "You don't look like somebody I should accept this request..." If you're at 30 to 40% accepts and then people aren't replying...
This season's supporting sponsor is DX. Now that everybody at your company is finally using AI, the question that engineering leaders face is no longer, "Are we using AI?" but, "Is it paying off?" With DX, you can measure and benchmark the impact of AI adoption across your full product life cycle. DX shows you where AI is helping developers and where it's creating new bottlenecks. You can also use it to evaluate AI vendors, monitor costs and licenses, and see exactly what's limiting your agents. That's why hundreds of enterprises, including Snowflake, Sony, and BNY, use the DX platform to measure AI's impact on developer productivity. Visit getdx.com/lenny to get a demo of DX. That's getdx.com/lenny.
So say you've landed a call and you're going to do a sales call, say your first one. What is your advice for doing a great job on the sales call?
Mostly two steps in a sales call. There's the pull discovery step, and then there's the conceptual pitch of how we might help step. And so the theory behind a sales call is, again, it's like if you have pull, you're going to rip the thing out of my hands. I don't come into this call wired up, ready to try to convince you to buy, super amped. No, it's just if you have pull, you're going to convince me to let you buy.
And so I approach this with the vibe of just leaned back, excited to chat. Let's see if I might be able to help you. And so I have a very specific structure of a sales call that I recommend for getting into discovery and then transitioning out of discovery. Basically, you start the call, "Hey, thanks so much for taking the time. I'm curious. I'm sure you get a bunch of people reaching out to you. Why did you take the call with me today?"
That's a chance for them to say, "You mentioned AI agents, and I've been thinking about this, and I've just been waiting, and I looked at your website," whatever it winds up being. And they fill out the entire PULL framework for you right there. That's ideal. And then you can say, "Oh, that's interesting. Can I ask a couple follow-ups?" But most of the time they'll say, "I don't know. You reached out to me. Excited to hear what you have to say."
Say, "Great." You use what they have just told you and say, "Okay, great. That sounds like a great agenda for today's call. We can do that. Does that sound good to you?" Get their thumbs up on the agenda. And then you earn the right to ask them some discovery questions about their pull by saying, "Great. Okay, before we get to those items on our agenda, do you mind if I ask you a few questions to better understand your context?" And that way you've earned the right to ask questions. It does not feel like an interrogation to them, because if it does, they're not telling you anything.
Okay, a few tactical questions. One is just how long should you try to make this call? How long should your invite be for? And then where does a demo fit in? Do you recommend a demo on this call or doing a separate call for that?
Yeah. So this is almost always a 30-minute call on the calendar. I found smaller calendar blocks, they don't see on their calendar, and so they don't show. And so 30 minutes, and then iffy on doing a demo. So if you're super early, you probably don't have a demo to show. But later on you might have a very short demo in your first call.
I guess because I'm thinking about the Jen conversation I had, and her advice is wait to do the demo, but that's an enterprise sales sort of product, not an early-stage, just pull hypothesis phase.
Yeah, totally.
Okay, got it. What's a sign that this meeting went well? Is it this kind of leaning in, pulling it from you feeling?
Yeah. So it's kind of you're able to surface pull, or you're able to say, "Okay, you don't have pull at all. Help me understand why this isn't relevant to you. What is?" And so you come away with either a filled-out PULL framework of, "Okay, I understand this person's pull, and they are trying to pull," or you understand why they don't have pull.
How many of these calls should you do before you're like, "Okay, there's no pull here. Time to move on"?
I don't have a hard... What I tend to do is if you have five calls and everybody's leaned back and you learn nothing, then there's a sign that something's wrong. And I've seen people do hundreds of calls where they still don't... So do five and then check in and see what you've learned from the calls. Was there any pull there? Did we learn anything interesting?
A startup I was just helping out, they had done five calls into banking, and they just felt nothing. But they got an intro from one of the people who said, "Yeah, this doesn't seem relevant to me, but you might consider defense companies." And they got an intro into that. They know nothing about defense. And in the first conversation in defense, the person's like, "Holy, are you serious?" And they're like, "Okay, maybe there's something here." And they changed their pull hypothesis.
It feels like a big part of your framework and approach is to just be brutally honest with yourself whether there's something here. I imagine a lot of founders are just so excited and convinced this is real, and your approach is just, here's a way to validate that and be really real with what's working or not.
Yeah. I think it's thinking of it as we're selling to learn, not really to push something.
Yeah. Not to push.
We're going to learn, and we're seeing if they try to buy. If they don't, cool. We've learned something. We can keep iterating from there. If they do, okay, great. Now we might have something. Let's see if it repeats.
The whole idea of calling this pull is so smart, because you always hear product-market fit is you're feeling pull. You're feeling pulled. This boulder is pulling you down. The wind is pushing you.
Yeah.
And so not only is it this acronym of what you look for, but it's this reminder: what you're looking for is pull, something pulling.
Yeah. And you can also tell, do I feel like I'm pushing right now? Do I feel like I'm convincing? That's a red flag that something either in your mind or in the conversation is off, and, "Okay, cool. Let's figure out what that is."
Is there an example that comes to mind when you think about a good sales call, what that feels like, looks like, what a pitch would be?
Yeah. So what you're trying to do is you're trying to get, again, the pull out of them. And so they say, "I'm trying to make a website, but one of those typical point-and-click website design things are just too much effort for me," right? So you have something about pull there. You've kind of pulled that out of them. They've described that.
And so the interesting thing is that once you have pull, your pitch is quite simple. What you're not trying to do here is you're not trying to describe this massive product vision or your theory of the problem. You know that they're trying to do X but blocked because of Y. And so your pitch in that
Case is, okay, so it sounds like you're looking for something to make a website without all the hassle of a point-and-click thing. Is that roughly it? And you describe it in a really small and simple way, not a really big way. You describe it in a small way, and they say, "Yeah, that sounds like it. How exactly does that work? Tell me more." They're pulling more information out of you, and that's when you know you're starting to be onto something.
And are you in your head thinking through the PULL framework of these four points and just thinking through, okay, is this actually something they need right now and unavoidable? What are their alternatives? And thinking through all that.
Yeah, those are actually the questions I will ask too. If they don't tell me at the very beginning when I say, "Why'd you take the call?" then I'm asking a question that's kind of like, "Is there anything as it relates to, I don't know, your QA process that you're trying to do but you've been unable to do with your existing tools, methods, team, whatever?" Right? And so that question has all the elements of PULL in it so that they can then say, "Oh yeah, actually we've been trying to automate end-to-end testing but can't do it with our existing tools."
And then if they give me some element there, then I have the framework in my mind. And I know a lot of people actually have the framework in a doc during the call, and they're filling it out live. And it's like, "I don't think I have the U." And then you ask a question. You're like, "Okay, but is it okay if you don't do that now? Is there some reason you have to do this now, or is this okay to do another time?"
And you're scared to almost ask. You're like, "Oh no, it's not going to work."
Oh, and the scariest one is to say, "Well, I'm sure you've looked into other options. Are they good enough?" Right? And to hear that one where they're like, "Actually, yeah, we can do it ourselves, and that's good enough." But it prevents you from, again, pushing a product the market doesn't want.
And just spending years of your life trying to make it work.
Yeah. There's a reason I look like I'm 60 and I'm 35, right? Don't push.
You look great, Rob. You look great.
Filters.
Oh man. So this touches on—we haven't actually addressed the specific challenge, which is that there's a lot you have to get over for people to decide to try something new and to buy something new. The status quo is generally fine. They have so many priorities. They have so many things they're dealing with. The bar to get over for people to be like, "I want this. I'm going to buy it now," is really high. And the idea here of this framework is to get over that hump.
Well, it's to find the people for whom the status quo is not okay, right? It's to find the people—everyone says change is hard and all this kind of stuff. Well, you're looking for the people who are already trying to change, who don't need convincing.
There's this idea that your product has to be 10 times better than the existing solution for anyone to care. How do you think about, okay, this is better, they tried alternatives, none of them do it, or some of them do it okay? How much better does this have to be for them to care? Or is it okay if it's just a little bit better?
The example with Jump, I think, again, the AI notetaker for financial advisors, is a good one. How much better are they than the other generic AI notetakers? Well, if those notetakers don't get the job done and we do, they are infinitely better. They unblock something. And so that's kind of how I think about how stuck are they with their existing options. And so I don't know about 10x. That doesn't quite register in my head. It's really, are they a coiled spring, and how do they respond when I show up?
So I think about a company like Linear, who competes with Jira. Do you know Linear?
Yeah, yeah, yeah.
So I'm curious if it applies through this framework. In my understanding, Linear wins over Jira often because the experience is just better. It's just a beautiful, smooth, well-crafted experience, and so they win a lot of customers because it just feels nice and engineers really like using it. Do you feel like that works through the PULL framework, or is there something else going on there?
Again, if we use the PULL framework to analyze that situation, what would have to be true is there's a certain kind of person who is trying to do their issue tracking, but they are blocked. They're trying to do something around issue tracking, and something about Jira's experience is blocking them from doing it, such that Linear's way better experience is actually relevant to them. Right? So I've made the mistake of taking that analogy and being like, "Okay, so I can just come into a category with way better UX, way better experience, and I'm going to crush it." And try that in HR software. I tried it in HR software, and it turned out the user experience was not relevant to the buyer, and so they didn't have pull. They didn't care that their systems looked like they're still on COBOL or whatever it is. So it wasn't relevant there. But again, the pull theory would say that basically in the case of Jira versus Linear, there was a kind of person who was blocked by Jira's experience.
And I imagine the stronger the pull, the faster all this stuff happens. It grows. I know Linear took a long time to get people using it, to trust it, to switch. And so maybe the pull, because maybe there wasn't as much of that blocking and it was more of just like, "Okay, I can just move faster, be happier," it took longer. Do you find that the stronger the pull, the faster the company grows?
Yeah, I've seen a bunch of startups where they go zero to whatever. Everyone now is going zero to infinity super fast, and it's because they have found these pockets of pull where people will rip a product out of their hands. And people will see these AI pitches now, and it's like, "Wait a second, it can do X?" and buy basically instantly. And I've seen that happen in enterprise. I saw an enterprise deal close in two weeks. When I was growing up, enterprise deals took 18 months. What the heck?
"When I was growing up." I like that. Okay, so let's move on to the next step. So at this point, you had your first sales call. I imagine the next step is closing the deal. And it's interesting because it's still early. You may not even have a product. What does that look like, going from, "Okay, I want to buy it now"? What do you do next?
Yeah. So it's going to depend on the size of the deal, but you want to come back with some sort of a concept and some sort of a plan. And so examples of this: the pharma company that I mentioned earlier, the company selling into pharma, he showed up and just threw a Hail Mary on an intro to a pharma exec. Pharma exec was like, "Oh my gosh, thank you so much for asking. Our current market research is da da da da. We're trying. It's just so bad. It's so slow." And the founder was like, "Okay, I don't even have slides here. I'm just hearing this for the first time. And so it sounds like you're looking for faster market research that looks like the current research you're getting, but it's just better in these kinds of ways. Is that roughly right?" And the exec was like, "Yes, that's exactly it."
And so the founder is like, "Okay, let's do this. What if I come back to you in a couple days with a mockup of what I think that could look like, and then we can discuss if that fits what you're really looking for and then decide if we want to move forward?" And so in that case, no slides, no nothing. Goes and vibe codes a rough layout of what this would look like, gets some feedback on it, says, "Okay, based on that, is there anything else you need to know to decide whether this is a fit that you want to bring into your organization?" Says, "Yeah, what's the price?" And then there's a talk track you can use for price, but that's basically it.
Okay. Tell me more about this price talk track.
Yeah. So the interesting thing about the PULL framework is that it can help you set the bounds for pricing. So what's the value of getting the project done, or what are the costs of the alternatives? So the L's. What's the value of getting this market research faster, or what is the cost you're currently spending with your market research consultants? Both of those can tell you, okay, the value of market research is X. The cost with consultants is, I don't know, $50,000 per year. And so that gives me a rough boundary to say, "Okay, what if we charged $50,000 a year, the same price as your current market research consultants?" It gives a frame on price that makes it intuitive to your potential customers.
Awesome. Okay. So the way you've written about this closing step, there's two parts. There's the fit of just, is this a fit? And then it's just a bunch of project management to get the deal closed. So we've spent a lot of time, I think, on the fit. The project management, is there anything there important to talk about?
Yeah. So you did a great episode with Jen, a great couple episodes with Jen, on the sales process. And so in bigger deals, enterprise deals, the champion has pull and decides, "Yes, I want this." And then you have to do a set of 17 demos. You have to genuflect in front of four committees. There's all of these things that you have to do. For smaller deals, you don't have to do that kind of stuff. It might just be the CEO who's like, "Yeah, cool. Next step is you send me the Stripe link, and we schedule an onboarding call."
And so the project management step will depend. My typical recommendation for project management in larger organizations is to have a conversation with the buyer, with the champion, to say, "Okay, cool, this is the project on your to-do list. When does this need to be showing results by?" They'll say, "Oh, definitely Q1 next year." Okay, cool. That's a forcing function. You work backwards from there to say, "Okay, given that we need to be live Q1, what are the set of steps that need to happen between now and then so we can be deployed and showing results by then?" And that is a forcing function for all of the steps in the sales process.
Awesome. So basically asking, when do we need to show success for this to be a thing that you all roll out? And then working backwards from that. Okay. At this point, a lot of people would create basically design partnership arrangements where they're like, "Okay, cool, we'll build this with you. We'll figure it out as we go. We won't charge you." Per your earlier point, you were not into design partnerships. I imagine your advice here is just sell it directly. Don't try to give it to them for free. Don't set up some kind of partnership thing.
Yeah, yeah. Why shoot yourself in the foot?
And again, the reason not to is because you find that doesn't lead to stuff that actually sells and works, building this kind of design partnership relationship.
Yeah. It basically takes something from, "I need to solve this right now," to, "Okay, now I'm helping you build your product." What are we doing here? So it's a negative signal to people who actually have pull, and it's a positive signal to people who don't.
Awesome. Okay, that totally makes sense. If there's pull, just go with it. You need to, yeah.
Yeah. And you can sell something that's—you might not have a full platform ready. You can sell something that's more service-shaped early on. I've seen a bunch of startups do that where they sell, "Okay, we're going to have an AI product manager who can do XYZ kind of thing. For now, it's delivered by us while this thing is working behind the scenes." And so you can frame it so they're not expecting a full enterprise-grade platform ready next week. They expect something more service-shaped, and you validate that there's real pull there, and you figure out what the actual thing to build is while delivering it a mix of manually and automated.
Okay, that's really interesting. That's come up a lot on the podcast, especially with go-to-market sales conversations. This idea of services being a great place to start, which historically has been a terrible idea because the fear is you never actually get to a place where you can automate it, and you're just running a consulting business forever with terrible margins. So you've seen this work, this idea of starting with basically humans doing the thing and then slowly building a product around it that increases margins?
Yeah, it definitely has downsides, right? You definitely can get stuck in a service business kind of thing, but everything has downsides.
Awesome. Yeah. And the idea is AI does more and more of this stuff. And part of it is you learn more and more of what the problem opportunities are and things like that with people doing the work. Okay. Going back to price real quick, classically founders are afraid to ask for big numbers and throw out high prices. Knowing that the stuff changes and you'll learn as you go, any advice for that first price pitch of what number to throw out?
Yeah. So early on, I'm really more testing willingness to transact versus willingness to pay. And so I don't care about pricing a ton in the early couple of customers. That said, I was just working with a company—their first deal is enterprise, and they've got a big demo day coming up. And so they're like, "How do we get the most possible revenue out of this so we can look like that for demo day?" Totally valid thing to do. In that case, what you do is you throw out a number in a way that doesn't get you slapped.
And the specific approach that I'd recommend for that is almost using a case study as a, "Hey, react to this kind of case study." And so you'd say, "Yeah, when we talk to others, everyone's done pricing differently. Sometimes it's been a small project for 80,000. Other times it's been up to a million in terms of—right? And these are the levers here, and a lot of people wind up in the middle. You tell me, how are you thinking about this?" And so what you're doing is you're not me on this side proposing pricing to you on this side. It's both of us looking at an example, a semi-real example of what you've heard from others as how they think about this, and letting them throw up on that.
Throw up on that. I like that. I know this case study concept is actually an important part of this whole framework. I'm going to come back to it, but okay. So let's talk about the next step. So say you have the sales call in BF2. What comes next after this first batch of sales calls that you're doing?
Yeah, this is where the paths might diverge. So hopefully you're right, and these people have pull. Great. You now have customers. Time to deliver and start repeating this and start figuring out how to automate things and just systematize this. You're on the right path. A lot of the times you get a weird set of responses. You learn that the people you thought were weird not to buy are actually weird to buy. It'd be weird if they did buy. They're not behaving in a way where they have pull. And in that case, what I tend to recommend is you just analyze. You go back and review the calls, and you say, "Okay, did one actually have pull? Did"
Zero, like what have we learned here? And then you craft a new hypothesis and run it again.
Got it. And I imagine most of the time it's not there. Is that your experience, or what's the pie chart of success versus not at this stage?
Yeah, I've seen maybe once or twice where it was there from the beginning, and that's magical. You feel like a hero when you get it right the first time. A lot of times it is like we're so wrong and backwards that we don't know. And so you just ask a Hail Mary a couple times, and that gets you on the right path. Or you do something crazy where a friend just went to a conference and scheduled 20 meetings and just was like, "I don't know what to do. You tell me what to build you," or something like that. I call that goblin mode, where you're just going all out and doing unhealthy things to see who will buy something from me right now to then generate your hypothesis out of.
Say more about goblin mode. This is amazing.
Yeah. You know when dogs get the zoomies, right? That's the thing I have in my mind for what goblin mode is as a founder, where it's like—
And this is a good thing or not a good thing?
It's a break-glass-in-case-of-emergency thing. And I think some founders actually operate like this all the time, where it's like, okay, there's actually a conference tomorrow in Europe that has these potential customers there. I can't get them to talk to me, so looks like I'm going to get on a plane right now and go there. It's just doing somewhat crazy things with the goal of getting in front of customers right now. And some people can do this all the time. Others like me, who are getting old, I can pull this out once in a while.
Get that goblin mode out sometimes. So the idea there is, and you're saying sometimes this can work, just going nuts, just going talking to everyone, looking for these earned secrets.
Yeah. And one example of this, it's kind of a crazy example, but a friend's building a company called Teero, which does dental staffing for dental hygienists. And his version of goblin mode was his parents went door to door to different dental offices to just get people to talk to him about being customers. And that worked. And so it's just weird stuff like that can work.
Amazing. Okay. So you say do a couple sales calls, say do five. Is that kind of the idea? Do five and assess. Is that a rough heuristic? Okay. So, say to your point, most times you'll find, okay, there's no pull here. Sorry, what do you do? Do you go back to the beginning, go hands-on with some other small business sort of thing, or what do you recommend?
Yeah. So, different pathways there. Hopefully you've asked the Hail Mary question and you've learned something there that's worth double-clicking into.
And the Hail Mary question is just, is there anything that we can do right now that is a problem on your to-do list?
Yeah. Exactly. And so you've generated some new information that you can then use to—
Do another set of five.
If not, then yeah, you just go back, get some firsthand knowledge, try it again.
Awesome. Okay. So this process is very straightforward. Have a pull hypothesis, fill out this template, schedule basically cold outbound with this surprising message that'll get people's attention, think you're interesting. Do five calls roughly, get a sense, is there pull or not? If there's not pull, throw out some Hail Mary questions, maybe enter goblin mode to look for something. Come up with another pull hypothesis, do five more calls, and repeat until you're like, "Oh, wow. We've got this pull."
Yep. And then you have a business.
There we go. Off to the races. Okay. So, say you've actually found something, something that is pulling and people are like, "I need this now." What comes next? There's kind of the building, onboarding process and then just keeping them happy. What's that process like? What advice do you have there?
Yeah, so I found that I didn't really have a good way to think about what happens after people buy. And so I felt like the dog who got a car, and I just threw the software over the fence and, "Good luck." What I've learned since then, the hard way obviously, is that retention is super important, and it's not obvious.
And so the way I think about delivery post-sale is that basically everybody who buys is guaranteed to churn until X, in which case they're weird to churn. And all delivery, everything, is about figuring out what is X and how do you design a bullet train so every customer gets there. And so X is, you might think of it as, oh, they're using the product or they have high NPS or whatever it is. It's almost never those things.
Mark Rober has this kind of leading indicator of retention, which for Slack was like you sent 10,000 messages or a thousand messages in your first X amount of time. If you hit that, it'd be weird if you churned. It's the leading indicator of retention. For my startup, we gave retention software to restaurants. If they got a notification that somebody was going to quit that they could prevent within the first two weeks after purchase, they would go insane. They would tell all of their friends about it, and it would be weird if they churned. And so we just designed the onboarding process to that.
And so what I recommend is once you have a couple people who are saying yes, don't just throw the product over and send them a login and pray. Go deliver firsthand as well, and you're going to learn a ton from that. And keep asking the question, "Are you going to churn now? Are you going to churn now?" And try to find the moment when they're like, "Oh, okay, cool. I can't live without this."
I love how your mind works, where it's these formulas and these templates and just everything is this. And obviously it's not this clean-cut, but it's really helpful, I think, for people to just think of it in these very structured ways, to take these general ideas of what it looks like when things are going well and how to find an idea to just, okay, here's what you plug in. Talk about the specific thing. It's working, adjust. So this is great.
On the churn piece, what's a sign, okay, shoot, everyone's churning? Just a sign of, okay, they thought they were in, but it's not working. Anything there of just what's a sign at this stage, okay, maybe it's not working versus it is?
Yeah. So, if everybody's churning, it is unacceptable for you to not figure out why. And so what I've actually seen is in a lot of cases, for a lot of horizontal products, you're going to have a lot of user drop-off. So, one startup I know, they were a horizontal AI workflows product. Cool. Join the club, right? But they found through being a horizontal AI workflows product that one or two kinds of customers kept using it while everyone else was churning.
And so if a bunch of people are churning, 90% plus of your customers are churning, first of all, I'm sorry. It sucks. You wake up at 4 a.m. every morning just sweating. But in that you often can figure out why. And is it something that you're doing or is it something about them? And that can tell you, okay, who actually had pull that we can sell, deliver, retain? And for that horizontal workflows product, they found that freight forwarders were using it for one specific workflow. And so they pivoted the entire company to focus on that. And so they went from being this horizontal product with massive churn, low price, to a very premium product for freight forwarders.
There's no point at which, okay, we figured it out. We're going to be a massive success. Every moment of the startup journey is an uncertain moment. But what's great about this process so far is every step you get, it's more and more certain there's something here at least. And then there's the forever in doubt of how big can this get? I remember talking to the founder of Databricks, which is now a bazillion trillion dollar company, and he said something like even at 100 million ARR, they were still very unclear if this was a thing that will last. And I think that's very common. So that's its own topic of just—
That's nice to know. That's nice to know because everyone's like, "How will this become a big thing?" It's like, "I don't know. We'll figure it out."
Yeah. It's just one step at a time. And so in this conversation, the final step in my mind is this idea you have of this user case study factory, which kind of takes you from things are starting to work to, okay, now we can create a repeatable system that helps us grow. So talk about that, what that looks like, what that's about.
Yeah. So this is the thing that whenever I talk about, everyone's eyes glaze over. And so I haven't found a useful way to talk about this yet. So just pre-warning, I think it's the most important thing in all of this, which is how do you think about your startup? What's your conceptual model for your startup? And you need to have a way to think about your startup to know how to grow it as fast as humanly possible.
So what winds up happening is you find somebody who has pull. You give them a product or service or whatever that they pull out of your hands. So, it turns out they were trying to do X, their existing options weren't good enough for Y, and you offer Z that helps unblock them. That sounds a lot like a case study that you would feature on your website. And it's a helpful thing because, okay, my job as a founder is not to produce a hundred totally different case studies, because that's not scalable. That's not repeatable. I'm looking to build one case study where a customer says hell yes before they buy and after they buy and just repeat that a million times.
And so that model helped me go from thinking that startups were a bunch of different things, I need to know all these different things, to, no, a startup is just a thing that repeats one case study infinite times. And all the stuff that I do is to build a factory for repeating that case study. And if I do this right, there's a case study where customers say, "Hell yes." And they pull themselves through each step of the factory.
The steps are the pipeline step: how do we get people to talk to us? Sales step: how do we turn potential customers into actual customers? And the delivery step of the case study factory, which is how do we get people who are customers to be weird to churn? And so everything we do fits into this case study factory. And if you see this in your mind, it radically simplifies a startup, how it works.
And then you can use the theory of constraints—we're going to get really nerdy for a second—from manufacturing to look at your case study factory and say, "Okay, where is the bottleneck to our growth? Is it that we don't have enough pipeline?" Okay, cool. If that's the bottleneck, then that's the only thing that matters right now. Let's solve that bottleneck, and then we'll move to the next one. The next one is our close rate is lower than it should be. Okay, cool. That's our bottleneck. Now we're going to go all in on that. And so the case study factory model gives you a way of thinking about your startup and knowing exactly where to focus at any one point in time.
It's a really interesting way to think about it, where instead of we are trying to just get more customers closed and more deals closed, instead we're building case studies. You're almost working backwards from what's the case study going to be of this company we're talking to. Say we're talking to SpaceX, we want it to look consistent across all the companies we're talking to. People call this repeatable sales motions, but I like the idea of thinking of it as almost working backwards from the press release, but for sales.
What is the case study we're going to write about SpaceX? Okay, here's how we got them. Here's how we sold them. Here's how we delivered it.
And then just create consistent, repeatable case studies that you will later be able to share.
Yeah, exactly. And then what sales becomes is it becomes, "Hey, this is the case study that we deliver on. Is this relevant to you or not?" And you can show the case study to people. They say, "Yeah, that's actually what I want as well." And so it becomes this kind of tool. And you can say, "Yeah, you don't look like our case study, so it's probably going to be a lot of work, and it might not be a good fit." And you can use it for qualification, disqualification, and for people to understand what you do.
That's funny. There's this whole theme now of building software factories where products build themselves. But this is really another version of a factory you're building, which is even the broader version of just the sales, the user, the case study factory.
Yeah. We don't make software here. We make case studies.
So is that your advice? Just think of it that way, like, "We make case studies here."
Yeah.
It's interesting. And it's not like you need to actually share and write up a case study. It's just a mental model for how to think about what you're trying to build as a sales go-to-market org.
Yeah, totally. And the good news is if you have the PULL framework, then you just describe here's how we helped them and what they accomplished, and you have a case study.
Amazing. Okay, there's a couple things I want to touch on because this is the end of the process, basically. There's a few things I want to touch on that came out of the community and things you mentioned real quick. One is you have this term, hell yes customers. Say more about that. You mentioned when you're looking for someone to buy it and then use it, there's this idea of you want them to be hell yes.
Yeah. It's basically somebody who pulls the product out of your hands before they buy, and then afterwards they use it as if it is addictive. And so they might literally say hell yes. But what matters is they're weird not to buy and weird to churn. And that process is mostly them pulling versus you pushing. That's your perfect fit customer. Your job is just to find more who are basically clones of them.
Okay. The other point I want to reinforce is you recommend no pilots, no proof of concepts, no design partners. Just go straight to we're going to sell this to you and roll it out, and it's going to be amazing.
Yep. And sometimes you're going to do that, and they say, "Okay, but the way we buy here is we actually need to pilot it."
Okay, cool. But don't proactively offer. Awesome. Okay. Another big question that came out of the community is, from an external perspective, this feels like this is just for startups and founders, but this actually applies for, and we mentioned this at the beginning, but just to reinforce this point, for larger companies that are working on a new feature, new business line sort of thing. Talk about if there's anything that you would think about differently through this process if you're at a mature company building a new product.
I'm helping a couple companies launch their second product. And what they are doing is actually the founders are like, "Cool, we're doing it again. We're running it back." And the founders are taking this approach to existing customers because they're going to try to upsell them. And they are actually selling new features before they've built them. Another example at existing companies is, I can't share the name, but a new product leader at a company was telling me, "Hey, yeah, the way we get our ideas all
of the ideas that have worked have come from sales calls where they said, cool, yeah, you can do X, but could you also do this other thing for us? And the products that came out of the customer in the sales calls asking for something that could do that project for them all worked. All the ones they whiteboarded never worked.
So the idea here is you have a product, you're hearing, you're basically finding these little nuggets of this could be a thing. And what I'm imagining is then you go through this whole pull hypothesis step by step. Just put up that hypothesis, talk to five of your existing customers, look for that pull, see if they're going to actually buy it, and then kind of go through the same process. And an important wrinkle here that we haven't reinforced enough maybe is that it's the founders that should be doing this, especially in a startup. But it's interesting you said even at a mature company, if it's a new product, the founders ideally are doing that selling.
Yeah. Ideally, not always the case. There are people who are doing zero to one stuff, but I just recommend if you're in that situation and you're a non-founder, really focus on trying to sell the thing and learning through selling, because there's a lot of ways to get lost in zero to one.
Awesome. And then again, if things aren't working, there's this idea of goblin mode of just, okay, just try a bunch of stuff, talk to as many people, get on planes, go have 20 meetings, and just look for something.
Yes. Yeah. Hail Mary, goblin mode. All of these things are just your break glass in case of emergency. Time is really valuable. And staying stuck is awful. If you're in this pain cave of zero to one, it's the worst time of your life and you just don't want to prolong that. So just get on a plane, go to the office, go in person, do whatever it takes to find something.
Rob, we did it. We went through everything. That was amazing. Is there anything else that you think is important to share or anything you want to, I don't know, double down on before we get to our very exciting lightning round?
Hopefully what's come across is kind of how simple this is. PULL framework, show to people, see if they pull. There's a lot of ways to overcomplicate this. And there's a lot of ways where we try to solve every variable in our head in advance. And I've found that just PULL framework, sell, see if they try to buy, and think less in that process, it will get you there.
Awesome. That sounds very simple. And I think it's important to know it's hard to find an idea that actually works. And this is all here to help you save a lot of pain and suffering and building and being kind of, not disillusioned, feeling like there's something there, wasting a lot of your life doing something that's not going to work.
Yeah. Think of it as like a metal detector on a beach. This is just giving you a metal detector. You might not find metal where you're looking right now, but at least I'm not giving you a spoon.
At least I'm not giving you a spoon. Meaning...
For the beach, right? To look for metal.
You're not... Oh, I see. You have a metal detector versus looking through all the sand with a spoon. Wow. I love that metaphor. And then sometimes you may find a thing and then you realize it's not worth anything. Yeah.
Okay. Wow. That's a great metaphor.
Well, Rob, with that we reached our very exciting lightning round. I've got five questions for you. Are you ready? Let's do it. First question, what are two or three books that you find yourself recommending most to other people?
Oh gosh. My favorite one is the four-volume The Nature of Order series by Christopher Alexander. It's a series of books on architecture. Best thing ever.
Never heard that recommendation before.
Those are my favorite. Favorite recent movie or TV show you've really enjoyed?
I have two favorite movies that we watch repeatedly. One is the most recent Pride and Prejudice and the second is the Penguins of Madagascar movie. Don't know why we're on both ends of the spectrum there.
Favorite or most interesting AI product that you recently discovered or use or love?
I've been using Muse, and it's like, if it works for me, it can work for anyone.
Yeah. Very hot right now. Amazing. Okay. Favorite life motto that you often come back to in work or in life?
Life is what you make of it.
So true. Final question. I'm curious to get your thoughts on this. So there's this idea of tarpit ideas. So I had Dalton Caldwell on the podcast. He was a partner at YC and he has this term tarpit ideas, which are ideas that people constantly have that are just terrible and don't work, and people keep having these ideas and they keep trying it and they're just like, okay, does not work. Are there any tarpit ideas you just find people keep coming to you and you're like, don't do that, it's not going to work?
Oh, that's interesting. The category of ideas is to go after a space when there is already a clear winner in that space without any theory on being different. I just keep seeing that. It's just like, oh wow, Lemlist just built a sales automation tool and they're bootstrapped and they're growing really fast, so let me just build the exact same thing as them or something very close. And you know, it's like, okay, but they've already won that, or they've already done that thing. And so unless you're like, "Oh, but this kind of customer is unblocked, and so we're going to build something kind of different for them," those ideas almost always don't work. And you feel like you're going crazy because you're like, "Well, it worked for them. What am I doing wrong?"
And I imagine everyone answers, "But it's better." And as we know, it can't just be a little bit better. And basically, you're saying, okay, this is unblocking them.
Yes.
And it's better than all the alternatives. They're just going to go with that thing. But I guess then, you know, this goes into a whole other conversation, like what if it's two times better? And I guess your advice there is it's probably not good enough.
There are many things, right? You could give me a 100x better printer for my house and I won't buy it because I'm not blocked.
That's a great example. Oh man, Rob, we did it.
We did it. Holy cow.
We did it. Holy cow. Okay. How can listeners be useful to you? That's our final question.
Oh gosh. If you like the framework, use it. Tell other people about it. Check out the book if it's useful, and reach out if you have any thoughts, ideas, or... This is a theory, framework, model that is just in development. I still feel like I'm kind of scratching the surface on this. This is kind of what I'm going to be doing for the next 10, 20 years. So if you have ways to improve it, reach out and tell me.
Awesome. And your newsletter is exactly that. I don't know how often you're publishing, but just like, cool, here's another way to think about this. Here's a wrinkle here.
Yeah.
Just the idea of calling it Physics of Startups is an awesome idea.
Thanks.
So point people to the newsletter. Rob, thank you so much for being here.
Thank you.
Bye everyone.
Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.
Article published · Updated
