How to understand customers

Well, Rob, welcome back, man. How you doing?

Good. Good. How are you?

You're doing better than good. Bills headed to the next round after, after kind of an insane game, actually.

Yeah. Yeah. Yeah. I was, I was not okay during that game. I like, like, uh, those who don't know, it like ended, uh, uh, 1 minute left, we scored and then we gave the, the Jaguars the ball back. And we have a history of doing that very thing and then losing. And so I was just like, I was doing these self-affirming, or I was like saying, we've lost the game, we've lost the game so that I wouldn't be disappointed. I was just saying that to myself. We're going to lose this. We have already lost it. It is a done deal. And then we won.

That's amazing. That's the opposite of self-affirmation.

It's like, it's just, it's just protecting myself from the, from, you know, you got, you have to protect yourself from happiness.

Yeah. Yep. I haven't been— having been a fan of a team that's lost a couple of game 7s of the World Series, I understand that emotion. Well, hey, what's, what's going on? Anything we want to hit before we, before we jump in today?

No, I think this is today. Today. So what? It's good to do a refresher on what are we doing here? Like, what I'm trying to do is I'm trying to answer the question. Why do startups take off? Why do certain startups take off, but most don't? And it turns out that's a really interesting question, and it is one that does not seem to have gotten the attention it deserves. There are kind of a lot of heuristics out there. There are a lot of slogans out there. There are a lot of 72-step methodologies out there. I just haven't found anything really fundamental about what causes a startup to work and, and like, therefore, what should I do? And so that's kind of what we're doing, building out kind of the physics of startups here. And we just have to ask some super basic questions like, like today's, which seems, seems like it shouldn't be a question that we need to ask, but it's a question of like, How do I understand customers? What does it mean to understand customers and how do I do it? And it turns out this is an interesting question.

Yeah. Kind of an uncomfortable question to try to answer. Like for me, I read, so this week's Substack is how to understand customers. Also PSA, forward deploy everyone, which sounds hardcore, but I felt I read this one and it made me squirm a little bit. And so I don't know if I am sure for me that's because I am doing this incompletely and I stand basically like guilty of not being best practice in any shape or form for this one. So I think this— I'm looking forward to this conversation because it'll be a good chance to diagnose How should, you know, how should founders engage with customers early on as well as their startups or as they sort of move from startup into company and how to really— like we talk, you write a lot about doing it in person. And so this is going to be one that, you know, forces you to confront like it's not a, I can kind of do it. It's like I'm either doing this or I'm not doing it.

Yeah. Yeah. And I think, I think on this point, there's a lot of advice out there that's like, you should talk to your customers, you should interview your customers, you should care about your customers, you should be customer-centric. So I, I just don't think that advice is good enough.

Yeah. Yeah. And we, and we'll hit, and, uh, uh, I like the, I really like the second half of, um, the way that you wrote this because it gets into exactly what should you be looking for when you're sitting there alongside whoever it is that's going to, you know, you're selling your product to, that it's going to be using your product. Um, but I actually, uh, let's, let's start with the first half, uh, as one typically does. I'm going to read a couple things that jumped out to me from the first, uh, first couple paragraphs. Uh, one is about the urgency of this. Uh, I have— talking about miscommunication between founders, which was an interesting spot to start this. Um, I have seen this play out in, uh, this exact same matter, and It causes co-founders to break up. And this example is just a 2-person company. This problem gets infinitely worse the bigger a company gets. It plays out in and across every department. Ever wonder why sales engineering, why sales and engineering almost always wind up hating each other? Or why startups default build things nobody wants despite setting out to build something people want? I'm having a hard time reading today. I don't—

it's tough.

It's tough.

That's more than you read at HBS.

Yeah, that's— oh yeah, that, that is true. Um, it's also like 3 grade levels higher than I'm prepared for. Um, anyways, you're— I thought that this start on, like, just to establish this isn't— you talk about building great products, you, you know, you talk about empathizing with the, with the customer, understanding them, building things that are helpful. But you decided to start this by talking about founder breakups and like the friction that it causes when you're not deeply embedded with the customer. Where is that coming from? Are there any hopefully anonymized examples that, um, you know, that this brings to mind?

