Subscribe
Share
Share
Embed
Tales from the PROS is hosted by Michael Georgiou, Co-Founder, and Eric Lawrence, Director of Growth at Imaginovation, an award-winning app and software development company. Each episode dives into honest, unscripted conversations, hard-earned lessons, and educational insight into how to help bridge the gap between technology and people.
If you’re a founder, exec, or innovator trying to navigate the tech world without getting burned, this podcast is your no-BS roadmap. Through real talk, personal stories, and insights from the front lines, you’ll pick up smarter ways to build software, steer clear of common mistakes, and choose the right partners in a crowded, often confusing space.
Whether you’re scaling a startup, driving digital change at a larger company, or just love keeping up with tech innovation, Tales from the PROS brings you straight-shooting advice and inspiration without the fluff.
Eric Lawrence (00:01.742)
Hey everyone. Welcome back to the Tales from the Pros podcast by Imaginovation I'm your host, Eric Lawrence. I'm filling in for Michael as he is away today and I'm joined here by a co-host in our chief product officer, Zach Bruno. Hey Zach, welcome.
Zach Bruno (00:18.862)
Happy to be here, looking forward to it.
Eric Lawrence (00:20.62)
Yeah, same here. So today we're talking about something that separates great products from costly mistakes, the discovery phase. So many founders want to jump straight into design and development, but the truth is skipping discovery is the fastest way to waste a budget to help us unpack this. Zach's here and he's led discoveries for hundreds of digital products. He's been with the company for over eight years now.
And Zach's an expert at turning early ideas into clear validated products. Today, he's sharing exactly what great teams do before a single line of code is written. So Zach, thank you again for joining us. And I am excited to pick your brain on this topic.
Zach Bruno (01:04.621)
Yeah, yeah, this is an important one. lot of teams, a lot of companies get this wrong. So yeah, happy to share any insights that I can.
Eric Lawrence (01:12.322)
Yeah. So let's, let's open it up when it comes to most teams underestimating discovery. feel like that's a common trend. What are the biggest misconceptions founders or executives have about it? And why do so many skip it altogether?
Zach Bruno (01:30.637)
So in most cases, what you'll see is discovery is skipped because teams think that we know what we need to do. Let's just build it and we have an audience for it. It should work. The problem with that is you skip the validation step and discovery is most useful when you're using it for validation. So the purpose of discovery is to take your idea, bring it to life as quickly as possible and get feedback on it. And, you know, in some cases now, when we'll get to this topic later,
AI kind of makes that easier to actually have a real functional product. But for the most part, building a prototype and discovery and validating, getting feedback with that to make sure that before we spend all this time building, we have something that people actually want and need is a crucial step.
Eric Lawrence (02:16.855)
Yeah, you know what's funny? I feel like for a lot of people, they focus a lot on the design stage. They get excited about that. They get excited about the way that the product's going to look. And then they think a little bit less about the actual planning piece. And have you really mapped out the best user experience?
Zach Bruno (02:34.369)
That's right. Exactly. And they over, they sort of start over designing because it's exciting. It's fun. And, yeah, using lay the groundwork and, know, end up building something that people may or may not want.
Eric Lawrence (02:46.529)
Yeah. When you run into somebody that comes to you and says, Hey, I have these designs built out. What, do you usually find is, kind of like a mistake that they've made that you have to basically find again and fix during that planning phase.
Zach Bruno (03:03.167)
Yeah, what I see the most is, you know, the first step is to take, you know, designs that are given and take a step back and really analyze the core needs of the audience that we're building for. So what you'll find in designs is that they have designed something that is cool. it's, probably is a cool experience to walk through, but it turns out that the core audience didn't actually need it or want it. So the goal is to ever hit the drawing board, make sure we have a strong foundation and, you know, build the.
the least amount for the most value.
Eric Lawrence (03:35.905)
Yeah, that makes sense. That makes sense. And I know the validation piece, it's what you said, it's missing a lot of the time. I wonder if the validation piece is mostly looked past because it's just hard to get validation. And I know for a lot of people, they have trouble kind of letting their idea go and putting it out in front of a lot of others.
Zach Bruno (03:57.578)
Yeah, exactly. Especially when you think you're sort of onto like the million dollar idea and you want to just build the whole thing because then it's too late for someone to copy you. reality is the sooner you get your idea in front of real users and clash it with reality, the sooner you'll have, you know, be able to start moving towards a product that is actually useful in the marketplace.
Eric Lawrence (04:02.563)
No.
Eric Lawrence (04:20.833)
Yeah. On the, on the validating piece, I'm interested to get your take on this. I know there's a bit of a balance when you are validating a product. you go for monetization? Do you go for just pure validation? Is this a good idea? What's the balancing act there? And I'm sure it might come down to it depends, but I'm interested to get your take.
Zach Bruno (04:46.762)
Yeah. So definitely, definitely the ultimate goal is with any product or business is to validate that your core users or your audience are willing to pay for the solution to their problem that you're presenting them. So definitely making sure that they're to pay for it. But what you're really looking for is to make sure that the solution you put in place actually solves their problem first. So, and the way you do that is by rapid prototyping, getting feedback and iterating on the prototype.
until it's at a place where we know the solution actually solves the problem. Now, the key with feedback, and this is sort of the biggest thing that all product teams have to balance is how do you balance between your vision and taste or intuition of what you should build that the users don't know they need and want yet versus taking their feedback, what they tell you and what you observe in their behavior and implement something that they need now. Because users only have insight into the context
of the product that they see and know. occasionally you'll get a user that understands and a customer that understands sort of the bigger picture, but in most cases, the feedback you're going to get is very relevant to what you've shown them. And so it's a balance between building the cool stuff in the future and what's immediately valuable now. And, you know, that's just to determine what you should have that solves the problem. Now, once you have your, you iterate and refine on the solution,
Eric Lawrence (05:58.276)
Hmm.
Zach Bruno (06:13.854)
to make sure that it solves their problem, then you can start testing, okay, is this valuable enough for people to pay for? And once people start paying for it they're willing to pay for it, even if you do it manually at first and don't actually build it into the product, that's how you know you're onto something.
Eric Lawrence (06:31.639)
Yeah, that's, that's really interesting because I know for our own project management and, you know, task management tool, magic task, that was a balance that we dealt with where, you know, there were a lot of things from a what's the user giving us feedback from versus like what direction do we see this? That could be blind spots for just normal users of how we want to move this thing forward. There there's always kind of that balance of, you know,
Do we feel like we know more than our users in certain ways, but should we listen to them in other ways?
Zach Bruno (07:05.19)
Absolutely. Yep. That's the sweet spot you got to find. Every product team has to go through it. It's one of the most challenging things.
Eric Lawrence (07:14.337)
Yeah. So getting a little bit deeper into the discovery piece, you know, the deliverables from that discovery can make or break a product and a project in general. What would you say are the most valuable assets that come out of a discovery? You know, maybe like things like a user journey, wireframes, clickable prototypes. And second part to that is how do they directly impact development success?
Zach Bruno (07:39.912)
Yeah. So, historically discovery, like I said, the goal of discovery is to bring the idea to life very quickly and start getting feedback, iterating on, you know, something that is easier than the actual product itself. and so that's, that's changed a lot over the years. What we're seeing now is during discovery, it's becoming easier and easier to build a real functioning prototype, via, you know, by coding AI tools, even if it's not great.
It's a way to allow you to walk through something tangible. Before that, Figma prototypes, design prototypes were very useful and they still are because you can sort of mock up a level of fidelity that you can't really get through a byte coding tool. creating a high fidelity prototype is often very useful. But I would say in general, the output of a discovery is to have something that helps you
Eric Lawrence (08:26.147)
Mm-hmm.
Zach Bruno (08:37.502)
frame the product in your own mind for your team to understand, but also something that you can use to pass to customers and get feedback or whoever the state, the core audience of the product is.
Eric Lawrence (08:49.251)
Yeah. And I'm interested to know, you know, you've been with the company for over eight years. How have the deliverables for, the discoveries that we do for clients? How, how has that evolved over time?
Zach Bruno (09:01.958)
Yeah. So when we first started out in discoveries, we were very much focused on building some, creating the documentation that allows us to plan and understand what to build better. like specing detail, you know, creating architecture diagrams, specing things out, user flow diagrams. But where we're seeing the discovery go is, you know, to mold more with what, what, you know, real product teams are doing.
outside of the service industry and where we want to assist in the actual iteration of the usage from the users and the feedback. And so what we're seeing is, like I said, getting the real prototype in the hands of real users is going to be the most valuable thing. But obviously it's a balance as well between planning what we need as a team to build the product and actually getting feedback from real users.
Eric Lawrence (09:58.84)
Yeah, I know that there was like a phase where OO UX object oriented user experience was really big where you could basically go in and, you know, holistically look at what are all the pieces that are going to go into an application or a piece of software and how do they all interact with one another? I feel like I haven't been hearing quite as much about that. Is there kind of a reason behind it?
Zach Bruno (10:25.081)
It's one method. Yes, we sort of had as part of our standard practice. But what we found is when you keep your processes too rigid, it sort of doesn't allow you to morph and mold to the product needs. So there's still a place for object oriented user experience, is what that stands for. OOUX is what that stands for. And so however we're mapping user experience doesn't matter too much. It really depends on the product and the client needs and the user needs. But in most cases, we're
we are still mapping some version of the data flow and the high level objects in the system, which is what the goal of object-oriented UX is.
Eric Lawrence (11:02.549)
Okay. All right. That makes sense. So it's, more just a case by case scenario. Got it. So my next question, this comes from the background of you having led discovery for projects ranging anywhere from startups all the way to enterprise. What are some real examples where strong discovery completely changed the direction or outcome of a product?
Zach Bruno (11:27.686)
Yeah. So in most cases, like I said, skipping the discovery is a mistake, which is the purpose and the topic of this episode. And so we have, with that said, we've learned the lesson. We've done it before. Right. So we've built products where we've skipped the discovery, sort of went straight into design and building it. And what we found is for one, we were less aligned when we actually went to build it. And for two, the product itself turned out to be overbuilt.
So in almost every case in the real world, whenever we do discovery, it turns out that the product we build is more refined and the team is more aligned on what we're building and why, especially the why from the beginning so that we don't run into those issues further down the line throughout the engineering process.
Eric Lawrence (12:19.223)
Hmm. Makes sense. And is there such a thing when you get into the discovery phase as like having too many cooks in the kitchen, as far as like when you're having these discovery meetings with, with clients and you know, they're, they're obviously going to be stakeholders on the call, trying to dictate what they want out of the product. Have you run into that where you would say there's too many cooks in the kitchen?
Zach Bruno (12:42.95)
Yeah, yeah, a hundred percent. So to the nature of our discoveries and the way we structure them, we are essentially the design engineering team and product management team, but our clients are usually the, what you would consider the product manager for their company. And so it's helpful to have one point of contact from our perspective to communicate with our clients and people we work with and our partners. if we know there's a case where, if we need to talk to other stakeholders, we set up meetings to.
go through their workflows and stuff like that makes total sense. But on a regular basis, communicating with more than one state, more than one point of contact is going to create downstream communication issues that we, in most cases you want to avoid.
Eric Lawrence (13:25.783)
Yeah, that makes sense. know from experience having one person on a client side that owns the project that is the main point of contact is usually going to allow for us to have kind of the smoothest process to be able to get from point A, which is to start the start of it to the end point B as quickly as possible.
Zach Bruno (13:47.623)
That's exactly right.
Eric Lawrence (13:49.24)
Yeah, great. I know we spoke a little bit about validation. What would you say? Like how can a team measure whether their discovery phase was actually successful? I'm talking about like what signs or metrics should they look for before moving into build mode?
Zach Bruno (14:06.715)
Yep. So that's a great question. Basically going back to sort of the two parts of the discovery alignment with what we're building and why. So the internal things that we need, but also the external thing, the internal things we were looking for is alignment on the purpose of the product, what we're building that aligns with the purpose of the product and that everyone's confident with the plan to build it. And so in our, in the case of our process, we are going to go into
the design phase, knowing that what we're designing is useful and makes sense and that the users need it before we even get into the engineering and actual build of the product. And then looking to the external validation part, what you're looking for is, like I said before, of making sure that the solution that you laid out and validated in the discovery solves the problem. And so when you get confirmation on that via observation of the users going through the prototypes or
direct feedback from the users, that's when you know you're in a good spot to move forward. And like I said, because it's a prototype, you might not necessarily know if people are to pay for it just yet, but by observation and by direct user feedback, you can get a good sense of that.
Eric Lawrence (15:21.793)
Yeah. And it's, always a good chance to, get your community excited about it because I know a lot of times our clients have a little bit of community rallied behind them that they've got to at least follow along in their journey. And once you get that, that prototype, you can share it with them so that they can get a sense of how it feels and looks.
Zach Bruno (15:41.391)
Exactly.
Eric Lawrence (15:43.744)
Awesome. Well, I really only have, you know, a couple other questions for you. you know, one of the last questions is from experience founders often push back on discovery because of time or cost. What, what's your advice to those who think discovery is just extra paperwork.
Zach Bruno (16:03.15)
Yeah, the discovery is so important that everything that comes after it is almost doesn't matter. It almost doesn't matter if it's not completed. So like I said, if you want to build a product and you're considering receiving the discovery, it's almost better to just not build the product because what you're going to build will most likely end up being a waste of time and money. So we want to avoid that. Right. And so we do that by meticulous planning and also
validation like we said before and Discovery being just you know a checklist or paperwork is I would say the right approach the right mentality bomb you know for the discovery is to think of it as sort of an ongoing process of making sure you don't waste time and money so yes it's a little bit of money and time upfront but it's worth it in the you know so you don't waste more downstream
Eric Lawrence (16:56.705)
Hmm. That makes sense. And I'm interested to know like from your perspective, know, you, you have a lot of experience doing this. If you were to set off on your own and build a product by yourself, know, realistically, how far do you think you could get in that journey before you would have to maybe loop in somebody else? Or do you think since you've been doing this for so long, you could, you could get to the place where you have a fully built final product.
Zach Bruno (17:24.868)
Yeah. So sort of depends on how technically you are. Right. But, I actually do do this, you know, on the side, just for fun, like I'll build little apps and stuff and get it to like friends and family to like test it out. And that's sort of, my own little way of validating products. And, know, I'm big in like the fitness space. So, I created like a nutrition app and, I'm actually working on a little, strength training app to track your strength training workouts and stuff like that. So,
Eric Lawrence (17:42.648)
Mm-hmm.
Zach Bruno (17:52.675)
Just, you know, I sort of have hands-on experience doing it every day, but part of those projects are also me learning to use like five coding tools and also agentic coding tools. So yeah, I think the big part is, like I said, if I were to take those products to the next level, the first thing I would do is get it in the hands of real users who actually could benefit from the product and do that iteratively until I'm confident that what I'm giving them solves their real problems. Once their problems are validated,
the solution is validated, that it solves their problems, then you can actually start trying to charge for it and seeing if people are willing to pay for it.
Eric Lawrence (18:30.327)
That's impressive. I would not say that I'm in any sort of technical ability to build a product myself, although I will say with things like lovable, it's becoming more more realistic each day.
Zach Bruno (18:42.969)
Yeah, I think what we're finding is I think sort of where the industry is going as a whole as well. The MVP stage, the early validation stage is going to become a lot simpler for people to do. Let's take Lovable, for example. It's not, we were already seeing some clients, you know, build an MVP with Lovable. And I'm talking about a very, very early MVP, validate the product, you know, to some degree, and then come to us for like the sort of full build out.
product build out now that it's been validated. So, you know, what we're seeing is like custom work is becoming more bespoke in that we want to create a really refined and custom user experience that Bob coding and agentic tools can't deliver on. But always, you know, if, you want to do discovery, right, you know, we're always here to do that as well.
Eric Lawrence (19:32.792)
Yeah. Well, I'm, I'm interested in that theory, where I agree it's, it's a lot easier to build MVPs, but I wonder if there's almost kind of these, these two sides to it where you have the haves and the have-nots, you have like the fully built really nice polished applications. And then you just have a flood of vibe coded apps where if somebody is trying to get validation,
Are they really putting their best foot forward with that? Can a vibe coded app be good enough that people are basically saying, hey, this is great. And somebody gets that validation that they need to say, okay, now I should really build the legit thing that's going to be scalable for the next decade plus.
Zach Bruno (20:16.993)
Yeah, yeah, and that sort of depends on what stage you're at, right? So would say that if you're like day zero or trying to go zero to one, you have nothing, you have no users, have absolutely, you're starting from a clean slate. I would say that it could definitely work to get your first initial users on there, try it out. And then from that point, when it's like, okay, I have something here, you would probably wanna start building something better, right? Like via custom development or whatever it is to.
You don't want to turn your people away that you're starting to get traction from because your product isn't good and not scalable and all that good stuff. So as soon as you know that it's something you want to deliver on, that's when it's time to build the real thing and build something scalable.
Eric Lawrence (21:01.291)
Yeah. In that aha moment where you say, have something here. that a matter of thousand users? I guess it depends on what the product is and what you're trying to do, but yeah, I'm not sure if there's a good, like consistent benchmark for a lot of our listeners who are going through this journey where they'd say, like, I feel like I'm on that fringe, but I'm not really sure to know when that, that transitional moment is.
Zach Bruno (21:09.975)
Yeah.
Zach Bruno (21:27.499)
Yep. I would say that it depends on one thing specifically. If you are the audience. So there's sort of two products you can build. can build a product that solves a pain point that you have. So you are the audience or you can build a product that solves a market need. If you're solving a market need, it's going to take longer to validate it. If you're so, if you are the audience and you're solving your own problem, you can start on that right away because you know the problems, you know, works right. obviously
Eric Lawrence (21:52.77)
Right.
Zach Bruno (21:53.792)
The goal is to find a group or community of people who share that problem with you so that you can validate with them and help them maybe even build a product with them. Building with users is very useful, but you know, going down that path, you can probably start the full product development much sooner as you're a little bit more sure of the direction that you're solving a marketing that you don't have experience in or you're not the audience. It might take a little bit longer to get to that point, but the sooner you do it,
The sooner you build the full product and the scalable product, the better of an impression you'll make on your end user base when you do attract the right audience.
Eric Lawrence (22:32.983)
Hmm. That makes sense. And yeah, that's, that's a smart way to look at it. So final question for you, Zach, looking ahead, how do you see discovery evolving with AI user research, automation and product analytics tools? And what should teams start doing now to stay ahead?
Zach Bruno (22:50.976)
Yeah. So I think product discovery with AI tools is going to be a much more hands-on process and in a good way. using AI to rapid prototype, build up functional, practical application that people can use, even if it's a part of a, an existing product, building, the new feature even as a, its own little separate prototype that you can validate before you go off and build the full scalable product. There's going be super useful.
Because it's important for people to know that discovery is a never ending process. You plan in the beginning of any zero to one product that you're trying to get off the ground. But as you're building, you won't need to keep validating and keep the discovery loop going. Otherwise, what ends up happening is you plan and build things that again, that you don't need, right? So the discovery is always critical. And as long as you keep iterating and validating the future stuff you want to build as well, you're to be in good hands.
With AI, it's just going to be that much easier.
Eric Lawrence (23:51.521)
Yeah, I think AI is completely changing the game. So makes a lot of sense. And yeah, I appreciate you jumping on this, Zach. I will say to the listeners, if you are going through this phase yourself, we actually have something that we can provide to you guys for free. that would help you in your own journey. We've put together a product requirements document. and this is something that our team uses when we go through the process of, you know, validation coming up with the right ideas for a product.
So just reach out to me directly or through our company website. If you would like for us to share that with you, we'd be more than happy to pass it your way and provide any advice as you get into the planning. But again, Zach, thank you for the time today. Hopefully everybody's come away a little bit more informed on how they should be approaching that discovery phase.
Zach Bruno (24:45.545)
Yeah, thanks for having me. Always a fun time.
Eric Lawrence (24:48.279)
All right, well this is Eric Lawrence signing off from Tales from the Pros. All right, have a good day everyone.