Prototype Like You Mean It, Part 1

In this episode, Justin Davis and Greg Ross-Munro break down why prototyping is one of the most important steps in building software-driven products or improving service business operations. They explain how prototypes help test whether an idea actually solves a problem before investing serious time and money into building it. The discussion covers practical ways to prototype quickly using spreadsheets, forms, automation tools, and AI-assisted development. They also explore the difference between prototypes and proof-of-concepts—and why entrepreneurs must avoid becoming emotionally attached to early versions of their ideas.

Transcript

Copy Transcript Copied

SPEAKER_00 0:06

Hey there, welcome into Leap to Scale. I'm Justin Davis. I'm Greg Ross Monroe. And this is the podcast that's out there to help service companies figure out how to get past the headcount ceiling, how to grow using technology and scale past trading hours for dollars. That's about productizing your business, uh, improving efficiency through technology. And we break it down in every episode and talk about it. Um, and you know, one of the things that we what one of the parts of the process that you have to go through when you're doing this, when you sit down to to either improve internal efficiencies in the pursuit of scaling past headcount or productize part of your business or some other combination thereof, is you've got to find ideas about how to do that. And we'll do another episode about how to find those ideas and where you how to think about that in the context of your business. And then you have to sort of find out if your ideas really work or not. And that's something that we call prototypes. And a prototype, well, that's a prototype is a way to help you find that out. It is one of the tools that you can use in order to find out if the thing that you're making is actually solving the problem, right? And so we're gonna break down today what prototypes are, why you use them, when you use them, how to build them, and why they're important to this entire process.

SPEAKER_01 1:40

Um Justin, I have a question. First, I I I get I get where you're coming from. I think everyone knows what a prototype is. Like everyone's like seen, oh, this is a prototype new uh Bugatti Shiron. I don't know, my my son is obsessed with Bugatti Shirons at the moment. So um this is like the it's like the first version of something you build. But you know, they're sometimes made of clay or whatever, but like how how would you how is a software prototype different from like everything else in the real world? Like I'm gonna build something.

SPEAKER_00 2:13

Yeah, I mean I think that in in some ways so let's like yeah, back it up to fundamentals for a second. Like, what is the prototype and why, right? What is so important about this? What are you actually doing? Um when you have an idea for either a way to make your business more efficient using technology or in some other way, or to productize something, or any real idea in in your life, you don't have a hundred percent certainty over whether or not that idea is actually going to do the thing that you think it's going to do, right? Oftentimes, one of the things about being creative, being an artist is that like it's hard, you you see things in your head, and the process of getting it from your head out into the real world is sort of what makes a lot of artists artists. I mean, that translation is is so important, right?

SPEAKER_01 3:03

And so some I would I would like to uh I would like to quote um one of my favorite uh thinkers on the subject, Mr. Justin Davis. And uh uh not to be a sycophant, but to say, but I think you gave an entire speech once on how your your idea is almost certainly wrong. Yeah. Like your first idea, whatever you have certainly wrong, is almost certainly wrong. Yeah, that's right. And you need to find out actually how it's wrong. Is finding out like what's wrong with it first and quickly is like one of the most important things you can do in building a product or building a lot of people.

SPEAKER_00 3:37

Yeah, and that's the thing, that's where prototyping, I think, with technology is different than say prototyping a car like the Bigatti Shiran, is that like when you're using with technology, what code and especially now AI and low-code, no-code tools and workflow tools, we're gonna get to those in just a little bit. It's what that unlocks now is the ability for you to test these things and see if they're right without spending a lot of money and with a lot of with very little risk, really, right? And you essentially, when you think about it this way when you have an idea about a problem that you're gonna solve, right? Whether that is I'm gonna launch a product into the market, which is you're solving the problem of building a business, or I'm going to solve this internal thing, which is actually solving a problem by throwing technology at it somehow to speed something up or organize something, make something more efficient or whatever, right? Like you have essentially what you are doing is you are in you're going to invest time, you're gonna bet time and resources against the certainty that you are correct that this will actually solve the problem or pan out the way that you think it will. And it's almost never 100% certain that it will. I mean, sometimes there are things that are very obvious that it will or will not work, but most of the time there is some gray area. So building a prototype is the fastest way and the cheapest way to systematically test little investments to make sure that you're on the right track so that you don't invest a whole lot of something and come back and find out that you were wrong very early on. And this is there's a thing about that and there's a thing about trajectory being wrong that increases risk, which is that the earlier on that you are wrong without fixing it, the more you go off course because it's just like steering a car. If you just take it a little bit off center and you let go of the wheel, for a little while it's not too much off course. You can always redirect back to the center. But the longer you let it go without being checked, the further and further it gets off the center and eventually isn't correctable. And so what we're trying to do is ensure that we're just always pulling it back to the center, and you can do that with prototypes very effectively.

