Why You Should Stay Scrappy and Test Before You Build

Summary:
This week, I share a real-world reminder about staying scrappy, starting small, and validating problems before jumping into big solutions. A friend asked me to help map out the entire real estate transaction ecosystem — but once we started, it became clear the scope was way too big. Instead, we narrowed the focus to one specific pain point, suggested quick empathy research, and sketched a simple path to test the idea fast. Lesson learned: don’t overbuild, don’t overthink — prototype to learn.

Transcription:

 So today I wanted to talk a little bit about being scrappy and about, getting really good at focusing on first things first. So, a friend recently reached out and asked me for a little help. He was, trying to do a little bit of data mapping and, some visualization. He's a real estate agent and he is trying to fully map out every transaction or every action that could take place for a buyer, a seller, or a broker.

He called me and said, Hey, would you mind facilitating some of this for us? And I said, yeah, sure. He brought a friend with him who is an engineer. The two of them are talking about doing a potential project together, and they thought that the first step for this should be, a mind map of all possible scenarios.

So as we started down this path, I made the total rookie mistake of, not really digging into the strategy, not asking about why we were doing this. But as we got about halfway through this project, I suddenly realized that there was. Millions of, ways that this could go. There was millions of potential paths that a buyer or a seller could take and everything ranging from, all the other players, all the other roles, mortgage brokers and banks and lenders and, inspections and all the other, things that could happen.

Staging, photography, there's a million. Things that need to happen for a real estate transaction to happen. And so I kind of pressed pause about halfway through and I started asking my friend, what is it that you're really looking for? What is it that you want here? And he started to describe a very specific scenario where.

An agreement has been signed to buy a house and he wants something automated in a way, that is not currently automated and he's having to do the same thing over and over again, and it feels antiquated and in dire need of a little bit of innovation. You know, when he took this problem to his friend, who is an engineer, of course, his friend said like, oh yeah, let's giant out this like giant ecosystem and so we'll better understand where all the friction points are.

And this is, you know, it's just too big of an in, of an ecosystem. It's just this giant constellation of pain points and decision points and roles and relationships and so. Anyway, the guy was well-meaning, and that was where he wanted to start from, but I actually pushed my friend back to something much smaller.

So, as we got to this idea of this one pain point that he has, I suggested, in classic design thinking style, right? Like, oh man, you need to go interview five other agents. See if they are experiencing something similar to what you're experiencing. See if it causes them the same amount of pain that it's causing you, and then we can take a look at what a potential solution might be.

But we're not even really sure that this is a problem for anyone else but you. So that's the first thing. Tons of entrepreneurs do this. They build something that, that they think will suit them well and they think it's gonna have market value. And it doesn't, it doesn't always have value. Just because it bothers you doesn't mean that it bothers other people.

Right. So, so the second thing that I said, I said, if this is a real problem, this is, we can quickly build a, a low res prototype or even a no resolution prototype for, for something like this. And. Test it really quickly. We can test this six times in the next two days. Like that is not a problem to, to better understand what we're doing here.

And just to be clear, I use prototyping as a verb. I like testing prototypes or ideas, as a means of learning not to. There's not much focus on the actual prototype itself, right? Like we're not trying to hurry up and get to an end product or an end service. We're really trying to learn more about the user, more about the problem, and see if there's a real insight there.

So anyway, rookie mistake for Parker today by not digging in earlier about strategy before I just started helping these guys, map out this giant constellation of actions and transactions that could take place, for a real estate deal to go down. Anyway, I've learned my lesson, so the next time I won't go in so freely like that.

I was just trying to help a friend out and, but I will say that we ended up getting to clarity. We ended up getting to a place where he knows exactly what his next step is. It's a much more manageable project, to look at now, so he can hop in, he can start taking a look at exactly what's been bothering him, find out if it bothers other people or not by doing some empathy research, some interviews, just talking to friends of his.

And then we can kind of quickly design, some no resolution test, which will help him figure out if this is a real thing or not. If this is something worth pursuing and worth building, then we give it to the engineer and, tell him what we're looking for, see if he can build a continued low resolution prototype, before we invest any serious time or money on tech.

So anyway, that's what I got. Stay scrappy. Don't get ahead of yourselves. Build the thing, test it. Make sure you have a real user in mind and a real need you've uncovered. All right, that's it for this week. Talk to you soon.