speaker-0: good product manager will look at if you have a glass of water that's half full, a good product manager and and the person that comes to you with the glass of water that's half full says, Hey, I need you to pour more water in this. I need I need more water in the cup. Fit can you fill up the cup? And a bad PM, a PM that's young and early in their career and doesn't really have a look around the corner type mindset will grab a glass of the pitcher and fill up the water. A good PM will look at the glass and say, is that actually the right glass for what you're using it for? Or do you actually have enough water and you just need it in a sports bottle because you're going to be running and or do you need it for something else? Because if I fill up that glass and then you're going to go and take it running, you're going to spill it everywhere. And so like product, good product doesn't meet people where they ask. It looks underneath the ask at what the actual problem and use case is that you're building for. And then we attack the use case rather than the surface level or screwed up solution.
speaker-1: Break up, bring the
speaker-0: All right, welcome back to Proper Precon. I'm Troy Simon along with Trey Darnell. ⁓ Trey, on this show we've talked a lot about just pre-construction as a craft. ⁓ we talk about judgment, context, communication, relationships, all that good stuff. Trust, a big one. We touched on that a couple weeks ago as well, behind the number. Today we're gonna take a bit of a different look at pre-construction from s you know, a slightly different angle. We're gonna talk about product, but not product maybe in the sense of like a sales pitch or features or buttons or anything like that, but more more about product as a discipline, how good products get built, how product people understand industry problems, what it takes to create ⁓ those products and actually help pre-construction move forward.
speaker-2: Yeah, and I I think it's an important conversation just because the industry's seen a lot of different software over the years and you know, it tends to help digitize things initially, but then after that it's like, well, what does it leave you with? And it doesn't always help you work better. So I think that that difference usually comes down to whether people are building the product actually understand the work, right? The prec like pre construction that we're speaking to specifically, not just the math, not just cost data. It's like how do we connect those that cost story? ⁓ and so assumption, scopes, risk, communication. Owner expectations, design talent, trade feedback, all those things are part of how we do pre-con, right? So if you're building a a product for precon, you have to respect the crap.
speaker-0: Yeah. I mean, and that's why I was excited to hear what today's episode was a few days back when we ⁓ got it planned, actually. So we're joined by Eric, ⁓ our director of product here at Edify. Eric spends a lot of time listening to customers, understanding those the workflows and challenges that they're having ⁓ with their current solutions, working with engineering and and design teams here at Edify and helping translate those things into real product decisions. So converting that pain into what we hope is going to be a fantastic solution. So Eric, without further ado, welcome to the show. Thank you for being here today. Of course. Glad to be here. Good to listen to the sun. It's worth it.
speaker-2: That's right, yeah. As Troy said, top ten hit.
speaker-0: It it's confusing why it's not on the top ten yet, but we'll s we'll remember.
speaker-2: We'll get there. Yeah, so so Eric, let's start with your background before we get deep into the pre construction piece. Tell us a bit about your path into product. How'd you end up in this role? And kind of what shaped the way you think about building software.
speaker-0: Yeah. So I I went to school actually for construction. I got my ⁓ bachelor's in construction management at Cal Poly Slow. So I I studied construction and I was fully expecting to go into the G C industry and ⁓ you know, be a builder and out of Cal Poly started working in the field for a little bit and found better fit in the estimating role. ⁓ was there for a little while, but they've always been my people, but I've wanted to make an impact in a different way. And not not just bidding work, not just pricing that, but like actually tangibly like something grander than that. So technology has always been a means to achieve high impact. And that's where I started to look. So I started to look at ⁓ how do I get into tech? And the jump from I'm an estimator to I want to be in tech is one that A lot of recruiters don't understand. And so I ⁓ I had to get strategic in how I make that jump. So I actually I went on LinkedIn and I messaged every single product manager in Procor. ⁓ and one of them reached out to me and was like, Hey, I'll I'll chat with you. So I chatted with them because I had done a ton of startup competitions and naturally product was kind of where I I had gone I'd naturally fit in and I was really good at it. So ⁓ chat with them for a while and they recommended me. So that's how I got into Procore. And I started at Procore in I think it was 2017. ⁓ and from there, like started working really closely with software teams actually as a QA where we're hyper focused on quality and making sure that what we release is good and meets the needs of users and worked really closely with their product manager at the time. in basically treating quality like a product. And ⁓ that seamlessly transitioned into a product role at Procore across ⁓ Procore Financial. So I spent a lot of time on the budget, change management, ⁓ just across the board. ⁓ worked on the if you've ever gone into Procore and added a line item anywhere in financials, that was my team. Just across the board of Procore. That was a great experience. Learned a lot and then from there went on to a maintenance app, ⁓ maintenance product where it's called upkeep, ⁓ and at upkeep, they look at kind of the end of construction when the actual keys have been handed off. ⁓ there's actual maintenance to be done on the building. And so a lot of work orders. ⁓ in that flow it was super exciting because we were building for two different personas solving the same problem, which was really unique. ⁓ You have a technician on the floor that some of them are not the most tech savvy. And you have an admin in the web who is extremely tech savvy and needs lot of detail. How do you solve a problem for somebody that doesn't really know how to work an iPhone and capture data in a means and method that is detailed and accurate so that you can extract value for it for the admin role to be able to then feed back into. technician role. So that was a really unique problem set where we solved problems cross platform. And I got my feet wet in that in in mobile development and and all that. Took that one to box ⁓ and spent some time in the corporate world in box. ⁓ and then w I was in their mobile I was their mobile product manager and then from there came down if I ⁓ so fully full circle ⁓ in terms of setting construction, being in construction, now building for construction, which is pretty cool. That's wild. That's interesting. I didn't I didn't know some of that background of you. I'd like to talk to you more about those competitions. That's pretty cool. ⁓ I mean not today, ca we got so much to go through, but ⁓ that that was that's that's great stuff. When you when you think about like great product work, what do you think people might misunderstand, you know, about about that role, whether it's a product manager or even something like you where you're sort of leading the product management teams. Because from the outside I think people maybe they just think product is just kind of deciding on features, you know, maybe what to build next. ⁓ I think it goes deeper than that. I mean, what what do you say about that? I think it goes way deeper than that. ⁓ if we built what everybody told us to build, we would not have the product we have today. you you don't solve problems at the prescriptive layer. You solve problems digging beneath that. So like a really good ⁓ VP product that I I had at Procor w told me in The time I was like, I don't know if I understand that. And then over time I've been like, okay, that's actually a really good analogy. He said a good product manager will look at if you have a glass of water that's half full, a good product manager, and and the person that comes to you with the glass of water that's half full says, Hey, I need you to pour more water in this. I need, I need more water in the cup. Can you fill up the cup? At a bad PM. a PM that's young and early in their career and doesn't really have a look around the corner type mindset will grab a glass of the pitcher and fill up the water. A good PM will look at the glass and say, is that actually the right glass for what you're using it for? Or do you actually have enough water and do you just need it in a sports bottle because you're going to be running and or do you need it for something else? Because if I fill up that glass and then you're going to go and take it running, you're going to spill it everywhere. And so like Product, good product doesn't meet people where they ask. It looks underneath the ask at what the actual problem and use case is that you're building for. And then we attack the use case rather than the surface level or scare drive solution. And sometimes they're the same, but yeah, often they're not.
speaker-2: I love that ⁓ it kind of makes you think of like function and form. Like form kind of seems superficial. You see the form on the top level, like I need that thing, and then functions like the underlying value that the utility that the thing provides. That's that's awesome. So I I and I do think that we hear a lot of like, Well, I just I need this button or I need this report or I need this thing. And there is typically a deeper understanding that you have to dig into ⁓ to separate that literal feature request from the actual problem the customer's trying to solve. And And frankly, I think you're very good at that. Like I've been on plenty of calls with you where you're like, you're very curious. And you're like, well, what what is what's the intended outcome? Like, what do you anticipate? What do you expect here? Like, what are you trying to get to? Because part of the problem is if they just say, I need this button, right? If you give them that button, you might just be giving them the same thing they already have. You're saying, Well, there might be something else you're after here. I can give you not just the button, but the thing that actually gives you. tenfold what you're asking for, which is a much more valuable conversation.
speaker-0: I mean, I've plenty of examples even being here of that, where like even in the the milestones of metadata work that we'd done. we were asked numerous times at a solution level to just build what they have, right? Like build build the the the the classic workflow, right, is ⁓ I do a cost model, I filter off of all these properties of a project, I go through, I estimate it. those properties then get benchmarked with the estimate for future data. Hey, our form is usually, you know, a hundred and fifty question long questionnaire that we require estimators to go and fill out at the end of an estimate. And if they don't fill it out, then there's X, Y, Z repercussion. ⁓ they have to fill it out. ⁓ but there's no way for us to enforce it. So can you build the same thing with an Edify so that they can enforce it? Well, if we do that, you're gonna have the same problem. And so like when we when we started digging at that, what we were digging at is, do people even do it? Like e yeah, you've created a form and there's a hundred and fifty questions, but do people actually fill in a hundred and fifty questions? And the overwhelming response and answer was no, they don't because you're asking the question at the wrong time. And if you can ask the question when you're actually building out the estimate per milestone and you can actually ask it in context. You're capturing the same information with the same output that you're trying to achieve with the prescriptive solution that you've already built to solve it because you've had to solve it that way. But if we just go and build that, we're gonna build it wrong. And you're gonna just have the exact same problem, just with a different UX in in our product.
speaker-2: Yeah, for sure. And that's like the impact piece is you're not really impacting an industry if all we're doing is reinventing the wheel. We wanna we wanna blow the wheel up. We wanna give you, you know, something better to actually use in the first place, not a you know, twenty, thirty, forty year old tool. We're not making it look like MS DOS.
speaker-0: Yeah. There's a lot of things ⁓ that maybe make pre construction ⁓ different. I was curious, given the r the trip you've taken from estimator to, you know, quality assurance, I think it was, the change in management to to what was it, box and and then you know, back here to edify. People outside the industry may look at say, I wanna do an estimate and they're thinking, Well, you know, they're counting things and we all know there's a lot more, as you just described, like maybe underneath the hood of what's really happening. As you made that journey, was there anything that stood out to you maybe that's that's helped you in this role that says, hey, pre-construction teams, they work differently than this maybe other way we might build software for, or is there just a lot of similarities? It's a similar template. It's a different answer than the template. Like the the template being you have to understand your users and you have to build for the users and the problems that they have in order to like Edify has a genuine opportunity here to disrupt an industry. Like truly, and AI unlocks the box for everything that people have ever wanted with historical data. And Edify is just sitting on a gold mine. and you have to know who you're building for and the root of the root of the root of the root of the problem that they have, so that you can build a solution that feels good. Like Musk is famously quoted for like saying the machine that builds the machine is vastly more complex. Than the actual like output of the machine. So like the thing that builds the car is so much more complicated to construct than the car, right? Cause you have to think through literally everything and anticipate everything. And if you get it one degree off, you're wrong. And if you're wrong, I say this with Dustin all the time if you're 1% off, you're 100% off. You might as well just not build. So it has to be, especially in the space, knowing your users, there is no margin for error. It has to be perfect. It has to work perfectly. ⁓ and so anticipating those needs can be really challenging. But our milestones project is a good example of that of like we had to build the machine that houses the machine in order to make sure, like when we were building milestones, we weren't focused on milestones. We were actually looking at trend line and backing into how we need to build milestones to make trend line happen. And that is way more difficult. than being like, hey, how do you set a milestone on an estimate? It's so much more it's so much deeper to the And that's why we have things like the design stage layer, ⁓ with the milestones that are free form tech. So you have flexibility that rolls into structure and like there there's just you keep pulling the thread and the thread and the thread. I think a lot of those learnings from previous companies around how the same problem can be solved in many different ways is very similar here.
speaker-2: I think that's where free con can be hard to build for because, you know, the work's not just task based. It's it's so much judgment based. I mean, th there's information defined on the drawings for sure, but even there's judgment applied to those things because there's information not on the drawings, right? ⁓ and so an SRM may make a decision based on the drawings, but or based on what they know about the owner or the architect or the market or the trade base, like whatever it is for that phase of design. Yep. ⁓ so when so when you think about building a product for that kind of work, how do you make sure the product supports the judgment instead of trying to replace it. 'Cause you kinda you said the A word, you said AI a minute ago, right? So let's just go ahead and go down that rabbit hole.
speaker-0: ⁓ yeah. So I I think you know, we just hired an an amazing ⁓ AI PM to to kind of help take us on this journey. And and one of the things that I've been talking about with him specifically is that like there's two routes for AI. There's a gentic and then there's intelligent. And both routes will be explored a hundred percent, but The question is when do you explore one over the other and how do you explore each that they complement each other? And like to your point, Trey, I don't think Edify will ever be a at a point, nor should it, where it says, this is what this costs. That's too bold. But what it can say is, hey, we have the cost model, we have the project, we have all of the data through all the milestones and how cost has evolved over time. We have what you bought it out for. We have that entire A-Z workflow, all housed within a project object that has metadata on it, attributes on it, area sheets, rooms, units, et cetera, that completely and entirely categorize the what of that project. And they give it its basis for cost. Today, that is that funnel is brought to a point with a ton of filtering and a ton of. Senior knowledge when you go into cost model, where the most senior people are the ones that are typically building the cost model, that are typically having these conversations, finding projects of like kind, pulling from those benchmarks, isolating the risks, knowing what to account for, knowing what to avoid and what not to avoid, which styles to turn and which ones not. We have all that data. So like we can elevate those insights so that we don't need a substantial expertise to be able to create what once required a substantial expertise. And we can bring in the insight of GMP level cost at conceptual stage design to help you make better decisions, because that never before has that been on the same platform. So like that's the intelligent piece. Then there's the agentic piece. And I think AI in general, when we go down the agentic road, I think you can Throw people into the future too quickly. I think you definitely can. I think you have to meet where they're at, show them what the future is, and then take them into the future. In that agentic flow, if you jump too soon and too aggressively, you lose trust. But if you build trust along the way and you can make things, there's things within agentic flows like human in the loop, always making sure, like we're not going to go build your estimate, but we're going to
speaker-2: That's right.
speaker-0: look at your plans and specs and suggest what could be pulled into it. And then you choose. Right. We're taking your workflow that may have taken two hours and we're condensing it down to twenty minutes. Like there are things like that where I think it's very much so feasible in today's world. And who knows with AI? AI in a year from now may be in a completely different spot where it really does get into the more dramatic abuse cases. But right now, like I think you got to put your foot in the water before your whole body jumps in. Yeah. I think a lot of people when AI really started to go mainstream over the past what twelve, eighteen months that people were like this fever around it, right? ⁓ people were looking at as a way to replace tasks and things like that. But I like that approach where the more intelligent it's really coming alongside and helping them make those decisions better, faster, quicker, not make the decision for them. I think that's a like an important point because the technology can either respect the craft or or flatten it, you know? Yep. And and and when it flattens it, a user's gonna feel that that pretty quickly. And so they'll know was, hey, this I don't know if these people really understand the way I do work or not. ⁓ you know, so it's you gotta go at at the right pace. I think you guys are making, you know, some great decisions there. I mean, i it y I feel like you kind of already answered this, but I'm gonna ask it anyway. Are they looking at it from your from your director's spot there and as you're, you know, managing a team and looking forward, are there certain signals that maybe you've learned along the way that can that sort of signals that hey this product team actually understands its users. I mean the biggest signals I've gotten have been well one, I would say of any product team I've ever worked with in my entire career, this product team is the most talented and the most customer centric and problem oriented that I've ever worked with. So we have we have a best in class, 100% exceptional tier of product managers here, ⁓ which is Makes my job easier. But ⁓ that is hard to find. There are a lot of people that are PMs and I would say it maybe controversial, but I would say less than five percent are probably legitimately good at their job. ⁓ because a lot will meet customers exactly where they're at and the prescriptive layer they won't look beneath. And looking beneath really challenging, either have that way of thinking or you don't. And so like in interviews and stuff, that's what we look for is that way of thinking is like the r underlying root. And I think proof, the proof is in the pudding. And the pudding is every time we talk with customers, every time we hear from customers, there's such alignment across what we're doing and where they need us to go. And like you look at things like advancing pre-con, which Trey, I know you've been there a ton. Like we get such strong resounding feedback that is almost entirely aligned with where we're headed. Which is so exciting that like you can take quantitative or qualitative feedback. So an interview here, an interview there. And advancing pre-con actually makes that quantitative because it takes the qualitative and you're talking to now a thousand people. So you're starting to get really good trend on the market. And it's so clear where the market's headed. The market is headed in the exact same direction we're headed, but they're not able to get there by themselves because they don't have all the data. That's why I say Edify is in such a unique position, truly disrupt, because we actually have the data. A lot of people say they want to do X or Z Y or Z, but they can't. Or they'll or they'll take a crack at it, they'll s it as it does that, but it's not actually doing that. It's looking at one piece of the puzzle, not the entire picture.
speaker-2: Yeah, I'm there. So A, I'm I'm wondering what the flavor of edify pudding tastes like now. So we gotta figure that out. ⁓ I bet it would be delicious. I can already see the colors, but it'll be delicious. but that does kind of lead us to this idea of like built with builders because I know you do interview customers and prospects and we get industry feedback and and you know this We've kind of titled this episode Built with Builders, the Product Side of Precon. And the phrase matters to us because we don't believe products should be built in a vacuum. It should be built with people doing the work. ⁓ there's when I was at Plan Grid, we had s there's some kind of network like ⁓ like Builders Network or something. But I love the width component of this because it actually creates this kind of this this idea of partnering, not like across the table, but like on the same side, going towards a common goal. You know, we're not just taking feature requests and building exactly what someone asked for, but how do you think about that balance between listening closely to customers' prospects and still being responsible for shaping the right product direction?
speaker-0: It's a good question. And it's one of the hardest tensions in product is there are some feature requests where you actually do need to meet people where they're at right now. And you can't wait for the future. And like the hardest part of my job is identifying when it's that case and when it's the case of, well, yes, but what we're building is actually fundamentally broken. And We're not gonna build a broken workflow. We're actually fixing it in this way. So like there's just there's a ton of examples of like w places where We could build something some way to help unlock right now, but in doing so, that actually incurs a ton of debt and like takes the disruption that pre-con needs and kicks the can. So like here here's an example. We're talking about this literally right now, actually, is variance reports. We have in-app variance reports that are exportable and in that they're Excel and you can add notes and The side because it's Excel, it's fully customizable, but we're bringing them in app. And that is coming very soon. As a as a means of that, we're also looking at a ton of different AI use cases and where AI can help, like I was saying, provide the insight around this stuff. And we have we're kind of at a crossroads right now where we can either build in like notes in app on a variance report, or we can wait a little while. And build in an actual intelligent aggregation of everything into a summary using AI where you're solving the same problem. But then the industry's had to solve this with Excel. They've had to solve this with text because they've been stuck in that way. They haven't had this data to be able to bring that insight. We have everything. We have the lineadings, we have the estimates, the milestones, what changed, what didn't change. So there's so much. Greater depth of insight. And like, will we add notes in app to variance reports? Possibly. Like we're open to feedback. We'll we'll iterate and tweak that as we need. But doing that, let's say we do do that. Now comes the question of, okay, well, now we're going to start work on insights on variance reports via AI insights. What do you do with the notes that people have already left? How do you migrate those? Do you migrate those? That what if they were in conflict? Like, should you be able to manually capture? So now you're slowing down innovation in the future because you built for today. And like that is a really challenging trade off to weigh because that's that trade off not only has like user friction challenges, but it also has challenges technically. We're like, we're slowing out the actual building of these things. So that the future is coming to you slower, which in some cases is very much so needed and wanted. ⁓ but in other cases, again, it's just give or take. It depends. You mentioned the word tension. I I f I find that to be a perfect ⁓ that was a perfect word really for for what you described. I mean, because customers, they're experts in their pain. They know what the friction is. They know what slows them down. They know what creates risk. But you guys the product team, you you have to take that pain, figure out the pattern, then figure out what the scalable solution's gonna be for it. So how do you know when you get that one off, when something's maybe a one off request versus a bigger industry problem that's worth solving? 'Cause like you said, you can't build everything. And if you build build it now, it could be a lot of debt that is the cause of that for the future. So how do you distill that down and say, that's a great idea, but that's not the industry problem that we have to solve for today or for tomorrow? That's where my role comes in pretty heavily, which is you have to have a direction. You have to know where you're headed. And I I think a lot of companies, ⁓ the failure state of a lot of companies, they don't have enough conviction on where they're headed. And there's not that conviction is rooted in idea. It's not rooted in real. genuine problem. so like our strategy is very rooted in problem. It's very rooted in real, genuine pain that we're thinking far bigger than just an estimator. We're thinking pre-construction. We're thinking grand. And when we look at that and the opportunity space that Edify has to change that and genuinely disrupt that, if you know where you're going. And you know where the those like longer term problems are that you're headed to solve, there's going to be feature requests along the way. And some of the feature requests are small and isolated. And for that, we do things like, okay, what's the impact versus the level of effort versus the cost? Like it the impact, high. Level of effort low. Okay, that's attractive. But the cost of this and the debt of this that this will create, extremely high. Okay, less attractive to to go. It's a balance between taking people on a journey but not forgetting that, but not abandoning them in where they're at today. So like there is a tension in terms of ⁓ honestly milestones as a great example. The project took us a year. It was a very, very, very, very large project. And there were many times along the way where we were questioned and we were like, are we sure that we need to actually be building it? This structurally, this sound, this foundationally, to get to where we need to go. And the answer was always yes. Like we've we're rooted in the problem. This is the proper way to solve the problem. Now we've layered on trend line and it's like the industry had like blinders lifted off and they're like, ⁓ my God. Like I s now I see the value of putting everything in one spot, categorizing it all in the way that you did, but like you're gonna be questioned along the way. So like there were a lot of feature requests. That we've had to say no to in order to make that possible. A good example and something we're going to be doing soon is like our formula editor. There's a huge opportunity to improve that. Does that move the needle though on the vision that we're trying to achieve? Not really. But does it make it easier for estimators to do their day job? Yeah. So like there's a there's a tension there between, okay, we're gonna push that a little bit to pull the future forward, but we're not gonna forget about it. And we're gonna make X, Y, and Z improvement today to help make those the the key workflows and the really challenging things that estimators experience today easier so that we can almost like let a little steam out of the kettle, but we're not just opening the kettle. Does that make sense?
speaker-2: That's almost like it's almost like you know you're on the proper precon podcast right now. You're using all the words.
speaker-0: This is the proper development podcast today. Right. Like full this is some good stuff.
speaker-2: This is why Yeah, I I I like that a ton. ⁓ it's like that's that's where good p good product people really move the needle for an industry. You're you're not asking like what can we ship. You're asking, you know, what problems are we solving, ⁓ who are we solving for and what does it actually what does it actually make work better at the end of the day. So from that standpoint and actually because of your background too, because I I look back like I'm also, you know, ⁓ construction ⁓ science ⁓ major as well. Like You came from that and now you're a product, you came into tech. Like from that standpoint, what are the best qualities of product people who can actually move an industry forward? Because I would say that you you took a leap of faith and were trying to get into tech coming from the construction side. I I did a similar thing, right? And that doesn't mean you're necessarily looking for the stereotypical product things that you might look for in other businesses.
speaker-0: In terms of the question you're asking, in terms of like the people that we bring on, like what do I look for in people?
speaker-2: That's right. Yeah.
speaker-0: The ability to translate. Like that me saying I think five percent of PMs genuinely are like highly talented. Like PMs are are I am of the opinion that when you see a good PM, you jump on that immediately. Like there's no it's like walking down the street and finding gold on the ground. You don't walk past it and say, ⁓ I'll go pick that up later. You're like, No, no, no, I'm gonna grab that right now because there's not a lot of gold on the street. ⁓ it is really, really hard to find PMs. I honestly a the example I just gave, milestones versus formula editor, ninety-five percent of PMs would have built the formula editor. Ninety-five percent. And they would have built it exactly as users want. But that doesn't always set you up to where you need to go. Right. Like you you need to see beneath that. You need to see not only beneath that in the sense of that one use case of a formula editor, which ⁓ I don't disagree. It would be super nice to have like People need this. People want this. I want it too. But if we try and build everything, we're going to build 20% of everything and a hundred percent of nothing. And that's not going to solve anyone's problem. So we have to be laser focused on what we want to achieve while again not ignoring the use cases and pain that people have today. ⁓ so yeah, I I look for people that can see around the corner when we when we do interviews for PMs. I don't want Somebody that's gonna say, ⁓ like, yeah, this is how I'd solve that. You miss the point. What's the problem that you're actually looking at? And like, if I tell you I need more water, are you gonna pour more water in the glass? Or are you gonna question why I need more water and what the use case is for me drinking that water so that you can re-question if that glass is even the right glass? Because the answer might be, ⁓ I need to pour more water in the glass. But oftentimes it's actually not. Oftentimes it's actually I think I need more water is what the user's saying. And the PM needs to look at that and say, I think you don't. I think you you if you d if I gave you more water, you would be really thirsty because you'd start running and all the water would fall out of your glass. So I think this solution would solve that need. And what's interesting is when we then go back and we show those solutions to users, there's almost always a light hold moment where they go, ⁓ shit, you're right. Like but but people haven't been forced to think that way. You have to beat them to it and then show them what it looks like.
speaker-2: Yeah. I know from my side, like your your only wish is that I don't go out and say, Hey, I'm gonna sell you this thing that we don't have. Yeah, please don't do that.
speaker-0: 'Cause everything I just talked about gets lit on fire.
speaker-2: Yeah. Yeah. That's then that's and and I like we work very well together in that in that sense, right? Like on the sales side, we don't like we don't you don't sell roadmap, you don't drop the candy in the lobby, we like this not how we operate, right? Now we wanna help solve problems too. But Troy, I think like we probably should talk about that piece of it 'cause I think it's really important.
speaker-0: Well and one thing before I jump in there, I I do you have, Eric, and you don't have to share it, I guess, completely, but you talk a lot about being laser focused and we have certain things obviously that we're working towards. Is there like when you think about Edify of the industry challenge we're trying to solve with that with this software and all of the different users that will eventually be able to collaborate and use this tool within each of those But we're talking about trade partners or general contractors or owners and developers. Each of those will have maybe a laser focused set of things that we need to add to the solution for their individual use case. But what's the big overarching vision that we're laser focused on with Edify? Yeah. The general flow that we have and where our strategy is kind of anchored on is if you look at the new world, like You can't look at our strategy without evaluating the current world that we live in today, which is we have a new tool set at our disposal that has the ability to comb mass, mass data sets and elevate insights. And what we're seeing over and over again, not just in construction tech, but across the board, is the winners in this in in any space right now are those that house the data. Those that house the data, I mean, look at like the full self driving race that Tesla's having. They're able to train off of that data. They're able to learn every edge case that a car may go through versus a Waymo esque type solution is very data limited. There's only a certain amount of cars. They're not able to paint the entirety of the picture of what they need to achieve to then layer AI on top and actually learn from it and house those insights. So that's why like I think Edify is very uniquely positioned in that. And our key flow is to house that data. So, like this started this strategy, it's a multi-chapter strategy. And chapter one was actually when I started here almost three years ago, which was like, you can't tell me about the puzzle if you're missing puzzle pieces. So built puzzle pieces. So we built cost modeling. And then we filled in the puzzle piece, but then it's Yeah, but the whole blue, there's no picture. I don't know what data is categorized and what milestone and that matters a lot. So I can't draw that inside. Okay. So we built milestones. And then well, yeah, but then I can't learn from that puzzle because there's so much more data that's captured in my project. ⁓ that I'm not able to use the rooms and units tools and I'm not able to add metadata to it. So we redid the rooms tool, the units tool.
speaker-2: А за
speaker-0: We went through, we added project metadata. We're adding these fields to be able to tell a story. Then we layer on ⁓ cost trend line. And now we're in the next chapter of the strategy, which is a lot of the puzzle pieces have been filled for estimators. There are many different puzzles that we'll be solving for owners and architects and self-perform and all all of pre-construction, right? Yeah. But for estimators, a lot of those puzzles have been solved. And there's still some gaps like in contracting, and we're gonna be focused there and Filling that puzzle piece in, but by building the workflows and housing the data, we set ourselves up to layer and intelligence and fundamentally reshape how people work. And that's the core river that we're floating down, which is we've built the workflows, which is arguably the hardest part. We we've we've housed a connected platform, and a lot of people say they're connected platform, but they're not. We're truly a connected platform where every tool, every piece of data is in one spot within our product. And to be able to then layer in the intelligence allows you to fundamentally change the way that you work. We're not a tool now that meets you where you're at that makes your job easier. We're actually a tool now that becomes it's a risk to not use us. It's a risk, competitive risk to. not have the love the that insight layer because how you price a job is whether you win or lose that work. And if you can make intelligent, high quality decisions early on, our hypothesis is you can fundamentally flip the the industry on its head and bring those insights early on so that you're not starting a project in the negatives or starting a project with just landmines everywhere. ⁓ so that that is the the goal and the vision for for us. Yeah. Well that's that's amazing. And and Trey wanted to talk about trust and I know we gotta wrap it up, but I gotta feel that that's what you just described is is w how we're gonna build that trust. The industry's seen a lot of tools come and go. People have seen big promises from from tech companies in this industry, ⁓ long implementation that that didn't materialize materialize. They've got long implementation cycles, they've got clunky workflows. ⁓ tools that don't match, ⁓ they don't connect. From a product perspective, I I feel like what you're what you just described is how we earn trust with users. Trey, would you would you agree with that?
speaker-2: Yeah, I agree. And I mean, I I think you mentioned chapters. I think this is probably chapter one with Eric on this podcast. There's gonna be a chapter two because we are only skimming the surface for what we really wanna dig into more. but yeah, I think that builds the trust. and our goal is to highlight folks who don't only want the transaction, but want the relationship. ⁓ and I think it's one thing I love I love about you, Eric, is like You're not a transactional individual. You're a very relation driven person. ⁓ and you bring that into how you think about product and how you think about solving problems, which is to your point, these it's the four percent of like it's just good PMs, right? So super thankful that that you're here at Edify. ⁓ Troy, we we probably do need to do the fast five though next, just to kind of stay on stay on task and
speaker-0: Yeah, I think it's gotta be the last thing. We have to let Eric go 'cause we promised him five minutes and we have sixty seconds. So Rap Eric, this is fast five. No long explanations. It's five questions, just rapid fire answers, first thing that comes to your mind.
speaker-2: That's not. All right, ⁓ so feature requests, friend or foe. What's one product habit that creates bad software?
speaker-0: ⁓ friend. Not listening.
speaker-2: I think I could have just answered that one for you after today. I mean, even after working with you. Most underrated skill for a product person.
speaker-0: Listening.
speaker-2: Yeah. We're gonna shake these up next time. What is one thing construction software needs less of? Preach. All right. Finish this sentence. This is our permanent closer. The precontine that figures out blank will have a massive advantage in the next five years. Awesome.
speaker-0: Data. Awesome. Very good. Eric, thanks for ⁓ joining us today. We'll let you get out of here and ⁓ Trey and I will we'll wrap the episode up. But thank you so much for joining us. Of course. Thanks, guys. It's amazing. That was huge. ⁓ I mean, I knew Eric, but I felt like I know him like at a whole nother level after today. ⁓ I mean, there's just what what a great
speaker-2: Yeah, man, thanks for joining. See you later, buddy.
speaker-0: What a great hire. What a great decision by leadership and and Mike and Dustin to put him and Eric, you know, to put or ⁓ Eric, Zach, to put him, you know, in charge of of the product team. I mean, what that's that's that's a great what a great leader. He's got a great ⁓ skill set to fulfill that vision, you know, that that that the leadership team has built or, you know, pointing to for for Edify and and our users. So ⁓ trust is huge. What do you say?
speaker-2: Yeah, I agree. He he's he has the right mindset and it's people first. I mean, we we say the you the the tagline, right? Like people people process tech. It it's in that order on purpose. Now again, we at we're at Edify, we're at a tech company, but like leading with the people and process component of that ⁓ is is huge. And even talking about like built with builders, like that's that's something that stuck out very blatantly to me, it's like that's what he does. He wants to get on calls with product people. He wants other product managers to get on calls with product with with our customers and our prospects to like really understand thoroughly what the challenges are. ⁓ I just think the more time that you spend understanding those things, ⁓ the more powerful the solution's gonna be at the end of the day.
speaker-0: Mm-hmm. Yeah. I mean, he talks about, you know, building that that trust and ⁓ you know, it's not it's not gonna be you can't build it off just one you know, one f shiny release or whatever that you're doing, right? It's that it's that consistency and that more importantly, that laser focus that they have over time to commit 'cause I think that's where a lot of companies maybe fall short. And I don't even know it doesn't even have to be in product, right? And it doesn't even have to be a construction tech for that matter. I was talking to Dustin about this yesterday that a lot of times, you know, people are excited about an idea, they're excited about a direction, they're excited about a vision. Yeah. They get into that direction and vision and realize it's harder than they thought it was gonna be. Right? And so a lot of times we just bail and we we figure something else out. We we chase something that's newer, that's shinier, that might be easier. And sometimes the hard thing to do is just stick it out. Just just A little bit longer, stay focused on it, dedicated to it, commit. You know, and that I think is what's gonna what's brought Edify's success in this short amount of time and what it's gonna just be ten X that success over the next couple of years because of that commitment that Eric was talking about today.
speaker-2: Patience is a virtue. It's a fruit of the spirit. It's in it all of that leads to trust, right? At the end of the day. And so I think I'm with you. I think ⁓ we we really need to get Eric back on. We need to have a chapter two. ⁓ and kind of talk through some more some more just talk through some more things from the product side of it. ⁓ I know that he kind of had a short period of time, but ⁓ we're just gonna move on and kind of talk through more ⁓ more of the things that they're doing and maybe even there's a lot of stuff that's gonna be coming out in the near future, not to point towards the shiny things, right? But at least point towards the larger workflow and like he could probably even show some of those things. Yeah ⁓ outside of what he's working on. So
speaker-0: Well, I think what's important too is adoption. I mean, we I was talking to Brendan yesterday, the day before, about about, you know, this. And it's like it's super important, you know, to that you know, you're not just selling things. Like you need people to actually adopt these tools. Cause if you if you put something out and you you you put a product before them and you you don't follow through with it, ⁓ you know, adoption's gonna suffer. If they can't use the tool, If if it's like if the example Eric gave, where they said, Hey, I need more water, and he's Well, I don't think you do. If I give you more water, you're gonna spill it. ⁓ what you need is maybe a bigger class, right? And if you have someone that's giving them just giving them more water and they end up spilling it in that, you know, metaphorical, I guess, example there, ⁓ adoption's gonna suffer, right? So product and the decisions they make directly impact CS. They directly impact sales, they impact the whole org. Right. I think a lot of people just think adoption is is tied to training, right? It's a it's a customer success problem. But product plays a huge role in if the product is a, if it's even marketable. Do you have something that people are willing to buy? But even more importantly, they gotta be able to ⁓ to roll this thing out enterprise wide and adopt it. If the product doesn't match the way the people work, adoption's always gonna be uphill.
speaker-2: That's right. It's not a good look for a business for that to suffer. ⁓ it's like product sales and CS. Everyone has their own objective things. But the reality is we start breaking it into chunks and pieces, we start looking at the tran transactions. Mm-hmm. But if we st if we get stuck in those lanes too long, we lose sight of the big picture. Yeah. And so we have to keep sight of the big big picture. When you when you purchase a software, I mean, I'm saying this from from like when I was on the industry side, like when you purchase software, you're not just purchasing a tool, but it's like a part purchasing purchasing a partnership. But that partnership has already been building up to that point in the first place. It's just now it's codified with money, which is which is a good thing for a business, don't get me wrong, but it's really the partnership and and then getting that, you know, getting as much utility as fast as possible. So yeah. Eric's Eric's great on the product side. RCS folks are awesome on the CS side with with ⁓ implementing and adoption. Our sales team does a really good job. Just leading with honesty and integrity. And like, ⁓ if there's something that frankly we don't do or we don't do it the way you do, and that's a that's like a no go, then that's okay. Maybe down the road, then there's an opportunity there. So gotta connect all those dots.
speaker-0: Yeah. Yeah, a hundred percent. One of the things that we didn't get to because we ran out of time, but I I was particularly interested in was the the thought that ⁓ it can be challenging in what Eric and and team do in balancing what those users need today versus where the industry needs to go tomorrow. And so if all they built right is if they all they do is build around today's needs or today's workflow, they're just sort of digitizing old habits. Right there. But if you build too far ahead of the market, then people may not be ready for it. Right. And so I was curious to get and he kind of talked about it a little bit, but I wanted to maybe talk a little bit more about that balance between building for now, building for the future, and balancing those two out. ⁓ and what what challenges that that is for a product team 'cause I know it's gotta be significant.
speaker-2: Well what what is it that Preston said last I actually need to I need to buy that red book. What Preston said last week, like you design when you design a solution for today, you're designing it designing it for today's problems. You're not designing it for problems twenty years from now. Yeah. Yeah. But but the reality is we're designing a solution actually for today's problems. It's we are. It just turns out that it is a next gen tool that can help solve for problems as they evolve in the future, which is a bit different, right? Yeah. ⁓ it's it's a distinction. So I think I I actually wanted to plug that into and next time we get to talk with them we'll we'll probably we can go down that path. But I'm I'm with you. I'm super super curious on some of those things. Yeah.
speaker-0: What a great, great talking to Eric. Hopefully we can get him back on. ⁓ any last takeaways you got and we'll before we end ⁓ end the broadcast today?
speaker-2: what we have coming up. ⁓ next we're looking probably into next month. We have a couple coming up. One episode with David Haley, a DPR, and ⁓ we're gonna talk through tech and innovation and then with them and then with ⁓ Scout program management to get more of an owner program management perspective on the pre con side. So ⁓ really excited to get those teed up.
speaker-0: That's awesome. And I'm looking forward to seeing you next week in person.
speaker-2: Yeah, yeah.
speaker-0: Yep, yeah, a little plenty. So all right everyone, well thanks for listening. Thanks for tuning in to Proper Precon. Remember that Proper Precon Podcast is powered by Edify. If this episode made you think of someone in product, pre-construction, estimating, construction tech, leadership, ⁓ grandmas, aunts, uncles, send it their way. Don't forget to like and subscribe. ⁓ it really helps us out a lot. Check us out on all in Spotify, Apple Podcasts, YouTube. We're all around. We'll see you next time. Thanks for listening.
speaker-1: I'm a Prick
speaker-2: Yeah.
speaker-1: you
speaker-1: Break up, bring the
speaker-0: All right, welcome back to Proper Precon. I'm Troy Simon along with Trey Darnell. ⁓ Trey, on this show we've talked a lot about just pre-construction as a craft. ⁓ we talk about judgment, context, communication, relationships, all that good stuff. Trust, a big one. We touched on that a couple weeks ago as well, behind the number. Today we're gonna take a bit of a different look at pre-construction from s you know, a slightly different angle. We're gonna talk about product, but not product maybe in the sense of like a sales pitch or features or buttons or anything like that, but more more about product as a discipline, how good products get built, how product people understand industry problems, what it takes to create ⁓ those products and actually help pre-construction move forward.
speaker-2: Yeah, and I I think it's an important conversation just because the industry's seen a lot of different software over the years and you know, it tends to help digitize things initially, but then after that it's like, well, what does it leave you with? And it doesn't always help you work better. So I think that that difference usually comes down to whether people are building the product actually understand the work, right? The prec like pre construction that we're speaking to specifically, not just the math, not just cost data. It's like how do we connect those that cost story? ⁓ and so assumption, scopes, risk, communication. Owner expectations, design talent, trade feedback, all those things are part of how we do pre-con, right? So if you're building a a product for precon, you have to respect the crap.
speaker-0: Yeah. I mean, and that's why I was excited to hear what today's episode was a few days back when we ⁓ got it planned, actually. So we're joined by Eric, ⁓ our director of product here at Edify. Eric spends a lot of time listening to customers, understanding those the workflows and challenges that they're having ⁓ with their current solutions, working with engineering and and design teams here at Edify and helping translate those things into real product decisions. So converting that pain into what we hope is going to be a fantastic solution. So Eric, without further ado, welcome to the show. Thank you for being here today. Of course. Glad to be here. Good to listen to the sun. It's worth it.
speaker-2: That's right, yeah. As Troy said, top ten hit.
speaker-0: It it's confusing why it's not on the top ten yet, but we'll s we'll remember.
speaker-2: We'll get there. Yeah, so so Eric, let's start with your background before we get deep into the pre construction piece. Tell us a bit about your path into product. How'd you end up in this role? And kind of what shaped the way you think about building software.
speaker-0: Yeah. So I I went to school actually for construction. I got my ⁓ bachelor's in construction management at Cal Poly Slow. So I I studied construction and I was fully expecting to go into the G C industry and ⁓ you know, be a builder and out of Cal Poly started working in the field for a little bit and found better fit in the estimating role. ⁓ was there for a little while, but they've always been my people, but I've wanted to make an impact in a different way. And not not just bidding work, not just pricing that, but like actually tangibly like something grander than that. So technology has always been a means to achieve high impact. And that's where I started to look. So I started to look at ⁓ how do I get into tech? And the jump from I'm an estimator to I want to be in tech is one that A lot of recruiters don't understand. And so I ⁓ I had to get strategic in how I make that jump. So I actually I went on LinkedIn and I messaged every single product manager in Procor. ⁓ and one of them reached out to me and was like, Hey, I'll I'll chat with you. So I chatted with them because I had done a ton of startup competitions and naturally product was kind of where I I had gone I'd naturally fit in and I was really good at it. So ⁓ chat with them for a while and they recommended me. So that's how I got into Procore. And I started at Procore in I think it was 2017. ⁓ and from there, like started working really closely with software teams actually as a QA where we're hyper focused on quality and making sure that what we release is good and meets the needs of users and worked really closely with their product manager at the time. in basically treating quality like a product. And ⁓ that seamlessly transitioned into a product role at Procore across ⁓ Procore Financial. So I spent a lot of time on the budget, change management, ⁓ just across the board. ⁓ worked on the if you've ever gone into Procore and added a line item anywhere in financials, that was my team. Just across the board of Procore. That was a great experience. Learned a lot and then from there went on to a maintenance app, ⁓ maintenance product where it's called upkeep, ⁓ and at upkeep, they look at kind of the end of construction when the actual keys have been handed off. ⁓ there's actual maintenance to be done on the building. And so a lot of work orders. ⁓ in that flow it was super exciting because we were building for two different personas solving the same problem, which was really unique. ⁓ You have a technician on the floor that some of them are not the most tech savvy. And you have an admin in the web who is extremely tech savvy and needs lot of detail. How do you solve a problem for somebody that doesn't really know how to work an iPhone and capture data in a means and method that is detailed and accurate so that you can extract value for it for the admin role to be able to then feed back into. technician role. So that was a really unique problem set where we solved problems cross platform. And I got my feet wet in that in in mobile development and and all that. Took that one to box ⁓ and spent some time in the corporate world in box. ⁓ and then w I was in their mobile I was their mobile product manager and then from there came down if I ⁓ so fully full circle ⁓ in terms of setting construction, being in construction, now building for construction, which is pretty cool. That's wild. That's interesting. I didn't I didn't know some of that background of you. I'd like to talk to you more about those competitions. That's pretty cool. ⁓ I mean not today, ca we got so much to go through, but ⁓ that that was that's that's great stuff. When you when you think about like great product work, what do you think people might misunderstand, you know, about about that role, whether it's a product manager or even something like you where you're sort of leading the product management teams. Because from the outside I think people maybe they just think product is just kind of deciding on features, you know, maybe what to build next. ⁓ I think it goes deeper than that. I mean, what what do you say about that? I think it goes way deeper than that. ⁓ if we built what everybody told us to build, we would not have the product we have today. you you don't solve problems at the prescriptive layer. You solve problems digging beneath that. So like a really good ⁓ VP product that I I had at Procor w told me in The time I was like, I don't know if I understand that. And then over time I've been like, okay, that's actually a really good analogy. He said a good product manager will look at if you have a glass of water that's half full, a good product manager, and and the person that comes to you with the glass of water that's half full says, Hey, I need you to pour more water in this. I need, I need more water in the cup. Can you fill up the cup? At a bad PM. a PM that's young and early in their career and doesn't really have a look around the corner type mindset will grab a glass of the pitcher and fill up the water. A good PM will look at the glass and say, is that actually the right glass for what you're using it for? Or do you actually have enough water and do you just need it in a sports bottle because you're going to be running and or do you need it for something else? Because if I fill up that glass and then you're going to go and take it running, you're going to spill it everywhere. And so like Product, good product doesn't meet people where they ask. It looks underneath the ask at what the actual problem and use case is that you're building for. And then we attack the use case rather than the surface level or scare drive solution. And sometimes they're the same, but yeah, often they're not.
speaker-2: I love that ⁓ it kind of makes you think of like function and form. Like form kind of seems superficial. You see the form on the top level, like I need that thing, and then functions like the underlying value that the utility that the thing provides. That's that's awesome. So I I and I do think that we hear a lot of like, Well, I just I need this button or I need this report or I need this thing. And there is typically a deeper understanding that you have to dig into ⁓ to separate that literal feature request from the actual problem the customer's trying to solve. And And frankly, I think you're very good at that. Like I've been on plenty of calls with you where you're like, you're very curious. And you're like, well, what what is what's the intended outcome? Like, what do you anticipate? What do you expect here? Like, what are you trying to get to? Because part of the problem is if they just say, I need this button, right? If you give them that button, you might just be giving them the same thing they already have. You're saying, Well, there might be something else you're after here. I can give you not just the button, but the thing that actually gives you. tenfold what you're asking for, which is a much more valuable conversation.
speaker-0: I mean, I've plenty of examples even being here of that, where like even in the the milestones of metadata work that we'd done. we were asked numerous times at a solution level to just build what they have, right? Like build build the the the the classic workflow, right, is ⁓ I do a cost model, I filter off of all these properties of a project, I go through, I estimate it. those properties then get benchmarked with the estimate for future data. Hey, our form is usually, you know, a hundred and fifty question long questionnaire that we require estimators to go and fill out at the end of an estimate. And if they don't fill it out, then there's X, Y, Z repercussion. ⁓ they have to fill it out. ⁓ but there's no way for us to enforce it. So can you build the same thing with an Edify so that they can enforce it? Well, if we do that, you're gonna have the same problem. And so like when we when we started digging at that, what we were digging at is, do people even do it? Like e yeah, you've created a form and there's a hundred and fifty questions, but do people actually fill in a hundred and fifty questions? And the overwhelming response and answer was no, they don't because you're asking the question at the wrong time. And if you can ask the question when you're actually building out the estimate per milestone and you can actually ask it in context. You're capturing the same information with the same output that you're trying to achieve with the prescriptive solution that you've already built to solve it because you've had to solve it that way. But if we just go and build that, we're gonna build it wrong. And you're gonna just have the exact same problem, just with a different UX in in our product.
speaker-2: Yeah, for sure. And that's like the impact piece is you're not really impacting an industry if all we're doing is reinventing the wheel. We wanna we wanna blow the wheel up. We wanna give you, you know, something better to actually use in the first place, not a you know, twenty, thirty, forty year old tool. We're not making it look like MS DOS.
speaker-0: Yeah. There's a lot of things ⁓ that maybe make pre construction ⁓ different. I was curious, given the r the trip you've taken from estimator to, you know, quality assurance, I think it was, the change in management to to what was it, box and and then you know, back here to edify. People outside the industry may look at say, I wanna do an estimate and they're thinking, Well, you know, they're counting things and we all know there's a lot more, as you just described, like maybe underneath the hood of what's really happening. As you made that journey, was there anything that stood out to you maybe that's that's helped you in this role that says, hey, pre-construction teams, they work differently than this maybe other way we might build software for, or is there just a lot of similarities? It's a similar template. It's a different answer than the template. Like the the template being you have to understand your users and you have to build for the users and the problems that they have in order to like Edify has a genuine opportunity here to disrupt an industry. Like truly, and AI unlocks the box for everything that people have ever wanted with historical data. And Edify is just sitting on a gold mine. and you have to know who you're building for and the root of the root of the root of the root of the problem that they have, so that you can build a solution that feels good. Like Musk is famously quoted for like saying the machine that builds the machine is vastly more complex. Than the actual like output of the machine. So like the thing that builds the car is so much more complicated to construct than the car, right? Cause you have to think through literally everything and anticipate everything. And if you get it one degree off, you're wrong. And if you're wrong, I say this with Dustin all the time if you're 1% off, you're 100% off. You might as well just not build. So it has to be, especially in the space, knowing your users, there is no margin for error. It has to be perfect. It has to work perfectly. ⁓ and so anticipating those needs can be really challenging. But our milestones project is a good example of that of like we had to build the machine that houses the machine in order to make sure, like when we were building milestones, we weren't focused on milestones. We were actually looking at trend line and backing into how we need to build milestones to make trend line happen. And that is way more difficult. than being like, hey, how do you set a milestone on an estimate? It's so much more it's so much deeper to the And that's why we have things like the design stage layer, ⁓ with the milestones that are free form tech. So you have flexibility that rolls into structure and like there there's just you keep pulling the thread and the thread and the thread. I think a lot of those learnings from previous companies around how the same problem can be solved in many different ways is very similar here.
speaker-2: I think that's where free con can be hard to build for because, you know, the work's not just task based. It's it's so much judgment based. I mean, th there's information defined on the drawings for sure, but even there's judgment applied to those things because there's information not on the drawings, right? ⁓ and so an SRM may make a decision based on the drawings, but or based on what they know about the owner or the architect or the market or the trade base, like whatever it is for that phase of design. Yep. ⁓ so when so when you think about building a product for that kind of work, how do you make sure the product supports the judgment instead of trying to replace it. 'Cause you kinda you said the A word, you said AI a minute ago, right? So let's just go ahead and go down that rabbit hole.
speaker-0: ⁓ yeah. So I I think you know, we just hired an an amazing ⁓ AI PM to to kind of help take us on this journey. And and one of the things that I've been talking about with him specifically is that like there's two routes for AI. There's a gentic and then there's intelligent. And both routes will be explored a hundred percent, but The question is when do you explore one over the other and how do you explore each that they complement each other? And like to your point, Trey, I don't think Edify will ever be a at a point, nor should it, where it says, this is what this costs. That's too bold. But what it can say is, hey, we have the cost model, we have the project, we have all of the data through all the milestones and how cost has evolved over time. We have what you bought it out for. We have that entire A-Z workflow, all housed within a project object that has metadata on it, attributes on it, area sheets, rooms, units, et cetera, that completely and entirely categorize the what of that project. And they give it its basis for cost. Today, that is that funnel is brought to a point with a ton of filtering and a ton of. Senior knowledge when you go into cost model, where the most senior people are the ones that are typically building the cost model, that are typically having these conversations, finding projects of like kind, pulling from those benchmarks, isolating the risks, knowing what to account for, knowing what to avoid and what not to avoid, which styles to turn and which ones not. We have all that data. So like we can elevate those insights so that we don't need a substantial expertise to be able to create what once required a substantial expertise. And we can bring in the insight of GMP level cost at conceptual stage design to help you make better decisions, because that never before has that been on the same platform. So like that's the intelligent piece. Then there's the agentic piece. And I think AI in general, when we go down the agentic road, I think you can Throw people into the future too quickly. I think you definitely can. I think you have to meet where they're at, show them what the future is, and then take them into the future. In that agentic flow, if you jump too soon and too aggressively, you lose trust. But if you build trust along the way and you can make things, there's things within agentic flows like human in the loop, always making sure, like we're not going to go build your estimate, but we're going to
speaker-2: That's right.
speaker-0: look at your plans and specs and suggest what could be pulled into it. And then you choose. Right. We're taking your workflow that may have taken two hours and we're condensing it down to twenty minutes. Like there are things like that where I think it's very much so feasible in today's world. And who knows with AI? AI in a year from now may be in a completely different spot where it really does get into the more dramatic abuse cases. But right now, like I think you got to put your foot in the water before your whole body jumps in. Yeah. I think a lot of people when AI really started to go mainstream over the past what twelve, eighteen months that people were like this fever around it, right? ⁓ people were looking at as a way to replace tasks and things like that. But I like that approach where the more intelligent it's really coming alongside and helping them make those decisions better, faster, quicker, not make the decision for them. I think that's a like an important point because the technology can either respect the craft or or flatten it, you know? Yep. And and and when it flattens it, a user's gonna feel that that pretty quickly. And so they'll know was, hey, this I don't know if these people really understand the way I do work or not. ⁓ you know, so it's you gotta go at at the right pace. I think you guys are making, you know, some great decisions there. I mean, i it y I feel like you kind of already answered this, but I'm gonna ask it anyway. Are they looking at it from your from your director's spot there and as you're, you know, managing a team and looking forward, are there certain signals that maybe you've learned along the way that can that sort of signals that hey this product team actually understands its users. I mean the biggest signals I've gotten have been well one, I would say of any product team I've ever worked with in my entire career, this product team is the most talented and the most customer centric and problem oriented that I've ever worked with. So we have we have a best in class, 100% exceptional tier of product managers here, ⁓ which is Makes my job easier. But ⁓ that is hard to find. There are a lot of people that are PMs and I would say it maybe controversial, but I would say less than five percent are probably legitimately good at their job. ⁓ because a lot will meet customers exactly where they're at and the prescriptive layer they won't look beneath. And looking beneath really challenging, either have that way of thinking or you don't. And so like in interviews and stuff, that's what we look for is that way of thinking is like the r underlying root. And I think proof, the proof is in the pudding. And the pudding is every time we talk with customers, every time we hear from customers, there's such alignment across what we're doing and where they need us to go. And like you look at things like advancing pre-con, which Trey, I know you've been there a ton. Like we get such strong resounding feedback that is almost entirely aligned with where we're headed. Which is so exciting that like you can take quantitative or qualitative feedback. So an interview here, an interview there. And advancing pre-con actually makes that quantitative because it takes the qualitative and you're talking to now a thousand people. So you're starting to get really good trend on the market. And it's so clear where the market's headed. The market is headed in the exact same direction we're headed, but they're not able to get there by themselves because they don't have all the data. That's why I say Edify is in such a unique position, truly disrupt, because we actually have the data. A lot of people say they want to do X or Z Y or Z, but they can't. Or they'll or they'll take a crack at it, they'll s it as it does that, but it's not actually doing that. It's looking at one piece of the puzzle, not the entire picture.
speaker-2: Yeah, I'm there. So A, I'm I'm wondering what the flavor of edify pudding tastes like now. So we gotta figure that out. ⁓ I bet it would be delicious. I can already see the colors, but it'll be delicious. but that does kind of lead us to this idea of like built with builders because I know you do interview customers and prospects and we get industry feedback and and you know this We've kind of titled this episode Built with Builders, the Product Side of Precon. And the phrase matters to us because we don't believe products should be built in a vacuum. It should be built with people doing the work. ⁓ there's when I was at Plan Grid, we had s there's some kind of network like ⁓ like Builders Network or something. But I love the width component of this because it actually creates this kind of this this idea of partnering, not like across the table, but like on the same side, going towards a common goal. You know, we're not just taking feature requests and building exactly what someone asked for, but how do you think about that balance between listening closely to customers' prospects and still being responsible for shaping the right product direction?
speaker-0: It's a good question. And it's one of the hardest tensions in product is there are some feature requests where you actually do need to meet people where they're at right now. And you can't wait for the future. And like the hardest part of my job is identifying when it's that case and when it's the case of, well, yes, but what we're building is actually fundamentally broken. And We're not gonna build a broken workflow. We're actually fixing it in this way. So like there's just there's a ton of examples of like w places where We could build something some way to help unlock right now, but in doing so, that actually incurs a ton of debt and like takes the disruption that pre-con needs and kicks the can. So like here here's an example. We're talking about this literally right now, actually, is variance reports. We have in-app variance reports that are exportable and in that they're Excel and you can add notes and The side because it's Excel, it's fully customizable, but we're bringing them in app. And that is coming very soon. As a as a means of that, we're also looking at a ton of different AI use cases and where AI can help, like I was saying, provide the insight around this stuff. And we have we're kind of at a crossroads right now where we can either build in like notes in app on a variance report, or we can wait a little while. And build in an actual intelligent aggregation of everything into a summary using AI where you're solving the same problem. But then the industry's had to solve this with Excel. They've had to solve this with text because they've been stuck in that way. They haven't had this data to be able to bring that insight. We have everything. We have the lineadings, we have the estimates, the milestones, what changed, what didn't change. So there's so much. Greater depth of insight. And like, will we add notes in app to variance reports? Possibly. Like we're open to feedback. We'll we'll iterate and tweak that as we need. But doing that, let's say we do do that. Now comes the question of, okay, well, now we're going to start work on insights on variance reports via AI insights. What do you do with the notes that people have already left? How do you migrate those? Do you migrate those? That what if they were in conflict? Like, should you be able to manually capture? So now you're slowing down innovation in the future because you built for today. And like that is a really challenging trade off to weigh because that's that trade off not only has like user friction challenges, but it also has challenges technically. We're like, we're slowing out the actual building of these things. So that the future is coming to you slower, which in some cases is very much so needed and wanted. ⁓ but in other cases, again, it's just give or take. It depends. You mentioned the word tension. I I f I find that to be a perfect ⁓ that was a perfect word really for for what you described. I mean, because customers, they're experts in their pain. They know what the friction is. They know what slows them down. They know what creates risk. But you guys the product team, you you have to take that pain, figure out the pattern, then figure out what the scalable solution's gonna be for it. So how do you know when you get that one off, when something's maybe a one off request versus a bigger industry problem that's worth solving? 'Cause like you said, you can't build everything. And if you build build it now, it could be a lot of debt that is the cause of that for the future. So how do you distill that down and say, that's a great idea, but that's not the industry problem that we have to solve for today or for tomorrow? That's where my role comes in pretty heavily, which is you have to have a direction. You have to know where you're headed. And I I think a lot of companies, ⁓ the failure state of a lot of companies, they don't have enough conviction on where they're headed. And there's not that conviction is rooted in idea. It's not rooted in real. genuine problem. so like our strategy is very rooted in problem. It's very rooted in real, genuine pain that we're thinking far bigger than just an estimator. We're thinking pre-construction. We're thinking grand. And when we look at that and the opportunity space that Edify has to change that and genuinely disrupt that, if you know where you're going. And you know where the those like longer term problems are that you're headed to solve, there's going to be feature requests along the way. And some of the feature requests are small and isolated. And for that, we do things like, okay, what's the impact versus the level of effort versus the cost? Like it the impact, high. Level of effort low. Okay, that's attractive. But the cost of this and the debt of this that this will create, extremely high. Okay, less attractive to to go. It's a balance between taking people on a journey but not forgetting that, but not abandoning them in where they're at today. So like there is a tension in terms of ⁓ honestly milestones as a great example. The project took us a year. It was a very, very, very, very large project. And there were many times along the way where we were questioned and we were like, are we sure that we need to actually be building it? This structurally, this sound, this foundationally, to get to where we need to go. And the answer was always yes. Like we've we're rooted in the problem. This is the proper way to solve the problem. Now we've layered on trend line and it's like the industry had like blinders lifted off and they're like, ⁓ my God. Like I s now I see the value of putting everything in one spot, categorizing it all in the way that you did, but like you're gonna be questioned along the way. So like there were a lot of feature requests. That we've had to say no to in order to make that possible. A good example and something we're going to be doing soon is like our formula editor. There's a huge opportunity to improve that. Does that move the needle though on the vision that we're trying to achieve? Not really. But does it make it easier for estimators to do their day job? Yeah. So like there's a there's a tension there between, okay, we're gonna push that a little bit to pull the future forward, but we're not gonna forget about it. And we're gonna make X, Y, and Z improvement today to help make those the the key workflows and the really challenging things that estimators experience today easier so that we can almost like let a little steam out of the kettle, but we're not just opening the kettle. Does that make sense?
speaker-2: That's almost like it's almost like you know you're on the proper precon podcast right now. You're using all the words.
speaker-0: This is the proper development podcast today. Right. Like full this is some good stuff.
speaker-2: This is why Yeah, I I I like that a ton. ⁓ it's like that's that's where good p good product people really move the needle for an industry. You're you're not asking like what can we ship. You're asking, you know, what problems are we solving, ⁓ who are we solving for and what does it actually what does it actually make work better at the end of the day. So from that standpoint and actually because of your background too, because I I look back like I'm also, you know, ⁓ construction ⁓ science ⁓ major as well. Like You came from that and now you're a product, you came into tech. Like from that standpoint, what are the best qualities of product people who can actually move an industry forward? Because I would say that you you took a leap of faith and were trying to get into tech coming from the construction side. I I did a similar thing, right? And that doesn't mean you're necessarily looking for the stereotypical product things that you might look for in other businesses.
speaker-0: In terms of the question you're asking, in terms of like the people that we bring on, like what do I look for in people?
speaker-2: That's right. Yeah.
speaker-0: The ability to translate. Like that me saying I think five percent of PMs genuinely are like highly talented. Like PMs are are I am of the opinion that when you see a good PM, you jump on that immediately. Like there's no it's like walking down the street and finding gold on the ground. You don't walk past it and say, ⁓ I'll go pick that up later. You're like, No, no, no, I'm gonna grab that right now because there's not a lot of gold on the street. ⁓ it is really, really hard to find PMs. I honestly a the example I just gave, milestones versus formula editor, ninety-five percent of PMs would have built the formula editor. Ninety-five percent. And they would have built it exactly as users want. But that doesn't always set you up to where you need to go. Right. Like you you need to see beneath that. You need to see not only beneath that in the sense of that one use case of a formula editor, which ⁓ I don't disagree. It would be super nice to have like People need this. People want this. I want it too. But if we try and build everything, we're going to build 20% of everything and a hundred percent of nothing. And that's not going to solve anyone's problem. So we have to be laser focused on what we want to achieve while again not ignoring the use cases and pain that people have today. ⁓ so yeah, I I look for people that can see around the corner when we when we do interviews for PMs. I don't want Somebody that's gonna say, ⁓ like, yeah, this is how I'd solve that. You miss the point. What's the problem that you're actually looking at? And like, if I tell you I need more water, are you gonna pour more water in the glass? Or are you gonna question why I need more water and what the use case is for me drinking that water so that you can re-question if that glass is even the right glass? Because the answer might be, ⁓ I need to pour more water in the glass. But oftentimes it's actually not. Oftentimes it's actually I think I need more water is what the user's saying. And the PM needs to look at that and say, I think you don't. I think you you if you d if I gave you more water, you would be really thirsty because you'd start running and all the water would fall out of your glass. So I think this solution would solve that need. And what's interesting is when we then go back and we show those solutions to users, there's almost always a light hold moment where they go, ⁓ shit, you're right. Like but but people haven't been forced to think that way. You have to beat them to it and then show them what it looks like.
speaker-2: Yeah. I know from my side, like your your only wish is that I don't go out and say, Hey, I'm gonna sell you this thing that we don't have. Yeah, please don't do that.
speaker-0: 'Cause everything I just talked about gets lit on fire.
speaker-2: Yeah. Yeah. That's then that's and and I like we work very well together in that in that sense, right? Like on the sales side, we don't like we don't you don't sell roadmap, you don't drop the candy in the lobby, we like this not how we operate, right? Now we wanna help solve problems too. But Troy, I think like we probably should talk about that piece of it 'cause I think it's really important.
speaker-0: Well and one thing before I jump in there, I I do you have, Eric, and you don't have to share it, I guess, completely, but you talk a lot about being laser focused and we have certain things obviously that we're working towards. Is there like when you think about Edify of the industry challenge we're trying to solve with that with this software and all of the different users that will eventually be able to collaborate and use this tool within each of those But we're talking about trade partners or general contractors or owners and developers. Each of those will have maybe a laser focused set of things that we need to add to the solution for their individual use case. But what's the big overarching vision that we're laser focused on with Edify? Yeah. The general flow that we have and where our strategy is kind of anchored on is if you look at the new world, like You can't look at our strategy without evaluating the current world that we live in today, which is we have a new tool set at our disposal that has the ability to comb mass, mass data sets and elevate insights. And what we're seeing over and over again, not just in construction tech, but across the board, is the winners in this in in any space right now are those that house the data. Those that house the data, I mean, look at like the full self driving race that Tesla's having. They're able to train off of that data. They're able to learn every edge case that a car may go through versus a Waymo esque type solution is very data limited. There's only a certain amount of cars. They're not able to paint the entirety of the picture of what they need to achieve to then layer AI on top and actually learn from it and house those insights. So that's why like I think Edify is very uniquely positioned in that. And our key flow is to house that data. So, like this started this strategy, it's a multi-chapter strategy. And chapter one was actually when I started here almost three years ago, which was like, you can't tell me about the puzzle if you're missing puzzle pieces. So built puzzle pieces. So we built cost modeling. And then we filled in the puzzle piece, but then it's Yeah, but the whole blue, there's no picture. I don't know what data is categorized and what milestone and that matters a lot. So I can't draw that inside. Okay. So we built milestones. And then well, yeah, but then I can't learn from that puzzle because there's so much more data that's captured in my project. ⁓ that I'm not able to use the rooms and units tools and I'm not able to add metadata to it. So we redid the rooms tool, the units tool.
speaker-2: А за
speaker-0: We went through, we added project metadata. We're adding these fields to be able to tell a story. Then we layer on ⁓ cost trend line. And now we're in the next chapter of the strategy, which is a lot of the puzzle pieces have been filled for estimators. There are many different puzzles that we'll be solving for owners and architects and self-perform and all all of pre-construction, right? Yeah. But for estimators, a lot of those puzzles have been solved. And there's still some gaps like in contracting, and we're gonna be focused there and Filling that puzzle piece in, but by building the workflows and housing the data, we set ourselves up to layer and intelligence and fundamentally reshape how people work. And that's the core river that we're floating down, which is we've built the workflows, which is arguably the hardest part. We we've we've housed a connected platform, and a lot of people say they're connected platform, but they're not. We're truly a connected platform where every tool, every piece of data is in one spot within our product. And to be able to then layer in the intelligence allows you to fundamentally change the way that you work. We're not a tool now that meets you where you're at that makes your job easier. We're actually a tool now that becomes it's a risk to not use us. It's a risk, competitive risk to. not have the love the that insight layer because how you price a job is whether you win or lose that work. And if you can make intelligent, high quality decisions early on, our hypothesis is you can fundamentally flip the the industry on its head and bring those insights early on so that you're not starting a project in the negatives or starting a project with just landmines everywhere. ⁓ so that that is the the goal and the vision for for us. Yeah. Well that's that's amazing. And and Trey wanted to talk about trust and I know we gotta wrap it up, but I gotta feel that that's what you just described is is w how we're gonna build that trust. The industry's seen a lot of tools come and go. People have seen big promises from from tech companies in this industry, ⁓ long implementation that that didn't materialize materialize. They've got long implementation cycles, they've got clunky workflows. ⁓ tools that don't match, ⁓ they don't connect. From a product perspective, I I feel like what you're what you just described is how we earn trust with users. Trey, would you would you agree with that?
speaker-2: Yeah, I agree. And I mean, I I think you mentioned chapters. I think this is probably chapter one with Eric on this podcast. There's gonna be a chapter two because we are only skimming the surface for what we really wanna dig into more. but yeah, I think that builds the trust. and our goal is to highlight folks who don't only want the transaction, but want the relationship. ⁓ and I think it's one thing I love I love about you, Eric, is like You're not a transactional individual. You're a very relation driven person. ⁓ and you bring that into how you think about product and how you think about solving problems, which is to your point, these it's the four percent of like it's just good PMs, right? So super thankful that that you're here at Edify. ⁓ Troy, we we probably do need to do the fast five though next, just to kind of stay on stay on task and
speaker-0: Yeah, I think it's gotta be the last thing. We have to let Eric go 'cause we promised him five minutes and we have sixty seconds. So Rap Eric, this is fast five. No long explanations. It's five questions, just rapid fire answers, first thing that comes to your mind.
speaker-2: That's not. All right, ⁓ so feature requests, friend or foe. What's one product habit that creates bad software?
speaker-0: ⁓ friend. Not listening.
speaker-2: I think I could have just answered that one for you after today. I mean, even after working with you. Most underrated skill for a product person.
speaker-0: Listening.
speaker-2: Yeah. We're gonna shake these up next time. What is one thing construction software needs less of? Preach. All right. Finish this sentence. This is our permanent closer. The precontine that figures out blank will have a massive advantage in the next five years. Awesome.
speaker-0: Data. Awesome. Very good. Eric, thanks for ⁓ joining us today. We'll let you get out of here and ⁓ Trey and I will we'll wrap the episode up. But thank you so much for joining us. Of course. Thanks, guys. It's amazing. That was huge. ⁓ I mean, I knew Eric, but I felt like I know him like at a whole nother level after today. ⁓ I mean, there's just what what a great
speaker-2: Yeah, man, thanks for joining. See you later, buddy.
speaker-0: What a great hire. What a great decision by leadership and and Mike and Dustin to put him and Eric, you know, to put or ⁓ Eric, Zach, to put him, you know, in charge of of the product team. I mean, what that's that's that's a great what a great leader. He's got a great ⁓ skill set to fulfill that vision, you know, that that that the leadership team has built or, you know, pointing to for for Edify and and our users. So ⁓ trust is huge. What do you say?
speaker-2: Yeah, I agree. He he's he has the right mindset and it's people first. I mean, we we say the you the the tagline, right? Like people people process tech. It it's in that order on purpose. Now again, we at we're at Edify, we're at a tech company, but like leading with the people and process component of that ⁓ is is huge. And even talking about like built with builders, like that's that's something that stuck out very blatantly to me, it's like that's what he does. He wants to get on calls with product people. He wants other product managers to get on calls with product with with our customers and our prospects to like really understand thoroughly what the challenges are. ⁓ I just think the more time that you spend understanding those things, ⁓ the more powerful the solution's gonna be at the end of the day.
speaker-0: Mm-hmm. Yeah. I mean, he talks about, you know, building that that trust and ⁓ you know, it's not it's not gonna be you can't build it off just one you know, one f shiny release or whatever that you're doing, right? It's that it's that consistency and that more importantly, that laser focus that they have over time to commit 'cause I think that's where a lot of companies maybe fall short. And I don't even know it doesn't even have to be in product, right? And it doesn't even have to be a construction tech for that matter. I was talking to Dustin about this yesterday that a lot of times, you know, people are excited about an idea, they're excited about a direction, they're excited about a vision. Yeah. They get into that direction and vision and realize it's harder than they thought it was gonna be. Right? And so a lot of times we just bail and we we figure something else out. We we chase something that's newer, that's shinier, that might be easier. And sometimes the hard thing to do is just stick it out. Just just A little bit longer, stay focused on it, dedicated to it, commit. You know, and that I think is what's gonna what's brought Edify's success in this short amount of time and what it's gonna just be ten X that success over the next couple of years because of that commitment that Eric was talking about today.
speaker-2: Patience is a virtue. It's a fruit of the spirit. It's in it all of that leads to trust, right? At the end of the day. And so I think I'm with you. I think ⁓ we we really need to get Eric back on. We need to have a chapter two. ⁓ and kind of talk through some more some more just talk through some more things from the product side of it. ⁓ I know that he kind of had a short period of time, but ⁓ we're just gonna move on and kind of talk through more ⁓ more of the things that they're doing and maybe even there's a lot of stuff that's gonna be coming out in the near future, not to point towards the shiny things, right? But at least point towards the larger workflow and like he could probably even show some of those things. Yeah ⁓ outside of what he's working on. So
speaker-0: Well, I think what's important too is adoption. I mean, we I was talking to Brendan yesterday, the day before, about about, you know, this. And it's like it's super important, you know, to that you know, you're not just selling things. Like you need people to actually adopt these tools. Cause if you if you put something out and you you you put a product before them and you you don't follow through with it, ⁓ you know, adoption's gonna suffer. If they can't use the tool, If if it's like if the example Eric gave, where they said, Hey, I need more water, and he's Well, I don't think you do. If I give you more water, you're gonna spill it. ⁓ what you need is maybe a bigger class, right? And if you have someone that's giving them just giving them more water and they end up spilling it in that, you know, metaphorical, I guess, example there, ⁓ adoption's gonna suffer, right? So product and the decisions they make directly impact CS. They directly impact sales, they impact the whole org. Right. I think a lot of people just think adoption is is tied to training, right? It's a it's a customer success problem. But product plays a huge role in if the product is a, if it's even marketable. Do you have something that people are willing to buy? But even more importantly, they gotta be able to ⁓ to roll this thing out enterprise wide and adopt it. If the product doesn't match the way the people work, adoption's always gonna be uphill.
speaker-2: That's right. It's not a good look for a business for that to suffer. ⁓ it's like product sales and CS. Everyone has their own objective things. But the reality is we start breaking it into chunks and pieces, we start looking at the tran transactions. Mm-hmm. But if we st if we get stuck in those lanes too long, we lose sight of the big picture. Yeah. And so we have to keep sight of the big big picture. When you when you purchase a software, I mean, I'm saying this from from like when I was on the industry side, like when you purchase software, you're not just purchasing a tool, but it's like a part purchasing purchasing a partnership. But that partnership has already been building up to that point in the first place. It's just now it's codified with money, which is which is a good thing for a business, don't get me wrong, but it's really the partnership and and then getting that, you know, getting as much utility as fast as possible. So yeah. Eric's Eric's great on the product side. RCS folks are awesome on the CS side with with ⁓ implementing and adoption. Our sales team does a really good job. Just leading with honesty and integrity. And like, ⁓ if there's something that frankly we don't do or we don't do it the way you do, and that's a that's like a no go, then that's okay. Maybe down the road, then there's an opportunity there. So gotta connect all those dots.
speaker-0: Yeah. Yeah, a hundred percent. One of the things that we didn't get to because we ran out of time, but I I was particularly interested in was the the thought that ⁓ it can be challenging in what Eric and and team do in balancing what those users need today versus where the industry needs to go tomorrow. And so if all they built right is if they all they do is build around today's needs or today's workflow, they're just sort of digitizing old habits. Right there. But if you build too far ahead of the market, then people may not be ready for it. Right. And so I was curious to get and he kind of talked about it a little bit, but I wanted to maybe talk a little bit more about that balance between building for now, building for the future, and balancing those two out. ⁓ and what what challenges that that is for a product team 'cause I know it's gotta be significant.
speaker-2: Well what what is it that Preston said last I actually need to I need to buy that red book. What Preston said last week, like you design when you design a solution for today, you're designing it designing it for today's problems. You're not designing it for problems twenty years from now. Yeah. Yeah. But but the reality is we're designing a solution actually for today's problems. It's we are. It just turns out that it is a next gen tool that can help solve for problems as they evolve in the future, which is a bit different, right? Yeah. ⁓ it's it's a distinction. So I think I I actually wanted to plug that into and next time we get to talk with them we'll we'll probably we can go down that path. But I'm I'm with you. I'm super super curious on some of those things. Yeah.
speaker-0: What a great, great talking to Eric. Hopefully we can get him back on. ⁓ any last takeaways you got and we'll before we end ⁓ end the broadcast today?
speaker-2: what we have coming up. ⁓ next we're looking probably into next month. We have a couple coming up. One episode with David Haley, a DPR, and ⁓ we're gonna talk through tech and innovation and then with them and then with ⁓ Scout program management to get more of an owner program management perspective on the pre con side. So ⁓ really excited to get those teed up.
speaker-0: That's awesome. And I'm looking forward to seeing you next week in person.
speaker-2: Yeah, yeah.
speaker-0: Yep, yeah, a little plenty. So all right everyone, well thanks for listening. Thanks for tuning in to Proper Precon. Remember that Proper Precon Podcast is powered by Edify. If this episode made you think of someone in product, pre-construction, estimating, construction tech, leadership, ⁓ grandmas, aunts, uncles, send it their way. Don't forget to like and subscribe. ⁓ it really helps us out a lot. Check us out on all in Spotify, Apple Podcasts, YouTube. We're all around. We'll see you next time. Thanks for listening.
speaker-1: I'm a Prick
speaker-2: Yeah.
speaker-1: you
