How to build the 'right' product | w/ Rob Snyder

Well, Rob, welcome back, man.

We're doing it, doing it again.

That's right. What's going on? I know the Bills are starting. We're getting into NFL season. So all of our listeners should expect the quality of our conversations to decline dramatically after this week.

Yeah, they're listening to this saying, I don't know how it could go down. We will not disappoint.

Well, I think we could jump in pretty quick to this one. I think this— I'd say this week's blog post, we're talking about supply versus demand in product. And it's like the last couple of weeks have been a little bit more foundational, defining demand, talking about like big picture. This is what the sales process looks like. Here we're jumping into something that's very practical. It's going to be like feature-oriented, important for reasons that we'll talk about directly and also indirectly, but would love to start with like what's going on, like what's been on your mind that led you to write this particular blog?

Yeah, I've had, I've had this one queued up for a while, like in my brain at least. And it's, it's, um, when I describe demand and supply on the sales side, people like, it's, it's easy to kind of get it. But what I find is that like most people will like nod their heads and say, yeah, Cool. Demand makes total sense. I need to look for it for demand. And then they'll just, they won't look for demand. They will look for something that they think is demand, which is like people wanting their product. And so, um, and that's not demand as we know. Demand is what's on the buyer's to-do list. It's, it's totally separate from wanting a product. And so there was actually a video that I watched back in, I don't know, 2017, 2018, maybe, maybe a little later. I don't remember when the video came out, but it was basically after I had spent a year just hitting my head against the wall, unproductively building stuff that nobody in their right mind would have wanted, but I couldn't figure out my way around the messiness of that. And so the, the video is about a very simple example of demand and supply as it relates to feature requests, like your customer requests a feature, what does that actually mean and how do we unpack it? And this was the video I watched this. I remember where I was. I was on a bus to the T to my office in downtown Boston, worked out of our VC's office, which is terrible. I just, I'd never recommend that. They'll just like come and look over your shoulder and be like, so have you figured it out yet? No, I have not. And so, and so I watched this video and just, this was the moment my brain just disassembled and started to reassemble. And it was because it was such a concrete example and it broke my thinking that I was sure like that people were going to want my product. And so I'm sharing this one because this video has like 7,000 views on YouTube. It is insane. And so I was like, Well, the least I can do is give it a solid 17 more from this audience. And, and, um, and yeah, I just think it's, it's useful to start seeing demand everywhere. Demand is not just a thing you, that's on the sales side. It's in every single part of your business.

Yeah. Um, and from my perspective, I've probably watched it 4 times, like trying to wrap my brain around like different elements of it. Like there's, um, basically Ryan and Chris, they're from Basecamp. It's an, it's an early Basecamp video. For those who don't know, Basecamp is a project management software. They've been around for 20 years. I think, Rob, you had shared some stuff with me like, I don't know, 5 years ago about them. Like they're, they're some like interesting thinkers in the space in addition to building great products. And financially they've, they've built a really super successful business that's, I think, mostly bootstrapped. Am I remembering?

Totally bootstrapped. Jeff Bezos gave them a couple threw him a couple bucks at some point, but yeah, essentially bootstrapped.

Um, but basically, uh, I'm going to, I'm going to set it for, for me personally listening to this, it forced me to confront supply and demand in very tactical ways that, um, uh, so basically what's, we'll get into a little bit more of their context, but they're getting feature requests and then they're trying to understand what is the demand behind a feature request? But I'm going to— I'd like to kind of set the stage a little bit with a few things that you write in reflecting on this, this video that we'll put the link to the video in the, in the show notes. It's hard to— and this is where you're talking about why this is important, not just for feature requests. It's hard to understate how much supply versus demand in products impacts startups. I'd bet good money that most startups spend at least 90% of their development hours building supply without really understanding demand. And then this part I think is super important. This compounds. And we talked about compounding in our, in our last one as well, how demand compounds through the sales process. But this is in the product development part. This compounds because now we have to maintain and build atop a broader surface area, talking about allowing— when we allow customers to dictate like the product roadmap and things like that. Anything that you want to add on like the importance of, of getting this right internally in organizations?