SPEAKER_01 5:53

I I think that um that that's a really good analogy, especially seeing as we're going back to the cars. Now we can like your Bugatti Sheeron is off-centered and like the design is going that way, so that's cute. Um, but I think there's another aspect, just to like a s which is a a cost aspect, right? Everything has an investment, yeah. And the perfect prototype, like if I had to like design something, like the perfect philosophical, the platonic ideal of a prototype, it would be at this like cross section of the least amount of work to do to validate something, and the least amount of cost necessary in terms of how complicated it is, how long it took to do, how uh how much fidelity, like how like how it how much it looked like the real product. Yep. The the the sorry, the end goal product. Like that is the perfect like if you can spend the least amount of money to do the least amount of work and still then have that validate your idea, that is the perfect prototype. Exactly, right?

SPEAKER_00 6:57

Like this is basic ROI stuff, and I think people forget about this. Like, your goal is to do the least amount of work or create the least amount of a thing to get the the maximum amount of the result for the trade-off that you want, maybe not the ceiling of what you could get, but the optimal trade-off, right? And so if you go build this massive, massive thing, it might have been that you could have built something way, way smaller and invested way less money and gotten the same trade-off or better.

SPEAKER_01 7:23

There are people who there are people who with the best intentions do that with us. Um, you know, and we that we've worked with, who we have tried to talk out of spending more money. And we're not even like the stuff that we do is like generally we're pretty good at being like good stewards of of what our clients and the people we work with, like their money and their time. I saw this thing recently, and and I cannot name names, but um the uh a very large, well-known company I know spent one point something million dollars doing the design of something, doing the design of a product that from end to end, like it it looked exactly like it was supposed to look, and they didn't show it to one person, not even internally. And the problem is that one day the boss, the CEO, saw the thing, or the president in this case, saw the thing, and flipped out because they had spent one point whatever million dollars on designing it without showing it to a single person, not a single customer, not a single like internal like stakeholder. They just IT went and did it on their own, or marketing did it on their own, whoever it was. And I'm like, I you can't I mean if you're looking if you're looking at the worst case scenario, I I would assume that's the that that's the worst, right? The the there's I'm sure there's and and in terms of like where that baseline is, that baseline may include if you have to report up to stakeholders inside of a larger organization, it may have to be, it may have to look pretty good. Yeah. It may have to like feel crisp because you know, like your boss is a person's like if they're gonna see that font is not the right front front from the from the brand guideline. And so in order to get it through to that phase where they can jump from the like what's right in front of them to the actual philosophical, like, is this gonna solve the problem? You need to like check a few boxes along the way. But you don't have to build every screen, build three screens, right?

SPEAKER_00 9:27

