Ep. #931 - SDLC: Defining Requirements

Matt DeCoursey 00:00
And we’re back for another episode of Startup Hustle. Matt DeCoursey here with Matt Watson. Hi, Matt.
Matt Watson 00:06
What’s going on, man?
Matt DeCoursey 00:08
I’m trying to define the requirements that are necessary for me to have a successful plan. And I’m struggling a little bit. I think you might be able to help me out.
Matt Watson 00:20
I hope my wife doesn’t have any requirements for me this weekend.
Matt DeCoursey 00:24
Yeah, me too. I think that’s, yeah, and if they do that, those sad requirements are clear and concise and within the capability and resource set that each of us has.
Matt Watson 00:41
And functional.
Matt DeCoursey 00:42
Yes, I agree. Well, well stated. Yeah. According to a survey, 39% of her husband’s honey-do lists fail due to requirements being listed. So we’ll talk more about that after I let you know and remind you that today’s episode of Startup Hustle is powered by FullScale.io. 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. Visit FullScale.io to learn more. Matt, you know, if you go to FullScale.io, you get an answer, like two minutes worth of questions, and the platform, it’ll match you up with people that do stuff that you need to be done. Yeah, they’ll make sure that you can define your requirements. They will meet that, yeah. You can click a couple of buttons to schedule an appointment. See if the people are right for you and maybe get started. Or maybe keep looking. So yeah, made it pretty easy to define those requirements. Now, when it comes to part three of our eight-part series about the software development lifecycle, today we’re going to talk about defining requirements. And while I was jokingly stating that 39% of honey-do list items fail due to poor requirement analysis. In reality, I was using a stat that 39% of software projects fail due to poor requirements and analysis. And this is, I would be willing to bet, that with the last, that number has gone up even more with a newfound remote team layout. Because this is where, I think, if you’re working in a remote or hybrid environment, this is where defining requirements becomes even more essential to getting stuff done. What are your thoughts on that?
Matt Watson 01:27
Will they meet my requirements? Well, you’ve heard me say this before, many times. I feel like so much about software development is a team sport, right? And so much of it is about one simple thing. Communication.
Matt DeCoursey 02:49
Yep.
Matt Watson 02:49
And if I don’t know what needs to be done, or not to do and how to do it, and all just like basic stuff, just communicate and tell me what I’m doing. No different than your honey-do list, like she sent you for paint, but didn’t tell you what color or if it was high gloss or matte, or didn’t tell me the details. Right? Like, if you don’t have the details like you’re gonna fail.
Matt DeCoursey 03:12
Okay, well, that’s true. I mean, we do not understand that it is. I mean, if you don’t know what you’re supposed to do, or how to do it, getting it done quickly, or accurately, or without it being a pain in the butt. And this is a two-way street. It goes both ways. Like, you know, and I feel that it’s kind of like, you know, you mentioned the paint thing that people were like, Hey, we need to build some software. That doesn’t tell me anything, you know, and stuff. Yeah, hey, we need to do this, we need to do that. And that, and that’s a challenge. So, you know, when we talk about actual, functional versus nonfunctional requirements and all this different stuff, I mean, Matt, you know, you’re, you’re the, you’re the technical founder of the two of us. So like, let you kind of lead off and bring us into this journey about, you know, what, what are some of the key points? And, you know, as I mentioned, you know, with nearly 40% of things failing due to poor requirements, what usually goes wrong at this stage and why?
Matt Watson 04:18
Well, so our last episode was about planning, right? And requirements are all a byproduct of planning. And, you know, in the last episode, we talked more about strategic level planning and, you know, getting, you know, the leadership team to all agree on what’s important and then actually setting goals and figuring out the initiatives and the higher level part of this right. And I feel like today’s episode is more about getting into the weeds of the more detailed requirements, but it’s all a byproduct of the planning, and you got to do good product planning. It is at a higher level than before. For example, the company I work at today is called Camp digital. You know what? They felt like we were the highest priorities. And we had, you know, all the requirements for and were the most important things. When I started, I reassessed all of that and figured out that everything that they were focusing on was the least important of all the stuff that needed to be done. And you know that that’s all a byproduct of the planning. But when you get into the details of these requirements, the problem is sometimes people feel like my point is that they feel like there are certain requirements that are really, really important. And then that kind of almost drives the planning. When it’s the other way around. You know, you got to focus on the high-level objectives first, and the requirements kind of drive those. But sometimes people get so focused on the requirements, like they think that they have to fix, like, one of the things we start, when I started, they, they’re like, We have to upgrade the version of Angular, like the requirement, we have to do it. And I joined the company, I’m like, okay, sure, it is an old version of Angular, why do we have to do that? We only use it internally. We have like, 10 people that log in and use this thing. If we don’t do it, what happens? What is the worst thing that can happen? Right, but the problem is software developers get bent out of shape about shit like this, and all of a sudden, they think this requirement is the most important thing. And then it, therefore, drives all the planning, they scare the shit out of the nontechnical people in the room thinking that this is the most important thing when I look at it, I’m like, I’m gonna give a shit. I don’t care about that. What’s important to our customers? How do we create more value? And let’s change. Let’s figure out what those requirements are. Right?
Matt DeCoursey 06:35
I think, yeah, I think you have a good point with the internal versus the external tool, you know, and I’ve always looked at different things, you know, here’s what we see. And then there’s what our users or subscribers see. And you have a great point, like, you know, and I think it’s actually a great example, like, the new and improved version of Angular, for the internal tool, doesn’t bring users, it doesn’t save subscribers, it might make it feel or look a little slicker. But that’s not that it doesn’t necessarily have a key priority. Now something on the user end, or where people are paying, I could validate that argument maybe a little bit, or if shirts out around, it was a matter of technical debt, you know, like, hey, if we don’t do this soon, it’s it, you know, it’s going to be really expensive down the road. So, before we get too far into this, I think we should also talk about boundaries. And what scope creep is, because if you don’t if you’re bound, if you’re if your requirements are poorly set, or not defined, you can end up with the not desirable situation of what Matt what scope creep?
Matt Watson 07:52
Well, it’s when you set a defined set of goals, but people just keep adding shit to the goals, right? It’s like, winning the Super Bowl is not enough. Now you’ve got to win seven years in a row. And it’s like, it just keeps going. And that’s inevitable. And planning is you set goals and like, these are the things we need to accomplish. But people just keep adding more and more to it, which some of its job security, it’s great, like, hey, we have more work to do. But for example, we talked for another episode about our internal tool at Full Scale called rocks. And, and it’s like, once you define like, oh, we need it to do XY and Z, like, let the team go get it, and then we’ll move on to the next project. After that, scope creep comes in. If you keep adding shit to the first project, they never get to the second project. And never really, that’s what happens. And that’s the problem.
Matt DeCoursey 08:44
You just keep adding, adding, adding, adding the first project, which some of the stuff might just require further review and analysis about what the priority level is. And if we wanted to put in real-world examples, it’s like, if we were talking about football, we’d be like, we’re gonna run a running, play a passing play, running, play, a passing play, and then a running play. And we’re all calling that all in one huddle. You know, rather than sitting back and saying, Okay, did this work? Do we move the ball forward? Because you might have a different situation? Or I don’t know, it’s just scope creep is really deadly, especially if you? Well, it’s probably the most deadly for people that provide software for other people.
Matt Watson 09:28
It? So it definitely is costly, right to get to that point, I think. But so where this is really deadly for, say, a startup is like, Hey, we’re building a mobile app. And you can make the decision early on if like, Hey, we’re only going to support Android or rolling us for Apple, or whatever. And then we’re going to ship the product. Well, instead, somebody at the 11th hour decides, oh, no, no, no, we can’t only ship on Android, we have to support apple. And we have to support a mobile web app version. And like, Hey, we’re just never going to launch the product. Yep. Let’s just keep building more shit. And then what happens, you spend a whole lot more money trying to build the Apple version, and whatever, and more weeks and months go by, and you never ship anything. And that’s the kind of scope creep that is so fatal to a startup because they don’t focus on shipping something out the door. This type of scope creep kills them.
Matt DeCoursey 10:18
Yeah, you can see it also talks about functional versus nonfunctional requirements. And like, what’s the difference? So nonfunctional requirements focus on what users expect from your system. Meanwhile, functional requirements lay out what the system should do. And, you know, there’s, there’s a little difference there. So like, you know, and once again, user expectation. So I think when you talk about scope, creep, or nonfunctional requirements, sometimes these things really balloon into big things because a lot of people get one little bit of feedback from one user and want to just change the whole system. Yes. Yeah. And so that’s like, that’s like almost like a gateway drug to, to scope creep, and stuff like that. So you get one user that’s like, I really wish this did this, and it affects their business. But, you know, if you stop it, yeah, I’m not saying don’t listen to your users, because you need to listen to him. But if you’re a regular listener, you know that you probably know what I’m going to say. And that’s listening for the echo. And that echo is, you know, that echo is a big thing. It’s something that, you know, the Echo is like the resounding sound like, you’re not just one person asking, it’s like five or six people asking or more and, and then you want to sit back and look at it, and you’re like, is this is you know, okay, let’s now let’s define the requirements, I’m getting a little off track here. So I want to move back towards actual requirements and write this up. Now, most of the time, software teams are using a number of different tools, and, and, and things. So Matt, what a JIRA is probably that’s Jri, provided by a company called Atlassian. I have no interest in dropping that you’re welcome Atlassian. But that is probably the most widely used.
Matt Watson 12:16
That’s what I use every day. But you can use a lot of things. You can use freakin post-it notes on a whiteboard, hello, for free. If you Yeah, you can use literally anything. And when you’re working on a new project, the key thing for me is just defining like very high level projects, like we need to do this big project, this big project, this big project, whatever it is, and then taking the time for each individual project to do what I would call story points, you know, like story items of like, for example, we’re working on a project now from importing data from Google AdWords performance data. So it’s like, Okay, we got to figure out, how do we schedule the jobs we need to run? How do we do error handling? How do we define, you know, how many days where the data, we’re going to save the data, like, it’s just trying to figure out like, high level requirements of, of what the project needs to do. So then the developer knows, like, Hey, these are all the things we have to account for. And it’s kind of, I like the story mapping side of that, like just, you know, defining at a high level, like kind of the story items of what needs to be done. And some of those end up being tasks. Some of them are architectural decisions. Some of them are just notes, right, but it’s like, they’re, they’re the story items that kind of tell the overall story of the project.
Matt DeCoursey 13:33
And when Watson’s talking about a story, and he really, that word is accurate, you’re telling the story of what you need it to do. Right? And, and, and the why and look, when you know when and I really want to recommend explaining this to the people that build it, like, what how would this be used? Why would it be used? And then one thing I mentioned from the planning episode yesterday, was also along the lines of, you know, what are the dependencies? So you know, when you’re defining requirements, and like you mentioned, okay, so you mentioned something that’s going to make her sad or change, betting on a cost per click thing. Now, if that’s one function, or feature or requirement, but if you don’t know what else that might connect to, or what could be affected by any changes that you make, you’re probably going to break it. And I think that’s where a lot of people fall short on the requirements, they get on it. They get on a zoom call, and they’re like, hey, we need this to do this, this and this and then they get off the call and then they’re hoping that it gets done and or they’re pissed off when something else breaks and like these things, like I mean, this is okay, Matt, you and I are not maybe the best people to follow along, lengthy instructions, but this is a time when that can actually be okay. Now, on the flip side of that, I don’t think you need to get too far into the weeds. You know, you don’t need it if there are some dependencies changes that you make. And this could affect this database, it could affect all US Gigabook as an example, if we make an appointment and putting that on and off of the calendars is pretty easy. That’s not the hard part there. But it’s connected to 12 different things. You have invoicing, rescheduling, emails, reminders, all up surveys, different reports and the dashboards, like all kinds of changes and stuff like that. And if you disconnect all those because you’re trying to do one other thing, well, you’re going to end up having to define 12 other things that you need done after that, and probably test off your users along the way.
Matt Watson 15:40
So there’s, as you mentioned before, functional and non-functional requirements, and we actually have a great blog post on FullScale.io, about this topic. And I think it’s worth spending a couple minutes and talking through more details of this. Because in any kind of project you do, the answer is always It depends, right? Like, depending on what kind of thing you’re doing. Everything is different, right? And looking through this little list of bullet points on the site, I want to walk through these for just a second. Okay, so you have things like authentication that somebody has to log into the app before they could do whatever this thing is, you have authorization, okay, which users could do this thing? Do I need an audit trail of the fact that whoever did this thing, did it? What are the business rules that are related to whatever it is that we’re talking about? Like, sometimes they can do it? Sometimes they can’t? Or are there different account settings, kind of like what you mentioned earlier? Like, you know, all of that, can they edit out? Edit whatever they just did? Can they undo whatever they just did? How does this interface with external systems? Do it? How long do I have to store the history of whatever we just did? How do I delete that so many months or years later? That’s just all of the functional side of it. And then you have all the non functional side of it, which gets into things like capacity, like how like in performance, right? Like, how often like, can we do this a million times a minute, does it need to support that? What kind of flexibility? Is there in the system? maintainability portability, like what kind of work for mobile or not work for mobile? How reliable is this product? Do I have high availability? Is it scalable security, like all these different things, so there’s a shitload of stuff. That’s what I’m saying. And it’s really hard when you’re trying to figure out a project for going out of all the things I just mentioned, which ones are important, because not all of them, they’re not all a lot of stuff.
Matt DeCoursey 17:34
Now, there’s a lot, man, there’s so much to consider why.
Matt Watson 17:40
But if you’re a really good software development manager, architect, you know, developers have done this for a long time, you know, whenever you’re talking to the product owner, or the customers about what needs to be done, all these things are going around in the back of your head trying to figure out, Okay, for this project, what’s important, like, what of those things we just went through are critical to the project and which ones are a huge waste of time, and you don’t want to even think about them.
Matt DeCoursey 18:05
And if you define a lot of that stuff in the planning stage, it’s going to act as your template down the road, like all that stuff you just mentioned. Once that’s defined once and you have now established, hey, this is how we define our requirements. Those are just questions that you put a quick answer in when you’re defining the requirement as on a top level. Now, if a lot of this seems intimidating, it’s because it is. And that’s why having some experience or being an expert is a good idea. So finding expert software developers doesn’t have to be difficult, especially when you visit FullScale.io, where you can build a software team quickly and affordably. Use the Full Scale platform to define your technical needs. And then see what developers, testers and leaders are ready to join your team. Go to FullScale.io. To learn more. I wasn’t kidding about the expert part like now, Matt, you’re an expert. I’m an expert. We’ve done this for a while. But if you haven’t found some people like whether it’s at FullScale.io or somewhere else there is a lot to be said about having that experience he’s looking at quickly, Watson just rattled a lot of that stuff off by that we put it put a link we’ll put a link to that blog article at the Full Scale site in the show notes. So you can see it so Alright, so let’s move on down the line here mountain talk about a guide to have a quick guide to requirements gathering. So well first, first off, we were in the planning phase, we began to assign roles that’s still going to be applicable here. You talk about meeting with stakeholders. Now what’s a stakeholder? Is that someone that’s just holding a T bone in their hand.
Matt Watson 19:40
Now I wish that, like at my company, we have a product owner, a product manager, and their job is to help drive this process. But then we have to meet with other stakeholders within the company that would use the product or they have the product expertise or expertise about a certain feature. Are there the lead users of whatever it is we’re going to do? So I mean, just like it rocks that Full Scale, right, you might have people that’s like, oh, we need to go talk to the person who’s in charge of recruiting, because we’re working on something that’s related to recruiting, or we’re working on something that helps potential customers, find our employees at Full Scale. So let’s go talk to the sales team. Because, you know, they talk to customers every day. And they’re, you know, they’re up to speed on these challenges and how we need to fix it or improve it, right? It’s having the stakeholders that have expertise in the different domains. And then you have the executives and the managers that have their own crazy ideas of, you know, like, the salespeople at Full Scale might have one idea, but then you as a CEO may be like, No, that’s a stupid idea. I hate that one. Right, and you Trump all of it. And so the thing is, you have to get all of these stakeholders in a room and agree, or otherwise, you just always have conflicting priorities.
Matt DeCoursey 20:50
This is what a product owner or manager usually does in a lot of cases. And we’ve used the Full Scale system. So once again, Julie, our product manager, does a great job. She goes and talks to the teams and the people that actually use it. Yeah, I think that this is why this is such an important thing, because it’s easy to assume what other people need or want, but go ask them, you know, and like and my role one once again, is this annoying? And if the answer is yes, or even, maybe you have more work to do. So that’s the first thing when I go to talk to people that use the Full Scale system. I’m talking like our managers, administrators, recruiters, people like that i That’s the first thing I asked I say, I’ll give you a good example. Not so recently, when I was in the Philippines. I was with you. We went, we went, we went and drank coconuts on a beautiful island, or there, didn’t we? Yeah, you could see that video in the Startup Hustle chat on Facebook. So come join us and talk to us over there. So with that, you know, I sat down with our recruiting team, and I asked him, what’s the most annoying thing about our platform, and it was something I had never even thought about. So they spent a lot of time reaching out to applicants. So maybe anywhere from 700 to 1000 people apply for a job at Full Scale every month. And they’re reaching out trying to so they end up texting with them a lot. But there wasn’t in our admin dashboard, there was not a place or a way to search applicants by their cell phone number. So they would send out a text, or someone would reply, and they’re like, Who is this? Oh, wow, they have to go, they have to like to go and look manually. And they’re spending a ton of time doing that, and it was slowing them down. So in that particular case, that’s really annoying. And all we had to do was simply add a search field for that to solve that problem right away, wham, Bam, done a week later, they fixed that before I even left the Philippines, and it made it less annoying. And that’s a good way to get to the bottom of it. And then also, like you just talked about, you know, I think it’s okay to list assumptions. But don’t just make the assumption, like talk to the people that use it. And then I think if you’re depending on where you’re at, in the hierarchy of your business, I mean, you’re gonna want to get approval in certain regards and say, Hey, I think this is a priority, or this is where we’re at, we’re gonna put, you know, we do regular reviews of our product timeline, and then you’re gonna monitor the progress. You know, sometimes these things don’t, I think it’s more important to get set well, depending on where you’re at with your product. So a lot of times, you’ll hear me say, Hey, give me something to give feedback on, especially on an internal tool, like if our clients and users aren’t seeing it, then I’m gonna say that a lot, give me something to get feedback on, and then you at least have a start. Well, and that’s how you don’t over analyze. That’s how you don’t infect your own project with scope creep.
Matt Watson 23:50
Well, and so back to your example of, like, searching by phone number. So that’s a great example of like, hey, this seems like a simple enough thing to add to the software and, and can be helpful. But then you have to, you have to get the requirements, right, like, are we searching by the whole phone number? Do I put in the area code? Or like in the Philippines, they just have like zero, but it’s actually plus 63? It’s like, am I searching by plus 60 3am? I’m searching for zero? Am I matching just part of the digits of the number? Am I searching across current employees, or just people who are applicants, people that, you know, it’s like, what people are researching for, it’s like, the devil is always in the details is my point. And sometimes, it’s figuring out all those little nuances that make it more complicated. And if you don’t tell the developers up front, like, Oh, I just wanna be able to search by the last four digits of the phone number, then they just do some other crazy stuff. And it’s the devil that is always in the details. That’s the point.
Matt DeCoursey 24:37
Well, some of that when you look at it, so I thought about five people spending way too much time doing that. If you’re looking at cost benefit analysis, like you can burn through things like making people do repetitive stuff or take too long to do simple things can really run up your labor cost and another thing too, is like, I’m just gonna say it again. If it’s annoying, people don’t want to use it. It’s just well,
Matt Watson 25:02
so the struggle is always, as a developer, you know, you get these kinds of little projects, I don’t even necessarily call it a project. They’re like very small features that need to be added. And it’s very easy to spend a lot of time adding those kinds of features. There’s nothing wrong with that. But you could be burning massive opportunity costs, because there’s other bigger fish to fry that can really move the business forward. Right. And that is always the struggle. And that’s why a good product owner is really valuable, because they have to play that central role of what’s important to the business. Versus Yeah, Sally keeps saying, oh, we need to search by phone number. And then the next day, it’s this other thing, little thing here, and nothing here. And those are all great. But those are little ankle biters that are keeping us from doing other really big initiatives. And that’s, that’s the struggle with planning and requirements in general is trying to get done what provides the most amount of value without creating a bunch of scope creep and overcomplicating things like, Oh, we, we wanted to do this phone number search. But it ended up turning into this great massive project because the developers wanted to use ElasticSearch knowing this complex searching thing, then it would search and rank people and search by all these fields. And it’s like, I wanted a phone number search. Instead, I got like Google.
Matt DeCoursey 26:17
So do you have a machine learning algorithm? What is the rank problem? Yeah. So man, I’ve got good news. The good news and you know, I wake up every day trying to better understand how I can make your life easier. So I’m gonna use the techniques that I have, that I have polished over the years. And, they are also applicable for requirements gathering. So you could use questionnaires, you know, there are maybe you can even make a simple Google form, and have people fill it out. You have a use case scenario. So that’s a written description of how you think your team members will execute or need something. So you can request that from people mind mapping,
Matt Watson 27:04
I love mind mapping, that’s one of my favorite, they tried
Matt DeCoursey 27:07
to map my mind and it looked like an octopus. So they stopped like it was explained to everybody what mind mapping and mapping is visualized is visual brainstorming in a lot of ways. And it’s helpful for assessing what product requirements might be needed. So we actually Full Scale, have a whole ton of our management users platform team, use a site called mero. MRO once again, I have no vested interest in using Miro.
Matt Watson 27:37
The mind mapping tool.
Matt DeCoursey 27:39
It’s all about visualizing. So what I liked about Miro is it’s got a ton of templates that are pre made to help you know, because you say, hey, map my mind, what does that even mean? How do I draw a wireframe? How do you do any of this and it’s got like hundreds Miro is a billion dollar company. So it’s out there, and you can do a lot of sharing, you don’t necessarily have to have a lot of users. And you can even do one of the things that can be challenging for CEOs and founders or people that are just trying to get your idea out of your head and in a visual format can be difficult. So tools like Miro are really good for that.
Matt Watson 28:17
I like it for trying to organize my thoughts, right? Like if I’m trying to build software, I, you know, think about it if people aren’t familiar with it, it’s basically like drawing circles and stuff and organizing them. But it’s like using Full Scale as an example. It’s okay, here’s Full Scale in the middle. But then over here, I got a bubble-like our employees. And then I got a bubble for applicants and I got her a bubble for things that HR needs and whatever and then it’s okay, now I go to the employee, one, it’s like, okay, the employees need to do these features and functions that all build off of that bubble. And it just kind of keeps growing in complexity, but it helps you kind of start in one place and kind of grow in that complexity, kind of going different directions and kind of mapping out.
Matt DeCoursey 28:53
These are shared tools too. So like you and I could share a lot and like I could so you just you can just see it almost like a waterfall. Like you have a box at the top that would say you know, org chart well applicant Yeah, applicants and then you could just literally have a bunch of people asking Okay, if you say data that we need to collect and then that’s going to have a whole string, first name, last name, address, phone number email, you kind of go down and down and down. And then the last thing is prototyping so prototyping could actually be it and this is you’ll see developers and product teams sometimes do this when they need to sell something back upstream. So you might have stakeholders or people like founders CEO CEOs who knows owes you like that the who knows I was at our company, we just started but a prototype my you might you could see like management teams, saying hey, we’d suggest the development team I’d say hey, we suggest doing this certain way and they try to explore And then they’re like, Well, that sounds good. But could you maybe do a basic prototype, which is just a rickety example of how something could work. And then you’re gonna kind of visually see it or in some cases, prototypes might be that beta, they might turn into that beta that you just kind of test and see what’s up, you’ll see some platforms will ask you to opt-in, they’ll be like, do you want to see our early releases of our imperfect shit. And that you might be looking at prototypes, and they’re looking for feedback, they want to see how people use it, what people use it for, and stuff like that.
Matt Watson 30:30
So prototypes to me are really important. And the other thing we haven’t mentioned, I think, goes along with a little bit is like user UX, like mockups, and like wireframing, and stuff like that, which kind of goes along the same lines of prototyping. But as a software developer, if you’re a really good software developer, you can do like 80 to 90% of a project. And like 10% of the time, like, just basic, like I got it working, and it does something and I can show it to you. Now the challenge is finishing like the last 10 to 20% of the functionality actually takes like 80 or 90% of time, because it’s like, Oh, we didn’t test any of it. We didn’t design it for security, we didn’t make it perform. We didn’t do all these other things that are all the little details and minutia of the requirements that take forever. But just like, hey, I imported some shit into the database. And I threw together a little screen that shows something and it kind of shows how it could work, you can throw that together really fast. Yeah, that’s the part where prototyping is super valuable. Now getting that like production ready, and all the little shit figured out takes forever. But that prototyping can be really valuable. And the reason why is most people are very, very visual. And you can explain to them like, oh, we could do this thing. And they just don’t really get it even though they act like they get it until they actually see it and can touch it and feel it, then all of a sudden, the light bulb will go off. And that’s where UX likes wireframing. And using those kinds of tools, along with actually building real prototypes very quickly is super valuable.
Matt DeCoursey 32:03
If you ever build an MVP, it was a prototype.
Matt Watson 32:07
And then you think you think you’re ready to ship the product, but you really need to spend like 90% More of the time. Because it’s not really production ready.
Matt DeCoursey 32:15
If the last 20% takes as much as the first 80%. That’s the second 50%. Yes, percent.
Matt Watson 32:24
Yeah. And that’s usually why software development takes twice as long as you think it’s gonna take Yeah, yeah. Oh, we have no idea how to deploy the thing to production. That’s, that’s like, that’s all the kind of shit that’s hidden, right, and the last part of it.
Matt DeCoursey 32:36
I want to remind everyone listening that until you’ve built it until you know more about it, you’re not an expert at it. So there’s a lot of trial and error that goes into this. And that’s part of the process. And sometimes you have to redefine, oh, man, I’ve redefined a ton of requirements. Because sometimes you think you have what you need. And then all of a sudden, you’re like, Well, we were close. And now we have to do it again. So okay, so much of this info comes from feedback related to users. And those users might be your clients, they could be, I mean, their users could be a number of the people that are using the software. So about how do you set the balance between giving users what they want, and then or how you want to build it?
Matt Watson 33:16
Well, so over the years, I’ve used various ideas, feedback portals and stuff, right? So you can log in, and you can like, give ideas and vote on other people’s ideas. And those are a great way to sort of crowdsource you know, ideas and Feature Ideas. The problem with it, though, is most people ignore that stuff. Like they don’t actually go through those platforms and do any of the ideas. So then you just piss all your customers off, because they spend all this time voting on ideas. You don’t do any of them. They’re like, for the last three years, the number one thing on your idea board has been XYZ and you slept and done it, what the hell’s wrong with you? It’s like, man, we shouldn’t ever even have an idea board. So if you’re gonna have one, which is awesome, you introduce some of the shit on there.
Matt DeCoursey 34:02
No, I agree. I agree, I think that I’m going to go back to the point of adding a building things should need to create, they need to help you sell more, spend less, preferably both. And, you know, sometimes making things simple, easy and organized is the equivalent of saving your day.
Matt Watson 34:22
You have to spend time talking to your customers and your users to get constant feedback. But you also have to take with a grain of salt, everything they tell you, because you have some users that are really stupid. And you have some users that have really bad ideas. And at the end of the day, you’ve got to mold that into what your product or somebody like Henry Ford would say something really famous, like if I asked Ray what they wanted, they would say like a faster horse, right? Not a car, you know, and that’s true. That’s what happens. You get customers and ask for really crazy things that don’t align with what you want the product to be and do where you want to go long term. And the thing is you can get very easily distracted by all those little things. And so you have to take their feedback, but take it with a grain of salt.
Matt DeCoursey 35:06
So we talked in the planning phase about what a buyer build meant. And part of defining requirements is also determining whether to buy or build a product. And there’s, so what does that even mean? Well, we’re in this world of inter-platform connectivity. And, you know, over the last 10 years, especially, it became kind of a must that any software platform be able to connect to other software platforms. And there are even tools like, like Zapier, that exist to help assess the streamline connections between different software products. If you’re selling a SaaS product, and especially something that’s like a business, a business thing, you are going to invariably have a ton of users that use a wide variety of stuff. And there are tools that you need to connect to it, and like you can integrate with everything. And, you know, like, some of it is even just your own functionality internally, you know, it’s like, do I want to spend all this time building a calendar, when maybe Google has one I can put in there? Or? I mean, there’s just a lot of different I mean, I, this is such an endless sea of options. It’s difficult to even give too many examples, because they’re everywhere.
Matt Watson 36:23
Well, the build versus buy thing is very important. And it is, it rears its head and all over the place, right? No different than software developers like, Oh, I wonder the same with machine learning? Should I set up all my own servers to figure out how to do machine learning and become an expert on how to do that? Or should I go to like Amazon Web Services and use their hosted machine learning thing, and just click the easy button, like, but I had, I had a conversation with somebody today, who was an entrepreneur, a business owner, and they wanted to create some kind of software that had to do with selling training, like she wanted to build some training platform and sell her training to people. And she’s like, oh, I need this learning management system. And I can’t find one. And I think, can you help me build one? I’m like, Dude, no, if you build one, you’ll spend the next like two years trying to do this, you will have wasted like a million dollars in this will have all burned and failed. And it’s a terrible idea. The key is she needed to define the requirements and do real market research. And she could have found something that would have been a learning management system to do it. The thing is, and the reason I’m bringing this up, is you may have to give up on some of your requirements, it may not be the perfect thing. But if it will do like 80% 90% of what you need it to do. And you can give up a couple of those requirements, you can find something, so I told her, I’m like, you can find something off the shelf. I mean, it’d be perfect. But you know what, you can start selling training in probably 30 or 60 days, or you spend the next few years trying to build the perfect system and you fail.
Matt DeCoursey 37:48
If you find yourself saying it doesn’t do everything I need, that might be a sign that you’re about to build something that you should buy. Because I mean, I’ve run into that with so many different things. We use Gigabook a lot as an example. And I’ve talked to users, so it does 90% of what I needed to do. You did really well. Yeah. Good job. Well, congrats. And then I’ll, I’ll respond. Oh, so that’s great. Congratulations. And they’re kind of like what there’s, I mean, it’s, there’s, especially if you have kind of niche needs, you know, like, you’re definitely not going to find something that at the same time, like you mentioned, like the learning software, people will reach out to me all the time. They’ll be like, Hey, man, so my cousin’s a hairdresser. And I think she’d love a Gigabook; how do I get her started, and I’d like, to send her to a platform that specializes in bookings for salons. Because it’ll be a better user experience. You know, it’s like one cent, there’s some things that are built to do certain things and some things that are built to do others. And in some cases, I mean, man, there’s an endless sea, you will be shocked at how many things people have built solutions for. Okay, so, Matt, last thing before we wrap up this episode, so we mentioned earlier that oftentimes, there are conflicting ideas between stakeholders, developers, all of that, um, do you have any tips when it comes to like dealing with or smoothing out those like, you know, I mean, I mean, for me, sometimes it’s just back to that role assignment and like, someone’s got to make the decision.
Matt Watson 39:22
So who’s going to be sometimes the hardest part is getting people to make a decision, you know, or people think they want to do too many things. And you can’t get them to settle on like, No, these are the two or three most important things and we’re going to focus on them. The hardest part as a management team is if everybody has different ideas, and everyone wants to go different directions, and that can be the death of your product, right? Like, hey, we need to beat our competition, but instead of focusing on beating our competition or having an industry leading product, we’re totally distracted, and we don’t know what we want to do, or we want to be too many things for too many people. And you have to have the vision to have the product division of where we’re trying to go. This is our North Star, maybe nobody, maybe not everybody agrees. But this is the North Star. And this is where we’re gonna go. And you and I have had some of these conversations before about rocks, you’re like, you had a vision for where you want it to go. And maybe sometimes I don’t under percent agree, but it’s like, Hey, you’re the, you’re the visionary here, and everybody’s gotta get in line and follow you at some point. If you don’t have somebody who has that product vision in your company, for this product for this team, or whatever, you’re in trouble, somebody has to have the product vision of where it’s gonna go. And somebody at the end of the day is gonna make the final decisions and force rank, like, Hey, these are the two or three things we can focus on. Everything else is a distraction. Let’s go. If you can’t do that, you’re, you’re in the corporate world, probably.
Matt DeCoursey 40:46
I agree. And sometimes you just got, like you said that, if you’re the founder, the owner, you just make the call. And I’ll tell people, I’ll say like, Hey, look, someone’s got to make this decision. And I’m gonna make it right now. This is what I want to do. This is how I want to do it.
Matt Watson 41:03
And that way, if it’s and if it fails, and I’ll take responsibility for something really important, yeah, that’s really important. Because some, you’re better off making a decision and doing something than just standing still and making no decision because maybe, maybe you and I don’t agree, but if we never do anything, we just sit and we don’t move anywhere. But maybe we say okay, Matt, fine, we’ll we’ll do it your way. And then a month later, we’ll figure it out was totally wrong. And we’re like, Okay, fine. Now we’ll do your way, we’ll go the other way.
Matt DeCoursey 41:24
No, and well, and that’s the thing, that’s the key to having a mature sophisticated team. Because just like you mentioned, like, I mean, neither one of us have ever wanted to be the blocker for progress. But you know, sometimes you try things and it doesn’t work out and try something different, make it stretch.
Matt Watson 41:43
So if you don’t make a decision, you just go nowhere.
Matt DeCoursey 41:46
Kind of like the decision of trying to hire software engineers, testers, which is much easier to do. When you let Full Scale help we have the people on the platform to help you build and manage a team of experts. When you visit FullScale.io. All you need to do is answer a few questions and let our platform match you up with our fully vetted, highly experienced team of software engineers, testers and leaders. The average developer at Full Scale has seven years of experience, Matt, and the world of tack that’s like dog years. So that’s a lot. Full Scale, we specialize in building long term teams that only work for you. That’s important people that wake up every day and want to solve the problems that your business needs to solve. And learn more when you go to FullScale.io. No matter you’re on fire this episode, MAN Yeah, a lot, a lot of really good stuff. It’s almost like you’ve done this before.
Matt Watson 42:35
I have and building software is really hard. I think that’s the key takeaway here. It’s really hard. And you can overcomplicate it, like we talked about all these like functional, nonfunctional, there’s like 20 Different things we spouted off, if you sit around and worry about the detail of all 20 of those for everything you do, you’ll never, you’ll never do anything, right. And that’s why agile development is popular, you know, it’s just trying to, you know, quickly identify what we need to do and doing it and then adjusting and continuing to refine it and continuing to move forward. Because otherwise, if you focus on all these details, and you try and plan out like weeks and months in advance like you just get it all wrong anyways, you get halfway through it, and you figure out like all the assumptions were wrong. And the thing about software development, and most times, it’s just controlled chaos. That’s what it is. And you just have to try things, figure out, this doesn’t work, it didn’t perform, the user didn’t like it, whatever, and you just have to adapt, you have to be agile.
Matt DeCoursey 43:33
I agree. I think defining requirements is sometimes hard for me as the CEO because having a vision and defining its requirements are two different things. And I, you know, with the invention and the increased prominence of product managers and owners, in the software development lifecycle, it’s a great role. I gotta say that adding that to our team and building a Full Scale platform made a huge difference because having someone that can, then you can kind of that kind of ride in the sidecar. And you can say, they really do own the product, they understand what it needs to do, how it needs to do, and you can talk to them very quickly, like Julio sitting there, and she just takes a million notes. And I always make fun of her because she writes in like, one-point font. And that’s always, you know, kind of interesting. You know, with that, that turns into the product requirements, it turns into the roadmap, and we review that stuff. And it’s made it a lot easier because I mean truly defining requirements in a way that is done well. It can depend on how much stuff you have to outline and measure and draw up. I mean, it can be a time-consuming process. So, you know, find someone that’s good at doing that. If you’re struggling to do it because it will make a huge difference in how quickly things get done and the quality at which they get done as well as even just simple stuff, you get a good leader in there to help with you. They will also very, very much help you establish priorities, as they’ll just get it and understand that, and that’s kind of my closing artists.
Matt Watson 45:20
There’s so much detailed work to be done. And if, you know, building software is like an assembly line, and the product manager has to be right, they’re feeding him the work. This is what needs to be done. This is what the most important priority is. It’s so critical to a well-run team.
Matt DeCoursey 45:36
You know, we’re going to be back in another week, Matt. We’re going to talk about designing and prototyping. And then we’re almost set apart from what we like, which is actual software development.
Matt Watson 45:46
I thought it was selling stuff. That’s my favorite.
Matt DeCoursey 45:49
I like selling stuff to the team. That’s definitely my favorite. But I can’t do any of that until soft designing and prototyping. We have to build something, and we have to deploy it, and then we have to operate and maintain it in an effective way, or we’re not going to have we’re not going to we’re going to have a whole lot of hoops to jump through when it comes to selling so yep, yeah, they get the shit done. I’m gonna go try to sell something now that you mentioned, man. I’ll see you next week.
Matt Watson 46:14
Alright, see ya.