Yeah, I think it's, um, this is going to kind of, if you haven't, if you don't have experience with this set of ideas, this is going to hurt your brain as it relates to your product roadmap. It's going to hurt a lot because what's going to happen is you're going to go back and look at your product roadmap. And think hard about, do you just have a list of features that you're building, or do you actually have a set of things that fit at real demand? When you have a list of features that you're building and you think of your product as kind of like this set of features, you wind up building a very broad surface area, which sounds like a good thing to have. It sounds like a good thing to have a relatively broad platform with many features and all this kind of stuff. But it's not like, again, if you've been in it, you know this, everything you build, you have to maintain and you have to consider in the next set of things you build. Right. And so building the wrong thing or something that's like too complex or big, right. And, you know, we're like, it just, it shoots you in the foot, not just in the amount of time it builds today, but it you pay a tax every single feature you build, every single thing you build after that. And it, you know, this, this stuff. So thinking on the demand side, which we'll get into on, on this, on this one, but thinking on the demand side will prevent you from building the wrong thing and building the wrong thing just compounds even if you just do it once.

Yeah.

Yeah.

And we'll, I think that like jumping specifically into this Basecamp example will make that very practical, like how that compounding could have worked. Rob, I'll go ahead and just kind of like walk through a few of the pieces and then let's have a conversation as we go. As a warning to our listener, I think this conversation with Rob and I is going to be a little bit messier than usual as we're like wrestling with this concept and some of the nuance in it. So the situation, the Basecamp team receives a request for a permissions feature from a customer using their software. Basically, you know, they say the team is struggling with, is this demand or is this supply? They went and they talked to the customer. And so the permissions feature was they wanted, the customer said, can you add a permissions feature for archiving a project? And they wanted to be able to approve it. So the Basecamp team goes and talks with the customer who says that when a, the situation was a contractor had archived a project and it disappeared for the whole team and the whole team freaks out like, what, where did this go? The contractor had just finished their part of it, didn't want to see the, you know, didn't want to, didn't need to see it and so they archived it. And so then after that, the client said they asked for the feature request of the permissions feature. However, the Basecamp team, in reflecting about it, said that their demand was different, which was closer to, I want to feel comfortable that my project won't disappear, something like that. As you were listening to the Basecamp situation, like, what are you reflecting on or what's like jumping out to you, Rob? Yeah, yeah.

Okay. So like, The story again is basically Basecamp receives a feature request from a potential, from an actual customer, right? And the feature request is, I need, you need to build a permissions feature, right? And here's all the reasons you need to build a permissions feature. When you hear from a customer, you need to build a permissions feature. It sounds like there is that customer demand, has demand for a permissions feature. And so, right, like most of us will be like, huh? Or I, again, you listener are smarter than, than both of us, but like, uh, uh, I would have said, huh, we got 17 requests for a permissions feature and like a bunch of upvotes on that. Definitely demand for a permissions feature. But that's not the way to think about it, right? That is customers requesting supply. That is not customers expressing demand. And so when we get a request for a permissions feature, we, the question is, how do we figure out what demand is? Remember, demand is, is not what we make. It is what is in their world. What are they, what is the customer trying to achieve in their life? Nothing about our product.

Yeah. And the— oh, Rory, go ahead. Another way that Ryan in particular talks about it, he says like, do not say or don't ask yourself like what they're asking or don't ask customers what they want or even why they want it. Like those are the wrong questions, but rather when they want it, which translating it, you use slightly different language. To what they do. You say like, what is the project that they're trying to accomplish? But I think those are two ways of articulating a similar idea. It's like, what is specifically going on? They're saying what was going on? You're saying, what are they trying to accomplish when that is going on? Yeah.

