Ditching Hourly

Hello and welcome to Ditching Hourly. I'm Jonathan Stark. Today's episode is an anonymized question that I answered in one of my Ditcherville Live Q&A sessions inside of my group coaching community. It's about how project oversight retainers work. Stay tuned. Next question. Can you say more about project oversight retainers? Who is best suited to offer them? Where do they fall price-wise in a list of proposal options versus other retainers? And when is it a bad idea to offer one? Oh, so this is going to sound familiar from the previous question. Who is best suited to offer them? So someone who has more recently transitioned from doing a thing to knowing how to do the thing and selling the knowledge, selling the know-how instead of selling the doing. So if you think of the altitudes of involvement and you've got support and maintenance at the bottom, you've got execution or building in the middle or implementation, and then at the top you've got like strategy, high-level design, positioning, those sorts of things at the top level, the more advisory things, and you're at the middle level, the execution, implementation, building level, and you're trying to get up to the strategy level, or you're starting to feel people, people are starting to ask you, CEOs are starting to ask you higher level questions. So not could you build this for us, but could you help us build this? Could you teach us how to build this? Could you architect a solution and then we'll build it? So you're moving from that second to third level, that would be something to offer. So where maybe, oh, this is exactly how I did it. Okay, here's exactly how I did it. I used to do projects just like when I was in the firm eight years ago, someone would come, they'd say, hey, we need this thing built. I'd say, great, I'll give you, tell me all about the scope. I'd have a scope first conversation. I'd kind of try and build it in my head while we were talking. I'd map that out all out later, and we had a little formula that would roughly, this many hours, this many hours, this many hours for these kinds of features. And then I'd roll that all up into an estimate, an hourly estimate and say, yeah, I think it'll be 50 grand, could be wrong, could be 75, could be 100, I don't know, but it'll probably be about 50. And then as I got that, so that was how that worked and all of the bad things that happened from that happened. Then it got to a point where I went solo and I was still, my bread and butter was still building stuff, so I still did the implementation, but there was a phase at the beginning that was clearly distinct where we would, I wouldn't be coding yet, I'd be going around interviewing stakeholders, I'd be interviewing the leadership team, I'd be making sure that we were all in alignment about what the goals were. It was a strategic phase at the beginning every time. I used to just lump that in with the hourly if I did it at all after the sales meeting, and it would just be an hourly thing, but then I started when I went solo, I was like, this is a discreet thing. So I usually talk about it under the term roadmapping now. So an interim step can be if you're, once you're getting off of hourly, you can say, all right, I'm going to start selling roadmaps up front for whatever, five grand, 15 grand, 500, whatever, depends on what you're doing. Sell that independently. It has its own value proposition, even though the software has not even started to be built yet. It is a map and smart people want a map when they're trying to take a journey. A project is like a journey, right? And it's going to be confusing and dangerous and there's going to be dead ends and all sorts of problems. So it's really good to have a map. So the roadmap, you can create a roadmap and sell it as a thing and say, there's no lock in here. You don't have to, you know, I'm probably the most expensive builder out there. I'm more of an architect. I would be happy to build it for you, but I'll be the most expensive option. So we can talk about that if you want, but you could probably find someone who's much less expensive. And with this map, they'll do a good job. Or you could do it internally if they've got internal resources or if they wanted to hire a developer or whatever the implementation is that you do, you know, a designer, whatever, marketer. So they could hire an internal person, follow the map and do it themselves. They can hire someone cheaper and use the map to guide them along or they can hire you for a ton of money to do it. And very often they'll just say like, no, we just know you. We don't have the internal resources. We don't want to worry about finding someone cheaper that we don't trust. We trust you. We'll suck it up and we'll pay you. So the roadmap often turns into high ticket implementation if you want to do that. Here's what shifted for me. I didn't want to do implementation anymore, but the clients still wanted me to. So in that scenario, I've given the roadmap. They're like, this is great. We have so much clarity now. We can see where we're going. We've got that feeling that we can see what's going to happen and how it's going to play out more or less. They have a lot more certainty. Could you please build it for us? And I would just say, I don't build these things anymore, but I can introduce you to some teams that you can hire yourself.

