Speaker 1: If you have to create a Gantt chart, get a new job. Gantt charts are baloney. Well, they're not baloney. I say that and then, ugh, I'm so torn. ♪♪ How to manage a software project. If you haven't noticed, we are in a new studio and I've got an exclusive for you today. The reason why is I'm undecided. It's a little yellow and I know this, you're probably like, well, is that supposed to be brown? I'm gonna tell you the story to help you actually understand the lesson I want to share with you which is managing a project and how to go wrong. You know, if you're frustrated because you get people to build stuff for you and it's not what you want or the timelines are way longer than you had thought or proposed or even communicated to maybe your customers or the expenses and the costs have been kind of blown out of control. I mean I remember one time a guy called me, $1.5 million invested in a software product over a two year period, still hadn't launched. If those things, maybe it's not as bad as that but if you feel like you're trying to build the right product and you can't figure it out, I want to share with you guys my strategy for managing really any project but very much specific on software. And when you do this right, the cool part is you get working product in front of a customer. Things that your customers wanted in the first place, I think most of waste in a company is building things for people that they never wanted because you weren't listening properly and then finally making sure that they're done on time and on budget. You know, this backdrop, okay, and I'm not going to throw Tim. Tim, if you watch this video, man, I really appreciate the energy and effort. I had a vision. I was like, you know what? We've been doing the brick background for a while. A lot of people didn't realize it was real. You know, many times I've gone back, knocked on it, this is hopefully definitely real because you can see the dark spot stain, the knots, the holes. It was like I had this vision for kind of like this rustic wood type of organic thing and not that we didn't achieve that. I just think the color was off and it showed up and I wanted to shoot some videos so here's the deal. I want to share with you what I shared with Tim because I hired Tim to do it, we had to engineer this thing. I mean it's heavy, it's got aluminum frame. It's actually a quite cool piece of studio gear but I really learned how to manage projects back when I was 21. I got a job that I should have never got managing a team of engineers at a company called Syncrude getting paid way more money than I probably should have been getting paid and my boss pretty much pulled me aside because we interviewed over the phone, he looked up my resume, maybe he didn't do the math on how old I must have been based on when I went, you know, graduated and stuff and I was a contractor and he pretty much said you have two weeks to figure this out. And I didn't really know what figure this out means but I did what I hope anybody would do in my position is I went to the library and I got a library card. And I started buying books because I was gonna be responsible for about a team of 30 people. So I needed to understand how to manage those people, how to lead them, how to set expectations, how to interact with vendors. So I rented, rented, borrowed. I mean most of you guys are laughing. You've probably never been to a library. I, guys, isn't that funny? We live in a world where you've maybe never been to a library. And I got books on project management. I got books on technical architecture. I got books on understanding the world of consulting and that's where I learned Gantt charts. I'm still undecided how I feel about them but that'll be for another video and it was through that experience at 21 to 23 where I really refined my approach to managing projects. And what I want to share with you today is the four key areas that I think are super important. Number one is time blocking. When you build something new, you need to set the constraint. If you don't have a constraint then anything is possible. The scope for what you want to build can expand way beyond what you could possibly do with the resources you have. And it's super important to actually like say, okay, from a time point of view, we've got three months and we're gonna build this. If you're into agile development, which I highly suggest, typically you're doing kind of a six week product kind of road map with two week iterations and sprints but regardless, no matter if you're starting off from scratch in your first time building software or you've got a team, you want to set a cadence for time blocking what gets built in that time frame. So that's one. Number two, you want to make sure that you define the outcome and for me this is really from the user's point of view. Most of the features you're gonna build that are not paying down code debt and kind of fixing things, performance, that kind of stuff or fixing bugs are gonna be focused on the user and really trying to help them achieve what's called the desired outcome. And the way you do that is user story. So making sure that you have a defined outcome for what you want to have done. I did this built and we talked about it and I was like, you know, it's got handles because it's a big heavy piece of gear and it rolls around and it's in a studio and I want the what, and there was all these things and one of the things that I felt wasn't really captured was the outcome goals, okay? What the specs were. We talked about it, you know, but it was never really written down, drawn out and really like, okay, this is what I want you to do. And look, everybody has a different approach for managing their stuff but when I hire and delegate this to people, I'm just gonna trust that they're gonna do it the way that works for them. This is just some feedback and thoughts on how it could have went better. So time block was there. I had a date that I needed it delivered by and we were late by two days and I'll tell you why because it's number four in this video but it was really about making sure that the outcome goals are well-defined. Number three is you need to make sure that you prototype along the way, okay? And what happens is, and this is an example, is the stain, the color, instead of coming in yellow, could have came in on the brown tone that we had actually like screenshotted and sent across but the reason why is it was never tested, right? It wasn't something like and many times when you're building software, you communicate the specifications using words, text, a document and I can't tell you but like if I wrote a paragraph of an outcome I wanted and we had two different people read that paragraph and kind of build towards what they think or how it should work, we're gonna have two different experiences. So to me it's all about prototyping the user experience so it's called the UX, how it interacts, how the feature works because there are 100 different ways you can implement something and also the UI or the visual design. You know, how do you want the colors to look? How should the buttons be stylized? What layout and spacing should you use? And I think that regardless of what you're gonna build at the end of the day, if there's elements in there that are unknown, you need to prototype. You can do that through a designer's mock-ups, you can do that through clickable prototypes using Keynote or UX pin or Balsamiq or whatever tools. It is very important to prototype. So that's number three. Four is you need to make sure and this is what happened is if there's dependencies amongst the project, right? Other areas, other business units, other people that you communicate with them early and then often especially if you own the project. So what happened here is we had to work with a contract company to do an aluminum frame and communicate those specs but the timelines were never asked for and or committed from that person. The other thing is the custom stain for the backdrop was never tested early in the process of the project so that if there was a discrepancy in color because there's a fixed timeline that we could have fixed that early and get that resolved. That to me is probably the number one thing that every founder gets wrong is when you start a new project and this usually comes from three key areas in your business. The technology that you might assume is gonna work so maybe that's an integration, it's an API, it's your own code technology. Second one is marketing. What are the dependencies once you build this that marketing needs support on so maybe they gotta put a campaign together, they need to put a new features section, they need to add it to the pricing page so there's marketing dependencies and then finally operations. So you think about in your business there's like administrative support or you know it could be billing or whatever it is but there's an operations component and those three areas are dependencies on the overall project that need to be communicated, need to be understood and if there's legal or anything else that has to provide feedback into the timeline of getting that project done, start it early and often. So real quick those four and I'm gonna share with you guys a myth that every founder believes in that's just simply not true. One is you need to time block. You need to set the constraints. Number two, you need to define the outcomes from a customer's perspective. Number three is you gotta make sure that you prototype and test the user experience in the UI so you don't have a yellow background and four, you need to make sure that you test or start with those defined dependencies and make sure that they get rolling faster than waiting till that moment in time to actually move it forward. The myth that I wanna bust for you is that any product survives first contact with the customer. The truth is no matter how great of a job you did and Tim did an amazing job, there's gonna be iterations so actually build that into the schedule, build that into your plan and it's gonna make you a happier founder. Hope this video finds you incredibly well. As per usual, I wanna challenge you to live a bigger life and a bigger business and I'll see you next Monday. If you're the type of person that likes to subscribe on things, click the button. I'd love to have you part of the community. I'd also encourage you to subscribe to my newsletter where I share incredible new exclusive only ever found, yep, on the newsletter and if you're ready to get going, I got two other videos queued up ready for you to keep watching. Have an amazing day.