Yeah. And these are just tactics for getting— like, the challenge is that when you get a feature request, it feels like there's demand for the feature. And so you go and you say, okay, Why do you want this feature? And you interview them, you say, why do you want this feature? And they'll give you a list of reasons that they want this feature. And those, those reasons are them justifying why they want the supply, not them expressing demand. The different, like, they'll say, okay, I want, you know, because it will help us, like, a permissions feature will help us make sure that senior people have different permissions than junior people and contractors don't have the same permissions. As everybody else. Right. And that's a lot of justifications for wanting Supply. But then, right, okay, then, then what do we have at that point? What we have is we have a feature request and all the list of reasons why they want it. How do, like, it's not clear at that moment, what will we build? What could we build that would cause them to say, Yep. This accomplishes what it, what I, what I want it to accomplish, right? If we just build a permissions feature, well, the question is, what are they going to use it for? And so that's why we have to jump from the supply side and say like, let's just ignore the feature entirely. Let's ignore the feature. Let's ignore the product. What was going on in your world at that time leading up to this? And like, Just tell me that story. And when we get the story, right, we hear, oh, okay. So, okay. As you, as you mentioned, right, contractor was working on a project. Contractor finishes their part, presses the archive button, and goes away thinking, cool, I've done my job. Everyone else wakes up the next day. It's like the project is gone. Oh my gosh. Freak out. Realize contractor archived it. Then submit feature request. Okay. So what that tells us is like, let's forget about the feature request. What are they actually trying to accomplish in their world? What is the demand there? The demand there is not, again, it's not, I want a permissions feature. It's I want to prevent a one person from archiving a project for everybody without realizing it. Okay. Now we know what success looks like. Now we know what they're looking to solve for. Now we know what they're trying to do, the project on their to-do list. They want to prevent contractor or one person from archiving a project unknowingly from everybody. Once we have that, that's clear on the demand side. Now the question is, what's on the— what should we do on the supply side? And there we can say, okay, a permissions feature is what they said, but like, let's think about it. Permissions would be a whole new screen. It would have all these different things we'd have to scope out. Like, well, if you can just use permissions there, you probably want to use it in a bunch of different places. Right. And this becomes a massive project. Yeah.

Or you could just like— That's deeply embedded into the, into the design and the theory of your, of your product. That's just like a response to like one specific situation.

What it's, that is a massive surface area expansion. And like, what's gonna be, what's gonna happen when you're talking about this permissions feature is somebody's gonna like raise their hand and they're gonna be like, yeah, I've always said we should build a permissions feature and here's how I think it should work. Like, and that's what always happens, right? And so you can just get down, you, again, I've done this so many times. I remember customers were asking us for a dashboard At that time I was like, okay. And then we spent a ton of time mocking up dashboards, showing potential dashboards, customers kind of like scratching their heads and saying, yeah, that looks kind of cool. Right. And we were just all the way down on the supply side without actually understanding what demand was. And so, okay, permissions feature is one option. The other option is, okay, whenever anybody clicks the button to archive a project, it says, are you sure this will archive it for everybody? And then it says, you know, then it gives you an option versus it just happening, right? That is what they went with in this situation, which if you think about like the scope, the surface area is so much smaller and more, I'd say more surgical than a broader permissions feature. And really importantly, it fits demand better. Like it, it actually, if you think about what the customer is trying to achieve, they are just trying to prevent people from archiving. And so if they had to go, like, imagine the, like, scenario, if they had to go in and set up a bunch of permissions and do, like, all this kind of stuff, right? That's actually, like, a worse experience for them than just whenever anyone clicks the archive project button, it gives them a little middle finger and says, like, are you sure? Right? And so, And so the thing here to understand is that demand is obviously different from supply. We've covered that, but you can do much less on the supply side, so much less on the supply side, and it fits demand better. Yeah.

