Notes on the Physics of Startups

This is Notes on the Physics of Startups, aka how to get customers to pull products out of your hands and not waste your life in the process. A lecture I wish somebody else had given 10 years ago to me before I wasted a lot of my life. However, I'm here now doing it. I hope this is helpful. The context here is that my goal is to give you a new way of thinking about startups, sales, all of the components of Zero to One, such that you can get to the point where customers are pulling the product out of your hands versus you trying to push it into their hands. And that not to be quite as much of a process of you hitting your head against the wall repeatedly when this doesn't work and it not being obvious what's going to cause it to work when it works. This is, as I mentioned, based on a decade of time in early-stage startups where it has largely been me hitting my head against the wall unsuccessfully and occasionally being successful and trying to figure out why it works when it works, why it doesn't when it doesn't. To that end, I've advised a ton of startups over the past couple years. In a variety of roles, but I've done zero to a million ARR 40 different times now, at least. I think it's, I think it's probably higher than that now. Everything from AI, B2B companies, traditional SaaS, even some consumer stuff, some deep tech as well, and med tech and whatnot. And some of the fastest have been zero to $20 million in 2 years and zero to $6 million in 8 weeks. And so I wouldn't say I have this figured out, but I've seen a couple patterns and have been trying to develop the physics of early stage startups and just of growth in general to try to understand this. Anyway, I wish somebody had given me this lecture years ago. And also, this is a very long lecture and it only scratches the surface of the stuff that I'm trying to cover here, of the stuff I'm trying to articulate. I'd probably pass out if I tried to describe it all in, in in one sitting and that's why I wrote a book. And so there is a book on this. It's a, it's coming out in July and even the book is kind of scratching the surface, I will say. So who knows, maybe there will be a textbook someday that nobody will read, but I will feel accomplished having written it. Get in touch with me. You can check that out any other time. Who is this for? This is a lecture that is for startups. You could be at the pre-idea stage. I want to build a startup someday stage, or you could be actively in it. In an accelerator, going zero to one at YC, wherever. Or you could be at the stage where you have customers, but it's not growing super fast, doesn't feel super repeatable. This will help you. And this is also quite helpful for startups that are growing very fast and don't want to accidentally kick down a load-bearing wall when changing something. So this is also for established companies where you are trying to juice growth, you're trying to grow faster, you're trying to turn something around, or you're trying to go zero to one on a new product. And then anybody who gives advice to founders, I wish people who had given advice to me had known this stuff. And so I am giving this to you so that you might help your companies take off and grow faster. My story here is basically I thought I knew what I was doing. I worked at McKinsey, I went to Harvard Business School, and you come out of that pretty confident that you understand business, you know how things work. And guess what? At that point, it's like, okay, startups are cool. I can be honest about it now. A startup would be fun. I would like to be a billionaire. I'd like to build a world-changing unicorn. Why not? I've been successful up until now. That'd be great. That'll be good. Maybe I can retire at age 30. And so I did all the things, discovery interviews, ran experiments, had design partners using our MVP daily, like core, as core to their job. They were getting real ROI out of it. It was obvious that we were going to succeed. We were able to raise money and then nothing worked and it wasn't clear why. It, we just couldn't grow the business. And so we pivoted around kind of, I don't even think pivoted is the right word. We kind of flopped around for 2 years. And this was when I unlearned most of what I thought I knew. Hear, hear. And just kind of when nothing worked, why isn't it working? It all makes sense. It all should work. I'm doing all the right things. And so I don't know if you've been in this situation before, but if you haven't, I wouldn't say it's like, oh, I feel like I'm learning. This is great. It feels like, wow, this is the worst day of my life and career. Every single day. And so, yeah, not fun. And then also kind of interesting, we did a random Hail Mary pivot when I got a phone call from somebody I had demoed to who was like, yeah, I have no idea what you were trying to sell to me, but if I would pay you right now to do this. And from that moment, we went $0 to $4 million ARR in 2 years, which just broke my brain even further. Uh, this caused me to I mean, we, we basically got zero to a million where they couldn't even log into our software product that they had theoretically purchased. Like it didn't make sense. And so this caused me to basically unlearn most of what I thought I knew, not just about startups, but unfortunately about business as well and try to relearn it. And so since then, I've been trying to go through this zero to one process again and again and again and again. Uh, which is not good for one's health, but it is, uh, I think maybe a good way to learn. And so I'm trying to figure out how, like, what causes a startup to start growing very fast by doing it as many times as possible and just testing different things. So where most of us find ourselves, where you might be at this very moment, and if so, I'm sorry, but you were in this. Weird kind of situation where we have a valuable product or a great idea that will solve a big problem in the world. It could be massive, right? Huge market opportunity, all these kinds of things. We talked to potential customers, we talked to people in the market and they are like, they agree, they're like, oh yeah, huge problem. This is, this sounds great. We work really hard. We follow all the different playbooks. We, we, you know, try to sell. And people aren't buying. Our startup isn't growing fast. And all of this doesn't make sense. Like what's not happening is despite all of these things that seem like they should lead to a fast-growing startup, it's not growing as fast as we should. And customers specifically, like it does not feel like customers are pulling the product out of our hands. They're saying often all the right things. Sounds right, but they're not buying really fast and using, and it's not clear why. And so in this situation, if you've been here, or if you are here, it's not clear what's going on, what to do about it. And you try a sequence of things that all make sense, that sound right, and they barely work if at all. And you can't predict which ones will work and which ones won't. And so it's just confusing. It's really, really confusing and disorienting. And what I've realized is that this situation is the default outcome of how we tend to think about startups. This weird conundrum where everything makes sense, yet it's not growing super fast. Is the result of our normal intuitions about how business works and the things that we are taught. And so this is what I call the pain cave. It is a horrible place to spend a few years where you're— things that should work, you do them. They make sense. Product should work. This customer should want our product. And they say all the right things, but they don't quite buy. Or we try some new kind of growth tactic to get people to talk to us, to get people to use our product, to whatever it is. And it makes total sense. It feels airtight, and then it doesn't work in practice or doesn't work really well in practice. And when that happens, it's not clear why, which leads us to this weird place where there are infinite explanations of things of why it could not work, what we could do differently. Everything sounds right, and there's not a clear way to pick, given that we have been wrong sequentially on all things that sound right. And so eventually we just go back through this loop again. And so the structure here, the really confusing structure is when we have something that people should want. It would solve their problems. It would fix their pain points. They would get a lot of value out of it. Maybe we even have customers using it and getting a lot of value about it, getting rave reviews. And we know exactly what we need. We need one thing that is repeatable, scalable, that customers buy, use, renew on, that can get us up the curve, that can, that can get us from to our first million ARR, to our first $100 million ARR, whatever, whatever it winds up being. We just need that one repeatable thing that works. A and B should be connected, but they, in the pain cave, they are not. Customers aren't buying fast. It's not clear why or what to do about it. And so there are a couple of different patterns here. One is just pivot hell. If you're early stage, you might just pivot around. Thinking, oh, maybe go-to-market tech is better because then we're selling to revenue. Well, maybe enterprise is better because there are bigger contracts. Maybe PLG is better because look at how fast Lovable grew. Maybe dev tools are great because Claude Code, right? They grew from $0 to $30 billion ARR in 14 minutes. Maybe I can do something there. Right. And so, you know, it's always the grass might be greener over there until you go there and find out it's not. Then there's just the tactic whack-a-mole where it's okay, I saw this post on X about yada yada. Let's like, we're going all in on harnesses now. And it's like, all right, cool, great. Two weeks later, that didn't work. Now what? Then there's the particular mode that I fall into because I feel like I need to understand things before doing them. And it turns out this is a very complex thing to get your mind around. And so we just stare at the at the wall, stare out the window, unable to take any action or coherent action. And then at the end of the day, we feel exhausted and have accomplished nothing. That's a fun one. And then there's the just kind of like accepting it. The gods have forsaken me. Maybe somebody will put me out of my misery. So that's where we wind up. If you're not there yet, but you're not growing very fast, you are likely in a different part of the pain cave, which is, I call, which is what I call LARPing Corner. I don't know if you know what LARPing is, but LARPing, again, I have nothing against LARPing, live action role playing. It is an activity where adults go and reenact medieval battles in the woods. Again, totally fine activity. The challenge is if you don't realize that you are LARPing. Because you think you're in a real battle, but you're just playing pretend, which is what a lot of startups do before they realize they are in the pain cave. These are a bunch of things like doing design partnerships, doing pilots. These are things that feel like the things that successful founders probably do, but they actually aren't. A bunch of pitch competitions, some kinds of accelerators and incubators, if you know, things where you're You know, going and learning in a lot of sessions and doing, you know, oh, wow, we have, we're going to win a pitch competition. It's great. Yeah. It doesn't matter if customers aren't ripping the product out of your hands. Waitlists, partnerships, hiring a bunch of people, building a bunch of product, heads down to build the product and the website, doing a bunch of branding exercises, a lot of planning retreats, VC startup events, you know, all these kinds of things and raising money because it seems like a thing that startups do. Nothing against raising money, nothing against— well, I have some things against most of these, but you can raise money, for example, to find product-market fit. But most of what I've seen is we raise money because a lot of other people raise money and think that the next milestone is raising more money versus when we realize the only thing that matters is customer pulling the product out of our hands, then we act totally differently and think about money differently. And so what usually happens is it might take months, might take years, might, might never occur to us that we are LARPing and we've been just playing around the whole time. So the way to think about this is that basically the pain cave is reality is trying to teach us something. The market is behaving. Customers are behaving in a specific way that is real. There is some reality there that we can learn from. Every startup that takes off figures out something about reality to turn what appears to be indifference into really intense demand. People ripping the product out of their hands and growing super fast. The question is, what is reality telling us? And how do we learn that as quickly as possible before we spend a bunch of cycles in the pain cave? So that's the point today. Like, let's talk about the dynamics of the pain cave, why we wind up there and why this is so difficult. And then we'll come to a model of why people buy things and why startups take off. And then we will jump through to the, so what do I do right now? Which, just to cut to the chase. There is simplicity on the far side of a very long presentation here. If you're like me, you have to understand how the whole thing works. And once you understand, I think, how the whole thing works, then the, so what do I do, is quite simple. And so I will promise you that on the far end of this, that the, the thing to do is simple, but it's not something I can say now. That will, and if I say it now, it won't make sense and you won't do it. And so yeah, let's talk about the pain cave. So I read a bunch of startup books. I think these are all great books. They, they make a ton of sense. There are hundreds of others, not calling out any specific ones here. I think, I think these are great. The thing that happens is we read them, we try to put them into practice. And if our startup doesn't immediately take off, the question is, why? Is it us? Is it me? Am I just incompetent? Do we have the wrong product? Is it something about the market? Is it the playbook? Is it, is it actually, is there actually something wrong with the books? Are they teaching us the wrong things? Or could it be one of infinite other things? Is it something else? How do we know? And what do we do about it? This is where things get really complex. I think of this like, imagine you were, you were sent a bunch of parts to build a computer. I don't know why I picked a computer. You could pick a car, you can pick whatever. You're sent a bunch of parts to assemble a computer and you're, you're sent an instruction guide to follow to put the parts together. Let's say you follow the instructions and then the computer doesn't turn on. That's the exact kind of situation we find ourselves in when we follow these instructions. When we follow these, this advice, it's not clear why the computer isn't turning on. We're in that situation and it's not clear. Is it just the, the instructions are wrong? Is it the parts are wrong? Is it the person following the instructions is an idiot? So it's fairly simple to follow instructions. You don't actually have to know how the computer works. You follow the, the instructions. When something doesn't work, that's when you need to understand how it works, how the computer actually works, what the causality is of the different pieces, how they fit together. And if you have the wrong model in your head, you need to unlearn that and relearn the right model because the computer won't turn on. This is way more complex than just following a set of instru— instructions. And again, like the end model could be fairly simple. That's not relevant because if the end model is simple, but there are infinite possible permutations of that end model. The task is still complex. So what I mean by that is that's where we find ourselves in the startup world, where we follow some sort of instructions or we, you know, get some advice or whatever it is, do something that should work and it doesn't quite work. And we wind up in this loop and we are often given a set of new playbooks. Each time something doesn't work and this cycle will continue until something does actually work or something actually breaks. And so what we need, given that context, given that, that idea of the computer being assembled from parts, we don't need another instruction guide. What we actually need is a model of how a computer works or how, how a startup works. We need to understand how the thing comes together and the causality of the thing so that, not that startups can be easy, but maybe we will hit our heads against the wall a little bit more productively, productively. To that end, I have found that a rough model is not good enough. So the model that we need to be developing has to be pretty precise, like pretty darn precise. An example of what a rough model would be is build a 10x better product. That's a rough, very rough model. It's not clear what 10x means or better means. It's not clear that this actually works, but this is Like feels directionally right, but it's roughly equivalent to like the idea of to get strong, you need to go to the gym, which might be true. I guess it's kind of true. You don't have to go to the gym to get strong, but if you go to the gym and if you go to the gym, you might not get strong. So anyway, like this is where it's kind of like, okay, this is, this is rough. It's like directionally maybe correct. But there are also a lot of cases in which it's not correct. And so it's not super precise. And so in my case, I followed a rough, this very rough model to get stronger where I went to the gym every day, basically for 10 years and didn't get stronger. Then I read the book Starting Strength, which is a very precise model of strength that says, yeah, obvious, you need to lift heavy weights like this. In this particular method, in this particular sequence. And this is the process by which you get stronger. And I was like, okay, once I had that, I finally started getting stronger actually. And so I would recommend reading Starting Strength if you're in this kind of situation. Anyway, given that we need a precise model, question is how do we build that model? So one area to start is what do successful startups do? Well, they do a ton of things. They make, they have fancy websites, they have really impressive products, they raise tons of money often, they do things like OKRs, they work a lot, and it's not necessarily clear which of these things is necessary or causal or which are symptoms of their success. Or which things they are doing are literally preventing them from being as successful as they could be. So if we just look at what a successful startup does, it's hard to tell what is causal. And if we import something, let's say we import OKRs, for example, and say, okay, OKRs caused companies to be successful. So we're gonna follow OKRs religiously. And it turns out OKRs prevented that company from being successful or just didn't generalize. Well, guess what? We're gonna be very rabbinical about OKRs and not take off, and it's gonna suck. On the other hand, we can look into, okay, well, successful startups do a lot of things. Maybe we look at like, why do startups fail? Well, they fail for a ton of reasons too. Co-founders, running out of money, product breaking, fraud, whatever, right? Like, there's a lot of reasons startups fail, but not doing things that cause startups to fail doesn't mean you're doing things that cause a startup to succeed. Causes of failure are not necessarily— like, the inverse of those is not necessarily causing success. Right. Very, I've seen a ton of super impressive, high-functioning teams that work insanely hard, that raise a ton of money and don't build something that takes off. So yeah. What causes a startup to succeed? Well, I've, I've found that the best indicator is watching one startup longitudinally and comparing that. I can't even say that word, but comparing Startups, when they go from not working to working, what actually changes? And what I've found is that it's ba— it's like roughly this, and we'll get into a lot more detail in a second, but when they're not working, they're doing things and customers are roughly indifferent to it. They might say nice things, but they don't act. When a startup is working, the things that start— the startup does convert into customers buying, renewing, acting a lot. And so you think of it as in this stage, they're, they're doing a lot of things, but it feels like they're pushing a boulder up a hill. And this stage, it feels like the boulder is rolling down the hill, right? They don't have to push at all. The, the, there's something that is happening. That's causing their activity to convert into way more attraction. So we have to get into then this question of, okay, what causes that shift? And why do people, why do customers act sometimes? Why do they act as if they want things? Why do they buy things sometimes? And so let's see. This is one of my favorite quotes from Bobby Moessa. Uh, Bobby Mesta, actually. And, um, yeah, he wrote Demand Side Sales 101, which is a great book. He's behind Jobs to Be Done. He says, if you don't know why people buy things, you don't know how to sell. Which is obvious, right? If you don't know why someone buys anything, something, you're not going to know how to get them to buy something. But it's more fundamental than that, because if you don't know why people buy things, You don't know what to build and you don't know what to do. And so that's the context that we find ourselves in. Let me scaffold out the argument that I'm going to make in this section, because it's fairly non-intuitive, I think, and it's against a lot of what we're usually taught about why people buy things. So my argument is that basically everybody that should buy your product would be crazy to buy it. They'd be weird to buy it. That's true. Even if they have pain points, even if they have problems, even if you offer them a ton of value, they would still be weird to buy it, even if they say they want it. Okay. That's kind of, that's, that's one thing. So in that context, There is only one situation that I have found so far in which somebody would not be weird to buy your product, or they would be weird not to buy your product. 3 components. They are currently prioritizing something. This person, person is currently prioritizing something, but they are blocked from doing it by their current tools, methods, options, the things that are available to them. And the third thing is we offer something that unblocks them in this situation. If these three things are true, so basically if they're in a situation where they're prioritizing something and blocked, they're trying to do something and blocked, and we offer to unblock them, offer something that unblocks them. They would be weird not to buy it. They will exert the effort. They will pull the product out of our hands. In any other situation, it would be weird if they didn't. This, just like this, trying, blocked, and we unblock. Those three components are upstream of everything. It's upstream of the product we build. It's upstream of our messaging. It's upstream of everything that we think about in startups. Our growth rate, it causes our growth rate. It shapes our addressable market. It shapes all of those things. This is the exact opposite of how we tend to look at this. And so what I'm going to do is I'm going to try to bust some of these intuitions that we typically have here. How we usually look at the world is— this is my— I am clearly terrible at graphics, but this is the lens we typically look. We start by looking at our product and say, well, this product would solve a lot of problems, provide a lot of value. Our idea would make the world better. Everyone should use this. You should use it. And so the task we think is, how do I convince you to buy it? What's the best way that I can convince you to buy it? Can I poke at your pain points? Can I poke at your problems? Can I tell you that these are really big problems? Can I convince you of the value of our product? Can I come up with a very compelling value prop? Can I come up with a kind of jaw-dropping demo? This seems obviously right, but what we miss is just how many other people are thinking this way for that same target customer or for that same market. There are so many other people who would also like that person, that niche, to buy their products and services, and they also have very compelling arguments. They offer a ton of value. They solve a bunch of problems. They have nice messaging. I don't think we recognize just the scale of this. Think of it this way. Here's the question. Over the last year, how many products or services were relevant to you that you could have purchased? You can think of this in terms of your personal life and just, I don't know, as a rough estimate, I think there are 600 million SKUs on Amazon. Alone, there are 30,000 SKUs in every grocery store you walk into. And most of those are relevant to you. You could have purchased them. So the number, right? Like if you think in your personal life, but then there are, I think there are like 4 million service firms in the US, professional service firms or something like that. Maybe it's more, I don't even know. But so the number is not 20. The number is not A hundred. The number is not even a thousand. It's, it's in the hundreds of thousands to millions of products that— not— these aren't like irrelevant products that if you bought them, everyone will look at you and be like, I don't make— that doesn't make any sense. These are products that would make sense if you purchased them. And services that would make sense if you purchased them. Now, out of that massive pool. How many roughly do you think you bought last year? The answer is basically none. Even if you're a shopaholic, you basically bought none of the products that were relevant to you. So buying is not this common thing. It is weird and rare. It's something we have to explain, like Just again, in a given year, it's not in the, this, this deck, but I saw this down and I was like, oh, that's kind of funny. In a given year, you have a 1 in 1.2 million chance of getting struck by lightning. You roughly have the same likelihood of buying any one relevant product or service for you. It's roughly the same. Yeah, we did it. Kind of make estimates, but it is highly weird and rare for you to buy one specific product, which means we need to explain this in detail. If it was super common, people just buying things left and right, but you know, by default, they're going to buy things that are relevant to them. Not something we actually have to explain because it's so weird and rare and the default state almost all of the time is not buying something that's relevant to you. We need a really good explanation for why people buy things, because it's not something that just happens. At this point, you're probably like, okay, yeah, I get it's weird and rare, but I've seen some very big startups. I've read their histories and yeah, I just need to solve a big problem. Fix their pain points, provide differentiated value, be really good at sales, all these things. These things all make sense and sound right. And if you look at successful companies and read their histories, the words they say and the things it looks like they did will tell you this. I don't think that's actually why they took off. I think it's a plausible explanation, but it's not a cause. And so let's go through a couple examples here of things that we typically think are what cause people to buy. And I'll try to show why it's not actually causal. So first one, build something people want or even need. Right? This is the YC motto. It's a great motto. And it's like a great thing to like, I do want to build something that people act as if they want, but does somebody wanting something cause a purchase? Not really. How many things do you want that you do not buy? The, the vast majority. Of things that you want, you don't buy. So wanting doesn't cause a purchase. Same thing as going to the gym doesn't cause strength. On the other side of that, nobody has ever wanted a CRM or ERP. I don't think anybody has woken up in the morning in the history of the world and said, you know what, Today, I really want to buy NetSuite. I really want an Oracle database, really want Salesforce. Again, I, I get it there. These products are successful, but they're not successful because people want them. And so that tells us that wanting isn't super relevant. Need as well. There's a great quote, think of all the things you need to do that you never do. There's probably way more things that you need to do that you don't do than things you need to do and you do do. So wants, needs are not causal, not necessary, sufficient, or predictive of purchases. Okay, fine. You give me that. But what about solving a problem? Solving, fixing the pain point? Well, how many pain points or problems do you have in a given day that you haven't taken action on, that you're not taking action on? This, I mean, most problems or pain points do not lead to purchases. And then you've also bought a bunch of things that have nothing to do with pain points or problems. So on one hand, life is just a bunch of pain points and problems, and we mostly don't do anything about them or don't buy anything about them. And so pain points and problems are also neither necessary, sufficient, or predictive. Fine. But what about making a 10x better product or making an unbelievable offer, offering a compelling differentiated value proposition? Oh, uh, trust me, I have tried that stuff too. And it turns out there are so many kinds of value. In ROI opportunities and benefits that you could take action on, but don't. And so, like, Jobs to Be Done is another great one. I'm a huge Jobs to Be Done fan, but there are many jobs to be done you do without purchasing anything. And there are many jobs to be done you simply don't do. There are many things you purchase without needing explicit ROI. And so none of this actually is necessary, is obviously causal of purchases. And then you're like, okay, fine. But maybe there's some sort of a threshold effect here where if it's a really big problem, or if we offer a lot of value, or if we, I don't know, if it's a hair-on-fire pain point, they will buy. Yeah, maybe, but there's a lot of cases in which there's a lot of value, a really big problem, and people don't buy. This book is like very good. And it's one of the books that I actually like really strongly recommend. I have a list of books at the very end of this that I actually enjoyed and have been helpful to me. And this book and a couple podcasts that he does. Tells a story of the CISO of eBay back in the early 2000s. They came to him with a technology and the CISO said, holy cow, just on a rough estimate, this would save us $40 million per year. And guess what? That to me, that seems like a really big amount of value. And didn't buy. They never bought. Never bought. There's another case where there's like a really big pain point, it seemed like, where they would take— they took the same technology to people and they'd say, run a POC with us, and we will prove which of your computers is compromised. And it turns out, in cases, they would have their— the company, a big company's CFO's computer, Which is like logged in, accessed, accesses all their bank accounts and a bunch of really, really sensitive information. They found out that computer is hacked and we can prove that the, that computer is hacked and the data is going to this place in Russia and we have the only technology on earth that can solve this. Okay. That to me seems, I don't know, roughly, like what I would consider a hair-on-fire problem or hair-on-fire pain point. And guess what? They didn't buy. That didn't lead to people buying. This seems— if this seems crazy to you, then you haven't internalized yet how weird it is for somebody to buy something and how problems, pain points, ROI, value don't cause purchases. No, matter how big they are. That's something else. This all brings me to the Buffalo Bills fallacy, which is— I'm just a huge Buffalo Bills fan. Had to find some way to work them into here. You could come up with any analogy that would probably work better, but I want this one. So all these things that we think are related to buying are related to buying in the same way that weighing 225 pounds is related to playing for the Buffalo Bills. It's not necessary, not sufficient, not predictive. So like, yeah, there are some players in the Buffalo Bills who weigh more than 225 pounds. There's also some players who don't, and there are plenty of people like my Uncle Rob who weigh more than 225 pounds and do not currently play on the Buffalo Bills. And in fact, have never played on the Buffalo Bills. And so, yeah, this is basically where we find ourselves. As a result, we basically are in this weird situation where all of the things that we typically are focused on, when present, the buyer is still, would still be weird to buy. Our product. I'll say that again. The things we focus on by default, problems, pain points, wanting our products, needing our products, value props, ROI, all these kinds of things, benefits. These things, when present, still wind up with somebody who would be weird to buy our product. The question then becomes, when would somebody be weird not to buy our product? When is this not true? In fact, when is the inverse true? Okay. The outcome, the place we wind up is what I talked about, about 17 hours ago. We wind up with a valuable, high ROI product or idea that people should want that solves a big problem that they agree with, that makes total sense, that they would be weird to buy. That they would be weird to buy. And so that's the pain cave. That's why we wind up in the pain cave by default. And no matter if we add on sales and marketing skills, nothing like that. Like we're still pushing a product onto a buyer who would be weird to buy it. Basically, no matter what we do. So your question becomes, but I, but customers talk about these things in discovery interviews, sales calls, and even when we interview them after they've bought, they talk about problems, pain points, or features, or value, or ROI. My answer to that is just, how do you know? Are you sure? Are you just in, are you misinterpreting what they're actually trying to convey? Do you have the wrong lens? Are you classifying things as pain points that aren't? And is there something that you're not seeing or hearing that they are saying? My sense is that in most cases, we are falling into the Buffalo Bills fallacy, which is we are hearing certain things with a causal model in our head that is actually not causal. And so this changes what we hear and it changes how we act in situations with customers, whether that's interviews, whether that's sales calls, whether that's post-sale. That would— it's like, you know, it's basically like, I don't know, weighing customers instead of asking if they're— if they play on the Buffalo Bills, thinking that weighing them, if they weigh over 225 pounds, They, they are going to buy our product when that's, that's not actually the case. So let's get to the meat here. Who would be weird not to buy? In what situation would somebody be weird not to buy? The way we can get here is some kind of like logical flips. The priority test is the first one. Will anybody say this? You know what? Your product is really cool. Let me drop everything that I'm focused on right now. All my priorities to buy your product. They could say this, but it would be weird though. And it would be weird even if they have problems, pain points, our product would objectively benefit them, add real value, ROI, even if they're very excited about it, even if they say they want it. So this basically negates everything on the left side of the weird to buy graph. Even so, priorities themselves are not enough because No one's ever going to say, I am prioritizing something where your product is relevant. Your product does fit my priorities. And even though I have something that's good enough to get me there, that's good enough to do my current priority, I'm going to buy your product anyway. No, that's, that would be weird. Not impossible, but it would be weird. So they only would buy from us. If they're prioritizing something and their existing options are not good enough in such a way that it's— their options are not good enough that they're blocking them from doing what they're trying to do. And they can be blocked for a variety of reasons. It could be too expensive. They can't, they can't buy the— they can't— there is an option on the market, but it's too expensive. They can't afford it. That's a— or, or it literally doesn't do the thing they need it to do. And then there are like non-obvious ones, vibes and feel as well. I just, I just won't use it. But that's it. Okay. So priority blocked. Those two things, do those make somebody weird not to buy? No, still no, because nobody's going to say, okay, I'm trying to accomplish something and I'm blocked by my current options. Doesn't seem like you have anything to do with this. Like, it doesn't seem like you could help in this situation, but I'm going to buy your product anyway. That again could happen, but would be weird if it happened. So if they're prioritizing something right now, they're blocked for some reason, and we offer something that they perceive to be totally irrelevant, they'd still be weird to buy our product. But if we offer something that promises to unblock them in this situation, that's when they would be weird not to buy it. And this kind of loops a little bit further. So, right, like I'm trying to accomplish something, I'm blocked by my current options. Seems like you unblock me, but X doesn't quite seem to unblock me. X doesn't quite seem to fit what I'm looking for. Right. And so it's kind of like every single piece of what you offer, what you deliver. Has to fit with what they are trying to do and unblock them in a way. And so if, if, right, like, if they're like, oh yeah, everything fits except for pricing, well, then they're not going to buy or it's going to drag out. And so they still like, they might not buy, which means everything about your business is downstream. It could be functionality, right? Like everything about your business is downstream of customer trying to do something, blocked from doing it, and you unblocking them. So these are the conditions for We're Not To Buy. There's a person where, who's in some sort of situation where they're trying to do something, but they are blocked by their existing tools or the available tools, methods, options. For some reason, some specific reason. And then in this situation, again, they're stuck. They're stuck trying to do something, blocked from doing it the way they want to do it. And we just show up offering something that unblocks them and they rip it out of our hands to get their thing done, get this thing done. That's the conditions for weird not to buy. There's some ways to visualize this in your head that I think will be helpful. I'll give you two. There are plenty more that you could come up with. I think of a dam. And so when there is pull, when there is this situation where they'd be weird not to buy, they're trying and blocked, and we just have to show up and unblock them. So they're trying and blocked. It's like water against a dam where there is a force of water that wants to go this way., but it is blocked by something. You can see there's force there that we unblock. We open a hole in the dam and water comes out the other side. It's not pole if the water isn't even reaching the wall, right? There's no force against the wall. So if we poke a hole here, Nothing happens. No water comes out. That's fine. There's a wall there, but it's irrelevant to them. Or on the other hand, if they are, if there's no wall and the water's just going where it wants to go, that is a force that is not blocked. So moving, but not blocked. In that case, drilling a hole in You know, in some random wall that's not anywhere near here is irrelevant. Second visual for thinking about this is the boulder on a, on a hill or on a surface. And so if they would be weird in a situation where they'd be weird not to buy, it's, there's a blocked force where the, the boulder is on a hill. It's on a decline. The boulder thanks to gravity, wants to go down the hill. And, but there's like a stone in the way such that the boulder can't go where it wants to go, where it's trying to go. And so there's pressure there that if you do something to the boulder or you do something to the blocker, the boulder is going to roll down the hill. There's no pull if there's no boulder there. Blocking it. There's no blocker there blocking the boulder. Should have come up with different words, but, um, because it just comes down to the bottom of the hill and there's no force here. If the boulder, when the boulder's at the bottom of a ravine, it doesn't want to go anywhere. It's not, it's not trying to move. And so yeah, hopefully these give you a set. There's, there's like these forces that are at play trying blocked from what I'm trying to do, that those forces exist with the customer in the customer's world, totally independent of us existing. If they exist and we offer something that unblocks them, they should pull the product out of our hands. The energy comes from them. So to summarize, everybody would be weird to buy your product unless they say, I'm trying to do this thing right now, but my current options are blocking me for this specific reason. If they say this and your product solves it, if your product unblocks them, they'd be weird not to buy it. This leads to what I call the PULL framework, which are the 4 conditions that must be present for somebody to pull the product out of your hands. If these are not present, then they'd be weird to buy. So one is they have some specific thing they are trying to do right now. I call that project. This is going to be an acronym because it's hopefully more easy to remember. Uh, there's a specific project, something they are trying to do right now. Imagine almost like a Trello board or a to-do list or something like that. What's the— there's a contents of the thing that they are trying to do. That's, it's not just like a, you know, it's, it's not just a formless thing. It's a, you know, there's a specific thing I'm trying to do. Second is U for unavoidable. That right now we can't not do this. We're in some sort of a situation where not doing this would be weird. It's our number one priority in that situation. And then on the other side, we have the Ls, which are, we have a list of options that are available to us that we've considered, tried, maybe things we already have, and those must be blocking from getting the project done for some reason. That's limitations. So you can look at it this way as well, where it's okay, who is the person who has pull? What's the project? What's the thing they're trying to do? What's the situation they're in where not doing this would be weird? What options have they looked into? And why are these options not good enough? Therefore, right? What's the thing we offer that can unblock them in that situation? I'll walk through an example here for a company called Jump, which, as you'll see, does AI note-taking for financial advisors. That's where they started. They grew really fast and they're adding a bunch of other things. But when they found customers, those customers were in a situation, they were, you know, financial advisors. We just imagine like a solo financial advisor or a small firm of financial advisors. They're in a situation where whenever they have a client meeting, which they have multiple client meetings every single week, they must take notes and put those notes into their CRM. Otherwise, the SEC can show up. Ask for their notes, ask for their documentation, and they can get a big fine or something bad can happen. So it would be weird if they weren't taking client meeting notes, but when they're taking meeting notes and entering them into their CRM, they're trying to minimize the amount of time they spend doing that because they don't want to be doing that, but they have to be doing it. And so they could keep doing this manually. They could totally keep doing it manually, but that's not minimizing their time. That, that, that's, they're blocked from minimizing the, their amount of time if they keep doing it manually. And so they could also use a generic AI note-taker because those are on the market now. There's a bunch of them, but when they're using a generic AI note-taker, it's not clear if that's SEC compliant. And it doesn't integrate with their CRM. So it's not really actually minimizing their time. And it's not really, you know, it's not really clear that it fits what they actually need. So they are stuck in this situation. Again, this is all happening before Jump exists. All Jump has to do is show up and say specifically, like this tells them exactly what to sell. We sell an AI note-taker that is particularly designed for financial advisors that integrates with your CRM and is compliant with all the SEC requirements. When they say that, customers who are in that situation, it's like the, the, the water against a wall, water against a dam, right? That unblocks them and customers rip the product out of their hands. So zooming out, we now know when somebody would be weird not to buy, where most of the time they would be weird to buy. Somebody would be weird not to buy when they're in a situation where they're trying to do X right now, they're blocked by their existing options for some, some reason, reason Y, and we show up and unblock them so they can do X. It's all of this here. The choice then becomes this. We can push on people in this situation where they totally could buy. And in our minds, they totally should buy our product, would benefit them. They'd get real value out of it, but they would be weird to buy. Or we can focus build our ICP around and our product around people who would be weird not to buy. They're in this situation where they're stuck and they will rip the product out of our hands. Now, the trade-off here is that this seems like a bigger TAM, a bigger addressable market, but it's very hard to convince somebody to drop their priorities or use us when they have good enough options for whatever they're doing. And so what winds up happening is this is a theoretical, theoretically bigger TAM, but in practice, everything sucks. It's hard to sell. It feels like you're convincing. It feels like they're nodding and not buying and they're ghosting and sales cycles are long and everything's a very, you know, frustratingly long process. Or you could choose a kind of like smaller market, which I think of as the center of your bullseye market, who you focus on pretty exclusively, where they're going to rip the product out of your hands. And yeah, it seems smaller, but over time you'll probably learn things that'll make that bullseye bigger and bigger and bigger. This is the choice I'll let you choose. And I'll just mention this down here. You're often told to niche down. Which makes sense in theory. But if you niche down to some segment that you want to sell to, it's irrelevant because they might not be in a situation where they're weird not to buy. So again, this is upstream. Their situation, trying, blocked, where you can unblock them, is upstream of your niche or your target market or anything like that. It, that determines who is going to rip the product out of your hands and what you should build. I think this is clear, but the way to think about this is that unblocking them is like the dam bursting. The energy from this comes from the water. It comes from the customers. It does not come from us. We're not there. The dam's not pushing the water through necessarily. Like it's, it's, the whole, like the water's force is what is causing the startup to do it. Anyway, you, you get the metaphor here. This is why I call it like, I think of it as like the physics of charts because these are these forces that when we unblock them, the startup takes off, the water comes through the, the unblocked dam. What this does in our minds, this has a lot of downstream consequences and I'll focus on a couple. High-level ones, and we'll get into more later, but this changes the, what I call the causality of buying. In our heads, we think that there's what I call push theory, where we cause them to buy. It's something that we do that, or something about our product that convinces them to buy. But in this case, you can now hopefully see that This is an attempt to push a product onto somebody who would be weird to buy it, trying to convince them to drop their priorities, to change their priorities, to, to, you know, use us even though they have good enough options. And this is true even if they have problems and pain points and we provide value, it's still us trying to convince them. When in reality, what causes a purchase is a buyer trying to get unblocked from doing the thing they are trying to do. We are working with their priorities. We are unblocking them when their existing options are not good enough. And so this changes how we think about the causality of buying, which changes how we think about basically every step of the startup process from idea stage to how do we validate ideas? What do we sell early on? How do we sell? When do we sell? How do we think about all these things? And how do we, you know, what do we even deliver? When somebody is weird not to buy, it's a totally different feeling in a, when you're dealing with a customer. So push theory versus pull, the feeling in a conversation with a customer is entirely different. In the push model, it always feels like I am trying to convince you with my words, with my product, with, right, like about how awesome it is, why you should want it. It feels again, like I'm pushing, I'm persuading. When you find somebody in a situation where they are trying to do something but blocked from doing it, it feels like they are asking you for help. It feels like they are pulling the product out of your hands, which changes the sales cycle length. It changes like everything. If you're not sure at this point, well, you know, I do have a 13-slide sales deck, which has da da da da da, and it does feel like people are nodding. It feels like they really get it. They say they resonate with our vision, right? Here's some signals that you're pushing just so that it's very clear. If you are avoiding sales or if you dislike sales, it is probably because in your mind you think it's, you need to convince this person to buy something and you do, that feels uncomfortable. That's a signal that you're pushing. If you're waiting to sell until the product is quote unquote ready, that's also a signal that you're pushing. I'll get into that more in a little bit. If you think you choose your ICP versus The situation defines your ICP. That is also a signal that you're pushing. Just generally how you approach sales, you're pitching, persuading. If you have very long demos, if you describe your product as a big platform that does a lot of things, you're trying to convince them to buy. It's also when somebody doesn't buy. If you take, if you experience somebody not buying, as rejection, then what are you thinking the cause of a purchase? You're thinking, oh, I didn't convince them or they didn't like my product or da da da da. Like if you experience that as rejection, that's a signal that you are pushing. And if you aren't growing as fast as you want to grow, you think that the solution is to build more, get better at sales, improve your messaging. All of these things are ways to convince people.. So the end result is, if you're in a situation where things make sense, but customers aren't buying, or they're not buying super fast, even if it seems like they should, that's a signal that you are pushing. Let me walk you through a case study of push to pull. So I recently did a newsletter with, with these folks. And this is just a summary of the newsletter, where RockSalt is a modern inbound tool for B2B. On LinkedIn and Reddit designed for CEOs, subject matter experts to grow their following with a little effort. Before, when they were pushing, they had this situation where they're like, well, this is a modern inbound platform. We have a thesis about how inbound is changing. It's no longer people searching for things on Google. They don't really trust a lot of the content out there, especially because a lot of it's AI generated. They trust people now. So people, social, on social, are top of funnel, even for B2B. And so given that, who should we sell to? Well, there's, that's basically technically relevant to every B2B company. And so maybe it's people who care about LinkedIn, maybe CEOs, maybe CMOs, agencies. They started with the CMO for totally logical reasons. Those people have the pain and they own the number for top of funnel and they're watching organic traffic take a nosedive. In their sales calls, they focused on their thesis of how inbound was changing and people, it like deeply resonated. And CMOs would sometimes sign up. They would try to get CEOs to use it to post on LinkedIn. And occasionally it worked, occasionally it didn't. And so the question was like, okay, how do we get better at sales? Or how do we make our product better? How do we make our message even more compelling? But that was, of course, now you could see hopefully that that was the wrong question. Instead, we had to ask the question, anybody who cares about LinkedIn could in theory buy, but who is the specific person who actually has demand and is blocked, who is trying to do something and is blocked from doing it such that they will buy and use and not churn. It turns out that was not a CMO. It was a CEO or something, you know, C-level subject matter expert who is trying to post regularly on LinkedIn, but struggling to be consistent with it. They don't have a way to be consistent with it. So maybe they're posting once or twice a month. Maybe they have like a couple thousand followers. So it's, it's clearly something they, they wanted. They clearly have something to say. They want to say it. They're struggling to be consistent. In this case, they focused. They didn't play like kind of scrap the entire thesis. These people already knew this. They already believed in it. They didn't need the thesis. They just focus on what the CEO was trying to do on LinkedIn and why they were blocked. And when they found these people, the CEOs would rip the product out of their hands in a very brief sales call that had none of the like big platform vision, none of the big thesis. People were already bought in. They were trying to post more on LinkedIn, but they were blocked from doing it. They were struggling to be consistent. And so they saw a bunch of positive results from it. And obviously they did, because this is a person who was trying and blocked. So they rip the product out of their hands and use it. In this case, nothing they would really do, right? Like, they're selling to a bunch of people who might buy it, who could buy it, who, but like, wouldn't necessarily even use it after buying it. They, they had to then go and convince somebody else to use it. And those people would be weird to use it. Yeah, they'd be nice, but not actually, like, that's not why people wind up using it. And so this is also not just B2B. The, I talk in B2B because that's the world I live in. I've also seen this apply in a variety of different circumstances. So B2C, there's still pull for all sorts of B2C products. Again, like the B2C products still find pull. In B2B, one of my favorite examples is Workday, right? Workday is the bane of everybody's existence and, and nothing about the product that seems to explain why Workday succeeds. Pull does marketplaces as well. We can get into that if anyone's interested. But yeah, it's like, you have to— in marketplaces, often one side has pull to get access to the other side. But the first side, and because of that, if you have side one, they will bring on side 2. And so you just had to figure out how to bring side 1 on and figure out what their pull is that will bring them on when it might not be access to side 2. And so that, that kind of like changes the dynamics on marketplaces. Marketplaces suck, you know, uh, because they're super complicated, obviously valuable, but like really hard to do anyway. So that explains different kinds of end customers. This also works for products and services. So there's a project of, well, stopping bugs from reaching customers. This is what I'm trying to do. Okay, this could lead to buying software, buying human services, buying a variety of different things, you know, like it's, it's just a project. And then the, on the supply side, it just depends on what are the different options there. This also, you know, works for one-off purchases. Works for repeat purchases, works for subscription purchases. Um, uh, I'll talk about this a little bit later, but like we, I had a project on my to-do list, which was never be without the ability to pick up my daughter from daycare when the other parent is using our current, our only car and is down in Boston. Okay. So like, that's a specific project, but that could have led to a one-time purchase of a car. It could have led to repeat usage of Uber or a subscription to something like Zipcar. So, right, this is upstream. And then, yeah, it doesn't have to be— there's no reason that a project on a to-do list has to be rational or even consciously stated. I encourage, like, I think what you'll find once you have this pull framework in your mind is as you do things and as you buy things, things, try to fill it out for yourself. Try to fill out what your pull was, what your project was. And what you'll find is that the reasons that you do things are, are, uh, we'll just say interesting. They, they're often interesting even to you. And they, they're not the things you have to think about to really understand what you were trying to do in that moment. So it's, again, when I talk about projects on to-do lists, I like, You could think of that very literally of like what is actually on your to-do list right now, but nobody keeps a to-do list that's up to date. Some people do, but like not really minute to minute. I'm talking about the to-do list, the project that is in the buyer's soul, the thing they're really trying to do at any one point in time that's revealed by what they actually do. And then this can also work for feature development. This is also a fractal concept. So, you know, it's not just for full products. What I've seen is that teams in their PRDs, like product teams, for example, use POL to articulate the demands behind the thing that they're going to build, and they use that as the thing that shapes the feature. And so if you're not familiar, I'd recommend reading Shape Up Chapter 2. I think it's great. So now that you know that this trying blocked thing exists, just do me a solid and stop. At least don't say them to me. Don't say pain points or problems because, or vitamins and painkillers or whatever, because it will confuse you. You will be focused on the weird to buy side of the world by default, and it will make me angry. Just makes me so angry. Okay. So let's dig into the framework then. Start with part 1, situations and priorities. So the only way on earth to understand a priority is, well, it's, it's, we're going to basically create a rule here. The rule is going to be this, that priorities projects, things on their to-do lists cannot have anything to do with a product or a feature or a service or anything like that. And the reason for that is because when you do that, it creates this circularity. So like, let's say I need to buy a CRM right now. That sounds like a priority. That sounds like a project on my to-do list. But it confuses you because it focuses you in the product and around the product versus in the customer's world and their— and what they're actually trying to accomplish. And so, like, it creates this circularity, which is, okay, if buy a CRM is a priority, what does success look like? I bought a CRM. Great, cool. That's— that doesn't tell us what success actually looks like. It doesn't tell us what they're actually trying to do. And if you ask, why are they buying a CRM or why did they buy a CRM? They'll say, oh, well, we needed this feature or that feature. And we're stuck in the product where on the other hand, if we create this rule that it can't be about products or features or services, it's gotta be about stuff in their world. Then they won't say, okay, my priority is I'm going to buy a CRM right now. No, we're going to understand that slightly differently. It's, I need to be able to forecast how much revenue we will close this month. That is a priority. That is something that's in their world. It's not about a product. And we know then what success looks like. Okay. I can forecast, right? Like I feel confident in my forecast this month and we can understand why this is a priority. Now we're in their world and we can work backwards from it where they were in a situation where da da da da da happens. You can imagine what happened then. As you can see, right, like, this gives you way more useful information for what the product needs to do. And when you need to reach out to this kind of person and what you need to say versus just the buying a CRM. So this is, this is why we create this rule. This rule helps us understand what they're actually trying to do, what they're actually trying to accomplish. And so this rule, we can kind of like break the world down into demand and supply. The demand side, the supply side, two concepts from economics, but we're going to use them a little differently here. Where on the supply side, we have the products, services, features, all the things around our product. Um, it's value prop, it's benefits. It's like all these kinds of things. Then demand is this totally separate part of the world. You split the world and demand is what they're prioritizing, what they're trying to do in their life, in their job. So the rule that we created on the last slide is basically that demand is not wanting supply. I want a CRM is wanting supply. That's not what demand is. Demand is this standalone thing. I want to be able to forecast for next month, right? That is something that could instantiate a CRM, or it could just be a better spreadsheet, or it could be a variety. It could be a consult. It could be a variety of things on the supply side that could fit or serve that demand. But know that demand is this separate thing. Demand is not wanting supply. A feature request. So when a customer says, I need, or I want this feature. That is not demand for a feature. That is a request for supply. This is a really, really important concept to, to really think about. Demand, then, is this thing that's out there in the customer's world. It's not something we create. It's them, right? Like, this is what I talked about before. It's trying and blocked. That's on the demand side. They're trying to do something whether or not we exist and they're blocked whether or not we exist. We have to go out there and find this out in the world. It is not caused by our product existing, but demand causes supply to be relevant or not. The best video on earth. This is the one that started making me understand startups when I was in the Depth of My Doom in the Pain Cave is this video. It's linked here. I just recommend watching the whole thing. This is where they described supply and demand in a way that caused me to come up with everything else that I've come up with in this. It like finally made it make sense. And this is what happened right before our startup took off. And so I could kind of understand what was going on. So they describe How demand is not wanting supply and how a feature request is not demand. In this case, they had the, so these are, so Ryan was the head of product or something at Basecamp, the project management software, and they would get feature requests from their customers. They had a ton of happy customers that weren't in the pain cave at all, must be nice, but they would get a bunch of feature requests and they had to figure out what to build and what to prioritize. And so they got feature requests Like this, I need you to add permissions in Basecamp. Add a permissions feature. Now you hear that and you think, oh, that's demand for a feature. It's like, no, that's not, that's supply that I want. What they did is they didn't just go and build permissions because 40 people asked for it. They went and tried to figure out what was happening on the demand side that caused them to make that feature request, that caused them to request supply in that way. Well, it turns out one of the customers was working on a project in Basecamp where they had a contractor on. The contractor finished their role in the project and pressed archive project in their version of Basecamp, didn't realize that that would archive the project for everybody. In which case everybody else on the project, because the project was still going on, freaked out 'cause now the project had disappeared. And so that's when they put the request in for the feature request. That's when they said, all right, let's have a meeting. Let's put in a request with Basecamp for a permissions feature because that's what we think would prevent this. That is them requesting supply. In this case, their demand is not that. It is actually, I just want to make sure that one person doesn't accidentally archive the project for everybody. Now, once we understand demand, it might be that a permissions feature is the right thing to build, or maybe we could build a warning whenever somebody clicks the archive button. It says, are you sure this is going to archive the project for everybody? So you can see here that when we understand demand, when we actually understand the situation, what they're trying to do, why they're blocked, what they're really trying to accomplish, and don't conflate that with them saying, them talking about the supply they want, we can build something that is elegant, that actually fits their demand better. Nobody wants to go through and configure a permissions part of the application to prevent contractors from archiving projects. And that would be a lot of development work. It'd be a— it would touch every part of the product. It's just a lot to build. And instead, this would take a couple days to build and be a better fit for this demand. Way easier. Like, it's just— and it's just way better. And so you can see now how important this demand concept is. This happens at the feature level, but it also happens at the product business level. From the supply side, we— the— what I talked about earlier, the way that we typically see the world, we typically look from the supply side. We are blinded by our products, services, our features, and thinking about who should want it, who would benefit from it, how much better the world would be if they used our product. The pro— we, we, from our supply side, we look at the priorities they should have and the things they should care about, the things they should want. And all of this stacks up to prevent us from seeing real demand, which is what, even if our product doesn't exist, what are they trying to do and blocked from doing in their own life? We have to ignore our product temporarily. We have to ignore the supply side to see the demand side clearly. Otherwise, We just see what we want to see, what we want to be there. When we understand demand, it also explains quotes like, you know, customers can't tell you what they want, the Henry Ford, Steve Jobs type quotes. Customers don't know what they want until you show it to them. Right? And then what I hear a lot is, well, we're building something that is category-defining. It's a new category of product. There's a new thing that people have never seen before. So how could they know if they want it? It's like, yeah, the— you're talking about the supply side here. The supply side can be totally new and innovative and different, but it will only work if the demand side exists before. If it exists out there in the world, they're trying to do something and blocked from doing it. And they're not about wanting a product. It's about trying and blocked. My last point on demand, I think, is that demand is— I think of demand as this hidden concept we were never really taught about. Imagine that basically every business is riding on top of an elephant that we're not, we're just ignoring. And the elephant is going where the elephant wants to go. But when we don't see the elephant and we look at it and the business is doing a bunch of things on top of the elephant and they all seem to be working because the business is moving in a direction. The elephant is going where the elephant wants to go. The business succeeds if it's working with the elephant. It gets thrown off the elephant and crashes and burns. If it's not working with the elephant, are we just missing this elephant entirely? And this is why we look at the things that a successful startup does and we tend to miss what's underneath it that's causing it to actually work. And so we copy the things that this business does and it doesn't work for our elephant because we're not riding on an elephant. We haven't found an elephant, right? And so if you don't see the elephant, here, that hidden elephant. It doesn't make sense. Nothing makes sense. Understanding demand is seeing the elephant. So let's talk about priorities. So because we are human, think about texting and driving. Why doesn't that work? Well, it doesn't work because we can't do two things at once. We can only do one thing at a time. So priorities are, we at any one point in time, we can only have one priority. We have, like, imagine a Trello board. On that Trello board, we might have an infinite backlog. There are so many things that we would like to do, but at any one point in time, we can only do one thing. Same is true if we look at this a little bit differently. We're not looking at a calendar, but we're looking at a repeated process. Right? So for Jump, the AI note-taker, for them, every, right, like, every, every time a financial advisor has a client meeting, there is a workflow that is kind of like triggered where they have the meeting, but before the meeting, they have to review notes, they have to create the agenda, then they have the meeting, they have to take notes, and they have to enter those notes into the CRM, and at any one point in time, In that workflow, they're going to be doing one of those things. That's, and that's the priority right now. While there are infinite things they would like to also do, it would be weird if they weren't doing this at this point in time. So the question is, if we have an infinite backlog of things that we could do, why do we do what we do at any one particular point in time? Why does one priority win over the infinite other ones? There are, again, infinite backlog items competing for priorities. So at any one point in time, they could in theory prioritize something relevant to us, but they could also in theory prioritize literally anything else. We can get stuck in this position until we ask a kind of inverted question. What's the situation that they would be in such that it would be weird if this wasn't their priority, wasn't the thing they were doing right now? This is a really important question because again, if we're like, imagine you're doing outreach, imagine you're trying to, to find potential customers and you're reaching out to people who could in theory prioritize, be prioritizing this right now. They are, it is, it's possibly a priority to them. Well, infinite other things are possibly a priority to them. Right now. And so it probably, right, like if you talk to any one of those people who could be prioritizing it right now, the default state is they won't be prioritizing it right now and you'll be wasting your time. And so we have to flip this and focus on some sort of a situation in which it would be weird if this wasn't their number one priority. Let me give you a couple examples. There's a situation that many of us have been in where you have an enterprise potential customer who says, this deal is going to happen, but it will not happen unless you have your SOC 2, unless you give us your SOC 2 report. At that point in time, it would be weird if you didn't prioritize SOC 2. You could have prioritized that at any point in time previous to that, but at that point in time, it would be weird if you didn't prioritize it. Another example, um, from my friends at Sparkwise, learning and development team just led a group training to a small group of 5 managers, and the training went super well. It was great. And then some senior exec says, great, now we have 1,000 managers. We have 500 managers. We need to scale that same training without making it some sort of like a video training. We need, it needs to still be as engaging. We need to scale that to 500 or 1,000 people and we need to do that in the next couple months. And they don't have enough facilitators to do that. At that point in time, it would be weird if the learning and development department didn't prioritize figure out how to scale this group training. There's other kinds of situations. Someone was telling me about the HVAC hiring situation. Where in the HVAC industry in the US, it is chronically understaffed. The most HVAC companies have way more demand for, from their customers than they can literally physically serve. So they're in this chronic situation where it would be weird by default. It would be weird if they weren't prioritizing hiring. It's a structural situation. Whenever you talk to an HVAC company, they're going to be like, yeah, I'm always thinking about different things we can do to, to hire. They're in this kind of like structural situation where they have pull for something that helps them hiring. Or there's kind of like a marketer who has historically relied on SEO, who is watching SEO traffic go down every single month from traditional sources. Right? That's a person in a structural situation where it would be weird if they weren't prioritizing something along the lines of displace my SEO traffic source. So this is how I like— yes, people could buy your product, they could be— they could prioritize X right now. But we need to design around situations in which it would be weird if they weren't prioritizing X right now. We own those situations. So let me, let me show you a couple of examples of the situation. Um, so I live in rural New Hampshire. We have one car, or we had one car, and sometimes one of us needs to go to Boston. When we had our first kid and maternity leave was ending, Daycare was starting. We realized that at some point one of us is going to have to go into Boston, which would leave baby at daycare and the other at home without a car and without a way to get there. And so at, in that kind of a situation, it would be weird if securing another mode of transportation wasn't prioritized, which Eventually that situation led me to show up to the dealership. And again, I don't think anybody on earth has ever wanted a Honda CR-V, but I was— they could have, they could have had me do literally anything and I would have walked out with the CR-V. I would have done it and walked out with the CR-V. I could have licked sandpaper. Another example here is a financial advisor, which we talked about. They are required by the SEC to maintain notes. On each client meeting. So it would be weird if they weren't filling out notes in a CRM or somewhere after a client meeting. And then finally here, a VP of sales. I'm gonna give you a couple different permutations here. Now, in theory, so a VP of sales always wants to do stuff to hit their number, to grow revenue, but that's a reason to do infinite things. And also, it might not be a reason to do anything because like, there is a situation in which I believe by executing our current plan and keeping focused on that, I am confident we're going to hit our numbers this quarter. In that case, it wouldn't be weird if they did nothing. They could do— she could in that situation do a variety of things. But in practice, she's probably not going to. There's another situation in which I've decided that I can't hit this quarter's number doing what we're currently doing. In that situation, it, it would be weird if she didn't try something different. Now there's an infinite array of things she could do, and so we have to get a little bit more specific. I've decided that the only way to hit this quarter's number is to increase our win rate where we have to migrate from a competitor's system to ours. So in that case, there is— the priority becomes way more specific. Okay, how do we increase our win rate? Do we offer white glove migration? Do we offer free? Do we offer paid? How do we do this? Right? But if we've decided this, if we're in this kind of situation, it would be weird if she didn't prioritize this in that structural situation. Okay. So we've talked about situations and priorities. Let's talk about what blocked means. We're going to go back and I'm going to give you an example again from Jump in the financial advisor case, where this is that workflow where for every single client meeting, I have to take notes. I have to prepare for the meeting, create the agenda, take notes, and enter my notes into the CRM. Now, this is what I am literally doing. Am I blocked? I ain't doing it. Well, it depends what is actually on my to-do list as I am doing these things. There's one case in which right now I'm entering notes into my CRM and it takes 40 minutes and I'm doing that. And what's on my mind is I wanna minimize the amount of time I'm spending doing this. And I'm basically fighting against the, my to-do list and what I'm actually doing are fighting. I'm blocked from doing this with the least amount of effort. I ideally would like to not do this at all, spend almost no time on this at all. In that case, I am blocked from what I really want to do. The other option though is I savor the opportunity to type with these two fingers into my CRM. There's nothing better than doing this after a client meeting. In that case, I'm not blocked. I'm totally good in that situation. So I am not blocked at all. Poll conditions are not met. It would be weird if I bought something in that situation, changed what I was doing. So let me give you a couple of good and bad examples of trying and blocked before we get into different— there's a couple of different kinds of, of being blocked. And so, um, Jim, a solo financial advisor, is trying to buy an AI note taker because he wants one, but he can't find a good one. Again, that seems trying, trying to build an AI note taker, buy an AI note taker because he wants an AI note taker. But he's blocked because he can't find a good one. Seems like it fits the category of things, but this is a bad example because this is about supply I want. This is not demand I have. Michelle, the CRO of a cybersecurity company, is trying to hit her Q2 revenue targets. Trying to hit these revenue targets. Okay, cool. But we don't know if she's actually blocked. Michelle, the CRO of a cybersecurity company, is trying to hit her Q2 revenue targets, but doesn't have enough pipeline. Like, okay, we do have this stuff here, but this is, there are basically infinite supply options that could work for this, that could fit this. Could be, yeah, like there's, and so we need to get way more specific because it could be, oh, let's get a lead gen agency. Oh, let's, I don't know, let's have reps do da da da da, like, you know, there's a variety of things that she could do in this situation. So the poll conditions are not met. A good example is Jim, a solo financial advisor, is trying to minimize his time spent on meeting note-taking before, during, and after every client meeting, but the existing AI meeting note-takers are not SEC compliant and don't integrate with his CRM, so we can't use them. Okay, that's very specific. Try and blocked. Or Michelle, the CRO of a cybersecurity company, is trying to make sure that every rep follows the sales playbook. In every single call so that she can hit her Q2 revenue target, but she doesn't have enough time to watch every call and compare versus her sales playbook. So she's— but DIY, so basically DIY does not work. It doesn't seem like anything else does here. That fits and it's clear. We'll get to supply in a second, but it's clear. Trying blocked. Want, like, needs something that would unblock her. So there are two different kinds of blocked, and I share this because I tend to find people think about this in not quite the right way. The first kind is literally, I am blocked from doing anything. I'm not taking action on it right now because I'm blocked. I would prioritize this thing if I was not blocked right now. So if you look at my calendar, if you look at what I'm doing, if you watch over my shoulder, you won't see me doing anything related to this, but it's the thing that I would do if only I could, but I'm blocked, so I can't. That's a, like a, that's a, that's what most people think when they think blocked. This way though, the, the jump example that I gave earlier where they're manually taking notes. But they're in that situation, they are still blocked. They're taking notes, but they don't wanna be taking notes. So I'm doing something right now, but I'm blocked from doing it the way that fits in a way that fits what I'm really trying to do. So in that situation, you can watch over my shoulder and you'll see me doing the thing and it, it might seem like I'm doing it quite fine, but I'm actually blocked in that situation. Such that if you offer something that unblocks me, the dam will burst and I will rip it out of your hands. These two kinds of block, you can see, I'm going to give you two different examples of them, um, from just popular tech companies. So Uber, most of us, me included, back at the time, we're like, okay, Uber's market size is just, they're just going to take some percentage of the taxi market. But that's focused on the people who are traveling right now, but blocked, right? They are, they're going in a taxi and they're, they're doing a specific kind of travel, right? Like it's, they're taking share from taxis. I'm going in a taxi, but I'm blocked from what my priority really is. Like, I just don't, I, you know, I'm, I'm, the taxi is blocking me in that situation. For some reason, Uber shows up and I switch, but I was already going in a taxi. I was already going there. Well, there's another kind of, of blocked that Uber also tapped into, which radically grew their market, which was, well, there are other kinds of ways that I was going from point A to point B, right? Maybe I was driving myself, but now I won't. And so there are like a variety of different kinds of things, times in which I was going somewhere, but, but I was blocked from going there in the way that I wanted to. And then Uber unlocked that. But then there was a huge category of people who would be going somewhere, but because they were, they were sufficiently blocked, they weren't, they stayed in. I would be going out with my friends right now, but I'm not going to, because it's too much of a hassle to get a taxi. Too much of a hassle to walk, too much of a hassle to drive, right? Well, now that Uber is a thing, okay, I, I go from not going out, where it's, it, I am literally blocked from doing the thing I want to do, to now going out. Same here is true with like Lovable and Cloud Code. Cloud Code, people who use Cloud Code, like earliest adopters, were people who, if you watched over their shoulder, They were coding before, but they were blocked from what they really wanted to do, which was like build the product faster. And so QuadCode unblocked them. You watch over the shoulder, they're doing the thing, but QuadCode comes around and they rip it out of your hands because they were blocked from what they were really trying to do. Lovable, on the other hand, was for people who were non-technical. Who want to build websites and apps, and let's just take on the website example. They're like, I did not want to use Squarespace or Wix or whatever, because it was just so much hassle. So you wouldn't have seen me building a website, but it wasn't because I didn't want to build a website. It was because I just didn't want to use a website builder. It was just way too much hassle. So I wasn't doing the thing that I wanted to do. All right, let's jump to supply. The concept of supply. Once we know that they are trying to do something and blocked, the only thing that matters in that point, at that point, is that we unblock them. We offer something that obviously is the unblock for them. So let's imagine. That we're taking me. I'm trying to build my new app idea or my new website as fast as possible, but I can't code and don't have the patience or skill for a no-code builder. In this situation, what supply should be described to me? Should it be, we're building the future of apps that's enabled by our proprietary cloud sandboxing technology and our own AI hardness. That enables anyone, everyone, whether you're a developer or not, to build scalable and secure products. No, you've lost me through this. This is a lot of— the other side, you can say we offer an AI app builder where a non-technical person can build an app from a prompt. This is a clear thing that unblocks me. This is a word salad that I don't— that you lose me in. So the formula for supply If pull is, I'm trying to accomplish X, but current things are blocking me because of Y. Supply is, we offer Z, which helps you overcome Y to accomplish X. It's how we describe our product. That's what they, that sets their expectations for what it's going to do, what it's going to deliver for them. And that's it. Everything other than that is drowning them in details. That cause them to think, ah, maybe this thing doesn't unblock me. Our goal, and this is very counterintuitive because from in the push world, we want to describe the biggest possible product that can do the most possible things and add the most kinds of value, thinking that that will convince them to buy. We do the exact opposite here. We want to describe the smallest possible thing that unblocks them so that they can rip it out of our hands without thinking too much about it, because it's the exact thing that unblocks them in this situation. Anything else, basically, again, if we're thinking physics, anything else is not aerodynamic. Additional concepts, additional words, our vision, our thesis are additional things they need to understand when really they're trying to do X, but being blocked by Y and need something that unblocks them. This also helps us understand why the traditional way— this is nothing against Eric Ries, like the concept of minimum viable product is correct. We just apply it incorrectly because we start from the supply side, the product side, right? Where the minimum viable product starts from, here's the product I want to build. What's the minimum viable version of it that I can build and sell? So we start from the product I want to exist, the idea I have, what's the slice of that, that we can sell, that I, that I want to try to sell. That, that is push thinking. On the other hand, if you go minimum viable, like supply, that starts from the demand side where a person is trying to do X, but blocked by Y, the question becomes, What's the simplest way we can unblock them so that we can confirm that there is actually pull there and they will rip something out of our hands with the least amount of effort building something that might not actually work, that they might not actually pull out of our hands. In this case, we don't necessarily need a fancy platform and you could sell something as a service first to just to validate. You can start like today. Just to know we're talking about it, validate that demand is real. They are actually trying and blocked. Let's talk about some examples and implications. So if 3 criteria are true, then they will pull. There are basically only 3 criteria. They're trying right now, they are blocked, and we unblock them. If all of these, all of these 3 criteria must be true. If they are true, they will pull the product out of our hands. If they are not true, if all 3 are not met, we have to push. They might buy, but by default, they will not. This tells us, this, like, you have 2 options here in SERPs. You can play the push game where you're, where effectively You are trying to convince people to buy and use who would be weird to buy and use given what's on their to-do list, given what they're prioritizing, given their current options. That's the push game. That's the game that most of us are playing without realizing we are playing. On the other hand, we can play the pull game, which is finding people who would be weird not to buy our product and just not convincing them not to buy it. That is a much like it's harder. The upstream piece is harder here because we're not living in a fantasy land where people who could buy our product, right? Like there's so many people who could buy our product. It's unpaid market. You had to do some thinking about who would be weird not to buy our product. But once we figure that out for real, the startup grows very fast and it's way less convincing, way less pushing. So yeah, this is just a pretty pull framework. I am honestly tired, so we, you can read through these yourself. What I want to talk about is markets. Okay. So we talk about pull. Pull is a single person. A market size is a, is basically the, the sum of a peop— of people in, in a situation right now where they have pull. And so there are different models. Of this where there's, there's what I call a river where there's a stable situation volume over time. Doing taxes is a, is something where, you know, it's a, it's stable year on year. It's not stable necessarily within a year, but it's stable year on year. There's also waves where it's not, there's not a lot of people in this situation now, but in the future. Or as time goes on, there are a lot of people in this situation. This is what Silicon Valley often talks about. It, where, when we hear things like live in the future and build what's missing, what that's saying is, right? Like there's, so, so think about like a couple years ago or a year ago, even AI agents were this kind of new thing. And there were only like, only a couple people were using them. Only a couple people were, were developing with them and building them. And so if you are in SF and you're among this small group of people, you're, you in that, in that case are observe, you're kind of living in the future because you're watching what situations emerge as people are trying to build and scale AI agents. Even though it's a tiny piece of, like, there's very few people doing that today, but you say, you know what, I'm pretty sure, just like personal computers went like this, right? Like people who were using personal computers and trying to do things with personal computers and getting into situations where they were trying to do something and block with a personal computer. Well, you're tinkering at the frontier. You're tinkering in the future. You're living in the future and building what's missing. That's what a lot of like Silicon Valley ethos is to do this. Then there's a shock, right? Like there's a demand shock where there's relatively stable demand or whatever the profile is. There's a spike of people in a situation. My favorite example of this is imagine a new regulation comes out that tells you to— that says every business in the US has to do this new thing, right? Okay. At that point, everybody is forced into this situation to comply with the regulation. And then once they're done complying with the regulation, it's a one-time thing and no one has to worry about it again, right? And so there's something with that. Another example is like a competitor shuts down and all of their customers are put into this situation where they need to switch. They need to, they need to, right? And the situation would be weird if they didn't change. And so, yeah, the idea here though is that like over time in a given market, the, again, we have the like number of people in this situation at any one point in time and time on this side of the graph. Um, even if you're in like one of these wave situations, what seems to happen, and again, I'm not 100% sure on this. I'm still like trying to, trying to learn it, uh, about it over time. Like they're in this situation where they're trying to do something and blocked because their options aren't good enough. But at some point, a winner emerges, like a default choice emerges. And whenever anybody's in that situation, they kind of by default choose that option. So I think that's kind of how pull disappears maybe over time, or it's, there's like a default choice in that situation. The existing options are no longer not good enough because everyone knows about that option and they choose it and it's fine. They just get into that situation and buy, buy that, and then they move on and it's just like a known thing. And so my sense is that if that is true, and I think it is true, but like there's in any kind of, there's like, you want to own a situation and you have a window for winning the situation where there isn't yet a default choice. You become the default choice for a situation and you ride that and then you find your next situation. And so this means. You have to find a situation that you can own. Zooming out, I think Paul gives us a different perspective here. Push is us trying to convince people who should want our product to buy it. Pull is finding people who'd be weird not to buy it. The takeaway here is that humanity is blocked. What we are doing as entrepreneurs, as, as founders, as people building things is The job is just to unblock people from the important and meaningful things they're trying to do. That's the history of progress. That's why we've had the technological progress we have had. It's not just because we've been a bunch of nerds sitting and building new technologies. It's because these technologies have unblocked people from the millions of important things that they've been trying to do. And now we have indoor You know, now we have Japanese toilets. Now we have all these amazing things that unblock us and we just keep repeating that. And that's how the world gets better. This doesn't happen though, if we all are pushing products that the world should want, but doesn't, or tinkering on technology without unblocking people, without thinking about unblocking people. So stop pushing supply that we want and find people who are blocked. Okay, so now we come to the question of how do startups actually work? Which brings us back to that point earlier where I mentioned that, like, this is like a computer that we've been given the parts to. We've tried to assemble the computer, the computer doesn't work. Now we actually need to understand exactly how a computer works. And so how do we do that? What do we, what do we do? How does a startup actually, actually work? And so let's, let's jump in. So a while ago I said everything is downstream of pull and evolves to fit pull. What does everything mean? Well, let's, let's do it. So I'll start with a really good example of a model. You might've read High Output Management. In High Output Management, Andy Grove, former CEO of Intel, explains business using like an egg-making factory, basically like a diner or like an egg-making factory, and basically explains the entirety of a business from that foundation. And the theory here like makes sense because every business is kind of like a factory. In that it is a system like a factory and it produces output like a factory does. And that output is, is roughly the, you know, it doesn't matter if it's actually an egg or if it's software or if it's a service or whether it's content. The, the model of the factory as a system that produces something is a useful construct. The reason we need a factory model or a system model is, well, because systems are interesting things. So Russ Ackoff talks about a car is a system because a car, a car is a system that is defined by its ability to get you somewhere. That, so what a sys— how a system works is if you disassemble a system, if you pull the pieces of a system apart, if you disassemble the car, you no longer have a car. You have the pieces of a car, but you do not have a car. All those pieces on the ground can't get you anywhere. So we can think of a system as not the sum of its parts, but it's a product of all the parts interacting together. And so the other part of a system that's really, really interesting is that these parts all have to interact. In a way that serves the system and the purpose of the system. So if you take all the pieces of car apart, reassemble the car, but instead it's a Prius, but you put a Ferrari's engine in there, the car will not go faster. It will probably explode or it just won't turn on. It just won't work because it's about how all of the pieces work together. It's not about the best. You can't take the best engine, the best wheels, the best, right? Like, and you pull them from a bunch of different cars, smash them together. The whole thing doesn't work. And so businesses, a business is just like that, right? You have all these different parts of a business and all things that those parts might produce. And there's a tendency to look at each of these parts in isolation. This is especially true in startups where we think, you know, like product and engineering is one thing and then sales is another thing, but marketing is this other thing. And then, you know, design is over here doing the, doing these other things. And yeah, they all kind of fit together. They all kind of like hand off stuff to each other sometimes, but they do all different things. They're all kind of different functions to be manage to optimize separately, but that doesn't work. And it's, it's for the same reason of like, okay, you could put a Ferrari engine in, but if it's a, it's a Toyota chassis or if it's a Toyota, whatever, right? Like the thing isn't going to work. It's about how all the parts interact. And so we learned this very, very clearly when we, you know, we get some cool tactic from X, we get some cool you know, we see, we read a cool blog post, we change something and everything else breaks, which is why we have to look at this as one system. Not just the, like, we have to start at the system level and then we can understand the parts and how they interact. But we can't just focus on sales, for example, or product, for example. Now, if we misunderstand The, so we understand that it's a system, but we don't understand what the output of the system is. We have the wrong output. So assume that we're like, oh, it's, we're a software company and we produce features. If we think that's what the output is, we're going to design the company around producing features and we'll produce a lot of features and nobody will care. The business won't work. So the output, the thing that we are designing, the system to do really matters. We have to get that right. And so what is the right output of our business factory? Is it a product? So, okay, like we can use the factory model, but the output, is it the product, like the egg from the egg factory from High Output Management? Or is it like whatever the customer orders? No, because that's supply, that, and, and that's not considering demand. We're missing the, the elephant there. So we need to add demand pull in, into this factory concept. And so it's kind of some sort of a combination of demand and supply. And so what is that? Well, turns out it's a case study. So like what we've basically written so far is Pull. Jim was trying to minimize his time on client meeting notes, but couldn't use a generic AI meeting note-taker because it didn't integrate with his CRM and wasn't compliant. Right? Okay, cool. That's trying, blocked, in the situation, stuck. We unblock him. We offer an AI note-taker for financial advisors that integrated with Jim's CRM, solved all compliance needs. As a result, Jim went from 45 minutes of notes per meeting to less than 1 minute of notes per meeting. Okay, cool. Right? Like, that just reads like a case study that Jump features on its website, because that's what it is. Here's what Jim was trying to do, what he was struggling with before we show up, unblock him, and here are the results. That's the pull framework plus supply. That's what it is. So we, we can think about business as a case study factory. So instead of thinking of it as a product factory or a, you know, like responding to customer orders factory, we think of it as a factory that produces case studies that are designed around pull, where there are, right? Like if you thought about it as a product factory, it's like, oh, design, build, test, or something like that. When you think about it as a factory that produces case studies, well, how do you produce a case study? Well, you have to find a potential customer, you have to turn them into an actual customer, and you have to make them successful. You have to have them achieve the case study so that they don't churn. So, and so they're satisfied and all that, all that kind of stuff. And so this actually winds up being the customer journey or the steps of the factory and everything we do fits into this. This is the system. When we look at it, it's a case study factory with like roughly 3 steps. It's a fairly simple system. Everything we do, marketing, sales, product, HR, like all of this all fits into this factory model. So let's explore it. Okay, so we talked about how the factory works, right? There's 3 steps. We have to find somebody who has pull, we have to turn them into an actual customer, we have to make them successful. And so we can combine this with the idea of pull. Remember pull? Well, there, there, there is some sort of a force that is required to get somebody through the factory. There are different thing. Imagine, just visualize a factory that has different steps in the factory. Something's gotta move the thing from each one step to the next, and If customers have pull, they are exerting effort to unblock themselves. So they're pulling themselves from step to step. They are exerting the effort to move through the factory. If there isn't pull, we are dragging them through the factory. That's what's happening. We're trying to drag them through our factory. And at any point in time, they can just leave. And they often do. So that's why a lot of the things we wind up doing are compensating for lack of pull. We're, we're, we're making it so that we're trying to make it so that they can't leave. We try to do all these tactics to keep them in the factory. We try to push them through and it's like, no, we have to design the factory around pull. Again, Physics of Startups. It's all about their energy to be unbluffed, trying to do that thing. That they, that they are blocked from doing, us offering to unblock them at the end of this. And they're going to pull through the process of purchasing it. They're going to exert the effort to purchase it. And so a model of a fast-growing startup is a factory that can put a ton of volume through it and has a low defect rate at each step and throughout the entire factory. Because if you have, you know, imagine you had 40 customer calls per week. That sounds awesome. But what if they all— what if only one of them actually turns into an actual customer? That's a high defect rate. That's a lot of waste. Or what if you add 40 customers per week, and only one of them turns successful? That's a high defect rate. And then the factory has to be powered by customer pull, not our push. And so those are the things usually to get a low defect rate, you need to reduce variation in the factory, by which I mean, you can't have 30 different kinds of potential customers, all who are trying to do different kinds of things. And we're, we're, you know, each time we're doing something kind of like we have to, because each time we kind of have to change the machine a lot. And it's really hard to change the machine a lot for, you know, in custom ways each time. And so that's why We're looking for what I call one repeatable case study. And now the thing to remember here is that the pull is the thing that we don't control. And it, it again is what causes things to work. It, it's what causes us to design each of these steps in our factory in a way that fits pull, that that, so that the potential customer who has pull doesn't just walk out of the factory. And so how do buyers interact with our factory? Well, in a traditional push world, it is very hard for them to interact with our factory, because they see, oh, like, there's a lot of different things that we can show. We can talk about our positioning, our brand, our vision, our tagline, we have an elevator pitch, product demo, there's all these different components. And they typically look at these and it's hard for them to make sense of it. Well, it turns out, you can just show a case study based on Poll. And they, based on that, they know everything they need to know to determine if they want to pull themselves through the factory because they know, okay, someone just like me was trying to do, was in a situation just like me where they were trying to do X, blocked for this reason, and you unblock them and here's the results. Cool. What else do I need to know? So that means is again, the, the pipeline step we can define, you know, slightly differently. How do we find people who will look at the case study and pull? The sales step is how do we show them a case study that they look at and pull and they buy? And then the delivery step is how do we deliver on the case study to keep them, to make them successful, make them weird to churn. So given this, the only thing we need is one repeatable case study that can put a lot of volume through it, which generates all the other downstream things. Obviously poll generates the case study, case study generates everything else. Factory is a really cool concept. Factories, if you've never been in a factory, factories are awesome. I really like going to factories. But the other thing about factories is there's a lot that's been written about factories and how to make factories work better. My favorite thing is called The Goal. It's a business novel of all things. And in this business novel, which you totally should read, but, uh, it articulates the theory of constraint. Which is that in a factory or in a system, there are many things you could do to improve any machine in the system. But because it's a system, wait, wait, because there's a flow to the system, because there's a causality to the system, if you want to increase output, which is the entire goal, that's the goal. You want to increase output at any one point in time, there is only one machine that is the constraint of the system. That is the bottleneck of the system. That, that machine, whatever that is, is the thing that if you change anything else, the overall rate of output does not increase.. But if you change that machine, the overall rate of output does increase. And so a couple of things. If you have a 0% close rate, making your product better, which is somewhere between here, will not do anything for you. If you haven't found demand, it doesn't matter what your website looks like. Or if the market changes and you don't feel like you have pull anymore, nothing else matters. That's what Intercom realized and how they kind of like went forward with pull with SIN. So LARPing, we come back to, is doing stuff that's not impacting the constraint. It's focusing on anything that is not the constraint. Which is not increasing system output. So let's, uh, so this, there are like ways in which this changes over time. So, uh, we, we've looked at it in, in kind of like a static view of, of a basically a case study and a factory. We can look at how this, how this works over time. So let's, let's say that you have pull and, um, you have supply, you have it, it works, but then Claude Code comes around. And you realize that people who were in a situation who would rip the product out of your hands where they, where they would pull, now can just DIY stuff, DIY whatever you were offering with Claude Code. So they no longer have pull. Their existing options are good enough. Now you just have PU and nobody cares about your supply. So then the question then becomes, who is blocked now? And you change your pull, focus on a different situation and your product evolves over time. This is an extreme example. But what often happens is that, okay, we've had success for a certain amount of time, competitors have come, and so we're not really— the situation has kind of dissipated, and we need to find a new situation, which requires kind of like different framing of pull, it might require a different product, it might require da da da da da, right? And so, like, because things are dynamic, we often have to— and when we evolve pull, when we change pull, we have to offer supply that is coherent. And so, yeah, the same thing happens with the factory where the factory evolves as pull evolves and supply evolves and as we attack constraints. So like, let's say we have a case study factory that's going, but We have a 10% close rate or something. And so we fix something in the system, in the sales system, and it's like, okay, cool. That's no longer the constraint. But what we changed in the sales system is causing stuff to break in the delivery system. Okay. Now this is our constraint and we, you know, we make changes. And so this is how startups evolve over time, both your case study evolves and your factory evolves. This is a concept that actually has precedent from an architect named Christopher Alexander, who was talking about how design works over time. Now there's basically like an evolutionary fit-finding process that he calls unfolding. And so as pull or your understanding of pull evolves, your everything else has to evolve to fit it so that people rip the product out of your hands. And because the world is kind of complicated, complex, this happens in ways that are basically unpredictable. They're unpredictable to us today because we're going to learn things and new things are going to happen that we couldn't have predicted. And all of these things serve to change your product direction, your market size, all these things. And so what happens is, and in basically every single case I've seen, is that the process of getting from here to your first million teaches you what you need to do to get to 10 million. As you, as you interact, as you understand pull more clearly and supply, you, you learn the things along the way that help you evolve into the thing that can grow very fast. And so here's the full model together. This is the model that I believe is the thing that solves the computer problem from the first section here, where we wind up with a broken computer that we, that we don't need more instructions to fix. We need to understand the dynamics of the computer. And so we start with Paul. This is, this exists out there in the world. Somebody trying to do something but blocked from what they're trying to do. That's the, the base of this model, they see our case study, our pull, our, our supply basically that would unblock them. And they realize I, that they can get unblocked and just like water kind of exploding from a dam, the, from a burst dam, they expend energy. Their, their effort to pull through our sales process and our delivery process to get the thing done, to get that thing done. And so the factory exists for them to get to accomplish the case study and get their thing done. That's what the factory is. That's where the factory sits. That's where the— that's basically the whole model. This part here exists out there in the world, whether or not we exist. It's not about products, it's about accomplishing things in their life, that when they see our case study, they pull to buy, and we design our factory as one system that helps them buy, that they can pull through that and become successful so they can get their thing done. This is One person in one specific situation. We do this with one case study and just repeat this a million times over. It doesn't change form because we're selling to a million people because each person has to buy one at a time. Each person buys as an independent, roughly independent thing. And so this, it's just this process repeated a million times.. And as we repeat this, we attack whatever the constraint is and evolve towards, towards true pull. That's roughly the model, I think. I think that's like exactly the model, or at least, I don't know. Tell me if, tell me if you found something better. So in this world, the founder's only job And this is where simplicity comes in. Is— remember the theory of constraints? The founder's job is just to attack whatever the current constraint is. And constraints in this model are sequential. And they're just sequential, general, like what is real pull? Because we're designing this, everything we do is going to be designed here. Downstream of the person who is trying to do something and blocked. Our case study has to be built off, based off of that. And we have to build our factory based off of that. Okay. So real pull is the first constraint. Then we have to have supply that unblocks them so that they, they pull for it. And so, so we can show them a case study. Then obviously we need to, you know, at that point we kind of like don't really have a factory. And so we have to kind of assemble the factory piece by piece and the factory kind of like comes together and evolves over time. So then we need pipeline, sales, delivery. And as these things start kind of working, we figure out what the next constraint is and attack whatever it might be. And that's what, that's the founder's job. The founder's job is just to attack constraint, So that we can maximize output. What does the tactic constraint mean? This is a kind of interesting concept. I don't think it's something that people appreciate enough of how important it is, because basically the business improves output, right? The number of case studies we produce, and we want that to just go up and up and up because that means we're growing super fast. Well, the business improvement, business improves at the rate at which we break constraints, the, the where we solve individual constraints. And every time we solve a constraint, a new constraint pops up. And so the rate of business improvement is a function of the pace at which we break constraints. And so let's like run a sample model here where a, if, if we break each constraint, if we alleviate each constraint, we break the bottleneck. If each time we do that, it improves the volume of case studies our factory can produce by 10% each time we do that, then if we break a constraint every month, we will increase— every year, we will increase our factory output by 3x. If we break a constraint weekly, we have, you know, it's, it's 117. Our, our, our, our case study factory can produce 117x more each year, 117x what it was producing on day 1 than it was on, on day 365. So what this tells us is that we should be maniacal if we want to grow very fast. We should be absolutely maniacal about the rate at which we break constraints. And if you read Elon's biography like this, if you read about, you know, how Elon approaches business, he's designed his life to just maximize the rate at which he breaks constraints in across the factories of his business. This also explains why companies stagnate. You can look at different pieces of this, right? First is over time, companies tend to focus on what they want to build or who they, you know, who they want to sell to versus who has pull. Or what often happens is as you hire a lot of people and whatnot, like the individual pieces of the factory don't work together very well. And they all kind of optimize for whatever they want to optimize for. And then you have like, I don't know, product and engineering down here optimizing for random things, HR, like, you know, making sure everybody optimizes for the wrong thing. And like all these things that, that make the whole factory work worse, even if they make one part of it work together. And then they just, you know, over time, don't attack the constraint. Attacking the constraint is really, really hard to do.. And as you succeed, I've found it gets harder to keep attacking the constraint, because it gets harder to solve their problems, get more complex, more sophisticated, the constraints become kind of like, really hard. And you're doing all right, like you've got a $20 million revenue business, like you've got, you got a profitable thing. You know, it's just like lifting weights, if you want to keep getting stronger, The reward for lifting heavy weights, the reward for success is lifting heavier weights. It's, it's the reward for hard work is harder work. And there's less need, less like survival need to do it. And so, yeah, you can see why kind of companies stagnate. So let's talk then about what the heck do we do given all of this? So That was the model. That's my model. I hope the model makes sense to you. I hope it's helpful for you. Now the question is like, what do you do? Before the model, you, it, they should feel, you know, in my shoes, it always felt like there were a billion things that was super important and I was always quite busy working quite hard, but it wasn't clear if we were actually making progress. Or were we just like kicking the computer, trying to get it to turn on? And I, you know, and sometimes it felt like we were making progress, but then you look to the left and right and you see people who are going way faster than you and you're like, okay, am I making the most possible progress? And how would I know? Well, after we have this kind of model, we know exactly how the system works. We know the physics of the system where customers pull themselves through the factory. We know the design of the factory. We know we know exactly what to do as well, right? Just keep attacking whatever the constraint is. And we know the rate of attacking the constraint is the rate of improving the business. Without the model, there is like zero chance we would consider, we would do this consistently. Just, it would be weird if we did because there are many things that seem like they're worth doing. There are many fires that are always burning. And it's hard to tell which one's the one that's going to burn down the whole place. And so, you know, it's, uh, with the model, I hope you know exactly what to do. And yeah, the model tells you exactly what to do. And so what this looks like over time, you can see in my Miro board, is like, here's actually how a startup tends to evolve, where they go from an idea to pull, to first customers, first hell yes. And you can see that the bottleneck moves downstream over time, moves from demand to supply to pipeline, sales, delivery, and then it kind of moves all around. And so where I would start, if I'm in your shoes right now, I'm asking myself, do I know what real pull is? By default, I would assume unless you are growing super fast, you do not. You might have a hypothesis of it, write it out in the pull framework and then confirm if it's real. If it's real, you should be able to go to somebody, you should be able to find somebody who's in that exact situation, show them pull and supply, show them your case study and show them your pull framework and they should rip the product out of your hands. If that's not happening, your pull framework is wrong. And you need— the first constraint is your pull framework. So you have to get it right. And then, but if once you get it right, you move to the next bottleneck. So what is real pull versus fake pull? Is it real or not? This is a very simple exercise. When a pull is real and supply fits, they can't not buy your product. They will take out, they basically can't do anything other than buy your product. And they will say things like, yep, this is exactly my situation, exactly what I'm trying to do, exactly how I'm blocked. I need this right now. How do we get through it? And it feels like the dam bursting. Fake pull is anything other than real pull, anything else. It, you know, and you will, I'll say, I have spent a lot of time pretending or trying to convince myself I had found real pull.. And it just, it's like, it's night and day. And you'll hear things that are like enthusiasm. Oh, wow. This is great. Wow. This would save me millions of dollars. Okay, cool. That, that doesn't mean you're going to buy it. Wow. This will, this would be something we'd totally look into in the future. Okay. That's not today. And more info as well. Like, can you send me more info so I can follow up with my team? These things all sound Like they could be pull, but they are not saying, this is my situation. How do I buy? So anything there, I'd count as basically zero. Real pull does not whisper. Your method for finding pull does not matter. Now, this is where we get into the, like, analysis of existing startup methodologies, because all that matters is you find pull. There's stories of startups that have been clown cars into gold mines. Yeah. Doesn't matter. They found pull. I've heard even of a story of a nonprofit AI research lab that, you know, turned into a for-profit company. You can start as a nonprofit. Does that mean everybody should start as a nonprofit? No, of course not. But the point is, it doesn't matter how you find it or by which means you find it. So I've seen I've heard many, like Segment, if you hear the story of Segment, was exited for a billion dollars. They just shipped something random and it went mega viral and changed the entire business and took off and, you know, no research, no nothing. They just built something for themselves and, you know, it turned out it went mega viral as an open source project. You can also do decades of research and analysis and maybe that works. Or maybe it doesn't, but it doesn't matter. Like the work doesn't matter. Weird things have worked. All that matters is you find pull. There are, as I've said before, no style points, no effort points. Bunch of market research doesn't matter. Hundreds of customer discovery interviews. Again, doesn't matter if you didn't find pull. If you run a bunch of experiments, you think really hard, it makes a lot of sense. That's been me. All of these are just like stab me in the chest. The 10-year plan and vision. Yeah, done it. Followed a playbook perfectly. Great. You went to all the right schools, you went through the accelerators and stuff. It doesn't matter because the theory here is, you know, it's the same theory that got us all through school. It's like, oh, if I'm a good person and work really hard, I'm going to get good grades and I'm going to succeed. That's not what happens. Nothing matters if you don't find bull, and it doesn't matter how you find it. And all of these things will often prevent you from finding it because you do a bunch of work where you learn a bunch of things that aren't relevant. Now, how do you find pull? If you have existing customers, um, there's a way that I've found you can find pull among your existing customer base and understand it because you've often been looking at your existing customer base in the wrong way. So Sparkwise, I mentioned before, They are a McKinsey quality group training for any business with zero facilitation needed. They came from McKinsey and Bain or whatever. I think they're all McKinsey, I don't remember. But they sold to ex-McKinsey, Bain, BCG alums in a variety of different industries. They tried to sell to like Deloitte alums. My brother works at Deloitte and it turns out they didn't care. But McKinsey, Bain, BCG alumni would buy. Some bought really fast, some bought really slow, some used it a ton, others didn't. And it wasn't obvious why this was the case. It wasn't obvious. It wasn't like, oh, okay, it's this industry or, uh, you know, it's big companies only. It just wasn't clear what exactly caused some people to buy fast, some not to. And this had implications for them that are like massive. Like, how do we describe our product given this? Who do we actually try to sell to now that we've run out of ex-McKinsey, Bain, BCG alums to sell to? How do we, you know, what do we do from here? What we found is that you can basically just compare the people with real pull versus everyone else, whether they bought or whether they didn't. And what they found when they did that, and that's the core exercise that I recommend, is look at the people who bought fast and were successful. Compare those versus the people who bought fast and weren't successful, the people who bought slow, and the people who didn't buy at all. And compare and contrast the individual stories of these people. When Sparkwise did this, they realized that there was a situation where a learning and development team had run a small training and was tasked to scale that training out while keeping it very engaging. And so in that situation, They bought fast and used a lot. Everybody else did not have that situation. They were not in that situation. And so they might have bought it or they might not have. They might have bought fast, they might have bought slow, but they didn't use it a ton and become super successful. And so Sparkwise now knew exactly who they needed to target and exactly when. So that's for an existing company. If you're just starting out, I found there are You know, there's basically two steps here. You have to figure out what pull is, and the best way I've found to do that is to become your target customer and then sell before you build something specifically to make sure that there is real pull there. So what we're often taught is to do hundreds of discovery interviews, looking for what? I don't know, pain points, problems. Who knows? I don't know that— like, I would ask this question to you, to think about. If somebody interviewed you, if somebody interviewed you for 30 minutes, do you think they could build something that you would actually want? That you would actually rip out of their hands? Again, I don't, I don't think so. I don't think you could interview like, 40 people and figure that out. And so my experience on this is like, while I've done a bunch of discovery interviews, I was often looking for the wrong things. I wasn't sure if it was real or not. And so it was basically like, I, my experience has always, has generally been that you will learn a lot of interesting things in discovery interviews, but nothing that actually, or, or you won't really know unless you get massively lucky. You won't find pull. What I have found is that if you get firsthand experience doing the thing and experience pull yourself, then you build for yourself. Now, maybe someday there will be some sort of magical customer research methodology for finding real pull. Could possibly happen. Maybe I'll develop it. Maybe somebody else will develop it. Who knows? I just haven't seen it. Now there's this constant, there's this idea about building for yourself. I think it's, I think it's roughly right, but like I've seen it go wrong in a couple different ways, right? Which is basically if I'm a college student, I should build something for college students or I like travel and restaurants, maybe I should build a travel and restaurant tool. And so these things, like these are just like not necessarily people worth building for. And so what I found is, because like, if you can become your customer, you become someone worth building for. And so you, I want to go serve physical therapists, let me go shadow them, or let me become a physical therapist and try to figure out what pull is there. Let me, or let me build a consulting firm that serves this kind of customer and see what happens as I, as I work with them. This is basically become someone worth building for and then build for yourself. I've already talked about this, but, um, I think of anything that is like somebody telling you stuff versus you experiencing it as secondhand knowledge. And it's not clear to me that that's the best way to find pull. Uh, if again, you can find pull that way, but it wouldn't be weird if you didn't. I'm thinking of this in terms of what are the things that I can do that it would be weird if they didn't work? And getting that firsthand knowledge and feeling it myself and then confirming it by selling, you know, that's, I think that's the right, the right way to go. And so if you haven't found pull, it's going to be tempting to just put your head down and build. But if you haven't experienced, I, again, you should trust me on this, but you, you can learn this yourself. I've spent a lot of time doing things and saying, well, I think there might be pull here, so let's build something and then we can test it and like, It has never worked for me, but maybe it'll work for you. I don't know. Uh, but it wouldn't be weird if it did, right? Figure out who you want to serve, do their job with them, do this today. And you know, anything else is probably luck. A couple examples of this. Um, one person graduated Harvard Business School, got a job as a paramedic making $15 an hour, which did not make the school's average salary post-graduation look as good as it, as it could have. But you know what, he found pull while doing that and built a company around that. I know another person who cold emailed insurance brokers offering to be a part-time consultant for them. He flew out in person to onboard and figure out what to build for them. And in doing that, he figured out what to build. There was another person who, another MBA who had a list of potential industries they were considering looking into. They did outreach, cold outreach to come just shadow them, see which industry they actually wanted to serve, and then found pull from that. And then another thing that I have seen work is two students, they basically just did cold outreach saying, we're students, what would you pay us to solve? And they landed ESPN, then a bunch of others, they, this way. And that was just like two young students who did that. Now, the reason I don't recommend this is because like, it's kind of weird if this works, but hey, maybe it does. Maybe it does. I just think that like, these are better firsthand examples, but again, it doesn't matter how you find bull. You just have to find it. Now, how do you know if pull is real? Well, you're often told to do a lot of design partnerships or just launch it, do free trials, do free pilots. These things don't really tell you anything. What does a design partner tell you? Like, no, if somebody is trying to do something in block to such an extent that they will rip a product out of your hand, they will rip something half-baked out of your hand, they will try to buy, Basically regardless of like, and a design partner to a person in that situation is probably a negative signal. They probably don't, I don't think anybody would ever say, yeah, you know what, this is so important to me that, you know what, let me do this. I'd like to be a design partner for you. It's like, no, I need help. I need this done. I just want you to, I want to pay you to get it off my plate, which leads to the question of selling before you bill. Like, yes, obviously. Because we're— you're not actually selling a product. They're not buying a product. They're buying a thing that unblocks them. And if you're trying to sell a product, right, you're doing it wrong. You're just, you're just offering something that unblocks them. And if you're afraid of selling, you're afraid of rejection, what, like, what, like, you're thinking about this wrong. You're thinking about push. And again, if you're going to spend your life, you're going to spend a good portion of your life trying to build a company, your time and effort, you want to be sure that pull is real. And so how else would you know? Real pull is they try to buy. And so, yeah, the one thing I'll say, and a lot of people ask this, is— I've done this— you sell to one customer, you go heads down, build for them, and then raise your head up, and turns out, it's unclear that pull is repeatable. And so I recommend doing this to 3 to 5 people and seeing, comparing and contrasting, building with them, and then keeping the factory running. Okay, then another question I often get here is, well, but what about our long-term vision and market thesis? And how do we know that we're going to build a trillion-dollar company? All I'll say to that is pull is a hard constraint. Whether, like, it doesn't, these things, if you don't find pull, none of these things actually matter. If pull does not exist, you will not take off. There are so many examples of companies that just found pull randomly and they didn't have any thesis. Loom segment, OpenAI, maybe, um, you could, you could make an argument there. And so there are also, but like, to be clear, there are also examples of where it was very clearly planned. Tesla is a great example of that, at least for, for, for the Roadster and whatnot. Yes. And SpaceX, same thing. Right. Those are examples where it was planned. So basically, if you have a vision or thesis, it can constrain your search area and it might constrain the things you're willing or not willing to evolve into as you learn more. But that means, but like, yeah, even if you have a long-term vision and thesis, you have to find a pull right now. Otherwise you're going to be pushing and it's going to be a slog. Hopefully you're not in this case, but like a lot of people wind up being in this case. Oh wow. Why did I spend a ton of my life doing all this stuff? Well, turns out we were just logping. And so that's annoying. So let's jump into supply. So we just talked about pull and finding pull and validating pull. Let's talk about supply. You remember the formula, we offer Z, which helps people overcome Y to accomplish Z. Z, now we can talk about this, is the category of thing that you are doing, right? That can be just a consulting service, product marketing service, an AI engineer, it could be a variety of different things. And it's like the, the category of thing Plus the X and the Y set the buyer's expectation. Everything else is a double-click from there based on like what customers ask when they get pull and what objections they have when they get pull and kind of conceptually understand supply. And you can see this in a, uh, I would click on this and watch this. It's a Turbo Pump commercial where infomercials do a really good job at this in the first like 10, 20 seconds. They describe pull, describe supply, and then do a bunch of double-clicks into supply and, and like answer, answer questions based off of that. And so the turbo pump is a situation where you're trying to move liquid from one container to another, but you're blocked from doing that easily because the container is heavy and spills. You can see our man with his gas can here. Supply is we offer the turbo pump, an automatic Cordless liquid transfer pump. Everything from here is double-clicking into that. Here's how it works. It doesn't, it doesn't explain, you know, how it physically works, but explains how it unblocks you. Yeah. Okay. So instead of lifting this yourself and spilling it, you plug it in, click the button, and it, and it transfers the liquid for you. Why it's unique. They also have something in there where they describe the unique technology, but they call, they say it's Turbo Siphon technology that makes sure you transfer liquid down to the last drop. Now, what they don't say in here is what exactly Turbo Siphon technology is. It's just, here's what's unique about it. You don't need to double-click into that. And they have, you know, they handle objections, they answer questions, they try to throw a bunch of more concrete situations at you in which you are also trying to transfer liquid. If you're trying to fill a boat, if you're trying to do that, like there's all these different things. And then they talk about pricing and framing pricing. And that's a question people often ask too, is, okay, how do we frame pricing? Well, it turns out that Pull roughly gives you the bounds for describing and articulating pricing. And so the project, what's the value of accomplishing the project, right? In the jump case, You know, maybe it's, oh, we can support 10% more clients and each client is valued at X. And so, right, like the, the thing that Jump enables is, you know, I can earn Y more revenue from that because I can support X more clients. Like that's, that's the, you know, kind of like upper bound on what we can charge. But there's another price anchor, which is what's the cost of their other options? Like what does a generic AI note-taker cost? If we are wildly more expensive than a generic AI note-taker, they might say, yeah, I just don't feel like that's a— I don't— I feel like that's too expensive. And so those are the two kind of bounds of pricing. When we communicate pricing, we basically give them that, that anchor, that way of thinking about it, whether it's anchoring on the project or anchoring on the options or both. One thing I'll note is that supply often seems small, especially when you're transitioning from push thinking to pull thinking. There's two ways it seems small, which is basically in the push world, we typically think that we need to educate, we need to make the product seem bigger. And we need to talk about it more and show more parts of it. That makes it seem big. And it kind of— when it doesn't work, we make it seem bigger. When, on the pull side, We are actually trying to show the smallest possible thing because smaller things have less surface area for objections. For, for, and we just want to show the thing that unblocks them. And so if we just show the thing that unblocks them and just describe the thing that unblocks them, that does not usually cover the full breadth of our vision and our full platform and all the features and all the benefits of it. And so, and often we want to show the fewest screens, say the fewest words because each additional screen and word is, you know, something they have to process, something that they're going to have to think through and understand if it fits them or not. And it's generally going to convince them not to buy. So it winds up, we kind of get our pitch smaller and smaller and smaller and smaller. And that's often uncomfortable. It often feels, you often feel naked. When you are pitching on the supply side, because you might have one slide and a 30-second demo. And it's like, what are we gonna— what am I gonna do with my hands? That's when you know you're kind of doing it right, when that, and then they transition from, yeah, cool, get it, totally, how do we, like, how do we buy it? How do we get started? Pull also changes how you approach go-to-market. And so like, what, like push, just as I mentioned there on the supply side, What push does is it creates more surface area, makes things bigger, makes things more complicated, makes it seem like more than it is. And more than it gets, then it's definitely more than it needs to be. The same is true on all of these pieces, pipeline, sales, and delivery on the factory. So let's talk pipeline, we'll go through these sequentially. Pipeline, the way that founders typically do pipeline, get people to meet with them, is they start with who they want to sell to, and try to pitch them our product in outreach. And yeah, the response rate is typically horrific on that, because nobody really wants to come to a sales meeting, like very few people want to come to a sales meeting when pitched as such. And we're like, it's not about pain points, it's not about value. And we, you know, usually pre-product market fit, we don't actually know the exact words to describe the pull hypothesis correctly in a way that they look at and say, oh my gosh, that's exactly what I need. That's exactly me. And so it also believe, we also believe that our messaging's job is to convince them to join a sales meeting. But if we realize that it's not a sales meeting unless they have pull, in which case they will turn it into a sales meeting. And so we don't have to convince them to show them up, show up to a sales meeting. We just need to get them to talk to us and see if they have any sort of pull. So then we focus, then instead of focusing on whoever we think could buy, we focus on who would be weird not to buy. We send a message that's interesting to them that just gets them to meet with us. And that's usually, hey, I'm cool, you're cool, let's chat. And then you should expect to see 10-20% response rate. And I've seen that pretty consistently here. And it's just a mindset shift here. Here, you don't really get anybody to meet with you. Here, you often do. And some of them, you know, are not a good fit, but then you change your pull hypothesis. There's another method. If, you know, just outreach itself doesn't work, founder magic doesn't work, which I call goblin mode, which is a version of attack the constraint when the constraint is pipeline, right? Like do crazy things. It like, remember how important the constraint is and the rate of attacking the constraint is. Don't just like sit there and let an automation run and hope that maybe I'll get a meeting this week. No, if pipeline is the bottleneck, do crazy things to meet with potential customers. You need to go in person. Think of the cost of burn for a month of you not learning anything. Of you not improving the business. This is worth doing. Go to the conference across the country, like, whatever it takes. What crazy thing can you do today that gets you to talk to 3, 5 potential customers? Over time, what usually happens is you start with founder magic and it's not going to work. It's like, it's either you're going to talk to people who aren't a fit or you're going to not talk to enough people and you're going to do crazy things And usually you're gonna have what I call a dirty pipeline where you're having like 5, 10 conversations a week. But most of these conversations are with people who don't have pull. Your job is not to just sit there and take it. You have to attack the constraint. It's— this is still the constraint. So you change your targeting, you change your messaging, you change everything until pipeline is no longer the constraint, and you attack it like a crazy person. I see people iterating on this far too infrequently, where it's like, if you're doing just outbound in general, you should be iterating on it every week. And if you're— oh, if you're waiting for outbound to work, you should be doing goblin mode stuff to make sure you have people talk to you today. And then like, some people might object to, well, if I'm sending messages out, it's like, I'm interested, you're interested, let's talk. I'm going to get a bunch of people on a call. Who, you know, aren't going to buy. It's like, well, two things there. One is if they have pull, they will buy. And two is, yeah, that's probably— it's probably not going to be everyone's going to buy. And so you're gonna have to clean a dirty pipeline, which is difficult and annoying. But that's much easier than fixing an empty pipeline. And so clean the dirty pipeline. And so, uh, after you have product market fit, if you know that there's, that the person who buys is in this specific situation, your job is just to figure out what to do such that this person in this situation would be weird not to talk to you when they're in this situation. And so imagine if, you know, you have, they're in a situation where they've just paid a lot of money for an expected, expect expensive consultant, and the consultant's work didn't stick. Okay, cool. Maybe we should partner with that consultant, right? And they're stuck in that situation. The consultant looks bad, but da da da, right? Like, okay, let's partner with the consultant. That's what I call a toll booth. You put a toll booth in this situation such that they can't pass, you know, it's like you could put a toll booth anywhere on earth. You're not going to put it in Siberia if you want to actually make money. You want to put it in a place that everyone, all the volume goes through when they have a poll. And so that's an example. ClickUp got its first million ARR by finding people who were in a situation where they were trying to do something. They had used another project management tool and left a 1-star review of it because it was blocking them for some reason. Zapier realized that people bought Zapier when they were trying to connect Google Sheets with Stripe. Or Google Sheets with Google Forms, or, you know, like, connect X with Y. And so their entire strategy became, let's own SEO for that. Anytime somebody Googles connect system 1 with system 2, right, like, and they built an entire strategy around that. They owned that. They had a toll booth in that situation. There's another example of a consultant who sold into Fortune 500 CEOs when the CEO was having a public spat with an activist investor, which would come through in the news. And so that consultant could have just called the CEO and said, you know, called the office, got on the assistant or whatever and said, I can help you. And that could work. That certainly could work. But the consultant was like, okay, what would be weird not to work in this situation? And the answer was, I'm going to send a samurai sword, a freaking samurai sword. Hundreds of dollars samurai sword with a note that says, I will go to battle with you, to the CEO. And it's like, okay, that's gonna work pretty well. And that, and so, you know, you just own that situation. Another example is Datadog, which did CTO conferences. There's something about being at conferences where CTOs were at, like, you know, engineering conferences where if they were there, CTOs were generally in this situation when they were there. Such that CTOs would rip the product out of their hands then. And so what Datadog did was they— and you can, you can like look this up, it's crazy— they went from 0 to 100 sales reps, where their only go-to-market channel was conferences. They got— they basically spent all of the money possible owning this situation that they could possibly spend profitably. And they grew just doing that before they figured out what their next tactic was. And that's a great example of a toll booth here. Okay. Let's talk about sales. Again, sales on the push side is let's poke and prod for pain points. Let's give a big description with a long demo. And as a result, we're going to have, we're not going to be able to predict who can buy, who's going to buy. We're gonna have long unpredictable sales cycles. We're going to be hearing mixed things. We're going to be implementing very complicated sales frameworks and da da da da. And the pull side, it's just, we need to understand if this person has pull or not and what it is, offer just the thing that unblocks them and then let them, like, don't convince them not to buy, let them convince you to let them buy. And it feels totally different and it leads to I mean, if you're, if you're selling to people who would be weird not to buy, obviously the close rates are going to be higher. They're going to, and they're going to buy faster. And so the sales call structure for a call like this, you can see the full script, is basically figure out their pull, offer supply that unblocks them, and then figure out what to do next. Maybe you're selling enterprise and you need to go through a set of steps, then great. Take path 2, where you schedule the next call to plan to do the project plan to purchase the product. Or maybe you're selling smaller deals or, you know, selling SMB. Talk through pricing, schedule the onboarding, send the contract, send, send the Stripe link. And if they have pull. And so this is roughly the structure, you can see a full script here. And it's very simple. What we're doing, we're literally just trying to set up the call so that they will tell us their pull. We're trying to understand exactly what their pull is, confirm we've got it right, and describe our product, and maybe demo it, maybe show something, or maybe just show a slide that says, this is, this is how it will unblock you. And that's that. But then we can take this and say, okay, if this is a sales call, Then we can wrap that into a sales process. There is the, there is the call one, which we just went through. Well, how does the rest of the sales process work? Well, they're kind of, there might be a second call. We'll say here's just like a template. And in that second call, we just want to make sure that this person believes that this will unblock them and it fits what they need. And so that's the first part of a second call, right? We just confirm pull and supply. And we collect any remaining questions or concerns from them. And we go through them one by one to make sure that they say, yes, this fits what I need. I want to champion this internally, which basically means this is— and if you're enterprise, if you're selling like big contracts, you might think, oh, but I have to go through 40 different group demos and all that kind of stuff. Yes, but there's one person whose project it is, who's going to bring you through their procurement process, bring you through the 40 group demos, right? That's, that's, it's that person's pull that's going to cause the company to buy it. It's not the company doesn't have pull, the, the, you know, large stakeholder group does not have pull. It's a single person every single time. And in enterprise, there's just a lot of steps because they, they have to follow a lot of steps in order to purchase it. But it's not— you're not selling after that. It's, it's— you're helping this person, this person who's got the project on their to-do list, who's blocked, you're helping them sell to the rest of the org, you're helping them navigate their purchase process. And so because of that, I described the first part as kind of like fit. And that's where the sales part is. And then from, from then on out, it's project management, where we are collaborating, with the person whose project it is to get this done. We're collaborating with them to help them buy. And there's some specifics I have here. I'm getting tired, so I'm not going to keep reading them. You can read them yourself. And so this is how the sales process starts. And over time, you kind of compress it. You know, it's the same thing. We're attacking the constraint. Could we remove steps from the sales process? Can we make things async? You know, on day 1, your sales process should be pretty bad because you don't know what good looks like because you don't know, like, this is a rough template, but you're gonna optimize it. You're gonna have specific questions you ask. You're gonna just, you know, kind of like relentlessly debug it. And you make effective, make it effective and compress it. Compressing it by focusing on where are there defects? Where are there the constraints within the process? So example, you know, multi-call close to one-call close, template project plans with, with happy paths. So in here, you say, hey, here's how other people have bought, what do we need to change? You can make parts of this totally asynchronous, you can have an asynchronous demo they watch before talking to you, or after, or, you know, whatever you could do self-serve, there's all these different things. And finally, delivery. What happens after they purchase? We usually think that, oh, if only they just use the product and like the product, that will cause them to not churn, which is not true. The goal, or the way to think about this in the Pull world, is that even when they purchase, they will churn by default until this, until there is a moment when that stops to be being true. They're in a new equilibrium state where they would be weird to churn. It might be like when they're actually unblocked, when they actually accomplish the project, or when they realize they're going to be. And the point of the delivery staff is to design a bullet train to that moment so that every customer would be weird to churn, right? We're making this from this kind of like haphazard step in the factory to a step, like a totally automated step. And so you think about it, here's the boulders again, right? When somebody buys, they will churn by default. They're going to churn. We have to figure out when they would be weird to churn, when they are in a new equilibrium state. And this is not necessarily that they are getting value out of it because they could get value and still churn, or them being happy with it. I've seen plenty of customers be happy and still churn.. And so we need to know when this change happens. And how do we make sure that this happens for every customer? What's the moment that— when Mark Roberge from Stage 2 talks about the leading indicator of customer retention, that's what I'm trying to convey here. And we need to design a bullet train to that moment. And then we just keep attacking constraints, right? Like, if the constraint becomes market size, maybe we need to launch a new product instead. With our existing customers, which is like building a second case study factory, finding pull again. Maybe we need to enter a new market, right? We can create multiple different factories or multiple different lines in our factory. If there's a constraint where con code is making DIY good enough for more and more things, we have to find pull again. And there is always a constraint. If there isn't a constraint, if you don't think there's a constraint, you might need to look internally. So with that, I will leave it here. I would, you know, if you've gotten this far, please consider ordering the book and reach out to me. And these are the set of books that I would read or that I just enjoyed and think you would too, if you've enjoyed this. So thank you. I hope this helps. And again, there's— once you understand the model, once you understand the kind of like physics, it becomes a little bit less hectic. And I hope more clear exactly what to do in such a way that it will actually move the needle and cause you to build something that the world desperately needs.