Build three building what you need, be lazy, embrace laziness, only build as much as what you need, right? And so let's talk a little bit about fidelity because what we're getting at here is is sort of the fidelity. When we say fidelity is what we mean is like sort of how complex or detailed does this thing need to be that you need to make, right? Do you need to build a massive $150,000 web app to do this, or can you do this in a spreadsheet? And as it turns out, spreadsheets are fantastic, fantastic uh tools to build prototypes in. And um, something that I I like to say a lot is that I think that almost all software somewhere is built to replace a spreadsheet, uh, or all software is built to replace a spreadsheet somewhere. Um, because a lot, if you really think about it, a lot of it is, right? And spreadsheets are incredibly useful tools. So I think that when when you're thinking about building a prototype, think outside the box. Don't think necessarily, oh, I have to build this particular thing, this particular form factor, right? It might be that a spreadsheet and an email list are enough to build a prototype of a product, quote unquote, or service that you could scale up to 50 people before you like get to the point where that becomes unmanageable. With a Google form in front of it, maybe. Yep, exactly. So look for the easy solutions and think of yourself as you have a few different options. You can either go find something off the shelf that does what you already need, which you probably wouldn't be doing necessarily wholesale because you wouldn't, you would have just done that. You wouldn't be prototyping at this point, right? But then you can either build this thing from scratch and you can assemble it from different parts together that already exist. And some of the ways you can also do that, right? Because at some point you will outgrow a spreadsheet and you will get into the point where, okay, now this thing is scaling up, or maybe you need to do automated stuff, right? Maybe what you need to do is you need to uh be able to send out an email when so-and-so thing happens, or you need to be able to take in a form, process it, and then like stick a summary of it into your your QuickBooks, or I don't know, just making up crazy things, build your own expense system, whatever you want to do. Um, once you start to get into that point, or if maybe you're unable to use something that's like a spreadsheet to kind of fake it, then you could use something like make.com, you could use something like innate n and chat GPT or open AI also is an agent builder inside of ChatGPT that also allows you to build workflows that can also embed AI into the process. Um, and so that's a really useful way to think about it. So start with the smallest possible thing. And the other thing that I say about fidelity that I think is really important, this is an all-product development, and I think this is what we're talking about, is basically product development through a certain lens, is only build things at the level of fidelity that matches your current level of like fidelity in your mind or certainty in your mind about the thing. Don't build a big detailed thing and start worrying about what label all of these form fields are going to have when you're not really sure like how people are generally going to interact with this thing. Build it in a more abstract way. So if you're at the idea stage, it's a sketch, and then to progressing layers of fidelity until you fill in all of the boxes.

SPEAKER_01 12:54

Yeah, I think there's a an interesting point you made there about some of the AI tools and the spreadsheet, and like and and there's something that maybe people won't see that there's there's a subtle difference between, which is I think between a prototype and a proof of concept. Right, and this may seem like uh getting pedantic, but a proof of concept is generally uh a way of asking uh a specific technical question, maybe which is like which is is this feasible? Like is this is this possible? Is what I'm trying to do possible. Whereas a prototype is it's you know, it's like it's like should we build this thing? Should we build this thing?

SPEAKER_00 13:43

Is this the right way to solve the the yeah, right to yeah, yeah, yeah.

SPEAKER_01 13:47

And I think that's yeah, I think that's an important distinction because a lot of people will go will say, you know, you might actually want to be able do both at the same time in some situations. And the problem with some of the like the newer AI tools is they can maybe completely abstract away the the proof of concept pot yeah to you, and I'm not I don't think it's a huge issue, but like Yeah, I no, I think that's very fair. Like they could fake it, you know what I mean? They could no oh yeah, it's totally possible, right?

SPEAKER_00 14:19

I mean you're sort of polishing a turd a little bit, right? Like, or it's like it's actually like wrapping it up in gift trap and be like, oh what a beautiful present. And like so, and and I think some of that's really important actually to say because when you are building a proof of concept or a prototype, fundamentally you are really trying to answer a question. It's focused on what on answering the question. It is not focused on building the thing, you're focused on answering a question about will this work? Can it do it? Is this the right way to package this? And if we actually continue doing this, we'll have some result that we're looking for, right? And so I think it's like really important to stay focused on only building as much as you need to to answer that question and make sure that you're not adding layers on that obscure your ability to really get a clear answer to that question, right? And that's why I mean, honestly, I like to build, you know, sometimes I'll build, I'll certainly build proof of concepts as code in a command line because it's just streams of data that I can look at. And it there it's just you can't get more unembellished than that. And then um, but you can move up in complexity from there and just yeah, just watch the ornamentation for sure.