Yeah. I'm going to pull up the graphic that you have because as I was trying to wrap, I'm going to be the, I'm always the idiot in this conversation, but in this one in particular, like I was, it was It took me a little while to like figure out the distinction between supply and demand here, but what you have here on the screen for anybody that might just be listening, this is also in the, in the blog post that we'll link to. But on the left, you know, you've got demand I have, on the right you have supply I want, and the demand in this case, I want to prevent one person from archiving a project for everybody. That's the, that's the part that is essential to understand in this for the product team. The right-hand side is what the customer thinks that they want because they're trying to solve for the demand. And so they're telling you what supply and just skipping the context of the demand for what I actually don't realize. Like, why does that happen? Why does the customer go straight to, to supply?

Because they're, they're, uh, I mean, they think they're making our lives easier or there's like a feature request. Thing. And so, so in their minds, right, they're like, okay, what would have prevented this from happening? I don't know, permissions. Let me put in a request for a permissions feature. Yeah.

Yep. Yep. So they, their instinct skips straight to supply, which is the solution that they can imagine, uh, solves the problem that they experienced. Um, whereas, you know, there should be like a second option. Like there's probably a number of options here. That, you know, could, that could be supply that you offer for that demand. And the, as Rob mentioned, the much simpler one that accomplishes the same thing is what they call, you know, I think Ryan recalls it, calls it like a social warning or something or a social cue, which is just basically like, hey, are you sure you want to make this disappear for everybody? That's what when they went back and audited basically, or just like looked at their, what the contractor viewed when they went through this and it just said, this will make it disappear, but it didn't say anything about this will make it disappear for everybody involved. And obviously no contractor is gonna wanna like piss off everybody on the, you know, in their client's side by deleting an entire project. So it's like the solution, as you mentioned, Rob, could be much, much, much simpler.

Yeah, totally. And, and yeah, and that, that's exactly the thing, right? Is like customers, what, what's happening is customers, potential customers, and we can think about this specific example and then we can think about this way more broadly too. Customers are trying to speak in supply language. They're trying to talk about the features they want, the products they want, stuff like that. They don't get to do that. Like they can sure try, but they're not experts on the supply side. They're experts on the demand side, and it's our job to get them to speak on the demand side. And for us to make the translation to what's the right supply that fits their demand. So the thing that just broke my brain here was realizing that feature requests, even when a customer says, I literally, this is the exact feature I want, that is not demand. And that this, this idea just scales across every single part of your business.

Yeah, there's, there's two areas that I was wrestling with on this one. It's how, as a result of this, how do, how should we talk with customers? And as a result of this insight, how should we talk internally as teams, whether it's product managers or UX professionals or, or engineers? And they, you know, how would you say, Rob, let's say a feature request comes in. Let's use your dashboard example. You're talking with, you know, a customer that says, I'd like a dashboard to see what were they asking for, usage or something like that.

Literally, I want a dashboard.

Okay.

It would be, this product would be better if it had a dashboard.

How would you, knowing what you do now, if you were in that same situation, how would you talk with that customer?

Yeah. So what the first thing is to know whether a customer is talking about demand or supply. That's like the first cue. And so if the customer's talking about demand, it's like, cool, let them talk. Let's explore. If they're talking about supply, we have to redirect them. Say, cool, dashboard sounds really inter— like, and then not talk me through how you would use the dashboard or not talk me through why you want the dashboard. That's still in the supply land. Let's say, cool, putting the dashboard aside, talk to me about when you wanted this dashboard, what was going on in your world up until that moment. And what I'm looking for is like stuff that is not about the product. It's about, well, you know, I'm looking for kind of like a story. Well, so yesterday I was just talking with my office manager and we were trying to figure out X, Y, Z. And so we figured your product might have that information in it. And we were like, oh, maybe we'll go and try to look for this. So, okay, cool. Now I know what you were trying to solve for, right? Or to some extent. And then, then you talk to a couple other customers to see who have, who have made similar requests. See, Is this kind of story happening more or less? And then we can decide what to do about it on the supply side. But it is, it's like, again, know which side they're talking on. If they're on the supply side, that's not allowed. I mean, they're allowed to talk, but I'm not allowed to listen. And so what I'm trying to do is I'm trying to redirect them back to the demand side by pulling them out of the product.