Yeah, so I've actually, I've seen multiple examples like this where startup starts with an idea and there's, you know, there's two founders. There's the go-to-market founder or the quote unquote product founder if you, if you prefer to be called that. And then there's the like, builder founder, the CTO, that the, the kind of person who's actually building the product. And what happens is basically you get maybe a couple customers early on, get some revenue, and the, the building founder is just building a product, right? And, and kind of shipping it and deal— dealing with that. The product founder, the, the kind of customer-facing founder is out there talking with customers and watching them use the product and realizing that, wait a second, We're kind of approaching this wrong. We're kind of thinking about this wrong. We've been thinking it's X, but what it seems like is that it's actually more Y. And the, that co-founder has so much customer context that they can't possibly communicate it to the, to the like engineering founder. If the engineering founder hasn't been right there observing the sales calls, in the sales calls. Deploying their product alongside customers. And so what tends to happen is there's this kind of like the one, one founder has all of the customer context. The other has very little. They only kind of have what they are hearing and what they hear changes over time as the context changes from the, from the, and so I've seen multiple co-founder breakups because The engineering founder is just like, listen, we've built, I built this. Can't you just sell this? Why are, why are we changing things all the time? Like what's going on here? And, and the kind of customer founder is frustrated with the, the engineering founder for the same reason. It's like, how do you not understand this? And so that dynamic I've seen break, feel like cause I can think of 3 examples. In the last year of founders, founding teams I've seen break up for this exact reason.

Yeah. And there's, and there's a flip side to it. You, you give the example, uh, in the post about like you and your wife in the car, uh, and, uh, she says something like, I found two, two delis with sandwiches. And, uh, and as you write, it's like, it's a redundant statement, but in that context, you don't pause because you, you, you both are bringing along with you the last 15 minutes of a conversation about like what you're looking for, what the criteria are and stuff. And so the communication can work if you're doing it improperly. It works in the one direction. If you're doing it properly, it actually works in the other direction. And the way that you, you characterize this early is it enables you to build the right thing despite imperfect communication, which I think is a really powerful idea. I don't know if you have anything that you want to go deeper on there.

Yeah. So, so the example with my wife, I've just been thinking about that and she, I bring it up to her like once a week and she's like, why are you still thinking about this? This happened like in November or whatever. Like it happened months ago. And it's like, the context was, uh, uh, she out of nowhere says to me, I found two delis that have sandwiches. And I, I knew what she meant at that point, but I just found the sentence really funny. It happened to be that we were in a car. It happened to be that we were driving. It happened to be that we needed lunch, right? At some, at some point in the future. And so that sentence made sense given the shared context. And so it is, it is really interesting that I knew exactly what she meant despite that sentence having basically no useful informational content to anybody outside of that. So you, if you walk up to someone on the street and say, I found two delis that have sandwiches. They're gonna be like, what? Like, we need to deal with you.

Yeah. Yeah. Like, I, I, there's a place down the street also where you can check yourself in for a couple weeks and they're gonna, they're gonna help you out.

Yeah. You need a padded cell, sir. And so, so, so that's the, so that level of shared context is super important because otherwise you have to communicate Everything, like literally everything. And in this example, it's like quite a, quite simple one where delis with sandwiches, obviously, but think about a feature you're trying to build or think about like communicating this customer, like this, this customer in a manufacturing plant. Someone's never been in inside a manufacturing plant like that. This customer is specifically trying to do XYZ kind of thing. Like you can't communicate all of that context. So it gets lost. Even if you're writing the perfect, like, 10-pager to try to explain, it's just not going to translate. There's gonna be a translation error there.

Yeah. You've got, you have, not only is it not possible to communicate all it, but you're gonna invest a ton of time that is going to be basically just like lost trying to communicate it, trying to write out like the perfect specs that aren't that you are actually unawaringly bringing in a bunch of context even into what you're writing that is absent and unknowable by the person reading it or receiving it.

