Ep. #925 - SDLC: Planning

Matt DeCoursey 00:01
And we’re back for another episode of Startup Hustle. Matt DeCoursey here with Matt Watson. Hi, Matt. What’s going on, man? Trying to build a plan?

Matt Watson 00:10
Yeah, what is the plan? What are we doing?

Matt DeCoursey 00:12
I don’t know. I mean, there’s so much that goes into a plan. I’m not even sure where to start.

Matt Watson 00:18
The plan is there is no plan.

Matt DeCoursey 00:20
The plan is we’re going to build software, right?

Matt Watson 00:23
People always hate it when they say that to me. They’re like, what’s the plan, Matt? I’m like, is there no plan?

Matt DeCoursey 00:28
Well, I think our first plan is to call Full Scale. Yes, FullScale.io. Let’s find some people that know how to sell software. So, with that, it probably seems appropriate to mention that today’s episode of Startup Hustle is powered by FullScale.io. Because hiring software developers is difficult. Full Scale can help you build a software team quickly and affordably. And has the platform to help you manage that team. Go to FullScale.io to learn more. All you have to do is answer a few questions, and our platform will help match you up. I believe that you have recently done that yourself. Map for a project.

Matt Watson 01:06
Yeah, yep, scaling up. Maybe we need some help to get and scale this thing up.

Matt DeCoursey 01:12
Here we are. This is part two of our foray into the SDLC software development life cycle. And it’s time to create a plan. Now, as we mentioned in our overview, which was the last episode, this is the first part of seven pieces that many people refer to when it comes to the software development lifecycle. So that’s planning, defining requirements, design and prototyping and software development, testing, deployment, and then operations and maintenance. We will have an episode on each of those. But it’s time to talk about planning. And you know, as we mentioned, the overview so many times, you can have a real plan, sometimes you don’t. And sometimes, you throw the plan out the window and make a new one.

Matt Watson 02:00
Well, and I think for a lot of software projects, success or failure comes back to the planning, you know, and you know, I manage a software development team, I manage the product team. It’s our hardest, hardest, probably the hardest challenge, and our number one job every day is to plan what we are going to do. And why are we going to do it, and then herding cats with everybody else around the organization and to actually get them to agree on what’s important, which is really hard to do because I’ve got everybody to agree? And then I gotta go get my team to actually build it. But getting people to agree on what to do. Creating a plan is the hardest part, sometimes.

Matt DeCoursey 02:39
You might be sitting here chuckling because that might be the hardest of all of it. And you know, obviously, a plan doesn’t mean shit if you don’t execute. So that’s a whole nother . . .

Matt Watson 02:47
Everybody has different priorities, right? Especially in the corporate world. And in a larger company, you go around, everybody’s got different ideas about what’s important. And we need to do this thing when you do that thing. And then the development team themselves has their own stupid little pet projects that they want to do. They’re like, well, we want to upgrade from version one of Angular to version two or, and then the other developers like, we don’t like Angular anymore, we want to switch the view. And like, just all this other shit. Everybody has their own idea of what they think is important. And the biggest problem in a lot of companies is nobody has the guts to tell everybody else about all that bullshit and actually do something important. That’s where everything dies in the corporate world.

Matt DeCoursey 03:25
I hope you’re not so on Angular version one because I think they’re up to, like, eight.

Matt Watson 03:30
We won’t talk about that.

Matt DeCoursey 03:31
Yeah, it goes on and on. But you know, what Matt’s talking about is that, you know, we’re talking about frontend coding framework. And, you know, that’s where he’s right. You know you get into these things. It’s like, one person wants to build in this, they want to build it in that. And you know, how many now that there’s a joke, you know, how many software developers does it take to build a product? One, it takes one to actually build it. And seven to say, Man, I sure could have done that better. You know, and it’s so variable when it comes to this stuff. And everyone’s, you know, one of the things if you’re planning on building something, I’ve run into this a lot with the early stage startups. And, you know, they reach out to Full Scale, and they’ve got, they’ve got some weird, like, the 47th most popular type of programming language out there, and they’re looking for help. And they’re just baffled that they can’t find it. And I ended up talking to these folks. And I’m like, Well, how did you decide on using that? Well, my friends, cousins, brothers, sisters, and relatives told me I should. Yeah. And part of planning also depends on, like, you know, there are software frameworks and platforms and coding languages that are on the up. And there are ones that are kind of singing their swan song. So I think part of when you talk about planning, you’re going to talk about resources, costs and time and stuff like that. But part of the resources thing is like a subcategory of that is like what are you going to pour your resources into? What are you going to build stuff with? You know, like, I mean that would you buy a Tower Records right now like a record store isn’t a very good investment? That’s on the downswing? How about a blockbuster? There’s one of those left. It’s like a museum, but certain things are on the come up, and some of them are on the way down. So I think, before you get started, if you haven’t built anything yet, then I think that’s a good place to start is like get on getting on the trend of something that is moving upward, and seems to be popular, because when it comes to finding resources, meaning human resources, and people, you want to be able to find them because you can have a great plan. But if there aren’t any, if there are no carpenters available to swing hammers and pound nails, then your plan is already dead.

