How Story-Driven Discovery in Software Projects Leads to Better Results

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well hello and welcome back. We are continuing our season of Building Better Developers, Developing Our Podcast. This is a Building Better Foundation season. Part of it is we're having a lot of conversations this time around. In this episode, once again, we will be doing an interview. We're going to be talking to Dusty Gullison in a few moments. And if you don't know who he is, that's okay. You will soon enough. For me, I'm Rob Brodhead, one of the founders of development or Building Better Developers, also the founder of RB Consulting, where we help you basically assess your technology, build a roadmap for success. Good thing, bad thing that has happened to me lately, I spent a week in Vegas, just got back last night, which was pretty cool. It had been a while since I've been there. A lot of things had gone on and had grown. There are a lot of cool places to go. This place called Tappanash that we stumbled across. If you ever want to go to a cool cigar bar kind of thing, they are, their specialty is nearest green, which happens to be one of my favorites. So it worked out really good. It happened to be on, everybody's in town for Monday night football. So it was a good time. And that was all great. The downside is, is getting into Vegas and then leaving Vegas, everything went wrong. It was nothing big, but it was just little stuff. Like we got, you know, you got our flight got moved, just bumped back a little bit, but then we had to go from one end of airport to the other airport. We had like luggage got moved in the wrong place. It was just, it was just like one of those things where we're so happy to be there. And then we're so happy to be home. Just like I'm so happy to pass this over to Michael for him to introduce himself. Hey everyone. My name is Michael Milosz. I'm one of the co-founders of developmenter. I'm also the founder of Envision QA where we help businesses build smarter, stronger software with custom development and rock solid testing. Good thing, bad thing. Well, good thing, my wife is back. She was gone for 10 days. And the bad thing was I had to deal with the dogs and the animals for 10 days. And that was very stressful with my work. So I'm happy she's back and I'm ready for the holidays. All right. And now Dusty, go ahead and introduce yourself. Hi, I'm Dustin Bellson. I'm the CEO of e-resources. And, uh, do I do the good thing, bad thing too? Yeah, you can go right ahead. You will be, usually people don't, but this would be awesome. We'd like to have that. I like it. It's a nice little icebreaker. Uh, let's see. Uh, good thing is, uh, you know, this has been a good year just reviewing the last quarter and how this quarter's shown up. And, uh, you know, despite all the ups and downs, things looking good. So, uh, looking forward to next year, gonna have a little bit of a slingshot in there. Uh, bad thing is when all the travel starts before the end of the year where everybody tries to squeeze in the last minute projects, resourcing and all that. Well, it's good, but it's stressful. You know, it's really at the end of the day, we only have maybe two, three weeks left of the year for all intents and purposes. Yeah, very much so. And that's, uh, yeah, I'm in that, um, this year, every year I say, I'm going to take the last two weeks of December off and stuff gets just slammed in. And I've had too many years where like Christmas Eve or New Year's Eve, I'm, I'm still like cranking a few things out just to cover some fire somewhere. And this year I am just desperately again, like blocking stuff out and be like, Nope, not going to do anything. Not going to be anywhere near, you know, where I can help other than like a couple of status calls to just be like, okay, just keep things moving. But we'll see how that goes. I want to dive right in because one of the things about your company that I noticed, it's a, I think worthy of talking about is, uh, as you phrase this, like what the story gap and why organizations struggle to explain their value. And I think in particular, this is, or at least that we've discussed this a lot in particular, uh, service organizations, I think in general, but technology probably even more so anything that touches in that. It seems like you're in one of those situations where you could do, you know, people can come to you and say, can you do this? And you'll say, well, yeah, I can. And early on, you know, you struggle to, you know, you're, you're really just trying to pay bills and you're surviving. And so you're like, yeah, I'll do that. I'll do that. I'll do that. And then you get to a point where you're like, well, that's not really what I'm intending to do. And so I think this is where you step in and sort of say, like, how do you, how do you tackle that? How is it that you maybe, why do they struggle? And then maybe there's some things you can do to help people get unstuck with that. Yeah, I think, uh, by default in the tech field, especially in digital and infrastructure, things are communicated through specs, right? And statements of work are very spec heavy and, and, uh, really miss the nuance where really the person at the receiving end of whatever solution you're having actually has a different expectation. And so the expectation gap, the way you, the way we have at least successfully tried to bridge it from, Hey, I want to have this integration or I want to have this workflow or using the story was a really, really productive way of actually having them come back to what are your outcomes that you're looking for? Tell us the story, what it looks like for you on your day to day. And I used to have a saying in our company when I was younger and stupider, still, still learning. Um, she say, always speak to me in bullet points, you know, tell me, tell me exactly what you want to try just in bullet points. And the problem with that is that you lost the actual nuance in that. And I learned early on that it's the story that where you get the real expectation and you, you can boil it down to a simple example of if our MSP division, you know, someone calls in and says something, suppose this printer is not working. But the real issue is he wants a great report to be printed out in time for that. That's the real issue. It's not the printers working. There's a time sensitivity. You find out, Hey, what are you trying to accomplish? Instead of the computers work, are the printers working? We always tell our team that we're customer service people first, and we just happen to do technology and really learning about the person's expectations, what they're trying to do, what the end result is, what the story looks like. So when we do large, big enterprise projects, you know, quarter million to a million dollars worth of work, we want to look at what's the story of the organization, where are they going? What are they trying to accomplish? And what are all the characters involved in? And that allows us to actually see how what we're doing and how it touches and what the real expectations are, not just plug in this widget. Does that make sense? Yeah, that totally makes sense. And one of the things that I find that is a struggle, I think, especially people come out of technology world, because they that very much spoke to me the whole, hey, speak to me in bullet points, because that is very often they're like, I just tell me what to do. That's what I'm gonna do. And I'm going to go do it. And too often, I think that's that's part of what we talk about a lot of that's sort of what separates good developers from coders and just real technologists, is the ability to actually solve problems. But when you're working with and I guess it's on both sides of the conversation, whether you're working with a customer or you're you're training up your your people and your staff is how do you address them? It's I'm trying to think of both ways to do it, but sort of the forest and the trees aspects of this, because you want the story, because you really need the why to be a Simon Sinek kind of thing. Throw that out there. You need you want to know why do you why do you need this? You want it. But then there's also a need to dig into those sometimes and there needs to be yes, it's it's a and sometimes sometimes I've run into it both sides of where it's either a technologist, it's like, well, I don't know. I really need those details. So they forget the story. Or I'm talking to somebody, it's a business owner. And they're like, they're telling the story. I say, well, I really need some of these details. And they it hurts, essentially, for them to dig into sometimes because it's not a level of detail they want to get into. So it's how do you how do you marry it? Or how do you you share how those needs can both be met? Yeah. Really, I mean, any project really has two parts. It's that initial discovery. And then of course, the implementation. It's in a discovery where you really invest in conversations and developing a relationship with the end user. We highly, highly recommend actually interviewing everybody that's going to be touched by that project. Talk to them about how will this change your day to day? Tell me about what you do today. Tell me how long you've been here. What are the challenges you've had? It's really in those conversations and developing relationships with the end users and your your partner that you're trying to solve a problem for that you really get the value in the implementation because we've come back to clients and say, actually, after we've interviewed everybody, your discovery, you don't need this. This is a shiny object you thought was solving all your problems. But the real problem is all the shadow data over here are these processes that need to be reengineered and automated. And you can save yourself hundreds of thousands of dollars. You know, I always think about folks that go off and still do but used to go off and buy Salesforce thinking that they would sell more. Are they going to do all these things? The platforms, the tools, they're really not that important. You have to start with people first, and then processes, and then platforms. And a lot of folks, when they think they're solving a problem, they see something and go, what we need is a CRM or what we need is a CMS or what we need is this. And actually, what you need is to talk to your folks and go, how can they do their job better? You know, what makes them tick? Do they understand why they're doing this? Because Simon says right, start with why. But the key part of that statement is start with why. It's the start part. There's more to it than just the why. It's why and where and how and where we're going to end up in. What is our company look like in next year after we implement the solution? What does it look like in three years? What do people's jobs look like? Are they being more productive? Are they able to handle new things? Can we add a new line to something? And there's just a lot of things. And it's really everything in life. It's relationships. And stories are really good vehicle to try to have those relationships, talk about them and see how they can be affected by whatever solution you're building. So I got a question on that. So as you know, for all the years you've been doing this, and I'm sure you've got some interesting stories in the trenches, what are some of the, can you give an example of how this is a great experience getting the, doing the discovery and implementation, and then follow that with your worst or kind of your most challenging experience with pulling this information from your customer, your client? Yes, I have a good and bad with one client that I can think of in my, it was, there's good parts to it and there's bad. And it was a very large association, you know, multi multi million dollar, probably about an $80 million organization. They had disparate service lines. And when they brought us in, they wanted to talk about just something to do with their infrastructure, because of our NSP side. I mean, like, I mean, this is the biggest problem probably in most organizations, their RFP was not good. I think, you know, if someone could start a company that just focus on coaching people to build good RFPs, it would solve a bazillion problems, I would think. But we got the RFP and I went down and said, listen, we're not going to build anything off this RFP. We declined the RFP and told them why. And that's been one of our best ways to help get partners who said, here's what's wrong with your RFP and why you can't actually respond to it. And so when I went down there, and we did a story exercise with them over a couple days with their executive team walk through stuff. And that was really helpful in uncovering what the real issues were underlying it, they thought it was X, but they took the time and I think I really challenge every person out there that's hiring a company, take the time to have a company that cares to listen to you come in and walk you through a process. And, you know, I know, you know, I've been influenced by a lot of story brand and I've adapted some of that into a discovery process, talking about people's challenges and what their plan is, etc. But within that group, there's a subset, you talk about a bad part, where that person just refused to talk because a new change was coming. And they did not want to reveal and usually the folks at the top have a plan. And then the person below them, as soon as they start seeing what the questions are, and start having to talk about them, change is probably the worst thing for those folks, because they know they will never actually make it right. If this thing happens, they have their little fiefdom and they want to keep it. So I would say the challenge is getting people to engage. And the reason why it doesn't work is when you don't have leadership at the top that makes people with each. And for some reason, they didn't want to force that solution. Does that answer your question? It does, which I kind of have a follow up because I've had a recently a similar situation to a project I worked on where we gathered, most people were on board. But of course, you have your outliers that don't want to get involved in it has caused some interesting challenges. Sure. Do you have any tips on how to break these people out of their mold to get this information from them? Or kind of maybe ease the tension a little bit to help them be more engaged, even if leadership can't really like, it for lack of better example, you know, lack of leadership, or there just isn't a strong enough push to make people get engaged. Yeah, the folks that don't want to engage is kind of like that Stephen Colban loop where, you know, what we have here is people that don't listen. And they so we get what we get, right. And you're going to have probably a good three to 5% of people that are immovable. And usually I will sit down with the C suite, the CEO, the CEO, or whoever the champion of that initiative is in the organization. I'll say, listen, you have two choices, really, we either work with them and you encourage them, this is part of their job, that we need to move forward. Or what's three choices? Are you replacing them? That's a really two you replace them, either move forward or they get replaced. And I find in a lot of nonprofits and association, the will to do that is harder, because the job is a cozier job, generally speaking, in some ways, you know, and you're in the person has friends on the board, and this is politics get involved. So the way to overcome it, though, that we've had success in it, is it takes time. And I usually tell a C suite person, hey, we're not getting what we need. Let's not push this through as fast as you think we need to write. Let's take the time let me, you almost have to befriend and you have to help walk the person through where you know what their future could look like. And part of that is really understanding what their prop their pain points are. And having empathy for that, because really, at the end of the day, they want to know that they're more that they're valued. And if they don't want to be replaced, and you go, Okay, what would make you more successful at this job right now, regardless of what we're doing, and you start pulling that out of them. And you talk about what outcome would you like in this job? Like, how could what would you like to see in this department that you're working on there? And generally speaking, over time, you show them that you're not a threat, but you're an enabler to them. It's just like AI conversations with a lot of our clients, when we come in to put in an AI solution, or agentic automation of some sort, we stress that this is an enablement tool for you, it is not a replacement tool. The only time it becomes a replacement tool is if you resist. So kind of, you know, betterment of your solution, because, you know, especially in the commercial C suites, like you do it, or you don't, you know, you don't be here. So I always take it's about the relationship, starting a relationship, and we have some really good strategists, project managers, and account managers that are really good in coming alongside and positioning ourselves as their partner, not as a third party consultant, we're not the Bobs coming in and saying, Hey, you know, what do you say you do around here? We come in there and say, what can we do to make you happier at this job, more efficient at this job, and more successful so that you shine. And so that's really the route to do it's an empathy relationship side, or, you know, you get the C suite to bring in some pressure. Oh, great. Thank you so much. Yeah, I'm gonna talk back, I guess we'll flip back a little bit on the that whole that RFP comment. As I do find that a lot is that it's, it's like a crutch, it's really an interesting one is that like somebody will say, there's a there's a combination of that is that there's I think people get a hold of like, they'll hear ERP or CRM or something, you know, anything CMS, ABC, XYZ, it doesn't matter what they'll hear something, they'll be like, this is what it is, this is going to solve our problems. Yeah, like you said, and then you realize, no, it's not. And there's been RFPs, I don't know how many times I've seen RFPs big and small that they say, this is what we want, this is what we want to build. And these are the requirements. And you look at them and say, no, that is like, what you say you want to build, and what you're laying out is how to build it. Especially now, I'm wondering if you've seen this is where I'm going with the actual question is, like, have you seen this? Because I have in the last few months, if you say it's like, I guess getting worse in the last six months to a year or something like that, where people are now, I'm seeing people are using AI chats to go generate rate requirements on something. But they're not asking the right questions, basically. And so AI gives them answers, but not the way they need to, you know, it's not something that's actually helpful. Yeah, but I think a good RFP, here's the hallmarks of our piece that we'll look at seriously. When they have a business case, it's really articulated prior to actually asking for the solution they're looking for. So they identify the problem, they understand, they identify what the outcome they're looking for. And then they have if they do not have this, we will not respond, they have a budget that they want to apply to it. If you don't have a budget, you're not serious about solving a problem. And that's really where it starts. So a good business case that articulates the problem clearly, where they want to see the outcome and that's a good start. That's a start to talk. When you if I, you know, we actually do RFPs for other things in our company, and we do that, but we also want to say, we would like a discovery for we want to see what and we'll pay for discovery. I just did it yesterday. If you don't want a paid discovery, you're not serious about the solution because there's no company in the world that will understand your RFP and be able to live around it without them sitting down with you and having a number of conversations getting a bit of data. And sometimes it's a little bit sometimes it's a lot. But we really, we really tell clients that you should budget anywhere from 10 to 15% for a discovery of your out of your budget for a company you like that you think will fit the bill. And then that comes back and you do a Moscow, you know, must haves, you know, like to have and don't need to have. And that's what you want back from a discovery where they price out that so you can see where you're going. But I see a ton of AI generated RFPs, a lot of cut and paste. And I know because a lot of them are contradictory, and they don't think it's contradictory. And they really should have a consultant or RFP person help them develop that RFP if they're serious about making it and getting serious responders. The quality RFP is going to generate the quality of the responders that you have. And the last thing you want someone to do is giving you a yeah, that's your budget, we can do it. And then I just saw this with a CRM implication. They brought us in to do a needs analysis and create an RFP for this. We sent it out. And one of the vendors responded, yep, we can do this. We told the client, do not hire them. They have not done their own discovery. They have not articulated that they understand your business very clearly in their response. But of course, the clients like it's the cheapest one. I'm like, of course, it's the cheapest one. Yeah, of course. That's what it means. And so yeah, any any company worth its salt will will invest in the RFP process and discovery process. So when you're working with these companies, have you and if they don't have an RFP in place or they're still struggling to figure out what their problem is, do you have like a checklist or do you have any type of documentation or suggestions by them? 100% Okay. Yeah. So what what companies going to say, hey, can you help us with this? They don't have an RFP. That's fine. We'll do discovery. And what we tell them is you can take the discovery. And you can have us build an RFP for you and you can shop it out. You don't have to use us. But are we can use it and respond to the set RFP. I said it's a little bit of conflict of interest, but we want you to be able to see what you truly need first. Because if we don't know what we truly need, we're not going to be able to build it. So a discovery process if you don't have the RFP, and have a company that's really good at that and presenting a nice roadmap and understanding schedule, because there's nothing more glorious than receiving our P that actually has a Gantt chart and a budget. You're just like, that's amazing. We love these people. It might not be right, but they understand what what what it takes to go forward, right? Especially on enterprise type projects that are, you know, half a million dollars. So on the flip side of that, so if you're as you're advising these companies, looking for people responding to the RFPs, how do you help them weed out the good from the bad? Sure. So when you're like, so when we do this one project with this client, where we reviewed a number of CRM vendors for them, we created a requirements document that tied back to the business face into the story. And so here are the requirements that need to be implemented in this solution for the CRM to work correctly. And then we actually created a grading matrix for that for them. And so when we interviewed, I don't know how many, when I say we, I didn't do any of this work, our strategists and AMs did, when they reviewed it, they could actually create a checklist, and they create notes next to each one based on the answers that they were given. And so we could have a grading system. And so the client was, you know, here, this one's, you know, 92% capable of solving this. These 8% issues have to be resolved, this one's 80%, this one's 70%. And so you have eyes wide open. So you might want to choose the 70%, because of the 70%, those are the majority of the things that are really in your Moscow are key. They got the must haves, which are 70%. The other ones, we can phase to them. And we usually have an 80, 15, five rule we try to tell our clients is that you want to try to get 80% of what you want done in the first engagement part, if you're not going to get 100% perfectly done, but don't make the, you know, perfect enemy good. So let's try to aim for 80%. Things that are 50% of time that you need, let's face to this and see if they actually really are needed or you're going to accommodate some of them. If it's 5% of time, try not to accommodate education. That's where the price goes up significantly. So we try to have that grading matrix. We tie it again, it's a lot of science, but a lot of art in that. And it gives people, especially our clients, a good perspective and eyes wide open on what to expect. And when that translates into an SOW, it works out perfectly. Right. And you can say, oh, the SOW aligns perfectly with what we're expecting. Yeah. I think that's, I've run it for the few companies. It's gotten better, but especially in early years, I had to, you had to educate them a little bit to say like, this is part of the process. This is not, it's not like a throw away. This is not like you're going to go do this. And then all that stuff is lost and you start all over again. It's like, this is part of doing it right. One of the things I've run into, I'm wondering how often you've run into this. That's, I find an interesting, and talks a little bit about our earlier conversation about where you go in and you sit down with people and you see what they do and what their pain points are. And sometimes that evolves as a relationship evolves. They're a little more open about like some of the pain points or some of their little side apps that they use and things like that. It's really the same thing as we do an RFP and it's sort of like a straight up, how ever we do it, use it's like one to 10, what is it? Do you have it? And then behind that, there's a, then there's a secondary sort of a matrix that prioritizes stuff. Like you said, so you're going to say like, these are things we need. These are things we want to have. These would be nice to have. One of the things we found several times is that you trust the process and you build it out and you get down to, you know, usually it's actually pretty easy. I found that even with dozens or hundreds of people responding, you can actually get it down pretty quick with something like that to say, okay, we're going to go talk to Tim. But I've found more in a few times where you do that and you get into the bottom list, start getting into that short list and you get pushback from the customer. They're saying, well, this guy got a 90 and that guy got an 80, but we really like what the 80 is providing better. Which to me is like, okay, well, maybe we didn't prioritize these things. Right. I mean, some of it is like, I like that guy or that gal better than the other one, which I sure get that, but sometimes it is, it's at least I've seen that sometimes. I wonder if that's something you've seen as well. Yeah, that's, that's a really good point. Actually. I appreciate that Rob, because I think a lot of times in those matrices, it's the nuance that starts coming on. That's why we have that notes right next to whatever the grade is. And we go, you know, this person green low on the delivery of this, but I think they understand that holistic scope better based on that point. The other thing that's really great on the discovery is, and when you look at an RFP that's responded to after you've done that discovery, the ones that ask the good questions, the ones that are more question based responses in RFP, did you check about this? What about that? Are I feel like there's some shadow data over here that is, should be incorporated into this solution. So that's one of the ways that, you know, while we still grade it, we give recommendations based on the holistic view. Like while they don't have the experience in doing X, Y, Z, that doesn't matter as much as them understanding exactly what you're trying to accomplish because they solve these problems. Yeah, this is where it goes back to the art and the relationship, right? If the vendor actually has a comprehension of what you're trying to accomplish and the story and where you're going and writes themselves into that story very well and provides themselves as the guide to you very well, they're a better vendor at the end of the day. You know, I remember a story about, I think it was in Harvard Business Review about, you know, what's the best CEO or the best employee? And it's not the A student, it's not the B student, it's the C student. The C student actually understands how to get from point A to point B quicker and more efficiently and can see through the BS and doesn't, you know, dot every dot. And the reason why is at the end of the day that they know the long-term outcome, what will help them get to the end point more efficiently and actually address the root issues. Whereas the A student, you know, try to be perfect in everything, but that's, you're going to be stuck. I think that's for the companies that are the grinding companies that have the grit that go through it day in, day out and aren't all flashy about everything going perfect. They're the ones that I really admire because they actually know how to get from the point A to point Z and they know it's going to take a hard time and they're not trying to blow smoke. They're just going to grind right through there. I have a lot of respect for those. And that is where we're going to pause this first part of our interview with Dusty Gullison. And it keeps going. It's really a great time. First, I want to thank him again for his time and jumping on and having just really, it's one of these, it has been a great conversation. It's one of these states that like when you are surrounding yourself and getting input from people that have done the things that you're looking to do, you get a lot of great ideas. There's a lot of stuff that comes out of it that is, especially when you let them just talk, that is better than just throwing questions out there. You can hammer people with questions all day long, but there's going to be, to me, this is one of those where there's going to be things you don't know what you don't know. And I think some of those things come out and there was along the way, I was taking a few notes as well. Some things like, oh yeah, I should do that. Oh yeah. I'd forgotten about that. Bonus material for those of you guys out there. We talk about RFPs. We do have, and I think out, I don't know if it's available. I'd have to figure out where it's at right now, but shoot us an email at info at development.org.com for, we do have an RFP course. I think there's actually like an intro and then a more advanced one. A lot of the stuff we talk about here, it's in there, spend a couple hours investing, we'll, you know, in walking through it and we would be happy to talk about it. We've got some templates and things like that. Some of the things that we'd touch on here, but then we also go a little deeper about how to ask some of the questions and some areas that you need to make sure you cover when you're putting together an RFP. So it was just awesome for that to come in. So we will do a little bit of a shameless self-promotion for that as well. But let us know if you need any help with that because it is critical. It is so many projects. The RFP did not go well. And that's honestly why our consulting exists is to correct all of the bad starts and find ways to fix those. And at development.org, that's why we hope you will be a better developer. If you can understand these sorts of things. Thank you so much for your time. We appreciate you go out there and have yourself a great day, a great week, and we will talk to you next time. This was sponsored by RB consulting, your partner in building smarter, scalable tech from startups to established teams. RB consulting helps you turn tech chaos into clarity with proven roadmaps and hands-on expertise. Visit rb-sns.com to start your next step forward. Also sponsored by Envision QA, they help businesses take control of their software by focusing on what matters most quality, reliability, and support you can count on. Find out more at EnvisionQA.com. Thanks for tuning in to the Develop the Newer Podcast, where we're all about building better developers and better careers. I'd love to hear your thoughts or feedback. So drop a note to info at developthenewer.com. Be sure to subscribe on Apple Podcasts, YouTube, or wherever you listen. And remember, a little bit of effort every day adds up to a great success. Keep learning, keep growing, and we'll see you in the next episode.