How to Stop Finishing Projects Nobody Uses

I recently changed the definition of done in my business, and I'll tell you why. It's had a huge impact on the way that we execute, and technically on the value of basically everything that we do in the business.

We've accomplished several significant projects. We've undertaken the project, we've executed it, we've parked it done, and then we've moved on. And the business that I'm building right now, we're growing quickly. We're adding people quickly. And it's been really important for us to try to get some structure together. So we're trying to implement some systems, operational systems, things like that. And when we mark things done, we have a definition of done, and it's done.

So we redid onboarding last quarter, because the onboarding process was a little rocky for new customers. We redid onboarding, and by the technical definition of done — meaning it was a new process that adhered basically to the way that we had whiteboarded it — it was done.

Problem was, I went to an event about 30, 45 days later that I was speaking at, ran into a couple of people who'd recently been onboarded, and they said, "Loving the new this and that, but the onboarding is a little rocky." I was like, "Well, [expletive]. Didn't we just redo this?"

That's one example.

Another is, as we're getting ready to make some investments and explore some different options for the business — because we're growing, because we're hiring a lot of people, because we're making investments in the business — we wanted to get some financial structure. So it was like, hey, we've got to get our books in order. We've got to get a budget. We've got to get a forecast. We've got to get some basic reports, analytics. We've got to grow up a little bit here.

We set some definitions: hey, we're going to do XYZ. And we set that as the quarterly project. We went through — and this was with me, by the way. This is not me blaming anybody. This is with me. We set a definition, which is, hey, these things are technically like the output is completed, right? And we did it all. So we marked it done.

And then I go to make two significant hires. The two biggest hires that I've made in the business so far. I go to make those hires and I say, "Okay, what's this going to do to cash flow for the next 90 to 180 days?" I don't have an actual report that actually tells me what the impact of that is going to be.

Well, [expletive].

Okay. To give you a third example, just to beat a dead horse here. I created an AI script writer within our business, because we fractionally manage salespeople for MSPs. And as part of that, we want consistent framing on how we sell stuff. We want a consistent way to create the script so that different customers are getting not necessarily the same templated script, but so that we have the same underlying structure, and that it follows my philosophy — that it follows what I know to be true about how to sell [expletive].

We've got to have a consistent way of getting an output that we're confident in, so that it's not four different managers writing things four completely different ways. Because at the end of the day, we're responsible for a lot of these results.

So we created an AI script writer. I spent a lot of time building these outputs, going through and asking, hey, what are the things that we typically customize? I reverse engineered a lot of years of writing scripts and working with people doing outbound. These variables are the ones that need to be input. We put it into a form, and then we created a handful of really good examples. We created a template. We built this whole engine that was necessary to write the scripts. I hired a contractor to come in and install the skeleton of this [expletive]. We got it done. I was really proud of it. I ran tests. I'm like, "Hey, it's fine. Good output. Excellent."

By the time our fourth sales manager starts, I asked, "Hey, how's the script writing going? How's that script writer working for you?"

"What script writer?"

So I've now paid a contractor. I've invested a lot of time. And I've built a pretty damn good system for doing exactly what I want. And we're not using it.

That was also checked done. Why? Because it worked. It was done.

We just embarked on our new most important quarterly project as a team. In fact, it's the only one that anybody in the company has. We're redoing the SDR fractional sales management program. We're taking into account an audit of over 100 SDRs, and best practices, things that we've learned, redoing the onboarding piece, implementing the script writing.

And as we're coming to a close on this project, I shared this with the team, and I'll share it with you. We need to get really clear about what the definition of done is. Because you can mark things done on a list and it feels good.

In fact, years ago, Asana — I don't know if they may still even do this — every time you clicked a task as complete, this little unicorn would kind of fly up from the corner. And I swear it's because they knew there was a dopamine release. Every time you clicked a task done, it felt good. It felt good to see it disappear. It felt good to complete something. It felt good to close the loop. As you know, our brains don't like open loops, right? Asana would celebrate every time you completed a task. It was fun to complete [expletive].

And on the surface you think, well, that's good, right? That means we're getting [expletive] done. A lot of GSD mindset.

The problem is, depending on how you define done, it's very easy to go through and click, click, click, click, click — and not maliciously, not like you're full of [expletive]. Just actually go through, by the technical definition of done, and click, click, click, click. Things are done, and you feel good, and you move on to the next thing.

And you do this day after day after day, week after week, month after month, and you feel like you're moving forward. You feel like the business is moving forward. But it's really a lot of noise. It's not music. It's a lot of motion. It's not progress.

And it's because the definition of done is perhaps the highest-impact part of a project. How you define whether it's truly done or not is going to define whether you actually get any use out of that project — whether the thing that you just invested all of your time and your resources and your money into, whether you actually get any output out of it.

The whole conversation with my team, I shared these same examples. I said, "Listen, we're redoing stuff that we've done before. And before we call anything here done, and before we move on to our next thing, I want to raise my hand and say: let's get very clear about what done means this time."

Done in this business going forward does not mean the task has been completed according to a spec sheet on a Google Doc. That's what we forecasted. It's what we predicted done would look like.

But done is going to mean good and being used. If it is not good and it's not being used, then it is not done.

Done and done well are two very different things. I can race through a task. I can do the bare minimum. I can find how to hack a spec sheet and figure out how to call something done and move through as many tasks as possible, and add virtually no value to the business.

And then the second part of that is: it's being used by the person that it was built for. Many times this is going to be built for an internal customer. It's going to be an internal customer that ops is building something for, or that we are collectively building something for, that's going to be handed off and implemented and used by the rest of the team.

If it is not being used by the rest of the team, it is not done. Because that means it wasn't done well, or wasn't communicated on how it works, or something else — there's some other blocker. There's something that's standing between the completion of what we think is an executed project and the actual usage or implementation of that project to create value for the business.

And that is what matters most. It's got to be done well, and it's got to be used by the end customer. That way we can ensure it's a high-quality product that we're creating, not something that was rushed. And we can ensure the end user, even if it's an internal customer, is aware of the damn thing — like my AI script writer.

How frustrating is that, to invest a bunch of time and a bunch of money into something that never gets used?

So: they're aware of the fact that it exists, they know how to use it, and they're willing to use it.

When you redefine what done actually means, it redefines the value that you are adding by completing the projects that you are completing. And in that way, you get into the business of executing to add value for the business, instead of executing for execution's sake.

There's a dopamine rush that is released from completing [expletive]. But it does not matter if it does not add value to the business.

So re-evaluate the definition of done.

Hope it helps.