# The Power of Pull: Validating Real Customer Demand

**Podcast:** Tech Lead Journal
**Published:** 2026-10-26

## Transcript

I came out of McKinsey and Harvard Business School thinking I knew how business worked, thinking I knew what I was doing.
We had done a bunch of customer research, interviews, run experiments, recruited design partners.
And so everything seemed like it was lined up to succeed.
We had even raised money from VC.
And then it didn't work.
Then we tried to sell it and nobody would buy it.
And we couldn't figure out.
Why?
Today's guest is Rob Snyder, author of The Power of Pull, who turns startup failure into a framework for finding real customer demand.
And then randomly, we went zero to four million ARR on a different product.
I had no idea why it worked when it worked.
And then I didn't understand why it didn't work when it didn't work.
potential users, doing design review and things like that.
Why did you think that also didn't work?
What I've since realized is we do all of this customer research looking for the wrong things.
We look for pain points and problems, but it is not what's going to cause people to buy.
In my mind, is that there is a thing that's called demand, which is what we're looking for, but we misinterpret what demand is.
It is not desire for a product.
Demand is out there in the world.
It's somebody trying to do something.
It's like a project on their to-do list.
What we're looking for is somebody who is prioritizing something on their to-do list right now where their existing options for doing that thing are not good in their mind.
And so that's where the pull framework comes in.
It describes four different components that have to exist where if these things are present, somebody will pull the product out of your hands.
It would be weird if they didn't buy your product.
And if these four things aren't present simultaneously, it would be weird if they bought the product.
And so the four things are...
Hey, quick pause.
My goal with TechLegional is simple.
Learn from the best in tech so we can all grow together.
If this resonates with you, hit subscribe to follow the channel.
It's the biggest way for you to support the show and help us keep bringing great guests and insights to you.
Thanks for being here and let's get back to it.
Hello everyone.
Welcome back to another new episode of the Tech Lead Journal podcast.
Today, we have an episode mostly covering about product management and building a successful startup.
I have Rob Snyder today with me in the episode.
He just recently published this book titled The Power of Pool.
What you need to know about customer demand to build a successful startup.
So I think I find this book, the core thesis is something a little bit different than what the usual product management book that maybe you have seen in the past.
So I'd like Rob to actually tell us more about the concept of pool.
It seems to be a pun intended, pool.
But yeah, I'll let him speak more about it.
So welcome to the show, Rob.
Thanks so much for having me.
Rob, maybe in the very beginning, tell us a little bit more background.
Why did you come up with this book?
Because I know you have a story behind it as well.
And you're kind of like failure story with your startups.
And that led you to writing this book.
Yeah, totally.
So I came out of McKinsey and Harvard Business School thinking I knew how business worked, thinking I knew what I was doing.
And obviously the next...
cool thing to do after McKinsey and HBS was to build a startup and, you know, become a tech billionaire.
And so I was like, cool, that's clearly the next box to check.
And so I'm going to do that.
And we did kind of like everything you're supposed to do.
We had done a bunch of customer research.
We had done a bunch of interviews.
We had done run experiments.
We had recruited design partners.
We had proved a ton of value.
They were using our product every day.
And so everything seemed like it was lined up to succeed.
We had even raised money from VCs showing all the kind of like traction and all the research and all the stuff that we had done.
And then it didn't work.
Like then we tried to sell it.
And nobody would buy it.
And we couldn't figure out why.
And so that went on for two of the worst years of my life.
It was just like I was hitting my head against the wall every single day.
And it was terrible.
And then randomly, we went zero to four million ARR, like on a different product.
A customer called me and was like, hey, I don't need what you're trying to sell me.
Like, could you do this other thing?
And you would think, okay, cool.
Well, you figured it out.
No, I didn't figure it out.
I had no idea why it worked when it worked.
And then I didn't understand why it didn't work when it didn't work.
And so I have just been kind of trying to figure that out since.
And the book is my attempt to formalize what I have learned in the past, I don't know, decade trying to figure this out.
Yeah.
So when I read the intro of your book, you told the story as well.
I find it quite fascinating because I'm sure it is quite relatable for many startups founder.
And I think many startup founders, even though they succeeded in the end, right, they didn't start with the same idea with what made them successful in the end, right?
So I think this is quite classic problem.
But you mentioned that you also kind of like followed all the true tested methodology of how many startups these days are also doing, right?
You know, doing research, asking, maybe interviewing potential users, right?
Doing design review and things like that.
Why did you think that also didn't work, even though we have kind of like...
prayed, you know, using this methodology a lot in these days.
Yeah.
So it's basically, it's taken me a long time to figure out why those things didn't work.
At first I thought I was just incompetent and it was just, it was just like, wow, I'm clearly very bad at this.
But then I've seen a bunch of my friends and a bunch of other founders from all across the world try to do these things and they also don't work for them.
And so I was like, okay, maybe I'm not the idiot here.
And so what I, what I've since realized is that.
We do all of this customer research looking for the wrong things.
We look for pain points and problems and we look for them to say, oh, wow, this would be super valuable.
And we look to sign on design partners and we actively avoid sales in all of this customer research.
All of that is wrong.
Like all of that, looking for pain points and problems sounds like the right thing.
But it is not what's going to cause people to buy.
And so you wind up doing all of this work, rigorous work.
I've seen hundreds of customer interviews looking for the wrong thing.
And then you find it and you build a business or a product based on the theory that you found the right thing.
And so all of this leads to it would be weird if you succeeded following these kind of like.
academic style research techniques that we've all been taught.
Yeah.
So when you mentioned about that, I think in my mind, I associated this with like, for example, jobs to be done, right?
So I think it was quite kind of like quite famous, like you find the persona of a particular user, find out what are the jobs to be done, what are the pain points that they have, and you try to solve that with your product.
Or the other thing is like...
If you also know about Henry Ford's quote, right?
So if you ask the users what they want, they just want a faster horse, not a car, right?
So what is your take about all this?
Because it seems like it is kind of ingrained in the product management world about this concept.
Yeah, so this one's kind of hard to unpack.
So where I'll start is we have to have a theory about what causes somebody to buy a product.
And specifically, that theory has to state what's going to cause somebody to buy a new product when there are plenty of existing products on the market.
And so this gets kind of hard, which is to say there's a lot of noise out there.
There's the Henry Ford quote, like you mentioned.
When it comes back to...
in my mind is that there is a thing that's called demand, which is what we're looking for.
If somebody has some kind of demand, then they will buy a startup's product.
But we misinterpret what demand is.
We think that demand means wanting a product or having pain points that lead you to a product or something like that.
And if you think that demand means wanting a product, well, then you're going to say, well, I'm building something new.
How could people know they want it?
And so you're going to kind of look for pain points and stuff like that to say, well, they have pain points.
And so maybe therefore they will buy it and maybe they'll evangelize, maybe I'll convince them, maybe I'll category create my way to success here.
That's kind of the default mindset or it's on the other side of it of if they have a problem and that problem is big enough, they will want to buy our product.
It turns out there are plenty of problems that people have that they do nothing about.
You and I, right?
I'm sure our lives are a series of pain points and problems.
And for most of them, we don't do anything and we're not going to do anything.
So there's a difference there between problems, pain points, wanting a product.
That's not quite what demand is.
Demand looks more like trying to do something, like a project that I am prioritizing on my to-do list.
And that does kind of rhyme a little bit with jobs to be done.
but it's not exactly the same.
There's some nuances there.
Yeah.
So I think you have mentioned a lot about demand.
So maybe let's try to unpack your method, right?
The pool, the power of pool, right?
So I'll let you explain what is pool so that we can cover a lot more about this demand thing.
Yeah, so the core thing is that demand is a standalone thing.
It is not desire for a product.
Demand is out there in the world.
It's somebody trying to do something.
It's like a project on their to-do list.
Now, somebody can have a project on their to-do list that they're prioritizing right now.
and not buy your product because all the existing products are good enough, right?
They have existing products, they have something they currently use that's good enough.
So what we're looking for is somebody who is prioritizing something on their to-do list right now where their existing options for doing that thing are not good enough in their mind.
And so that's where the pull framework comes in.
It describes four different pieces.
that have to exist, four different components that have to exist, where if these things are present, somebody will pull the product out of your hands.
It would be weird if they didn't buy your product.
And if these four things aren't present simultaneously, it would be weird if they bought your product.
And so the four things are there's a project on their to-do list.
It's unavoidable.
P is project.
U is unavoidable.
First L is they have a list of options for getting that project done.
And the second L is those options have limitations that prevent them from getting that project done.
And so all four of those things must be present simultaneously.
Project, unavoidable, list of options will have limitations preventing them.
They're trying to do something they can't do with their existing tools, available tools, methods, options.
If that's the case, they will rip something out of your hands that just unblocks them.
Yeah, I like the way you play with this word pull and suddenly it's like someone pulling your products, right?
That's the demand, so to speak, right?
So definitely makes sense with all these explanations, right?
That's like the potential customer is having a project in their to-do list that is a high priority at the moment, right?
It's unavoidable and they have some list of options how to solve it, but they think it's not good enough.
There are limitations to those options, and that's why they are looking for this new product that maybe you're creating.
So maybe out of these four, in a typical startup world these days, when people build product, what do you think are the most missing piece?
Oh, gosh, all of them.
So this is not a framework that people use, and it's not a way that people tend to think.
We tend to think from our product or from our idea to the potential customer.
and say, so given that my idea is agentic workflows for manufacturing or whatever it is, right?
What are the pain points or problems in manufacturing that we can tie to, that we can talk about, that we can evangelize?
What are the use cases?
Like these are all ways to reason from our product idea or our product to the market.
And the pull is a totally different way of thinking because you have to entirely forget that your product or idea exists.
And you're just observing buyers in their natural habitat, going about their lives and realizing that most of the time, they're just fine.
They don't need help.
They're not stuck.
And you're looking for the points, again, just pretending you don't have a product, where they are.
stuck, where they're trying to do something and blocked.
And so this way of thinking requires the hardest thing a founder can possibly do, which is to totally pretend your product idea and you don't exist and see in the cold light of day where people are getting stuck and then designing around that.
Totally counterintuitive.
It changes how you approach product development, how you approach sales, how you approach kind of everything from that point of view.
But yeah, the general thing I see is that this is not even a method of thinking that is available to us given how we see the world.
Yeah, I can see why it's not something that is usual because...
You know, many people these days, especially, they go through like, you know, I don't know, like product management class, you know, startup class academy or something like that.
And they're taught to actually execute their idea, their vision, right?
Not necessarily finding, you know, like observe what people do in such a way that they are stuck.
So which means that what kind of research, what kind of, you know, like, I don't know, methodology, if it exists to actually help you observe these kind of, you know, limitations that people are having in their day to day?
Yeah, I'd say there are kind of like two broad methodologies that I recommend.
The first, so I actually strongly do not recommend customer interviews or like, especially, I mostly focus on taking things zero to one.
And so there are ways you could do interviews, but I just find it's like, it's...
way too error prone.
And there's no kind of like truth seeking mechanism at the end where you can learn a bunch of different things.
But if somebody isn't forced to get real and buy or put money down, you don't actually know if you learned anything or not.
So the first methodology that I actually recommend is just selling.
Sales is a really, really useful way to learn.
And it can kind of feel like research because in sales, if you're doing it right, You're asking questions and you're getting answers.
And then at the end of it, you see if you learned anything by whether they try to buy or not.
Okay, cool.
But if you don't actually have a hypothesis of, okay, what is pole?
Like what is somebody, where is somebody trying to do something and stuck?
Then I recommend a method that I call, go to the Gemba.
That's from Japanese manufacturing.
It's like, go to the place where the work is happening.
Go to the shop floor.
Go observe, do the job, get a firsthand experience yourself doing the thing that you're trying to sell into.
So an example is HBS grad told me about his, he just wrote out a list of industries that he was interested in maybe building a product for.
And he went and spent a week just riding along with a small business owner in each of the industries.
And it was like, okay, cool.
I'm just going to first see if I like this industry.
I'm going to try to build an intuition.
for these people.
And then I'm going to try to find the places where they're trying to do something in stock.
So first-hand is way, way better, way higher fidelity than kind of like second-hand research and interviews and surveys and all that nonsense.
Yeah.
I like the concept when you say sales is a research by itself, right?
So I think many people maybe avoid doing sales as a first thing.
They want to build something first.
Although these days they...
think in MVP or not, like build an MVP and try to, you know, have a customer or user using it.
So I think selling is obviously the best way to actually know whether you get rejected or get accepted, right?
So I think that definitely makes sense.
One probably counter argument that I have is what about for products that like innovative or, you know, like a visionary thing?
I mean, think of it like the SpaceX things, like building a rocket, you know, to Mars or something like that.
Yeah, yeah.
So those, I actually have helped out a lot at like a lot of deep tech places where, yes, we're building some kind of like innovative thing.
I think the misconception here is that because a product is going to take a lot of time to develop or technology is going to take a lot of time to develop, or it's a like crazy idea, that because of that, we can't find demand right now.
And that's actually exactly the opposite of the truth, which is the crazier the idea, the longer it's going to take to build, the like, the more important it is to find demand right now for it.
And because it's like way less likely to work.
And so what I've seen is that there's a kind of misconception here that's like, oh, because we're creating a new category, because we're building a totally innovative product.
People don't know if they want it.
They won't know if they want it until they see it.
It's not true.
That's not true at all.
Because remember, that's conflating demand with wanting supply.
That's the Henry Ford quote about faster horses.
Like, okay, they wanted faster transportation.
And when a concept was put in front of them, a means of faster transportation, they pulled it out of the seller's hands.
even before it was built.
And that's what I tend to see in these innovative, especially deep tech and like future things.
And like SpaceX is a really good example.
Like, do you think they tried to pre-sell this?
Yes, they tried to pre-sell.
They were, they found the government was going to be their number one customer.
And they were talking with the government all the time, trying to get, trying to pre-sell this.
And the government was, was giving them grants and saying, cool here, right.
Like they went from successful rocket launch to government contract and like, three months, like hundreds of millions of dollar government contract in three months.
That doesn't happen unless you've had the sales conversation that was like, okay, the last checkbox on this government contract is that you have to get a rocket into orbit.
So these are all kind of misconceptions.
Well, thanks for unpacking that.
Definitely makes sense, right?
So I think now I'm quite curious in your world, what do you mean by this?
this demand and supply, right?
Because I think you have some slightly different perspective about this demand and supply versus the typical economic definition of it.
Yeah, so we took econ 101, right?
There's the demand curve, supply curve.
And so I actually got this way of thinking from Ryan Singer, who was at Basecamp before.
And he was describing this actually in product terms.
He has a really great video about this.
It's called Feature Requests Are Not Demand.
And this is like, I've just like broke my brain.
So it's such a useful video.
I think it has like 15,000 views and I am like 14,000 of those.
So, but the, when we, as I've been talking about, right, we tend to think of demand as like wanting supply or willing to pay for supply, which means it's a concept that only exists in reference to supply.
And if it only exists in reference to supply, well, then the only answer is, well, let's build supply and create demand for it.
That doesn't work.
And the products that take off do not behave anything like that.
What we have to realize is that demand, so supply, we know what it is, right?
It's our product.
It's our service.
It's like all the things.
Demand is a separate thing.
That is not wanting supply.
It might result in the purchase of supply.
Or the behavior like I want supply.
But it's a separate thing out there in the world.
It's trying to do something.
It's like projects on my to-do.
I think of demand as like the Trello board or Asana board in my brain.
It's all the stuff I'm trying to do that doesn't have anything to do with products or features.
I'm trying to figure out how to collect money from my first customers.
I'm trying to figure out how to stop bugs from getting to production.
It's all of these things that I am trying to do that I might then jump over to the supply side.
to say, okay, what's the tool that can help me do that?
Or what's the method by which I'm going to do that?
And so you have to separate those two and realize that demand is upstream of supply.
It exists independently, but it causes supply to be relevant or not.
And so once you have that, I call it, you join the cult of demand when you start seeing this, which is, once you start seeing that demand is just a thing that is out there.
You go looking for it where people are trying and stuck.
And then you find that first and then design a product around that.
Yeah.
So I think it's a slight variant of what we are used to in terms of concept of demand and supply.
So I think thanks for mentioning that.
So I think, let's say this makes sense.
So I think the next step for you in your book, you emphasize a lot about finding the...
single, you know, hell yes kind of a customer, right?
So why is it so important to find this even like just a single yes, not like, in fact, people are talking about cumulative potential users that really love your product, only then, you know, they think it's worth to do.
Yeah, I mean, so what I tend to find is that we, especially product people, tend to think in abstractions, in groups, in personas, in niches.
Business only, like people, individuals buy and use things.
There is never, no niche, no persona ever uses a thing.
And it turns out when you kind of look at an abstract level, it's very hard to figure out what to do.
And so you always have to start, you go one customer at a time.
You always sell one customer at a time.
Customers have experienced your product one at a time.
in isolation and they go.
And so, so what I've found is that when you start thinking and when I start thinking in these abstractions, I always just create the abstraction that I want to exist.
I create the persona that I want to exist who happens to love my product.
And so, uh, the, the, the antidote to that, because obviously that person doesn't exist.
Nobody cares about my product.
Nobody, nobody's waking up in the morning and saying, you know what, Rob's B2B software is like, really, that's really interesting to me this morning.
Like, no, that's insane.
And so what I find, the only reasonable antidote to that is going one customer at a time.
And that's why I like starting with one-to-one sales, whether you're building a consumer product or a B2B enterprise product, you're one at a time.
And it's not just, can I...
get somebody to buy?
Can I convince somebody to buy?
Can I twist somebody's arms?
No, because what I want is I want somebody who is a hell yes customer, who pulls the product out of my hand more than I have to exert effort to get them to buy.
And then after they buy, they use it as if they are addicted to it.
It would be weird if they churned.
My job is to first figure out one of those, because I can't figure out 10 of those.
You know, like you first have to figure out one.
to then figure out how to get to 10.
And so what I tend to find is that startups, and I've done this a bunch of times, is you get your first 10 customers.
Half of them you had to push.
The other half kind of pulled.
Some people maybe really pulled.
And then some people, after they buy, hate you, just absolutely hate you.
They're like, oh, the worst thing ever.
Some people are quite happy.
And then some people are like, oh my gosh, this is the greatest thing ever.
And so I've found that you have to compare.
the people who are hell yes customers versus the others to figure out what actually creates a hell yes customer.
What is the demand here?
Who should I actually be targeting?
And then you kind of do a refresh of the entire business to just focus on your hell yes customers.
Yeah.
Focus on the hell yes customer.
I think definitely it's like very, how should I say, very...
pragmatic, right?
So you find really like the raving fans of your product instead of like pushing, cajoling people to actually buy your product, which in the end is not like a hell yes customer, right?
Because it's probably like you influence them too much about it.
So for many startup founders who are currently not operating in this way, they are still kind of like in the traditional world of doing product management.
You refer to them as living in this pain cave.
How to realize that they're actually, you know, trying so hard, but actually there's no demand for their product.
Yeah.
So there are some very common symptoms that I have experienced basically every single one of these.
So if you feel judged by this, like, trust me, I've done it.
So most common one is if you have conversations with potential customers and you hear a lot of enthusiasm and then they don't buy and it's not clear why.
That is just like the classic signal.
Or if they ask for, oh, can we get a free pilot?
Oh, maybe we should try it.
And then it just kind of starts extending and extending and extending.
That is the most common thing.
And what I'll tell you is it doesn't get better.
It's not like if they don't try to buy it basically right away, there's a startup I know that like they just did an analysis and they're growing and they realize that their pilot, anybody who asked for a pilot.
Their conversion rate on that kind of customer is zero percent.
Literally zero.
And they're growing.
Everybody who actually has demand buys without a pilot.
And so what you're looking for are people who are actually going to pull this out of your hands, who are going to try to buy.
Pretty quickly.
First call, maybe second call.
They actually are trying to buy.
And if you don't have that, if you're hearing things that are like, this is amazing.
This is exactly what, this is an important product to be building.
This is exactly what the industry needs.
Or even things of like, well, this would save us a million dollars a year.
What you're not hearing is, I need this right now.
How do I buy?
If you're not hearing that, then you are almost certainly in the pain cave and you're going to continually follow up with credential customer and they're going to reschedule and they're going to reschedule.
And it's just, and you're going to be, it's going to like, what the heck am I?
I'm pushing them to get them to do a free pilot.
What the heck is going on?
And then when you get somebody, like you finally get somebody into a free pilot or a paid pilot, even who cares?
And then you're pushing them to use it.
It just feels like all you're doing, spending all of your time pushing and convincing.
And if that sounds like you, then you are almost certainly in the pain cave.
And it requires you to have this thing that we talked about earlier, where you stop thinking about your product at all.
Just eliminate it from your brain and focus first on who has pull.
Where is there actually somebody who is trying and blocked?
That will solve it, but it will require you to, like, it's very hard to do that.
Yeah, I remembered in my previous startup experience, startup world, right?
It sounded the same like me, right?
So always when you introduce your product to some users, you know, random people, they think, oh, wow, it's a very, very interesting, you know, it's cool and all that.
but then they never put out their credit card to actually buy.
So I think what you said just now is definitely makes sense.
Like, and especially I think it's quite relatable for many people.
And even like, I think people assume this is the process, you know, especially in the B2B world.
And when you're trying to sell to enterprise, big corporates, they will tend to do pilots and all that.
Do you think it's still kind of like makes sense in this way?
Because traditionally, no?
Okay.
No, no, no, no.
Yeah, yeah.
Like that's, this is like, there's this, there's all this.
So I'll give an example.
There's a startup I know that spent two years just hitting their head against the wall.
MIT, super smart PhDs, like hitting their head against the wall, trying to sell some AI product into like HR or something.
And didn't work.
They got all these free pilots, just all these things that we talked about, right?
Free pilots, people using it, people enjoying it, and nobody actually buying.
And then they randomly got an intro into enterprise pharma.
They had no experience at enterprise pharma.
Their product was totally not related to it.
And so they didn't have a product.
They didn't have an idea of what they would sell.
And they basically just said, what would you pay us to solve for you?
What would you pay us to do?
And the person was like, oh my gosh, thank you so much for asking.
Here, we're trying to do X.
And that demand was so intense that without a product, They were able to sell into Enterprise Pharma in like two months with no pilot.
The Pearson, and I've seen this again, like big fortune 100 media company, a very similar thing happened.
There, where an enterprise bot, like we tend to think that it's, oh, because they're big enterprises, it has to take forever.
It's like, yeah, maybe if it's priority four or five out of, you know, 500.
But if there's actually somebody who is trying to do something and stuck and can't do this really important thing they're trying to do, they will pull something out of your hands, even if the product isn't built yet, even if you don't have your sock too, even if like all of these different things are not present.
And that's what you're looking for.
Yeah.
So, yeah, similar story, just like what you mentioned in your book, right, in your intro, like same experience, like you were trying to sell something, but in the end, you know, somebody asked you to do something else, right?
So I think it's quite a similar story.
So you mentioned about AI product.
I think now it's like the time of, you know, AI hype and all that.
People think building product, building software is actually quite easy, very cheap.
It can be done within, I don't know, days probably.
What's your take about this?
Because it gives the impression that you can just build.
build and build so many different products, is it actually a good strategy?
There's upsides and downsides to it.
So the good news is that you no longer have the excuse that you need to put your head down for six months to build the right thing, which means you are forced to deal with the cold reality that, hey, this thing you just spent a week on building, nobody cares about.
And, oh, wait, actually, It doesn't matter what we build if there's no demand, if we can't find demand.
And so in that sense, it's a great thing.
It's a really, really good thing.
You know, the downside of AI is that now everybody thinks they can build or many people think they can build anything.
And so it's even harder now to find demand when now do it myself with clog code is a viable option.
in a lot of different cases.
And it's a very good option in a lot of cases.
And so you have to find pull demand out there in the world where do it myself with cloud code isn't a viable option.
Yeah.
So I think many people are thinking about vibe coding and especially in the SaaS world, right?
Many people, some people think SaaS is dead simply because they think, you know, I can just build my own SaaS, you know, to customize whatever I want.
Right.
And hence, probably the pull is probably something that is more difficult these days, right?
So what is your probably advice for people who are building SaaS, something like this, like in order to protect, you know, their product from being vibe coded by someone else?
I've seen two methods here that have both have worked.
And there's probably more.
I've just only seen two so far, which is the first one is to focus on people for whom Vibe coding myself is not an option.
So this is why, I don't know if you pay attention to YC, but you see what often happens is people enter YC building dev tools and leave YC selling into insurance.
And so insurance, right, or logistic or whatever it is, like a lot of these mainstreet businesses, they don't want, like, yeah, they could learn to Vibe code.
but they're like normal human beings who don't care.
Don't want, like, I don't want to learn this kind of stuff.
And so that's path one is find people for whom DIY is not an option.
The second is find people who have tried DIY and hit some wall that DIY does not make possible.
So an example of this is a friend's company.
What they've found is that a lot of people are trying to DIY their own company brains.
So you make your own kind of personal brain.
You use the Karpathy stuff.
You do all that fun stuff.
And then the second you try to expand this to your team, you're like, cool, let's all connect our emails.
Let's all connect our slaps.
Let's all connect our meeting note takers.
And we'll put it all into this company brain.
That's going to be awesome.
And then someone says, but wait a second, I have my one-on-ones in our note taker.
Like our, our, my HR conversations are in there.
Like, what do we do?
And like, that becomes a hard, a place where you're like, oh, that's a wall.
And so there becomes a need at that point that leads to where DIY it's like, oh, I don't, that's actually seems really hard where DIY becomes no longer an option.
And so those are the two permutations that I've seen.
Yeah, no, I think definitely.
Yeah.
I think for people who.
who tried this method of vibe coding, right?
Obviously, sometimes they succeed, right?
You know, building stuff.
Initially, they probably feel, oh, I can build everything.
But yeah, definitely some complex product, especially enterprise needs, definitely requires much more, you know, capability.
So maybe- And I would also say just on that, just sorry to interrupt, but like what I've found too is after people have tried to DIY it, they become excellent customers.
because they know what they need.
They know they can appreciate the product.
Yeah, makes sense.
So these days, AI models are getting smarter and smarter, right?
And I think this is also one aspect of, I don't know, like in the world, right?
We think that AI is going to replace everything, many, many different things.
What's your view about this in the perspective of, you know, like building startups, you know, building technological products, right?
Or even building AI products, right?
Yeah, I mean, everybody's been predicting Harvey and Lovable's doom for like ever.
And, you know, they still seem to be growing.
I don't know.
I'm not on the inside.
I have no idea.
But so what I'd say is I just try not to predict the future because it turns out future is quite hard to predict.
And I'm not that smart.
And so what I've seen is that like, yeah, the models keep getting better.
100%.
DIY becomes an increasing option for a lot of different people as the models get better, and more things can be DIY'd.
Great, that's probably, that is probably going to continue.
But what seems to also be the case is that the very last mile of a product matters a lot.
And so for lovable, like, a lot of people who don't want to have to learn quad code.
There's a lot of people who want a website, don't want to have to learn Cloud Code.
For Harvey, it's like, okay, there's a lot.
There's like the last mile here that seems to be very, and you can kind of stay ahead and you can kind of tailor it even more at the last mile.
And like, I don't know.
And you just like, it's not a static thing.
So you all, I assume the Harvey team and I assume the lovable team are like, constantly anxious and freaking out about this and that anxiety and freaking out and like seeing all the magical things new models do and then also paying attention to what their customers need, what their specific customers need, what their specific prospects need.
Like those forces cause them to keep figuring new stuff out.
And that's, I don't know, that's what life is.
Yeah, it seems the iteration now getting faster and faster and you probably have competitors also easily, you know, cloning the same thing, right?
So I'd like for you to cover another maybe so-called anti-pattern, right?
Because I see many founders when they started their startup, they also think, I want to solve my own problems, right?
And kind of like I'm the first person, first customer, first person to solve, right?
And they kind of like live in this world for the rest of the company, right?
Is this also a viable approach in your view?
It is, it is, but there are two ways to do this.
There's the first one, and I've done both.
Way one is to say, I'm building the product that I want to exist, but there isn't a specific moment in my life when I would have actually paid for it.
Right.
And so that is called an ego project that is not building a product.
The other side of it is like, I think that every founder needs to basically have firsthand experience of the poll that makes their product relevant.
And so, yeah, like generally you are not, you are not interesting enough to build for like in a lot of cases, like you, you just haven't had something where you're like, oh my gosh, I need something here.
I, I actually, I would pay for something that doesn't actually exist in this space.
Maybe you do cool.
Build for that.
If, if you don't have that, don't just build the product you hope.
people will like, or you think, you know, you're going on an ego trip and like, everybody's going to worship me because I'm building this product.
Instead, go get firsthand experience so that you can build for yourself.
You can become someone who's worth building for and then build for yourself.
I think that's totally fine, but it's really, it was their real pull there.
Yeah.
I find that when you mentioned like finding the moment when you actually will buy your own product, right?
I think that's the true moment as well, right?
Because you could.
You could probably have a fancy idea, but in the end, you would probably not buy it.
And I guess it's not like a real pull as well.
So is this the same as the concept of LARPing?
I mean, in your book, you mentioned this A-L-A-R-P thing, right?
So live action role-playing.
Is this the same or is this something different?
Yeah, so this would fall into the category of LARPing.
So for those who don't know, LARPing is, again, I have nothing against LARPing.
It's just kind of a funny thing.
LARPing is basically, there are people who go into the woods and reenact or playact medieval battles with swords and they get all dressed up and this like a thing.
And so it's a totally reasonable, acceptable hobby.
I have nothing against LARPing.
The problem is that most of what founders do in the early stage is LARPing.
without realizing you're LARPing.
So you're essentially just like, imagine you're in a normal business meeting, but you're dressed up in like medieval armor.
It's just like so embarrassing when you do.
And so LARPing is this category of activities that look like they're business things.
They're things you would do to build a business.
but they have nothing to do with building a business.
And so you only realize after the fact that you've been LARPing for a huge amount of time.
So these include going to pitch competitions, going to startup events, going to like, you know, spending a bunch of time on your mission, vision, values statement before you know what you're doing.
Like it's all of these kinds of things that reflect a...
lack of an understanding of what causes a startup to work, but feel like business things that businesses do, right?
And so it's, you know, the other image I have in my head is like a child wearing a business suit, just like tapping away at a computer.
It feels like that.
Sometimes you realize you've been doing that.
Yeah, it's always, I think, in the excuse of doing marketing or building branding and getting more popularity or awareness, right?
So I think...
Definitely, it's a gotcha as well.
Like, don't do this LARPing thing, which I think totally bring you away from the true things that you need to do for your business.
So speaking about doing the things for your business, right, in your book, after you found several, hell yes, right, so I think in order for you to scale, obviously, you can't just do for individuals, one individual, one individual, right?
So in your book, you mentioned about this process of, you know, collecting, I don't know, what do you call it?
Success story factory?
Tell us about this concept, like how can people scale their products to become much more successful?
Yeah, so I found that we've like, we lack some like very useful conceptual models for like, how does a startup actually work?
And so what I found is that when you find somebody who has pull, who pulls the product out of your hand and is successful with it.
The result of that is like a customer success story or a case study you would find on your website.
And that's kind of like a hell yes customer, right?
And so your job as a founder is to just figure out how to repeat that.
And you want to repeat, the reason you want to repeat that.
and not have to create a new one every single time is because it's a lot of work to create a new one.
And then you have to build all sorts of features that are for each individual person if you're building a product.
And so you kind of want to get towards repeatability, where you're doing the same thing every time.
And you're kind of bringing somebody through the process of becoming a potential customer, becoming an actual customer, becoming a hell yes customer.
And so when you think of it that way, that it's a...
The goal is to produce a bunch of basically identical case studies, a bunch of identical success stories.
Then what a startup is, is just a factory for producing case studies, success stories.
And so that's why I call it the success story factory.
And when you have that factory model in your mind, well, you can bring to bear a hundred plus years of thinking about how to effectively run a factory.
product flows through a factory.
And like the most useful thing I've found is the theory of constraints for running a factory, which is, hey, we have people who are potential customers.
We're turning them into actual customers.
We're turning them into successful customers.
The goal of this factory is to maximize the production of hell yes customers who look very similar.
Well, what do I need to do today?
Well, I need to figure out where in the factory is the constraint, is the bottleneck.
Oh, is it that we're not talking to enough people?
If that's the case, then I just need to focus on that.
Because if that's the factory's constraint, then if I do anything other than that, it won't lead to an increase in production out of the case study factory.
So the factory model is a way to think about your business, is a way to see your business, how to see how all the pieces connect.
And you can see that it's not, okay, engineering isn't a separate thing from product, isn't a separate thing from sales.
It's all part of one.
kind of factory model that you can then use to know what to do at any one point in time.
Yeah.
So I think theory of constraints, many people of my listeners would probably relate to that, right?
Because it's quite common in the DevOps world to actually figure out what's the next constraint once you solve the bottleneck, right?
And there's always constraints somewhere, right?
It's not like, it's never ending, right?
So it's just moving from one part to the others.
Yeah.
So Rob, I think we have covered quite a lot of things, right?
Is there any...
things that you think is important for people to understand about this pull framework, right?
The power of pull so that we can also learn from that.
You've done a really awesome job getting all the biggest parts out of it.
What I would say is that pull is upstream of everything in business.
It is upstream of your product.
It's upstream of whether your go-to-market works.
It's upstream of what you should do and go to market.
It's upstream of how you should describe your product.
It's upstream of everything.
And it exists out there in the world, independent of you or your idea.
And if you just like sit with that, if you just try to embrace that concept, you will spend way less time building something that people probably won't want.
And you will find people who will actually pull a product out of your hands.
Yeah.
So it's an upstream.
So find the pool first, right?
So I think it kind of like reminds me of this.
lean concept, right?
So don't create too much waste, you know, always pull rather than push.
So I think that's pretty relevant.
So yeah, thanks for reminding that.
So once you have this book, right, once you kind of like, you know, mention about it, teach other people, is there resources available out there for people to actually learn more about this pull concept, right?
Or maybe there's online resources and things like that?
Yeah, totally.
So I probably put out too much content out there about this because I still view that my job is to keep figuring it out.
It's not complete.
It's still a work in progress.
And so at robsnyder.org, you can find a bunch of links to stuff.
I have a newsletter.
I have like a YouTube channel where I try to explain this.
I've even recorded like a three hour, it's absurd, but a three hour like walkthrough of all the concepts.
And then there's the book too.
And if that's not enough, I'm working on an AI Rob Snyder kind of like thing that you can plug in the clod.
Not quite ready for prime time yet.
And then you can kind of like work with me or I run kind of like little go-to-market accelerators for zero to one.
Right.
Yeah, I hope many people pull all this thing from you, right?
And hopefully the concept becomes much more important in this product management and startup world.
So Rob, I only have one last question for you before we wrap up the conversation.
I call this the three technical leadership wisdom, but I think for you, it doesn't have to be really technical.
So any kind of advice that you want to give to the listeners, that will be appreciated.
Yeah, yeah.
So I want to give three ones that are like super contrarian.
And so first one is, Tech comes last.
Like basically, avoid tech as much as humanly possible.
Especially for AI products, you should be able to sell them as services first, in most cases.
And so, do that.
Automate last is like the kind of thing from Elon's algorithm.
It's the same thing as startups.
Tech last.
Okay, that's thing one.
Thing two.
Make your product seem small.
not large.
In a sales conversation, when you're talking with a potential customer, you're going to think that the bigger I make the product seem, the more they're going to value it and want it.
When what you're really doing is creating more surface area for them to have to understand and ultimately object to.
And so once you understand the kind of physics of what causes somebody to buy, trying to do something and block, all you need to describe and show is the smallest possible thing that demonstrates that they will be unblocked.
Anything you show other than that adds wind resistance.
It convinces them not to buy.
Okay, final thing is that sales is the exact opposite of what you think it is.
So we tend to think that sales is I'm convincing you to buy.
I, the seller, convince you, the buyer, to buy.
That's not how sales works.
That's not what causes somebody to buy.
When you think that way, one, you're going to be awful at sales.
And two, you're going to do everything in your power to avoid it or delay doing it.
And so you're going to cause your startup to fail.
Sales is the exact opposite of that.
You're going to buy because you're trying to do something and you're stuck on it.
If that's not the case...
It would be weird if you bought from me, no matter what I do or say.
And so my job in sales is to lean back and figure out, are you trying to do something in stock?
If so, describe the smallest possible thing and lean back and see what you do.
You should try to pull that out of my hands.
And that's why sales is such a good research methodology.
It's not convincing people to buy, it's leaning back and giving them the space to demonstrate that they have pulled.
So you should do that right now.
Wow.
It's true that most things, if not all, are kind of like contrarian to what most people believe, I guess.
So thanks for sharing that.
I find it quite insightful, right?
Especially like the last one about sales, right?
Because we all think sales is like convincing people, influencing people.
And the bigger it gets, the better, right?
Or the cheaper it is, the better.
But it's not about that.
It's all about finding the kind of like needs, right?
The project that people want to do and they are stuck with the options that they have.
So I think that's pretty insightful.
So thank you so much, Rob, for this conversation.
I hope people learn a lot from this concept.
I find it quite fascinating that we all have a new methodology, so to speak, right, in the startup world and the product management world.
And I hope it's going to be beneficial for people who listen as well.
So thank you for that.
Thank you.