Matt Watson 05:51
Well, and so at Full Scale, we see this a lot, right? We talked to these companies, and they’re like, Yeah, we had the CTO who worked with us, and we were his little side project. So he decided it would be fun to use this really a-centric database that literally nobody’s ever heard of, like, can you help us convert away from that thing? We hear that a lot, right?

Matt DeCoursey 06:15
I’m looking for a senior XYZ developer, and it’s something that’s been a year.

Matt Watson 06:20
And yeah, you’re absolutely right. The key is that there are like six programming languages now that are the most common. Just pick one of the six, it almost doesn’t even matter which one of the six, and you can build shit, and you can hire people to do it. If you pick something outside of that six, God bless you good luck finding talent that can help. And it’s the same thing like yeah, just use Amazon Web Services use Azure, you know, use Angular view, react, like using these common frameworks. If you’re trying to use this other weird stuff, it makes it so much harder to find people to train people. It’s harder to solve problems when you have problems with them, right? You’re like, I’m trying to do this weird thing in Angular. It’s you can probably find something on StackOverflow that has had that problem. And you can find a solution to it versus if you pick this weird shit, nobody knows.

Matt DeCoursey 07:02
Yeah, so I think that you know, when it comes to planning, the first thing is to make sure your plan is something that, I mean, can become a reality. Yeah, it’s like his mountain answer. Now, in a lot of cases, the SDLC is going to apply to platforms that are already in motion. And then sometimes what we’ll refer to as legacy platforms, which are really old. And, you know, you see a lot of people trying to convert away from them because they built something in a dying technology, something that isn’t actively supported. And really, the struggle is real because there’s already a shortage of software developers in North America, which is part of the problem, you know, that’s part of what Full Scale helps people solve is how to snap the pieces and the components on the existing team to scale it up. And you know, we, we built a company, we kind of started it accidentally, because we have these needs ourselves, and we’re like, God is hard to find people that can get shit done, maybe we should create a solution that makes it easier for that. So if you’re not, if part of your plan, if you’re creating it, and you don’t have a high level of technical skill or knowledge, you know, whether it’s Full Scale or someone else, you know, find a good service partner, and some of that can give you good advice. And that has, you know, readily available resources or access to and with that, you know, that’s where we mentioned, like the first pieces of the planning, you know, the resources, the cost and the time, because, you know, back to the king of the punctuation mark on the end of this whole thing is, is if you have a very small pool of people to choose from, they might be in really high demand, because other people made that same error. So you might end up paying 40% more. Do you pick something that’s commonplace? Well, PHP is a good example. There are a lot of PHP developers out there, and they trend a little lower acquisition costs in hiring than certain other things that might be highly specialized. And then, you know, part of what’s also a challenge, too, is you have a lot of emerging technology, like people, I need a blockchain developer, there’s just not a whole lot of them out there. And, you know, that’s changing over time. But you got to kind of, you know, and part of where you don’t want to run up your time number is spending all your time looking for people that can actually put in time on it. So, yeah.

Matt Watson 09:18
In summary, the key is you have to have the resources. You have to have the talent you need to achieve whatever it is you’re trying to achieve. But the hardest thing for me when it comes to planning at an executive level is just getting everybody to agree on what is the most important thing to do. And, you know, I have this problem with my current job. It’s like, you know, I understand the product. I understand the roadmap and understand what we need to do, but I still buttheads with other executives around the company that doesn’t agree with me or think something else is more important. And some of it is because they’ve never built software before and they don’t understand what’s important, or they have a different vision for where the company is going or whatever it is right, or they have their own little projects. And that the hardest part is from a highly strategic plan, like starting at a high level is getting all the executives and managers to even agree on something.

Matt DeCoursey 10:10
Do you know that according to our notes here that 75% of the business or IT executives feel that their projects are usually doomed right from the very beginning? Yep. WTF, dude?

Matt Watson 10:26
No, no, it makes sense. I mean, it makes a lot of sense.

Matt DeCoursey 10:30
That’s crazy. That’s just crazy.

Matt Watson 10:33
When you think from a planning perspective, from a very high level like an executive, like an IT executive, the first thing you gotta do is, have company goals, you gotta know whatever, what are the goals, and everybody’s gotta agree on the goals, right? And then, once you have those goals, you can create initiatives that support those goals, right? It’s like, we want to do X, Y, and D, well, how are we going to get there? Well, we need to do this, we need to do this when you do this. And it’s no different than having like, OKRs, what do you remember what the hell Okay, or even stands for . . .

Matt DeCoursey 11:03
Assess objectives and key results. There you go.