SPEAKER_01 15:41

I think a uh one thing that people might not realize they have is that they may already have prototypes in their business, especially if you're in a service company. You may have already built a prototype and you don't know it, especially if you've got a spreadsheet. You may have a spreadsheet lying around in your business right now that you know you it has some cool formulas, you put this number in here and then it calculates the thing over here, and like all this work is going to work out what somebody's like pay band is, or it's gonna like work out how um you know much of their cholesterol medication they should do. Probably shouldn't do some of these things as a spreadsheet. But um, you know, I I saw a I saw but but but those are prototypes. Those are all prototypes. And if you if you can if you can do that and you can translate it to code, now you've got yourself a product, so you've got yourself something like that. Yep.

SPEAKER_00 16:31

I think that's a really, really great, a really, really great point that we can certainly go into more on another episode, I which I think is this notion of looking around at the spreadsheets that are sitting in your company. If you're if you're sitting around and you're going, man, this all sounds great. Um, and and again, we'll do an episode on ideation. I think that that that'll be an interesting thing to dive into. But looking around your company and saying, well, what what things have we made that are unique to us, that are doing a little calculation that's that is really helpful for us, or is creating this thing for us that saves us a bunch of time. That man, if that thing broke, we would be in a world of hurt. And then start to think about if other things are. That thing is your IP, right? Your intellectual property, right? And so you can use it internally, and then you can also say, but we could also maybe find 10 other companies that look like us that sort of do it like that too, and give them this same thing. And you know what you can even do? You can even sell the fucking spreadsheet to them. Yeah, that's a viable way to test a market. We're not going into that exactly here, but again, the point is a spreadsheet might be all you ever need to do. But it might not, you might not grow it.

SPEAKER_01 17:51

So one thing we see a lot these days is folks who are out there prototyping things they've got on their own. And when I say prototyping, they're using these AI tools or low-code tools or no-code tools to uh actually try and build it themselves. And I I want to say they're prototyping, but it's like a new type of prototyping. It's not it's not it's not like the kind of prototyping where we would tear it all down after the first iteration and rebuild it and do it 20 times or do it three times, whatever it is. There seems to be you know, the I'm talking about tools like Lovable and Replet and Bolt and stuff like this. Um and because I think the make.coms and the N itends, those are different, those are more like in those like proof of concept. Can I like string these things together and then like later kind of make that code?

SPEAKER_00 18:48

Yeah. But I also depends on what thing you're doing because some things are more workflow automation-centric and some things are more product-centric.

SPEAKER_01 18:57

So here's my question to you. I've noticed that when people have built these prototypes or these these you know AI assisted or no-code or low-code assisted platforms, that the problem is that they get really attached to them. Because like emotionally attached to them, because they actually sat there for a week or two and they built it themselves. And so when when it's time to move it out of the prototype stage and make it, you know, to let it kind of grow up and be scalable or robust or secure or whatever it is that it needs to do to become you know the backbone of a business rather than something that you spent a couple weeks of your own time and you know 20 bucks a month on. Uh, which I don't think we're there yet to make that a full product, technologically wise. Like, do you are you finding that people could have this emotional attachment to their prototypes?

SPEAKER_00 19:51