Or you can use this internal couple of people I met when we were talking or you mentioned you had, they're good enough, and I will oversee the project to make sure that they follow the map, if we use the blueprint metaphor, they put the stuff where it's supposed to be, they use the materials they're supposed to use, they're pounding the nails where they're supposed to pound them, and you just kind of, the builder metaphor is like you're the architect and you're walking the building site where they're putting up the mansion and you're sort of making sure, double checking, everything's on track, people aren't doing things in a way that's going to end up bad for the client. So you become an insurance policy, but it's specific to that project. Generally, projects are going to go longer, the implementation phase almost never stays on track, so you're going to want to do this on a monthly basis, and then when the project's over, they don't need you anymore. So it's usually got, the end of the engagement usually coincides with the launch or soon after the launch. In terms of pricing, I didn't really price it differently, I can't give you a specific price for it, but my average price for something like this centered around like 10 grand a month, depended a little bit on if there was any travel. These days, there really doesn't need to be travel probably, so I would think if the project is, if they're going to spend like quarter of a million or more on the implementation with someone else, they'll probably spend 10 grand to make sure that there's not five extra months of implementation, or even one extra month of implementation. 10 grand would be, if you save them one month of implementation, implementation is going to be 40 or 50 grand a month probably. I'm assuming software developers, you've got maybe two software developers, a designer, and a QA person, that's going to run you 30, 40 grand a month, or it could. So if you save them one month, that's worth the 10 grand. I mean, whatever it adds up, but anyhow, I don't think for a project that's like in the six figures, low to mid six figures, it's reasonable to have someone that's getting paid five figures to kind of make sure that it stays on track. And the higher, the more dangerous the project is, the riskier the project is for the client, the more they're going to want to pay someone like you to make sure that the house gets built the way that everybody planned on it getting built, and it doesn't go sideways six or 12 months from now. When is it a bad idea to offer one? I think it's a bad idea to offer one. Well, they're all going to be obvious. It's a bad idea to offer one if you didn't click with the client, because you're going to be married to them for at least three months, probably more like six, maybe more like nine or 12 or 18. So you really want to click with these people. You really want to feel like there's mutual trust because weird things are going to happen. So you want to make sure there's mutual trust. You want to make sure you click. You like them. You get the same. You laugh at the same things like you really want to be friends almost with these people, like the kind of person you would be friends with after the project is over. So, you know, any red flags I would run. When is it a bad idea? Another bad idea is when. This is so obvious, it's almost not worth saying, but if the if the implementation is too far outside of your expertise for you to really be considered or feel like an expert. So, for example, if if I but you probably wouldn't do the roadmap in the first place if that were the case. But but let's just say someone comes to you and say, hey, we really trust you. You did such a great job with my other company. Now I'm at this new company. It's this one's not PHP or this one's not Rails. This one's not React. This one's dot net. And you have absolutely no experience with dot net. Then I'd be like, oh, there's probably a lot of or NetSuite or Salesforce or whatever. They're probably, you know, in general, you're smart and you've you've you're good at what you do. But if there's a fundamental platform disconnect, you're going to have a hard time. Certainly operating at the level that you're used to operating at when the platform is something that you're comfortable with. But you're also going to have a hard time in any meetings where things get really technical. You're going to feel like an imposter, a serious imposter syndrome. So, you know, I mean, it's again, it's almost silly to say, but if you don't feel like your expertise is perfectly aligned, you don't feel like you've done this a million times from Sunday and, you know, all the ways it can go bad, then I probably wouldn't probably wouldn't offer it. But again, you probably wouldn't have done the roadmap in the first place. All right. Hopefully that helped. If we've got follow ups and maybe if you're you know, if I use too many software examples, software development examples, and you need some specifics from a different industry, just message me in Slack afterwards. All right. Hey, Jonathan, again, do you have questions about how to improve your business? Things like value pricing your work instead of billing for your time or positioning yourself as the

...person in your space. Or maybe productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal. Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes you to get ready for work in the morning. Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call you don't feel like it was worth it, just say the word and I'll refund your purchase in full. To book your one-on-one coaching call, go to jonathanstark.com slash call, C-A-L-L. That URL again is jonathanstark.com slash call. Hope to see you there.