The video discusses the importance of giving more value to users than taking from them. It emphasizes that if a product helps customers make more money, they will like it. The fear of being a consultant and the desire to grow quickly can lead to building products that do not solve users' problems. The video advises founders to understand their customers' problems and needs by engaging with them and offering value upfront. It also highlights the historical context of giving away value for free in the software industry. Ultimately, the key is to build products that solve customers' problems and provide value.

- Providing free or paid products that solve customer problems is crucial for success.
- Early-stage businesses should not be afraid of consulting or fundraising.
- This approach gives businesses an advantage.

The core secret to startup success isn't fundraising or growth hacking - it's solving your customer's biggest problems. But most founders are afraid to really understand those problems. What if that fear is holding your startup back? 
In this video, Group Partners Dalton Caldwell and Michael Seibel share how companies like Google, Twitch, and Microsoft succeeded by first giving more value than they captured - and how you can too. Learn why your MVP might suck on purpose, how to change your customer outreach, and why you should understand exactly how your customers make money. Because when you solve the right problems, fundraising and scaling become the easy parts.

Apply to Y Combinator: https://yc.link/DandM-apply
Work at a Startup: https://yc.link/DandM-jobs

Chapters (Powered by https://bit.ly/chapterme-yc) - 
00:00 - Intro
00:19 - Business 101
00:46 - Success Stories
01:34 - Minimal Value
02:31 - Fear of Consulting
03:42 - Early vs Late
04:58 - Forget Your Fear
06:01 - Customer Outreach
07:32 - Historical Context
09:51 - Takeaway

Sometimes founders are afraid of asking the like the dumb question, but that's a worthwhile question to ask.

But if you can help your customer make more money, they're probably going to like you.

This is Michael Saibo with Dalton Caldwell, and today we're going to talk about how do you give more than you take from your users.

Maybe we should start with a business 101, like MBA in 30 seconds.

So the basic idea underpinning all technological progress, business, very basic stuff is if you sell someone a tool, and if they can use the tool to make more money than the tool costs them, you're creating value when people like it.

And so, You know, some very basic examples, Google, when they first launched Google Ads, it was very easy to buy Google Ads.

You would pay Google per click, and you could sell stuff for way more than you paid Google.

So you would just do that all day long and make tons of money, right?

If you think about Word, you think about Excel, these are products that made normal office workers and normal kind of financial workers literally like 10 to 100 times more product.

And so if you can make an employee 10 times more productive, people probably buy that tool.

Buying a computer back in the 80s was expensive, and buying VisiCalc or whatever was expensive, but it was still way positive ROI, like 5 grand, 10 grand, no sweat.

There are a lot of founders out there that are building products that deliver no or minimum value to the user.

Classic fear is always like, well, I need to grow, right?

The most important thing is to grow in order to raise money.

And so I'm gonna build something that kind of sucks because like, or screw that it sucks, right?

I'm gonna build something that doesn't solve anyone's problem and just try to get money for it so that I

Yeah, it's like, it's make something VCs want.

It's the classic perverted thing that we are not fans of where you're like, well, superficially this resembles a software product that superficially people pay for.

And therefore we should charge a similar amount of money for it and like, the specifics of what it does as details, you know, we've got our top folks on that.

I think there's another 1 which is this fear of being a consultant.

I think 1 of the reasons why people build shitty products that don't solve people's problems is that when they start talking to a user and the user starts saying, well, here's my problem, I could really use this, this, and this.

The founder starts thinking about that and thinking and fearing, what if this user is different from every other user?

What if the problem they have is different?

And so what if I have to build something to make them happy?

I have to build something that no 1 else wants.

I think this is a core fear that happens because I think that every founder in the back of their head, thank you Reid Hoffman, is thinking, when can I get to blitzscale?

Like when can I raise the big round and throw this everywhere and have everyone use my thing?

And every founder knows in their heart that if they're not making a simple thing that everyone's gonna use, they can't blitzscale it.

And it's tricky, because like, this isn't

Yeah, there's a kernel, there is a good idea in there.

Like there's a good, there is an insight.

But I might argue it's exactly wrong when you're early.

Like what's the difference between being early and maybe not even understanding the problem well and being way later on when like being consultant is maybe more of a risk.

I think if you're not a deep expert on what the customer's problems are and how they make money and how they work.

You make assumptions about how their business should work, which could be mistaken.

So again, when the founders of Google started Google, I would imagine they were not experts on performance marketing, and how basically a lot of the early Google customers, as we recall, were mortgage refinance people, where they would buy people searching for mortgage refinancing, the advertisers would buy those clicks and they were worth a lot of money to them.

And the founders of Google did not need to be experts on that.

But as they got users and they built the business model, understanding what problems the the customers had was super important.

I mean what are some other examples of like...

I mean we've we've talked about this before but the classic examples with Twitch like we did not understand what streamers wanted until not only did we talk to them we started building things.

And so I think that like, maybe the issue here is that if you're being consultant early, what you don't end up doing is learning enough about the customer.

And so The counterintuitive advice we're giving is basically, forget your fear about it being insult internally, dig in with some customers, actually solve their problem.

And in the process, maybe you're building some stuff that's 1 off, but you're gonna learn a ton about the actual problem.

And then you'll have some insights on, okay, what's more generalizable?

What can I do that I can give to everyone?

And ideally understand the levers in their business that derives economic value.

Like basically, like don't make assumptions that you think you know how they make money or should make money.

better mental model of that, it's much more clear how you drive economic value.

And what's funny is you can even ask them.

You can even say, how can this help you make more money?

Like you can literally, sometimes founders are afraid of asking the like the dumb question, but that's a worthwhile question to ask.

If you can help your customer make more money, they're probably gonna like you.

I think 1 other area this applies that's counterintuitive is even in your customer outreach.

Because I think that a lot of times, founders when they're reaching out to customers, even in that moment, they're asking for more than they're giving, right?

We see these emails all the time where, you know, hey, I'm building X, Y, and Z software.

Do you have 20 minutes to jump on the phone with me to talk about it?

I think 1 of the things I've seen that works so much better in the initial outreach is when you actually offer something.

Now, we had 1 company in the current batch that basically was helping with customer onboarding, and they did this in the most simple way.

They actually took a video of the customer's onboarding flow, of the company's onboarding flow, and then provided their advice and feedback on what they could do to make it better.

Now, 1, that's the definition of consulting, right?

But when they started sending emails with that content in there, when they started giving as the first step, customers started replying, saying, "'Thank you, I can use that.

"'Like, yeah, I'm happy to talk to you about how you're thinking to make this even better.

So I think in outreach and in building your first products and dealing with your first 10 customers, You can give more than you receive.

Let's put this in historical context though, because this giving before you receive is not new.

Yeah, this is a whole broad topic, but just quick crash course.

The history of computers involves giving away a lot of value for free.

Specifically, the original business models of computer companies were to sell hardware and software was like a thing you had to give the customer to run the hardware to get value from

And so historically, software was just free and not really proprietary.

And this is beyond the scope of this talk here, but if you research the history of Microsoft, people in the audience, Bill Gates kind of pioneered the guilt trip to get people to pay for things.

I don't know, go read his letter, I'm not gonna do it justice, but the idea of proprietary software and charging for it was like, it came out in the 80s.

It was an innovation in the 1980s, maybe the late 70s.

And before that there was the free software movement which equated software and code to freedom.

Many of the tools that power everything to this day were created by hippies, created by people with big ideals, created by people that wanted to get more value than they receive.

So if you look at the history of GCC, of all the compilers, if you look at Linux, the Linux kernel, if anyone runs an Android phone, That's all free software.

There'd be no Google, there'd be no YouTube without Linux powering all this stuff.

Same with Git, like every web browser, Gecko, KHTML, you can research these things.

Also, SQlite is this free database that's in everything.

Like I'll bet to just watch this video stream, SQ Lite is involved like 50 different ways.

How many free products do you actually need?

And so this is part of the history of software and computing and technology is to give out all this value and realize the value that it's created can create enough economic value for the creators, for the people that make this stuff, and also just unlock more value in the world than what they charge.

And this is why the graph of how technological progress is accelerating so fast is this factor of giving more than you receive.

And if you take some of their inspiration when you're building your products, maybe you can have some wild success.

a lot of the value on the table for your customers instead of trying to take it all.

And the key, let's be clear, is your product actually has to solve the customer's problem.

It all comes back to All those free products, all the products people pay for, they actually solve the customer's problem.

And so if you can do that in the early stage, instead of being afraid of consulting or afraid of fundraising, bam, you have an advantage.


Speaker 0: Sometimes founders are afraid of asking the like the dumb question, but that's a worthwhile question to ask. But if you can help your customer make more money, they're probably going to like you. This is Michael Saibo with Dalton Caldwell, and today we're going to talk about how do you give more than you take from your users. Maybe we should start with a business 101, like MBA in 30 seconds.

Speaker 1: What do you think? Okay. So the basic idea underpinning all technological progress, business, very basic stuff is if you sell someone a tool, and if they can use the tool to make more money than the tool costs them, you're creating value when people like it. And so, You know, some very basic examples, Google, when they first launched Google Ads, it was very easy to buy Google Ads. You would pay Google per click, and you could sell stuff for way more than you paid Google.

So you would just do that all day long and make tons of money, right? Very straightforward. Makes sense.

Speaker 0: Talk about Excel and Microsoft Office. Microsoft Office is a perfect example. If you think about Word, you think about Excel, these are products that made normal office workers and normal kind of financial workers literally like 10 to 100 times more product. Yeah. And so if you can make an employee 10 times more productive, people probably buy that tool.

Speaker 1: Buying a computer back in the 80s was expensive, and buying VisiCalc or whatever was expensive, but it was still way positive ROI, like 5 grand, 10 grand, no sweat. Massive. Because spreadsheets made them better.

Speaker 0: Yes. Classic examples. So let's get to the problem. There are a lot of founders out there that are building products that deliver no or minimum value to the user. Classic fear is always like, well, I need to grow, right?

The most important thing is to grow in order to raise money. And so I'm gonna build something that kind of sucks because like, or screw that it sucks, right? Cause most MVP suck. I'm gonna build something that doesn't solve anyone's problem and just try to get money for it so that I

Speaker 1: can go raise money. I think that's a good path. Yeah, it's like, it's make something VCs want. It's the classic perverted thing that we are not fans of where you're like, well, superficially this resembles a software product that superficially people pay for. And therefore we should charge a similar amount of money for it and like, the specifics of what it does as details, you know, we've got our top folks on that.

Speaker 0: Yes. But we've talked about that before. So that's an obvious 1. I think there's another 1 which is this fear of being a consultant. I think 1 of the reasons why people build shitty products that don't solve people's problems is that when they start talking to a user and the user starts saying, well, here's my problem, I could really use this, this, and this.

The founder starts thinking about that and thinking and fearing, what if this user is different from every other user? What if the problem they have is different? And so what if I have to build something to make them happy? I have to build something that no 1 else wants. I think this is a core fear that happens because I think that every founder in the back of their head, thank you Reid Hoffman, is thinking, when can I get to blitzscale?

Like when can I raise the big round and throw this everywhere and have everyone use my thing? And every founder knows in their heart that if they're not making a simple thing that everyone's gonna use, they can't blitzscale it. So I think this is the core fear. I'm fearing being a consultant. And it's tricky, because like, this isn't

Speaker 1: wrong. Yeah, there's a kernel, there is a good idea in there. Like there's a good, there is an insight. There is an insight.

Speaker 0: But I might argue it's exactly wrong when you're early. Maybe we should talk about that. Like what's the difference between being early and maybe not even understanding the problem well and being way later on when like being consultant is maybe more of a risk.

Speaker 1: I think if you're not a deep expert on what the customer's problems are and how they make money and how they work. Most founders. You make assumptions about how their business should work, which could be mistaken. So again, when the founders of Google started Google, I would imagine they were not experts on performance marketing, and how basically a lot of the early Google customers, as we recall, were mortgage refinance people, where they would buy people searching for mortgage refinancing, the advertisers would buy those clicks and they were worth a lot of money to them. There you go.

And the founders of Google did not need to be experts on that. But as they got users and they built the business model, understanding what problems the the customers had was super important. Yes. Right? I mean what are some other examples of like...

Speaker 0: I mean we've we've talked about this before but the classic examples with Twitch like we did not understand what streamers wanted until not only did we talk to them we started building things. And so I think that like, maybe the issue here is that if you're being consultant early, what you don't end up doing is learning enough about the customer. And so The counterintuitive advice we're giving is basically, forget your fear about it being insult internally, dig in with some customers, actually solve their problem. And in the process, maybe you're building some stuff that's 1 off, but you're gonna learn a ton about the actual problem. And then you'll have some insights on, okay, what's more generalizable?

What can I do that I can give to everyone?

Speaker 1: And ideally understand the levers in their business that derives economic value. Like basically, like don't make assumptions that you think you know how they make money or should make money. Yes. Kind of test those assumptions. And once you have a

Speaker 0: better mental model of that, it's much more clear how you drive economic value. And what's funny is you can even ask them. You can even say, how can this help you make more money? Like you can literally, sometimes founders are afraid of asking the like the dumb question, but that's a worthwhile question to ask. If you can help your customer make more money, they're probably gonna like you.

I think 1 other area this applies that's counterintuitive is even in your customer outreach. Because I think that a lot of times, founders when they're reaching out to customers, even in that moment, they're asking for more than they're giving, right? We see these emails all the time where, you know, hey, I'm building X, Y, and Z software. Do you have 20 minutes to jump on the phone with me to talk about it? You know what I'm saying?

Is that not the definition of asking? Yeah. Before. I just want feedback. Yeah.

Speaker 1: Give me feedback. Your time. Customer discovery.

Speaker 0: Yeah. Your time is clearly worth nothing. Like, and I need you to help me. I think 1 of the things I've seen that works so much better in the initial outreach is when you actually offer something. You should give value up front.

Now, we had 1 company in the current batch that basically was helping with customer onboarding, and they did this in the most simple way. They actually took a video of the customer's onboarding flow, of the company's onboarding flow, and then provided their advice and feedback on what they could do to make it better. Now, 1, that's the definition of consulting, right? 2, absolutely doesn't scale. But when they started sending emails with that content in there, when they started giving as the first step, customers started replying, saying, "'Thank you, I can use that.

"'Like, yeah, I'm happy to talk to you about how you're thinking to make this even better. So I think in outreach and in building your first products and dealing with your first 10 customers, You can give more than you receive. Let's put this in historical context though, because this giving before you receive is not new.

Speaker 1: Yeah, this is a whole broad topic, but just quick crash course. The history of computers involves giving away a lot of value for free. Specifically, the original business models of computer companies were to sell hardware and software was like a thing you had to give the customer to run the hardware to get value from

Speaker 0: it.

Speaker 1: And so historically, software was just free and not really proprietary. And this is beyond the scope of this talk here, but if you research the history of Microsoft, people in the audience, Bill Gates kind of pioneered the guilt trip to get people to pay for things. I don't know, go read his letter, I'm not gonna do it justice, but the idea of proprietary software and charging for it was like, it came out in the 80s. It was an innovation in the 1980s, maybe the late 70s. And before that there was the free software movement which equated software and code to freedom.

Many of the tools that power everything to this day were created by hippies, created by people with big ideals, created by people that wanted to get more value than they receive. So if you look at the history of GCC, of all the compilers, if you look at Linux, the Linux kernel, if anyone runs an Android phone, That's all free software. There'd be no Google, there'd be no YouTube without Linux powering all this stuff. Same with Git, like every web browser, Gecko, KHTML, you can research these things. Also, SQlite is this free database that's in everything.

Like I'll bet to just watch this video stream, SQ Lite is involved like 50 different ways. How many free products do you actually need? And so this is part of the history of software and computing and technology is to give out all this value and realize the value that it's created can create enough economic value for the creators, for the people that make this stuff, and also just unlock more value in the world than what they charge. Yes. Right?

And this is why the graph of how technological progress is accelerating so fast is this factor of giving more than you receive.

Speaker 0: Yes. And if you take some of their inspiration when you're building your products, maybe you can have some wild success. Yeah. I think if you leave

Speaker 1: a lot of the value on the table for your customers instead of trying to take it all. Yes.

Speaker 0: Then you're in the game. And the key, let's be clear, is your product actually has to solve the customer's problem. It all comes back to All those free products, all the products people pay for, they actually solve the customer's problem. And so if you can do that in the early stage, instead of being afraid of consulting or afraid of fundraising, bam, you have an advantage.

Speaker 1: All right, man.

Speaker 0: Great. Great chat.

See all Y Combinator transcripts on Youtube

How Generosity Built Tech Giants