Yeah. And Chris, Chris mentions an interesting thing, kind of as a side note, that it can also be a lot of customers requesting the same supply. Like you can get like— there could have in this case been multiple requests for a dashboard, which makes it extra confusing because it's reinforcing that there is a need there. They might actually be different demands actually that they are prescribing the same supply for, or it might be that there's the same demand that's, you know, underrooting this, which you should diagnose with the right supply approaches, how would— let's say that your answer, I don't— in that, in that case, was the answer to build a dashboard? Or do you think like in retrospect, was that the—

I have no idea. I was too stupid to figure it out.

Okay. Let's say that your— the supply that you think you need to build the feature should— is actually different. So how do you have that conversation with the, with the client, or how do you redirect them toward Yeah, a supply that's different from the supply that they're requesting.

Yeah. I mean, like, they don't get, they don't get to build the pro— they can choose to churn or not based on what I do, but basically I would frame it back to them and say, hey, here's what I heard about your situation. If I'm like closing the loop with them, which is probably a good practice, but like, here's what I heard about your situation. So ground it in demand. So we considered building a kind of permissions part of the application where you do all these kinds of things. What we realized that we could just do is this, where when someone clicks this button, does that feel like it would kind of like fix what you're trying to fix here? They'd be like, oh yeah, that's way better. I like that better. Right. And it's done.

Yeah. Or they might say like that, that does this, but it doesn't do that or something like, yeah, it might, you know, help you, help you better understand it.

But like the important thing there is not, is just not to show supply options to them. It's to ground it first in demand. Here's what I heard about your situation. Is this, is this an accurate reflection on the demand side? Okay. Given that, let's now talk about supply because what I don't want to do is I don't want to just show supply and then think one is prettier than the other, or them kind of like sell themselves on the other without grounding on the demand side.

I like that. I like that a lot. And, uh, you also managed to work ax murderer into, into this describing, which I think that's the first time ax murderer has made it into one of your, one of your newsletters, that you describe, uh, clients as, um, as ex— as something like experts in demand, um, and ax murderers when it comes to, to supply. Um, one, one other thing I wanted to hit on is Something like really struck me with like thinking about Basecamp's environment is Chris was like, we were wrestling with this and we kept trying to diagnose the demand. But then when we would step back and think about it, we realized that we were continually talking about supply. And so they had this culture internally that distinguished between the two. That was not just, you know, we talk a lot about the founders, but it's actually like their entire team was using demand, you know, supply demand., language. How do you, uh, if you're leading a team of engineers or as you're working with, uh, you know, other team members, how do you like build that instinct to be talking about demand and supply so that, you know, individually people are making that type of, uh, using that criteria to make decisions?

Yeah. Yeah. One, send them this blog post and send them the, the video of, of Ryan and Chris talking through it. It's, it's amazing. It is like it, If you don't have this separation of demand and supply in your brain, you just can't, you just can't do this. Like, it's just impossible. So everybody needs to have that separated in their brain as a starting point. And then the question is, how do you make this into a habit in your organization? And so, you know, companies, for example, whenever they have like a, a PRD or like a requirements doc for a product or a feature, kind of like write-up. Before it goes into, into the build phase, right? What I've seen, like Jump as an example, uses the pull framework or a variant of the pull framework first to say like, here's the situation customers are in, here's the project on their to-do list, here's what the options they've considered and that we considered, and therefore here's what's, what we are recommending on the supply side. And so you can build that into like the first part, the framing part, of anything that you build to make that a habit on your team.

Hmm. Super interesting. And that you're, you're basically saying the same framework, the same principles that apply to, um, your sales approach, like early sales approach, um, like when you're first identifying demand from customers and selling, that can be reapplied throughout, like after you have customers, like in the way that you maintain and add to and enhance your, your product.