Yeah. And so then, so this right here, what we've just discussed is the case for everybody understanding customers, which is like a pretty straightforward case. I'm going to make the next level of the case, which is that everybody should, can only understand customers by working alongside them. The classic thing is like, okay, yeah, of course everybody should understand customers. So we should do customer interviews. I don't, I think that's nonsense. I think that kind of, that kind of thinking is why there are so many products that nobody wants because customer interviews are basically getting knowledge secondhand at best. Hmm.

Why, why do you say that? Like, why? Is it imperfect or insufficient to hear what they're telling you?

Yeah. So there are, so, okay. If we're starting with the, the, the shared context problem from a go-to-market founder to a technical founder, think of the shared context problem between a customer who's doing their job and you who's just interviewing them. It is 10 orders of magnitude more than the context problem between you and your technical co-founder. And so, right, like it would be insane if you could figure, like there are basically Bob Moesta, I think is the only person on earth who can actually do customer interviews and it's because he has 100,000 IQ and is like, just sees the world differently. Like there are, there are methodologies there that, that could possibly work, but it would be weird if this worked. And so instead of just hearing kind of secondhand and trying to understand what they're saying, trying to connect the dots, the only actual reliable way to do this is to do the job with them, to work alongside them in person or at work. Like if it's, you know, working with developers, you can go to their office and, and kind of like work with them, or you just join a Zoom call and work together throughout the day. Like, whatever. But it is, it is, we have to experience the job that they are doing or the thing they are doing in their life. Quick example, like this water bottle that I'm holding now pisses me off so much. I have no idea where you're going with this, but yeah, the reason is because the opening is the per— is like too small to give you a good like chug of water when you need it, but too big to take a decent sip of water. And this is an obvious— that if they had just like made a prototype of this and, and watched another human being like in the wild try to use something like this, they would've said, wow, this is the stupidest like water bottle top I've ever seen in my life. They didn't, they don't care. They don't care.

And so it's, I don't remember where I was going with that, but, but there, there's some, we're gonna, yeah, we're gonna, uh, I'm gonna take that snippet and we're just gonna send it to the executives at Columbia or whoever it is that has that.

Yeah, exactly. But the, the point is, if you, it, if they had just like not sat in a conference room rather than interviewing, they were like, what do you like?

What would you like?

Yeah. Yeah. They're like, Well, in the market, there are currently 0.5-inch circumference openings and there are currently 2-inch. What if we made a 1-inch? And it's like, whoa, we did it. And it turns out no one— like, it is the worst thing on earth.

Yeah. Yeah. Guessing, guessing at it. Um, maybe one more thing before we jump farther into this. Um, so this, it sounds like this post is for everybody whose name is not Bob Moesta or who, and even if you, if your name is that and you're not the Bob Moesta, then, um, for that person. But like startup size, I think, you know, we start out with co-founder breakups, but the lesson that you just talked through also applies to solo founders. How far should this go? Like, when do you stop needing to go be with, be with the customer? Or, you know, how does, how does it change as your, as your company expands?

Yeah, I, Well, I think it gets more important the bigger the company gets. And the reason is because when you hire more people, there's just more nodes of communication, which means there are more opportunities for translation errors. This is why marketing always hates sales, why sales always hates marketing, why everybody hates engineering, why engineering hates everybody. Like, it's, it is because there is not there's just, it's just like a translation error problem, like a communication, uh, uh, problem. And so like, this is why you'll hear stories and they're, they're spoken of as if, right? Like it's, it's, it, it's crazy. But like CEO of Uber, like drives Ubers on occasion. It like obviously does not need the money, not doing it for the money, doing it, doing it to, to keep close, like to understand what is the cust— what is the experience of the driver there? Right? Like Airbnb's founders lived in Airbnbs to get the experience, to understand the experience of this. And this is something that like just default needs to happen across the company. Otherwise, for people who just don't understand what we're doing here and they form some kind of model in their brain of what we are doing that doesn't reflect the reality of customers' actual experience and the when that model runs into the reality, usually the model wins and we wind up defaulting to building something that nobody actually wants. So whether it's product teams, engineering teams, marketing, sales, just like my sense is everybody needs firsthand customer experience and needs it at a cadence that is somewhere between yearly and monthly. And the closer you should be to customers, it should be more.