Matt Watson 11:07
So a lot of companies will have OKRs that are, you know, across the company, and you know, every department has their things to support the OKRs, all that kind of stuff. And the product, you know, in engineering is no different, right? We have our role to play, like, whatever the company’s goals are, how are we going to achieve them, but the biggest challenge is getting everybody else to say no to everything else. That’s always the problem when it comes to planning. Get everybody to agree on what is actually the most important and what is going to provide the most value to the customer. And that’s the thing I always have to fight with, against the engineering team, right? As the engineering team thinks, we need to, like, convert this thing. And we have technical debt, and this DevOps project and all this shit. And I always ask them, like, Okay, but how does that help us make more money? How does that help us improve the value of our customers? How are customers going to benefit from all this? Because this isn’t like a government job, we aren’t just wasting time, like digging holes in different places for whatever purpose, like we need to deliver value to the customers, right? And that the hardest part about planning is getting everybody to agree on things like how we actually do something that matters and provides value to the customer.

Matt DeCoursey 12:16
I think you have a really good point with talking about the word initiative. And the definition of initiative is the ability to assess and initiate things independently or the power or opportunity to act or take charge before others do. So when you can say to someone, hey, take some initiative here. And yeah, you know, eventually someone has to, and that’s where you talk about this as part of planning. Sometimes you just have to define the roles on the team. And if you don’t, you’re gonna end up with, well, some people will take the initiative, some people won’t, you know, and it can be a real challenge. And, and, you know, Matt, back to your point about the development team seeing things as having a different sense of priority, really, in the end, what you’re building at your business as a business, and if what you’re building doesn’t keep more users or bring more users and it could be misguided, and what you’re trying to build and like where its priority as now, you mentioned the term technical debt. And I think we should talk about that because part of the planning process should involve trying to minimize that. So technical debt is and uh, you know, I’ll look up a definition of that, but the layman the true definition, but the layman’s term is basically all of the shit that you do incorrectly, or didn’t know that you needed to do a certain way that you end up needing to redo.

Matt Watson 13:44
Yeah, or stuff that just ages out. It’s like, you know, we built this in this old version of Java. And now it has all these security issues. Yeah, because it’s old. And now we have to upgrade to this new version of Java. But because of that, we got to do all this crap that we have to do like all this work, you know, and it’s inevitable, there’s always a certain amount of technical debt that you have to do. And what I always say is like, you always have to balance the things you need to do, you have to do, and you want to do, you’ve got to have a mixture of those. But if you always focus on the things that you like, and want to do, then you never pay off that technical debt, or you never fix the certain bugs or whatever it is. So it’s like you always have to have a balance of these things. And it requires a healthy balance.

Matt DeCoursey 14:26
And you can certainly with technical debt, you can really, you can, in fact, run into a point where you accumulate enough of that, that you’re essentially trying to fix one thing and you break three others is probably the basic way to put it, or you run into certain things that are unfixable, or it’s like the idea that just to get to your backyard, you have to climb over a small an ever increasingly steeper and larger hill, you know, and just kind of keeps getting higher and you’re like shit, I’m just trying to get out to my backyard and should only be 10 steps away, but You’d have to go through 40 steps just to make 10 steps. And that starts to chip away at your ability to turn things out to fix things quickly or to just kind of produce something that isn’t really frustrating to work on. So, okay, so that some, you know, we’ll get back into some of that now, you know, obviously not when it comes to planning, and it comes to budgeting and things like that. And I mentioned in the overview that I felt like budgeting should almost be its own step. It is technically a subset of planning. We were pretty open about the fact that timelines are our hilariously. I made us predict. Yeah. And so how do you actually create a real plan without, like, Okay, so we’re, if you’re doing something from scratch, like, I mean, it is realistic, it’s, it is fairly realistic to say that no one knows how long it’s gonna take you to build it. So how do you create a plan around something like that?

Matt Watson 15:58
Yeah, so there are a few different methodologies that software developers use. One of the simplest is like, you look at things you kind of assign it like a T-shirt size, okay? It’s like there’s a small, medium, large, extra large, you know, five extra large, you know, tons of projects or talk about like bread sizing, is it a slice of bread, a loaf of bread, a bread box, a bread truck, a bread factory? Pick, pick whatever you want, right? But it’s trying to get some kind of the reasonable size of the level of complexity of this thing, right? Like, it’s like, okay, am I building a house or building a 100-foot skyscraper here, like, we’re somewhere in the middle, and just trying to produce some kind of rough estimate. And the hardest part is always trying to understand the velocity at which the team can accomplish things. And then, you know, how much capacity do we have? You know, like, how much work can we do like an assembly line, because at the end of the day, software development is kind of like an assembly line. It’s just really hard to measure, though. Because no matter what you do, there’s always a massive amount of unplanned work. Like, I was recording a podcast earlier today. And we use some call tracking systems at work. And for whatever reason, they changed some shit and screwed it up. So now our team is spending time on that today. They were part of the plan. That wasn’t part of the capacity. That wasn’t part of the velocity. But that’s what we’re doing today, is screwing around with fixing that shit. And so that’s the nature of part of what we do. Like there’s so much unplanned work that also sidetracks everything.