Yeah. So like the pull framework is at root, not a framework about sales, not a framework about product market fit. It's, it's a way of understanding what people are trying to do and what options they're considering such that we can put something in front of them that will be useful to them. It's a, it's a way to understand people's motion so that we can offer something that fits their motion. And so that is what it is at root. It applies, I think, everywhere. It applies in pre-product market, figuring out what people want to buy. It applies in sales conversations before and after product market fit. It applies in product development to figure out what feature to build. It implies basically anywhere you are trying to get somebody to ac— or like you're trying to help somebody accomplish something or trying to sell something or trying to make something that is useful.

Yeah, that's super interesting. So in this case, like applying the pull framework, the, the project and that, like, it's, we've, I think, I feel like we've hit the, like the peak pretty hard on, on that one. Like the project was Don't let somebody accidentally make my, you know, make my project disappear in the Basecamp software. Let's walk through like U, L, L. Like how do you think about that situation applying your, the pull framework?

Yeah. Yeah. So, so U, the kind of like why is, why is this unavoidable is pretty clear too. It's like someone just archived the project. It disappeared. We're freaking out. Yeah. Okay, cool. So that, that now makes sense. Now the L and the L here are like, what's the list of options and what are their limitations, right? And so we can include here things that they considered trying on their side, right? They considered probably like writing a policy document and including it in the product project, like charter or whatever, right? So they can consider DIYing it some ways., but right, like, it doesn't feel like that should be my job.

Yeah. They, they actually also, they say in the video, they looked for other project management software. Like they wanted, they wanted something that wouldn't have this like catastrophic risk in it, uh, with a, you know, big flag, but that like, that was one of the options they were looking at.

And we can then, we can then put there like, okay, what are the supply options we're considering offering? Right? We could put a permissions feature there as one of the options. Hmm. And we could put the kind of warning notification there as options. And we can look across these options from our customer's viewpoint, from our buyer's viewpoint, user, whatever, and see which one of these best fits their demand. That's the first screen. And then how do we build it such that it doesn't take forever is, you know, like that, that's something where we're kind of jumping between the demand and supply side.

Yeah. Yeah. Does, does lacking apply here or is this— Yeah.

Yeah. Limitations would be like, like we considered switching project management softwares, but that seemed like a big lift. We considered writing an internal policy doc, but right. It's, it's what comes after the, But that didn't feel right because blank.

Yeah. Gotcha. Cool. I like that use of that framework. Let's talk about like how this applies. You talk about the sales process, the product. I feel like we've talked about product and engineering, how to talk with customers, how management can use this like internal to teams. Is there one that there that we want to do a deep dive on that we haven't totally touched yet? Yeah. Maybe in the, like, let's talk about sales real quick. So you're selling to, you know, you're a founder that's selling. Yeah. And the customer's like, oh, this is interesting. I like this project. Could you build X in order to, you know, that would make me more comfortable to go with your software or something like that.

So here, here's like, let me, let me play this of like how this actually plays out on the sales side, which is you're in a sales call and customer says, yeah, this is, this seems kind of like what we need. Uh, does it also have this feature? Right. Does it also have, I don't know, like, oh, does it also have SMS notifications? And then you're going to say, oh, then, then like, That is shaped the exact same. That's a feature request. And now if you have a big sales team, sales team's gonna say, is that required to close the deal? Right? Like any good seller's gonna be like, is that required to close the deal? If so, I'm gonna go say SMS notifications is worth this amount on a deal. Can we put that into the roadmap? Or, you know, you might have a kind of like more product-oriented seller there who says, What do they say? They say, oh, why do you want SMS notifications? Right? And, and what we're doing is we're getting a bunch of feature requests from sales that are customers requesting supply. That's fine, right? Like, I, you don't necessarily need sales to be doing the deep product research here, but what you need to know is that when sales is throwing these feature requests, over to product or over to the founders, depending on the stage, that step has to happen of going back and saying, okay, SMS notifications. Cool. Uh, let's get on the demand side because I don't actually, this is customers requesting supply. This is them speaking on the supply side. They're not allowed to do that. I have to figure out what demand is so that we can figure out what the right supply side response is.