Hmm. Let's talk about what it means to be close to customers, what you write as forward deploying. Let's just pretend that your co-host on this podcast doesn't do that right, and you need to explain it to him or her or them. Like, what is forward deploying? Like, let's, let's break it down from like from the basics.

Yeah. So, so forward deploying, it's, it's a concept of forward deployed engineer. It was a concept created out of Palantir, and that's why the concept got quite hot. And because Palantir is stuck, it did this, which is fine. I don't want you to focus on the specifics quite so much. Forward deployed engineer is basically like a solutions engineer who comes in and works alongside the customer to implement the software. But the point is they're forward deployed. It's like when you were a consultant, you didn't just sit in the Bain offices, right? You would go eat in the customer's lunchroom, work with the customers, like at their office, right? It's about, it's about being there with them and helping them in their, in their office, in, in their environment.

Yeah. In that case, it was also about hotel points, uh, and airline, airline miles.

Mostly about the hotel points and airline miles.

Yeah, I could go sit in a, in a, in a client conference room and work independently on my laptop without talking to anybody for a very long time, as it turned out. But okay, so what, what we're talking about is being there in person. We've talked about this in the past where you're like, go watch people do their jobs. Is that one question on that one? Do they need to be using your product in order for this to be helpful? Like what? I want to make this super practical. So it's like How do you choose the customer?

Yeah. Yeah. Yeah. Let me, let me tell, tell a story here. Cause I think this, this will help. Um, um, and it, what I didn't cover in this post and I'll probably add on between us talking and the post going live is who should you actually do this for? Like, like what level in the organization? Is it the buyer? Is it the user? Like who, who do you, and how do you get somebody to say yes to this? Those are, those are things that we can, we can talk about. Um, but example of this is founder does not have a product. Wants to be a founder, uh, uh, at HBS. Um, he told me a story about how he didn't even know what industry he wanted to sell into, but he's like, listen, all I know is I want to sell into somebody that I actually enjoy serving. It's like, cool. Okay. So the way he went about it is he would reach out to potential customers. He kind of like created a list of industries. And he would first go and just shadow them for a day or two to see if he liked them. And so he started with solar panel installers, hated them. They hated him. Funny. Yeah. Then he, he kind of worked his way to independent physical therapy practice owners. No clue how he got there. These are very weird niche industries, but whatever, like good on him. And it turns out he in, like, he very much liked just being there with them. He liked the kind of approach they took to their business, the way they thought about it, the way they thought about customers, the way they, they, and the people they served. And so he was like, cool, I like this. And so what he did is he, he didn't have a product at this point. He just observed them throughout their day and, and basically tried in his mind and kind of like asked them about things that they were doing. They were using other softwares, they were using other tools, they were jumping back and forth between a bunch of different And he was just, so he was trying to use that to generate a product idea. And that's where the next part comes in is we need some sort of a conceptual framework, like some sort of a way to like, if we're observing somebody doing something, it doesn't need to be with our product. It can be with our product. Doesn't need to be. It should be kind of, it shouldn't just be narrowly about our product. It should be generally about what are they doing throughout the day. And sometimes they touch our product. Sometimes they don't. Okay. Like what, what are they doing and where is there a space for a product? Where's that? Like, where's the opportunity here? And so we need ways to think about what we are seeing that can help us get there.

Yeah. And, and with that, um, Rob, are you alluding to, um, like the calendar and the to-do list? We want to jump into those. Let's, let's I think they're very powerful concepts. Why don't we start with like defining the two of them and then the relationship between the two of them is somewhere that I still get my brain tied in knots. So, you know, let's— could you just start out by, you know, help us understand what is it like, what is a calendar, but like what is, what is an actual calendar in this context and what's a to-do list and how do they interact?