Matt DeCoursey 17:28
I think people are the hardest part about planning a timeline because some people do things quickly. And some people don’t. Yeah. And you know, and that’s the thing that’s like, it’s not just a linear path. You know, like, I mean, it’s almost like that. I hated those math problems, where they’re like, train A is going this speed and train B is going this speed, you know, it’s like, but that’s really what people are. And you know, people are exactly that, they’re people, they have other issues and things can occur, they could be sick, they’re gone. You know, like, I mean, you never know, they quit. I mean, a lot of different things could happen. You know, speaking of quitting now, if you need to find developers to work on your project, finding expert ones can be difficult. And if you visit FullScale.io, you can easily build your team quickly and affordably use the Full Scale platform to define your technical needs. And then see what available developers, testers, and leaders are ready to join your team. Visit FullScale.io to learn more. Now you talk about who can do things on a team as we’ve actually created four dozen differences of our own certifications because we started looking at our developers and people we wanted to hire. And you remember, like, how do you assess when you’re trying to build a team and plan for it? How do you know if people are really good at it? And we found that people weren’t very good at figuring that out. So we build our own system of certification and kind of life and die by that at this point at Full Scale, meaning like we’ve had 1000s and 1000s of people apply and take these assessments. And we have a pretty good idea about who’s going to be good at what. But that’s, that can also be a thing, if you’re trying to build a new team or a product, I think it’s fair to say that if you’re not, if you’re kind of going at it alone, and you don’t have experience finding people, some of them are going to wash out along the way, which is also going to affect your timeline because you gotta find new people to get in the seats.

Matt Watson 19:17
Well, when you’re planning, having somebody on the team that is very experienced with architecting software products or working in a product team who has done this for a very long period of time is super, super valuable. Because you need somebody that can like see around corners that knows where you’ve got to cross the t’s and dot the i’s knows where you need the gold plate things and where you don’t gold plate things right like that’s always the problem with software when you’re trying to do the planning is you got to be able to see ahead, you got to have some vision and understand where all the landmines are going to be of why this problem is going to fail or why this prop this project is going to like get way He slowed down like seeing ahead of like, well, we have to figure out how to deploy this thing on AWS, we have to build all this DevOps pipeline, and that’s going to take like two months. But if I don’t think about any of that shit, and then we get to the day of deployment, we’re like, hey, we need to deploy this thing. Oh, wait, we forgot to build that thing. That’s gonna take two months, right? Like, being able to see around the corners. And seeing a head is really important when it comes to software because there are all sorts of landmines along the way.

Matt DeCoursey 20:23
Well, that’s where you talk about the roles on the team and what you are, that you actually just describe two different roles, because there’s a difference between software development and manager, and a product owner-manager. And, you know, people that are product managers, and you know, a product manager is, I mean, I, the product manager has been around for a long time in the professional workforce. But for software, that’s still a newer thing, and you look at a lot, so a lot of people built software platforms, and for example, realize that their user experience, or maybe it was just clunky, or whatever. So then here comes the actual product manager. And I’ll just give the best example I can from what we do. So we have a product manager that I work with and you work with on the Full Scale platform. And what this person does is we’ll be able to, her name’s Julie and Julie, you do a great job, thank you. And we can reach out, and we’re like, you know, so our users are finding it, or are finding it difficult to use the search feature, because now we have 300 people that work at Full Scale, and they all do different things, and they do it better, and some don’t. And, you know, and like, are they available and all this, so we’ll describe what the problem is. And the product manager will scope that out and say, Okay, so this would need to occur, then this needs to occur, then this needs to occur. And this is how we’re gonna do that. And that person doesn’t even need to be a developer. In a lot of cases, as you had at Stackify, your products manager wasn’t a developer, was he?

Matt Watson 21:59
He had been formal, you know, and, and already with it. And where I work today, our product owner has no background in engineering, but his expertise is in digital advertising. And so our product is related to digital advertising. He’s the product expert. He understands the key to the product owners. They need to understand why, like, why are we doing what we’re doing? A lot of times, software engineers don’t give a shit. They’re like, you know, give me a hammer and some nails. And I’ll go do it just. Just tell you where to go. And I’ll go do it. But somebody’s gotta tell them why. And the product owner needs to understand the why, like, why how the product was supposed to work. And why does it work that way? That’s somebody got to be an expert at that.