Yeah. And another area I can imagine this, um, like coming up is after you lose a deal and they go with somebody else, then you following some, one of the practices that you, you talk about a lot, Rob, is like getting on the phone with people that didn't choose you. Yes. Um, and they might say, ah, we went with, we went with XYZ other option because of these features. Uh, and really like, that's like a surface level understanding of it. You need to understand like, okay, what was, what is the project that those features are critical to enabling?

Yeah, 100%. And then like, okay, another example here now that we're rolling is, um, you know, like an enterprise will send a, like a big, you know, Fortune 100 will put out an RFP, um, where they're like, here's the feature set that we need. And you know, it's just somebody who like, and it's just like a long list of features and like, cool. Like this tells me nothing. I actually was working with a founder who got one of these long RFPs. They had written this up internally and just got on a call like, this is a list of features. What are you actually trying to do? Right? Like, this is, this is useless. And, and by doing that, they're able to actually understand what, you know, you could imagine just taking that list of features and saying, well, this is our product roadmap. That'd be insane. Yeah.

Yeah. Um, Uh, let's talk, uh, about how you've practically, how founders can like implement this like today, basically.

Uh, go ahead. The core, core thing is the, if you take one thing away from this, it's just know whether they are talking about supply or demand. That's it. If, if they are talking about supply, Don't let that happen. Don't let them— they don't dictate your roadmap. They don't, they don't design your product. That's your job. They're experts on the demand side. Get them onto the demand side by any means necessary. That's the only thing that— and then yes, you can figure out how to implement this and how to make it a habit in your company, how to train people on it, right? Like, I think engineers getting trained on this is massively underrated because, right? Once they're able to understand the demand side, they can build the right thing way faster and better. That like, they will understand all the, the, 'cause building something takes a thousand little trade-offs here. They'll know the right trade-offs if they understand the demand side versus if they just get a feature request, they won't know the million different trade-offs they need to make.

Yeah. Yep. Um, anything else we want to talk about here or do we want to jump into mailbag? Real quick.

Let's jump into mailbag because I only have 10 minutes.

Jumping into the mailbag, we're going to start with a question from Ariel on the Weird If It Didn't Work post from a couple of weeks ago. And this one is about presell. And Ariel is asking, you know, does this mean, does presell mean asking people for money even if the solution doesn't exist yet? And They give an interesting example. For example, I had a call in which a potential user agreed to me shadowing them, reviewed a mockup of my solution, uh, and said I was undercharging for it. As a recruiting agency employee, they're unsure that they could purchase the solution given their company has just started cost cutting. Um, he says he wants to test it first though. Is this pre-selling or am I falling into the designer Kind of partner trap in parentheses again.