Yeah. Okay. So the challenge that I was looking to solve was that I had forward deployed with customers. I was like, they were using our product and I went in person to try to learn something. And I like just, I was watching them work and guess what I saw? I saw them working, like that's it. And, and I just saw them doing a bunch of tasks. I didn't have a way to think about it. Like what, what's happening? Is there a product idea here? Is there, is there something else we can like, what's going on? And so that's where these two concepts fit in. So let's start with the calendar, which is basically what are they doing on a minute-by-minute basis, minute-by-minute, hour-by-hour basis. It's just like literally observe them. If you were observing both of our calendars right now, it'd be obvious we're recording a podcast. That's what we are literally doing. Yeah. The calendar is the source of truth. What are they doing minute by minute, hour by hour? The second framework is the to-do list. So we have to try to understand, okay, but what are they trying to accomplish by doing this thing? What is, what is that ladder? Like, why are we, what are we trying to accomplish as we record this podcast? What is the thing that we're really, let's, that's, it's not about a podcast. It's about something we're trying to accomplish with this business. It's something we're trying to accomplish in our lives by recording this and So that's the separation between the two. It's basically action and intention. Maybe you could think about it like, what am I, what am I, what am I trying to accomplish that doesn't have anything to do with product? What's, what's kind of the demand side?

And is the right way to approach that to start with the calendar? Like the calendar is more obvious that you can, you can observe what is happening or you can look at a calendar and see what, what they are planning to do or what they have scheduled to do. Whereas a to-do list is more conceptual, like it's— they might have a Trello board, they might actually have a to-do list that they're following, but it's— there's a couple layers that are maybe deeper than that. So is it you start with the calendar and then you use that as the launching pad? Like the really valuable thing is the to-do list.

Yeah. Yeah. So, so let's say you're observing somebody. I was just thinking of this example, right? Like you're observing somebody who is trying to run payroll and it's like a, they spend 30 minutes trying to run payroll. Right. So the thing on the calendar is run payroll for 30 minutes, like figure out how to run payroll for 30 minutes.

Yeah.

And then what you're going to try to do, you're going to, you, that's like observable, but then you're also going to see that like one of two things might, might happen, right? They're just like pissed off typing like this thing doesn't work and they're getting like super frustrated, right? As they do that. And then, and so what you would infer, what are they trying to do? They are trying to like run payroll with less, they, they're trying to spend the least amount of time running payroll, right? That's the, that's the, the project on their to-do list. What they are literally doing is they're clicking buttons in a software and getting frustrated, right? On the other side of it is that they've got not like, they are totally fine. Just run. They're just leisurely running payroll, spending this time. They got nothing better. And so that's in that point in time is there, what's on their to-do list is like, fill my time with something, right? So, and, and Right. So that I, you know, so it looks like I'm working or whatever it is. Right. And so what we're trying to do is we're trying to get from what we observe to like, what are they actually trying to accomplish? And is what they are doing a good fit? Like, is there a match between these two things, their intention and their action? When there's not a good match between the two, that's, that's when you can, that's where there is opportunity for something that, that might fit better. There might be opportunity there. And then you can test that.

Yeah, let's, let's get into that delta in a second. But I don't want to skip over like really defining well the to-do list because you, you talk about a couple of misconceptions in the post. The first is the literal to-do list, which you write rather dramatically on this, Rob, the to-do list in their soul, which, you know, if payroll is in your soul, then that's, that's incredible. But I think you're getting at something different there. But and then the second one is that we think customers want products and features, kind of a supply-centric view of a to-do list. Why don't, why don't we kind of like address why do people interpret it that way? What are they actually saying and why are those the wrong way to think about a to-do list?

Yeah. So it's basically, it's not good enough to look at their actual calendar or to look at their actual to-do list because those things, that's not what we actually care about, right? Their actual calendar is just going to say meeting or something like that. It's not going to be very specific and then it's not going to have the time they're actually spending doing doing stuff. Same thing with to-do list, right? Their literal to-do list. If they have one, I have a to-do list here that has one thing on it today with a question mark on it.