Matt DeCoursey 22:39
Now, we’re sitting here talking about roles on a team. And we’re assuming that everyone listening actually has a team. If you have a tiny team, or even just like one person, you probably want that one person to be too. You want them to be a Swiss army knife, not a sword. They’ve got a lot. Like you can’t, if you have a tiny team, you cannot afford specialists.

Matt Watson 23:04
The problem is most software engineers are not really good at writing code. A lot of them are just not very good about thinking about what the product needs to do and the user experience of all of that. And that’s why a lot of times you see software, it’s like, whoever built this, like, yeah, they made it work, but it’s just very clunky.

Matt DeCoursey 23:22
Why do I have to click through six different things? Why do I have to go to different pages where I could do it all on one, and then and that’s often a thing that you’ll look at something you’ve already built? And you’re like, Okay, we can make this a little more streamlined.

Matt Watson 23:36
And their answers like, you probably remember, Dan, that worked for us, the Sci-Fi great guy loved and, but his answer for something like this would be like, did you read the manual? Like, dude, no, it needs to be easy to use? The answer is not to go read the manual like that. No.

Matt DeCoursey 23:51
Yeah, I think that’s yeah, so I’ve got a, I’ve got a when it comes to planning, I’ve got, you know, my role one with all this stuff. Is this annoying? And if the answer is not a hard No, you have work to do. The things that even products that do 100% of what you need to do from a utility standpoint can have really annoying parts about them. And you need to get it when you’re planning. You need to think about it if you like, so if people are annoyed with what you’ve built, they won’t use it, or they’ll hate it, or they’ll resent it. And some of it is like you mentioned, like when it comes to planning this general user experience of having things not being annoying, like if you’re sitting in front of platform X and you’re doing your job, and you have to do something 200 times a day. Those extra clicks or page loads or any of that get really frustrating after about an hour or so. Yep. And also, they’re not scalable, too, because we get a whole bunch of people in there, and they’re all refreshing pages unnecessarily and doing a bunch of stuff like that. It’s all going to slow down. So, I mean, part of planning is also like, you know, what do we want, I just keep it simple, I think is the best thing. I think in the end, the best software, the best signups, the best onboarding, the best user experience, it’s all simple. And when you hear the word intuitive a lot, you know, we’ll get into that a little later in the series. But give, you know, I don’t know what my options are as the first time, or maybe an infrequent user or something I don’t really understand, okay, what can this thing do?

Matt Watson 25:31
So that when you’re doing high-level planning, as a management team, about the product, and the big initiatives that need to be done, the most important thing you can do is always measure and weigh out the level of effort versus the level of value, right. And there are tools like Aha, we use Aha, it’s a product management tool and, and you can go in it, you can create your goals and create your initiatives and create your major features and major things you want to do. And it has all these tools to help you force rank them and all this stuff. But no matter how you do it, you can do it with frickin sticky notes, or doing it on a whiteboard doesn’t matter. At the end of the day, you’ve got to pay attention to what is the level of effort versus the level of value. Because if you have something that takes a massive amount of effort to do but provides no value, why are you even talking about that shit? It’s dead. Right? Versus, what are the things that provide a ton of value? They have no effort, like, maybe we should do that one first. Right? So force ranking stuff that way and thinking about it that way is really important. There are a lot of different ways to do product planning and ranking, you know what’s important and all that, and depending on your company, it’s all totally different. I really recommend a product like aha. It’s like $70 a month or something like that for one user account. It was really inexpensive. But it’s a great tool to do higher level planning, you know, above the weeds of using something like Jira, that’s more you know about individual tasks, you got to do a little higher level product planning. But just basic, like level of effort versus value, is a great place to start. And you can do it on a whiteboard.

Matt DeCoursey 27:02
Probably shouldn’t be mentioned in the 27th minute that if your plan isn’t written down, it’s not a plan. Yeah, probably should have led with that. So for those of you that made it to this point of the show, congratulations, you learned the most important part of a plan. And I mean, for real, because if it’s not, if it’s not, if it’s not something that everyone can see, because and I’ve been guilty of this in the past where the vision or the plan is in my head, and then you’re kind of hoping that you’re very quick meeting your explanation of a transferred all that magic to everyone else’s brain which then just got it with a crystal clear vision, and well, it has probably done.

Matt Watson 27:43
I am an IT executive. I work on planning a lot. So every couple of weeks, I have meetings with our CEO and our Chief Operating Officer, and all these other people. And I’ve shown roadmaps like, here’s our roadmap. So we use JIRA for that. And we always have, like, you know, always updating the roadmap and trying to juggle what everybody’s priorities are. And it’s hard, everybody, you know, you don’t mention something in the call. So then everybody bitches for 30 minutes about this thing. That’s the most important thing. But then they failed to see it was actually on the roadmap, and then they go off on some giant tangents. And it’s a never-ending battle. But the more you can have a basic roadmap and have everybody on the same page, we’ve all agreed this is what we’re going to do. And then you gotta tell everybody no to every other damn thing that becomes the hardest part is everybody wants to take you off what we all agreed was the roadmap.

