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 kind of a business 101, right? Like MBA in 30 seconds. What do you think?

Okay, so the basic idea underpinning all technological progress, business, you know, 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. 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 productive. And so if you can make an employee 10 times more productive, People probably buy.

And buying a computer back in the 80s was expensive, and buying Visa, Calcutta, whatever was expensive, but it was still way positive ROI, like five grand, ten grand, no sweat, because spreadsheets made them better.

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 going to build something that kind of sucks because like, or screw that it sucks, right? Because most MVP suck. I'm going to build something that doesn't solve anyone's problem and just try to get money for it so that I can go raise money. I think that's a cost.

Yeah, it's like, it's make something VCs want. It's the product's 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 is details. We've got our top folks on that.

Yes. But we've talked about that before, so that's an obvious one.

I think there's another one, which is this fear of being a consultant. I think one 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 one else wants.

I think this is a core fear that happens, because I think that every founder back in their head, thank you, Reed Hoffman, is thinking, when can I get to blitz scale? 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 going to use, they can't blitz scale it. So I think this is the core fear. I'm fearing being a consultant. And it's tricky because like, this isn't wrong.

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

There is an insight. 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 a 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 build the business model, understanding what problems the customers had was super important, right? What are some other examples?

I mean, what are some other examples of like, I mean, 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 maybe the issue here is that if you fear 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 consultant early. Dig in with some customers, actually solve their problem. And the process, maybe you're building some stuff that's one off, but you're going to 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. Basically, don't make assumptions that you think you know how they make money or should make money. Kind of test those assumptions. And once you have a better mental model of that, it's much more clear how you derive economic value.

And what's funny is you can even ask them. You can even say, how can this help you make more money? You can literally, sometimes founders are afraid of asking the dumb question, but That's a worthwhile question to ask. If you can help your customer make more money, they're probably going to like you.

I think one 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. Well, I just want feedback.

Yeah, give me feedback. Customer discovery. Your time is clearly worth nothing. And I need you to help me.

And I think one of the things I've seen that works so much better in the initial average is when you actually offer something. You should give value up front. Now, we had one 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 they provided their advice and feedback on what they could do to make it better. Now, one, that's the definition of consulting, right? Two, absolutely doesn't scale. But when they started sending emails with that content in there, when they started giving as the first step with, customers started replying saying, thank you, I can use that. Like, yeah, I'm happy to talk to you about how you're thinking make this even better. So I think in outreach and in building your first products and dealing with your first 10 customers 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 it. 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 going to do a justice. But the idea of proprietary software and charging for it was like, It was an innovation in the 1980s, maybe the late 70s. 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 give more value than they receive. 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 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, SQLite is involved like 50 different ways.

And so this is part of the history of software and computing 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 to 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.

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

Then you're in the game. And the key, let's be clear, is your product actually has to solve the customer's problem. Like it all comes back to you, like 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.