So you won't like fire Robert. No, that has the exclamation point. Finally, finally, it's that three exclamation points and they're like, do it this time, like underline twice.

So, so the literal to-do list is, is That's not what we care. What we care about is in the moment when they are doing something, what are they actually deeply trying to accomplish? Like what, what matters to them? What are they, what can we infer about what they want to happen? And so that's where the kind of pull framework comes at the project on the to-do list. It's been, it's, It's definitely on my to-do list, on my backlog to better define this and give like better ways to think about it. I just haven't figured out better ways to write this, but like, again, with that simple payroll example, they are, you see somebody just slamming keys in their payroll system, this stupid thing. And like that, what you, what you know in that minute is that The thing that is on their to-do list is something like, I, like, not this. Like, I don't want to be doing what I'm currently doing. And you can kind of refine it from, I want to, I want to have payroll. I don't want to have to think about payroll. I don't want to, I don't want to spend time on payroll. I don't want, like, it's something in that realm, right? And what you're trying to get to, and this is the important, I say it's in their soul. That's actually, that's actually like not kidding. It is, it is what are they just most deeply trying to do in this moment?

Hmm. Yeah. Do you want to, how about unless there's anything else to say on that, Rob, why don't, why don't we get into, you mentioned the gap that, that can exist between the calendar and their to-do list. And you write about how this translates then into a pull hypothesis, but let's talk about the two examples of when there can be a gap. One is when they're doing something that doesn't fit what's on their mental to-do list. And you give jump as an example. And then the second one is when they are not prioritizing something right now that they would love to prioritize if they could, but they're blocked. And that's where you talk about lovable. So these are, I think, very helpful things to be tangibly looking for and aware of that they might exist. And one of them you actually might not realize that it exists because it's actually— it doesn't exist. Like, they can't do it. But let's start with the first one. When they're doing something that doesn't fit what's on their mental to-do list, that one sounds closer to what the example you've given with, with the payroll. But why don't, why don't you give the context on, on how Jump fits, fit that before they, before they, you know, stepped in?

Yeah. Yeah. So, so basically before Jump, financial advisors took meeting notes manually. For all of their client meetings for regulatory reasons, compliance reasons, whatever, whatever, right? And they had to put them into their kind of CRM system in a way that could meet regulatory compliance, whatever requirements. And so that took 45 minutes per client meeting. That adds up. However, like, just knowing that information, we know the action We know the calendar 45 minutes after, and maybe 10 minutes before the meeting, they're doing prep and note-taking, but we don't know if there is a fit between that and what's on their to-do list. So if, for example, what was on their mind was this, this just helps. This, this is a great ritual for me. This is. This is part of, this is core to the industry. This is the, like, this is exactly what I should be doing.

Yeah. I enjoy this and I feel like I'm better at my job because of it. And I would, even if I didn't have to do this, I would still do it basically.

Yeah. Yeah. I'm, I'm, yeah. And, and, and so, yeah. And so you observe if that was the case, Jump shows up and says, hey, we can automate meeting note taking. For you that meets your compliance requirements. And they'd say, why?

Yeah.

Why would I do that? But in reality, what was happening was they were kind of fighting against that meeting. That was time they weren't spending with their family. They weren't spending on the golf course. They weren't doing like whatever. And so they were, they were, that it was, they were kind of forced to do that. And the thing that was actually on their to-do list while they were doing it was like, get these notes done with the least amount of, of my time spent on them.

Yeah.

Yeah. Because there was the mismatch between the to-do list in their brain and their calendar. That's when Jump showed up. People were like, this must be how Alexander Graham Bell felt when he literally customer, customer said that to them. They have a customer testimonial to that extent.

It is.

That game-changing because there was such a kind of tension, conflict between the to-do list in their brain and the calendar, the way they were spending their time, that Jump shows up and is a much better fit for the thing that's in their brain, in their soul, the to-do list, the thing they're actually trying to accomplish in that moment.

And so what you're looking for, if that's your hypothesis that something like that exists, is, is it emotion? Is it frustration? Is it, is it long calendar blocks doing manual tasks? Maybe that's just specific to this one, but like, what, what would you be looking for if that's for evidence that, that, that kind of gap exists?