Yeah. Okay. Let's, I'm going to answer this at two levels. The first level is, okay, given the conversation we just had about supply versus demand, we should actually know something about this. What does pre-selling mean? Does it mean asking people for money even if the solution doesn't exist yet? Well, okay. When we split out demand and supply for a startup, right? When we understand what buyers' demand is, then there are multiple different ways, shapes of supply that we could possibly deliver there. So example 1 is full product, like this Figma mockup that we've created. And we're like, hey, does this look like the a good fit to your, your demand. That's one option, but that's not the only option. For startups, we could also say, hey, this thing I could deliver as a service here, which is something that also fits their demand, gets us revenue, and helps us figure out what the right product to build is while also just, just like in the permissions feature example. Right? Way less effort for us to build. So that's what I would encourage you to think about pre-selling as. Pre-selling is validating demand by getting somebody to pay you for— to basically, they're paying you to help them accomplish their demand, help them get the project off of their to-do list. Okay. Then supply is just how do we configure the resources that we have available to us? To do that. There is zero reason why we need to show a fancy Figma mockup here. And in fact, people are willing to pay less for a software product than they are for a smart person to do the thing for them. And so I would encourage you to think more broadly on the supply side, especially early on for saying this is their project. Like, what are the different shapes of supply I could deliver? So that's my answer on preselling. And yes, to validate demand, they should pay you. For what? Something on the supply side, but like they should pay you and you should not go away necessarily and build for 6 years, raising a shit ton of money to try to build the perfect product and da da da da da, right? Like you can just deliver as a service or deliver as some elegant combination of grunt work and, and software. Now, Ariel, second point here, second point here is buyers, the buyer matters. And so what I'm hearing in this story is that you're talking to somebody who cannot buy software or cannot buy anything. And will not go up to advocate for the thing. They will not convince their boss to buy it either because why? Because they're gonna get fired if they try to bring in another tool. And so what that tells me is that there isn't demand here that can lead to a purchase. I care about demand that leads to a purchase. Because I want to not go hungry. And so I would say in this specific example, that per— like, fine, interesting to shadow that person. Find somebody who at least is in a situation where they can either buy or convince the buyer to buy internally and focus on that person because you can spend a lot of money building for users or kind of like people who are lower in the organization. Who can't buy, and their projects are totally irrelevant to the people above them.

Yeah, super interesting, both points. And the, the first one reminds me of, uh, like with your first startup, like you basically DIYing it in Google Sheets, um, for months. Um, and then, you know, and then you ended up building something after, after like really spending time with customers doing it manually.

Yeah. Yeah.

Um, all right, let's get to this, the second, uh, mailbag. This one was a YouTube comment, uh, from Cody Duvall, uh, on the Physics of Sales Part 1 video. Uh, how do founders see demand when building lists for prospecting? I would love an anecdote from Rob's first startup that provides a more tactical example of finding leads who show up with demand. So we, uh, so we fall into a buyer pool mode.

Yeah. So I'll give it like an actually more recent example that I think is kind of interesting that somebody has been doing to me. Which is, um, somebody has been noticing that my, like, LinkedIn posts are interesting and my follower count is going up. They're like, okay, this person might, like, is going for some sort of influencer thought leadership bullshit and probably at some point wants to write a book. Right. And so they've kind of like found the, that's kind of what they have inferred based on what's available about me. And I'm sure they are doing this about multiple people., and they're just reaching out and saying, hey, your content is amazing. Have you considered writing a book? Love to chat with you about this. Right? That is a perfect example of finding some public signals of demand and doing outreach based on it. Now, I've already written the book, so this is irrelevant to me, but you can see, right? Like if they had just, well, like looked at a couple more posts, they would've seen that. But, um,, but still like that's a perfectly fitting example here.

Yeah. Is there a, is there a scalable version of that one? I can imagine that, or is, is the scalability of that like follower count increasing or?

Yeah. So, so the thing is you have to first figure out what works before you worry about what scales. And so in this case, if you know that this works, then the question is how do we systematize it? Such that it works repeatedly, then how do we scale it? Right? And so you could then, if you know that this works, then you're like, okay, cool. I need to build 3 things, right? I need to build something that can watch for people whose follower count is going up. Second, I need to build something that can like analyze their content and see whether they'd be a good fit and like what kind of book they would probably wanna write about. And then based on that, I'd also probably need to get their email.

Yeah. Yeah. Or do one of the, yeah, if there's, if there's features that can be scraped from LinkedIn, like using a, you know, some kind of an automated outreach tool that you've, you've used. Well, cool. I know we're running up against time. Rob, great conversation. Or I don't know, great conversation with me. I'm sure our listeners suffered through parts of this. Would appreciate a review. This will be up on, if anybody wants to, you know, follow on YouTube, on Spotify, Apple Podcasts. Wherever they listen. Rob, any other last thoughts before we, before we drop? All right, cool. We'll catch you all next week.