Matt DeCoursey 28:34
Yeah, and what, and while building this stuff in your product timeline and roadmap, remember, there are certain things that are going to need to be done and ready and built and functional before you can move on to anything else. And we use the example of Gigabook and like picking a couple of things and what’s the core thing you do? Like you would get a book, it’s taken an appointment. So like, if we’re working on rescheduling options before it could take an appointment. That’s just stupid. That doesn’t make any sense. Like, yeah, and you’ll find that in your timeline, you’re going to invariably run into something where the lack of completion of one thing is going to stall the beginning of something else. And that’s where you start and look. People think okay, so I built this first layer of something. So the second layer should be equally difficult. No, it’s actually twice as hard. And then the third layer of that is four times harder than the first one. So when you start building software, a lot of pieces, parts, and components become interdependent on each other. And I think that early in building something, that’s where you hear things are a little unstable. They’re buggy. You’re sad, and you got to map these dependencies. I think it’s a really. I wish I had done more of that when we built Gigabook because the problem is, when you bring new people into the team, they’re just not going to understand. Oh, if I change something here, it could break eight other things here, and this is why this, this mapping of what things are due and what’s dependent on other things, becomes really important. So and that’s that back to that order of operations. But how’s that going? What are the plus and minus things before you divide them? And I never again, remember? And that’s probably why I end up with a weird answer every time.

Matt Watson 30:16
What are the other really important parts of planning that everybody always overlooks? It’s not just about the software engineering part of it. You’ve got a lot of time in planning for, like, how do we deploy this thing? How do we educate the sales team, the support team, the marketing, and the product marketing need to be done? How do we celebrate what we did and make noise? And somebody cares about it? You know, how do we train everybody about this thing? And that’s one of the things that a lot of people fail to do is like, hey, if we’re going to release a new feature in Gigabook or whatever, right? Like, how do we tell everybody at the company about it? How do we tell our customers? How do we, you know, how do we celebrate this thing and get some value out of it? Right? If we did all this work? How do we maximize the value we got out of it? And the bigger your company gets, the harder this becomes, right? You’re like, Hey, we want to change the pricing of our product, we want to have this feature all of a sudden becomes really hard. It’s like, how do we train hundreds of people, the fact that we’re making this really critical change, and the bigger an organization gets, it becomes harder and harder to make any changes. Because of that, it’s crippling because the ship just doesn’t move. But when you’re really small, you can make those changes. But People always forget the amount of time it takes to train people and do product marketing, make noise and get the maximum value out of the work that you did and celebrate it.

Matt DeCoursey 31:39
I think there’s the same for that if the feature launches in the forest, and no one hears it, did it really make a sound? Isn’t that true?

Matt Watson 31:46
Yeah, why did you do it? What was the point of the work?

Matt DeCoursey 31:50
These are? These are little things like I’ve run into with our own stuff that you know, and I’m juggling many things. And sometimes I’ll go back, I’m like, Hey, is this down there? Like it was done a month ago? Tell me. Yeah.

Matt Watson 32:04
And that’s always the hard part when you’re doing software development is you’re working on these big projects, and sometimes very slow moving, and eventually there’ll be this big thing that happens. But I always recommend people to always constantly pepper in the little things, you know, always do the little wins. It’s like, every month, we did these three little things. Maybe they did little things. But it’s like we’re making progress. We’re doing stuff, right? That way, you can tell your customers, look, we’re investing in this platform. We’re still innovating. We’re still doing new cool stuff. You still want to be a customer of ours, right? Not like, Well, we haven’t heard from you in like 12 months, and then you do this big release thing. Like, you know, keep telling your customers to do that product marketing, give some reason to message them, and have a reason for your product team to like, feel like they’re accomplishing something. And shipping something.

Matt DeCoursey 32:48
I think you have a great point there, Matt, because when you’re okay, you always have that old phrase where someone went postal, you know, because the mailman used to kind of go crazy at the mail plant every now and then because it just keeps coming in. They’re never done. It’s never complete. But your development team can feel that way too. Because a lot of times, they’re looking at this big backlog of tickets, and they’re looking at a two-year timeline. And they’re like, it’s easy to feel like, you know, they say a watched the clock never moves. And so something Yeah, celebrating the little wins can be pretty good. And when you were mentioning that, you know, it’s like, well, here in Kansas, where basketball fans Rock Chalk, Jayhawk, congratulations on the national championship this year, right? But I was like, very good chance to mention that. That, you know, a good team doesn’t just shoot threes. I mean, they make some layups, and they pass the ball, and they do it, you know, because if all you’re doing is dropping half-court shots, you know, I mean, it’s well, that’s not a high percentage kind of thing. And you’re probably not going to win a lot of games either. So yeah, I think that the, you know, that’s back to the whole thing, like remember this, your team is people. And that’s the hardest part in many cases about the planning. We mentioned that in the overview episode. So here’s another thing that I think we need to get into, as you mentioned, like the level of effort versus value, that’s there’s a buy versus build thing out there. Absolutely. That is something that should really be considered because there are a lot of things that you can basically rent, you know, by licensing a couple of things. And they might fill a gap or get some stuff done and let you go work on other things. And it might move you forward in your timeline significantly.