So yeah, so again, I'm, I'm not 100% sure. Like we're, we're re— here we are kind of like pushing at the bounds of the theory and, and playing around with it. And so I, I need to, I just need to go and forward deploy and see more cases of this. But my sense is that this often shows up as frustration of like, I am doing something I don't want to be doing that doesn't fit what I'm trying to accomplish. Yeah.

Yeah. Let's talk about the second one when they are not prioritizing something that they would prioritize if they, if they could. And so it's actually the, the absence of an action that I don't even know how you detect this, but why don't we start before we, before we talk about how it manifests, you give Lovable for non-technical designers. Why don't, why don't we give like the, we've talked about that in a previous podcast, but maybe the quick and dirty version.

Yeah. Yeah. So, so what Lovable helps me do at least is it helps me design a website from a prompt because I can't, I am incapable of like coding a website myself. I just don't have the patience and I'm incapable of using a Squarespace because I also don't have the patience. Entrance. And so what it enabled was, okay, from, from a pretty simple prompt, I can get a pretty close website or prototype or whatever, right? That, that, that will, yeah, that I can use. And so basically before this, I was not creating websites. If you looked on my calendar, I would, I like, you would not see a block where I'm creating a website, but that was because there wasn't an easy enough way. For me to create a website, right? On, I had create a website as like this thing on my to-do, right? Like a to-do list has an infinite backlog, but there's like a category of things that I would do right now if I had a way. And that was that for me and for a ton of people, right? This is, product has grown super fast and it's, it wasn't that, you know, it, for most of us it was just that this was a thing that we wanted to do, but were blocked from doing because there weren't good enough options. And so it wouldn't show up on your calendar. So how do you find this? I'm still trying to figure that out. I don't know. Um, uh, but like, that's the shape of it. It's the thing that they would do if only there were a way. And, and what I found for this is like, you kind of just show, you observe what they do. You kind of like talk to them, you see where they're struggling, and then you put something, then you put something in front of them, like a slide deck or like a, like concept, right? And see how they react to that concept. Hmm.

You know, I was thinking about this one while I was on my bike last night and I just ride my bike in my living room using a virtual program. And I was like, you know, if somebody would've looked at my calendar and at probably thousands of cyclists' calendars, they wouldn't have seen Robert is on his bike right now. They just, I just would've been doing something else cuz I wouldn't have been on my bike as much. And so it was another, but then Zwift came in and they basically have this like virtual world that you could cycle in, and it unlocked this like entire like sort of exercise period that I wanted to be doing that I couldn't because there wasn't like an option there. But what you're saying is, so you, you start with a hypothesis about what people are trying to do that they are not able to do. And it, it seems like these cluster around advents of new technology. Is that like, it seems like that's frequently the enabler of this or is, or are there like other examples?

Yeah, I don't know. I like, I, I've been thinking about this and I've been thinking about these, like one that comes to mind is the, um, the wheeled suitcase, which doesn't seem to be a technology thing.

It was just like, uh, it was like, I don't know what the wheeled suitcase is.

Suitcases didn't have wheels.

Oh, with wheels. Okay.

And then they had four wheels, right? And like, Each of these is like a, is, you know, like now you'd be kind of crazy not to have a four-wheel suitcase. Do you have a four-wheel suitcase?

My partner literally, um, she, she brings, uh, like a travel luggage thing and, uh, into work every day. I'm like, um, I need to, I need to get her. Apparently there's a, there's a solution for this. So, um, um, let's see it.

So, but like in that case, right, there was, there was kind of like pent up, like the to-do list. So there's no new technology here. There could be, but there's not necess— that's not the necessary case for this, right? In that case, it was just existing options didn't really fit what was on somebody's to-do list when they were traveling. And it just took somebody to observe that and say, wait a second, what if we put wheels on this bad boy? Right? And like, and put that in front and then, and then it's like, oh, obviously, like, I would be crazy not to use that.