Or like I mean, it's a really interesting point. You know, there's a cognitive bias known as the IKEA effect, and the Ikea effect is essentially a it's a cognitive bias that that causes the person who helps to create a thing abscribe more value to that thing. And it is a really dangerous blind spot, actually, in entrepreneurship and product development because it causes you to just think your ideas don't stink, you know, based frankly, right? Because as you my ideas are always great. I don't know if this is okay. And so as you build a thing, especially as you invest more and more time, and it's also a little bit of a sunk cost fallacy and and bias as well, you start to defend it to yourself and say, Yeah, this is definitely gonna work. And and I you get attached to that thing because of the level of fidelity, right? It has a look, it has a feel, it has a personality. Like when you interact with a product, a thing that people like forget, and I'm fascinated by because I I'm a geek about human-computer interaction, is that when you interact with a machine, you are having a relationship with a thing. And because of machines, and because of how how like deeply complex our interactions with them are, you actually develop like with products and stuff, you develop a type of relationship, and you can feel that when you log into a product, you can feel almost like you walk into a room with a different person. Some it's just very friendly and you and and you feel very comfortable, and some you you don't, right? And so you you create these relationships with products, and so I think in a way it's like a form of anthropomorphizing, but like apropomorphizing, I guess. And so I think that yeah, there is a time when that is could maybe get dangerous because again, if you have gone too far off, that's fine if you're on track, but if you are not and you go there too early, or you get attached to a thing that ultimately is gonna have to change massively in order to get somewhere else, then yeah, that can become problematic. But I be I mean the key there to remember is products are disposable. I mean, and it any I mean really more and more so. Don't get attached. You can just go make it again. Make it again better. Like, I mean, like you could just it's fine. It's just a product. But yeah, I think there is a problem. Uh, not a problem, but I think there is an interesting phenomenon there.

unknown 22:15

Yeah.

SPEAKER_01 22:16

I think what we're saying is you always got to prototype first. Prototype first. Doesn't matter what it is. Yeah. Whether it's on paper or like uh I've seen some people do amazing things with PowerPoint where they can like make clickable things and kind of show it with people, and like, oh yeah, it looks like and like wow, you did this in PowerPoint. Yep. Um you know, and find out if it solves the problem you're trying to solve. Yep. If you are trying to automate something or it's a workflow where you're kind of like starting to lean into that proof of concept, use a make.com or uh an N8N, or but most of the time like a spreadsheet is gonna be good enough, right? And then and then if you want to wander into the AI tools like the lovables, the replutes, whatever, you know, yeah, you can you use those as drafting tools. Um, they can have quick logic, but try not to become like too like emotionally attached to them because you may have to decompose them at some point and then bring them back up to being a more like grown-up tool.

SPEAKER_00 23:22

Yeah, I think we're um as we kind of wrap this up, I think that we're also converging onto a world, I think. I've had this like theory lately that um, or just thought lately, that there is no such thing as a prototype, actually. It's just an early version of a product, it's all one thing. That has not always been practically true because things had to kind of get rebuilt because whoever came up with the idea wasn't able to get it to a point where it could be continued. I think we are probably in the future going to be at a point where the idea of a prototype as a separate thing is not going to be a thing. A prototype is a phase that a partic a single product goes through. Um, and I think that's also I don't know, something I think about. I I I agree with you.

SPEAKER_01 24:14

I agree with you 100%. I think we I think in maybe we should we should do part two of this where you've already discussed that. But I think in part two of this, we should discuss how you could plan that prototype phase so that you don't throw it away. And that might be a level of expertise that you need, or like a person that you hire or something that knows how to do that. Um, but I think for most people, uh, if they're not technologists or if they're not like like you know, they have some training in product development, you should be okay with throwing your prototype away. You should be. And I agree that maybe like a certain percentage of the population can build prototypes as a phase. But we'll see. And and I think but that's gonna be that's gonna be as as these tools improve, that's gonna be an increasingly large number of people, but it's I don't think it's gonna hit 100%.

SPEAKER_00 25:05

No, and maybe what it is more so than it a change is that it is an additional pathway that has emerged, right? Where there is still the pathway of rip it down and rebuild it now, the next kind of clean version of this, right? Which will always be a good approach, and there will be this additional interesting pathway where prototypes actually are the same as just early products. Okay.

SPEAKER_01 25:32

Well, it was awesome, man. I um I feel like that was a good conversation. Um I think I feel like I have things to argue about with you next time. Yeah, I can't wait. Let's go.

SPEAKER_00 25:44

We'll see you on the next episode. Cool. I'm ready for an argument. Bring it. Are you? Let's go. Okay, all right. Let's see. Coming to a Spotify near you. Who cares about this type of prototype?

SPEAKER_01 26:00

Thank you for listening, everybody. All right, we'll see you next time. See you next time. Ciao.