Matt Watson 34:36
You’re absolutely right. And developers have, at least traditionally, always had a bad habit of this, like, instead of just using some common framework or spending $100 to buy this SDK or whatever, they can do this thing. They’re like, well, I’ll just build that, like, no, let’s spend $100. And let’s do it. And like I interviewed a guy on the podcast the other day, and his whole thing had to do with alternative investments for IRAs. So it’s like, oh, you have, you know, crypto or stocks or all these other things, I’m like, hey, the last thing you want to do is figure out how to be a custodian of stocks and be a custodian of cash and a bank and be a custodian of crypto, it’s like, no, just find partners that already do all that stuff and, and integrate them together and build on top of it, right? Like, there are so many things in software now that it’s sort of software assembly, it’s like, we can take these pre-built things via integration with a bank or whatever it is, and build on top of it. We don’t have to reinvent the bank and figure out how to comply with all that, or some SDK or whatever it is, and Azure hosting thing, AWS. So just use what AWS does and build on top of it. Don’t reinvent that shit.

Matt DeCoursey 35:41
We even talked about people like, hey, I need to build a dashboard, go spend $39 Yeah, and buy a template. There are two more like we want it to be original. It will be by the time you’re done with it. Because that $39, And I’m not kidding, you really can go buy really nice admin dashboard templates, in modern everything that are highly used and supported and updated. How are you going to build that faster yourself?

Matt Watson 36:08
And the problem is, if you have a bunch of cabinet makers that work for you, they want to build custom cabinets all the time. But if you can go to Ikea, and you can shortcut that shit. Sometimes that’s what you need to do.

Matt DeCoursey 36:20
Maybe not at IKEA, because I think it takes like nine hours to put together. But I mean, But your point is like, you can go to Lowe’s or Home Depot or wherever you just buy the cabinets and just under the walls, and they make really nice ones. Yep, you can stain on whatever color you want. Yep. I mean, because it’s gonna take a while and some of the tools also like the tools, the parts, the accessibility. And then and then let’s talk about one thing. So Matt, you know, I went to five different colleges. And I dropped out of all of them. The last one was actually a top 10 Business School. And one of the things that meant the most to me and that stuck with me was opportunity cost. Yeah, that’s what we’re talking about right now. So when you choose to do one thing, it means you’re choosing to not do something else. So with the buy versus build and the value that like the return on value thing. And also like your timeline, like you might I mean, they’re like we’ve been saying there, you might be a couple $100 away from some kind of framework or plugin or use of another something else, someone else has already solved this problem, and they know you’re going to need it away from you know, moving things forward. There might even be two or three different things, and look, later you get down in the timeline, you might be like, Oh, we could go back. And maybe I find that the things that I’ve bought rather than build, I still use because the cost of going back and rebuilding them is, it’s just it grossly exceeds either open source stuff today, what I’m paying for what I bought, or what we’re renting, or there’s just other things that are more important. So yeah, opportunity cost is the value of the foregone conclusion. And it’s also something that you can’t really have a right answer to in a lot of cases because sometimes your opportunity costs might be your own sanity. You know, like hey, I or things that you missed out on and other parts of life. It doesn’t always have a financial tie to it. Now speaking of finances, if you want to build your software development team quickly and affordably. We can help with that at Full Scale. We have the people on the platform to help you build and manage a team of experts when you go to FullScale.io. All you need to do is answer a few questions and let our platform match you up with fully vetted, highly experienced teams of software engineers, testers, and leaders at Full Scale. We specialize in building a long-term team that works only for you to learn more when you go to FullScale.io. So you know, Matt, we dropped a lot of things in here about planning. We talked about goals and initiatives. I think one of the things is to find someone who has some initiative if it’s not you. Yeah, I mean, go-getter that’s gonna just not sit around and what do you what you are like to say? Where’s Tom Brady?

Matt Watson 39:05
Yes, yeah, I’ve seen this before. Right. They’re like they want to hire interns or whatever to get shit done. I’m like, No, Where’s Tom Brady? We want to win.

Matt DeCoursey 39:14
Need to have one relax to say Patrick Mahomes.

Matt Watson 39:17
Yes. Yeah,

Matt DeCoursey 39:17
Let’s get rid of . . . I’m tired of Tom Brady. Where’s Patrick Mahomes when we need them but find an MVP? I mean, find someone that can really like run the squad, and maybe that’s you can have that someone else but yeah, I don’t think anyone. I don’t think any team’s not winning championships because they have too many Mbps.