Yeah. Yeah. Interesting. Um, how about, uh, let's, we're going to run up against time here. Not, not too long. Practically, how should, uh, founders be thinking about forward deploying? Like when you, let's say, let's say theoretically, hypothetically, your co-host for this podcast comes to you and says, Hey Rob, I need to, I need to forward deploy, but I don't know how to start that conversation, how to choose the right customer, um, like where I should, you know, where I should be going, where do I, where do I start?

Yeah. So it depends, it depends what you want to learn. If you want to, if you want to learn about your product in use, right? Like, and what additional things you should add to your product, what, or where people are struggling with your product, go observe users, like the actual day-to-day users of the product. If you want to figure out like, what are customers who buy this actually trying to accomplish? Look for the champion or the buyer or the person basically who, who you, who you do outbound to or who comes inbound and says, hey, listen, I'm trying to accomplish this in my company. It seems like you might be a fit. Go focus on them and, and observe their, their day to day. How to get them to, it's like wildly easy to get people to You've already shadowed, right? Like you've already gone and visited in your, one of your customers and it was like, I don't know, I feel like it's, hey, I'm gonna be in town. You mind if I swing by and meet you and, and kind of like shadow you for a day?

Yeah. Yeah. I, I think I did mine wrong. Um, I ended up, I went and they gave me a tour. We sat down and we talked for a while. I didn't observe them in their like cubicle, which is, I, I think the thing that I needed to, I need to— I learned, I learned things. And actually it became apparent in that particular case, it was with a large aquarium on the West Coast. It became obvious based on just the things I was hearing that we didn't necessarily fit there. We didn't fit their pool. And I understood more. So there was value there, but it was different from observing what they're doing with their time. And so I, you know, I think I'm like sort of— I got 60% of the way there, but the other 40% would have been super valuable.

How do you—

So is it, like, what you advise is like actually literally sitting beside the person that's implementing or that you're going to be selling to, and is that creepy? Like, how do you, like, is it awkward? How do you, you know, when you were forward deploying with your first startup, for example, either what did you do, or if you were going back to do it again, like, would you pull up a chair next to the person? Like, what would you be doing with your time?

You sit on the same chair as them, actually.

Yeah. Come here, Poppy. Just sit on my lap. Like, yeah.

Yeah. No, it's just, hey, do you mind if I shadow you throughout your day? I do this on occasion. And what I'm trying to do is I'm trying to figure out how to build the right product for this, like build a better product, build a da da da da. I'd love to learn from you. You, I've even seen people like, okay, so just forward deploying is even like the bare minimum, right? What I've seen is a lot of people go and get a job with them or become a consultant for them, literally join their team and do the work with them. Yeah. And so I'd say, you know, you might not be able to do that if you're like the product, the 17th product manager at a 400-person company, right? I get that. But if you're a founder, early stage, forward deploying is like the minimum, just going and observing somebody is the minimum. Go do, like, go actually do the job.

Yeah. Yeah. Um, Rob, other things that are on your mind, um, things that we didn't hit that are helpful to get to?

Uh, no, I think this is a good overview. I think this is a good overview. I think there's like a lot more here. I think this, this wound up growing, uh, the, the, as a, as a concept and as an idea. So, it's probably not complete, but we'll keep coming back to it and keep iterating.

One thing we, we didn't hit, and we're going to hit time, uh, is how this translates into the pull hypothesis. So I'll, I'll leave the, um, uh, I'll leave the link to the, the Substack in the show notes. Recommend reading through that part and thinking about specifically, you know, pull being what's, what's the project, why is it urgent, uh, what are the options they're looking into and why are those options lacking? But how, like bringing that mentality and that framework and seeing the way that the customer is behaving through the lens of, you know, last week we talked about force and fit. There we go. All right. I got, I got 50% on the quiz, but, but I thought that was also a helpful translation. Otherwise, Rob, if there's nothing else you wanted to hit, You've got a PMF camp, just as a quick reminder, starts on February 9th. Still have spots. We'll leave information in the show notes. And if nothing else, then we'll catch everybody next week.

Sounds good.

All right.