Matt Watson 39:36
Gotta have a quarterback.

Matt DeCoursey 39:38
Also, talking about timelines, they’re impossible to figure out. Just get started, and maybe you maybe reassess where that’s out. I think that that is. I think you can spend a hell of a lot of time really trying to solidify a timeline only to be wrong.

Matt Watson 39:53
It’s like business forecasts are all going to be wrong.

Matt DeCoursey 39:55
I think if you’re not establishing the roles on your team that your plan is doomed.

Matt Watson 40:01
Yep. Yeah, absolutely.

Matt DeCoursey 40:03
Who’s gonna do what? Who’s gonna make some decisions and then empower people to make some decisions? Because one thing that’s gonna slow down your timeline is making someone stop to ask really simple questions. I have my rule of Yes. Which is, if you think I’m going to say yes, 90% of the time, don’t ask, just do it. And I’ll deal with the 10% of the time. You’re wrong. People are going to want to have that we talked about the level of effort versus value, which in some cases is to buy versus build. I mean, dude, there’s never been a better time to buy a simple solution. And now, shortcut. Yeah, shortcuts aren’t always bad. Now, do you want to talk a little bit? When you talk about force ranking? What was that again?

Matt Watson 40:50
You know, trying to figure out what the highest priority is, right? You have to go through and rank everything, you know, could be like me and me, you and other managers all get together, and we all rank things. And then it’s like, oh, you ought to pick one. Number one, number two, number three, we’re gonna give it about four to 10. They’re dead. Right? You’re one to three. That’s what we’re focused on the rest of the shit. Forget it.

Matt DeCoursey 41:11
Yeah, and you’re in and out of business. These are things that make or save you money. And if they do both, even better, perfect. Yeah, so more, spend less. If you can do both, pick that one. Those are the best ones. Those should have double value because those are the most impactful things on the business. And, you know, you talk about OKRs objectives and key results, you have a system, have some goals, maybe celebrate some wins, and how are we going? Yeah, you know, I like, I like, I like calling out those that drive victory. And I really do like your point, Matt, about you know, don’t just take on mammoth epic things like, you know, any big, big, big thing you’re gonna do in life is really when you look at it just comprised incompetence, it’s a compilation of a bunch of little small things. And yet the elephant one bites at a time. So you know, like, I mean, as long as you’re taking bites, you’re moving forward.

Matt Watson 42:20
And if you can figure out how to get little wins along the way, that’s the thing. I mean, sometimes if you’re waiting to release some giant new product, like, you know, it’s a big bang, that happens later, but figure out how to provide, you know, small doses of things to celebrate along the way too.

Matt DeCoursey 42:35
And I think one thing that I want to add in here, as well as also listen to the feedback from your team, as you know, you start with the plan, and then you know, you need to like, you need to encourage people to not be just totally. Yes, people like, Hey, this is what we’re looking at doing, and say like, where do you see some flaws in this? And you know, as you mentioned, sometimes the dev team is going to be like, maybe we should do this, maybe we should do that. But I mean, yeah, the lesson to him, because the people that build it, especially if they’re experts, are usually going to be the best at saying, like, Hey, man, this plant is fucked.

Matt Watson 43:11
Sometimes they are the reason to talk.

Matt DeCoursey 43:14
Well, right, but people, will you get it? And I mean, Matt, you’ve had, you’ve had a bunch of people like pitch ideas or ask for feedback or whatever. And you’re like, Man, this is, why are you? Well, it was like a man. I haven’t used this example for a while. I was given a speech years ago, long before the podcast even started. And remember I told you about the guy that wanted to give me his business plan. After I’d spoken, I’m like, What’s this? He’s like, I’m going to take down Amazon. I’m like, No, you’re not there. And I was like, I don’t even want to hear it. I don’t even want to hear it. I was like, you don’t have a chance. So like, in relation to goals, like, it’s a great thing to have them, but they have to you have to have some ability to complete them. Like yeah, if your goal is that you’re taking down Amazon, Google or Apple-like, you’re not good luck. Yeah, you’re not. I mean, even the most well-resourced, like Yeah, if that couldn’t be done, it would have been already done by someone other than you. So all right, Matt. Well, we’re going to be back for that we’re going to, you know, we talked a little bit about planning. I think this is pretty good. And we’re gonna get into the ever so captivating world of defining requirements, but well, it’s an important part because this is where you’re like essentially putting your it’s like when the waitress comes by and fills out you know, she goes and puts the little ticket up on the little spinning wheel like right there at the kitchen you know, it’s like yeah, if the if she gets that part wrong, your hamburger has cheese on it when you didn’t want it had pickles when he didn’t want it and for me, for my wife that would be that would ruin her day. Yep. All right. Can’t wait to see you at dinner next week.

Matt Watson 44:55
See yah.