The Power of “Good Enough”

The Power of “Good Enough”

I’ve been working for the past several months on a hobby project with a few friends. It’s been quite a case study in process, and it’s taught me a lot about the role of a product nerd in a sort of vacuum—outside of a formal org structure or any real ceremonies. I think I’ll probably do a deep dive into some of those experiences in a future post (make sure you smash that subscribe button so you don’t miss it). But there was one thing we did almost as a joke when we were setting up our first project board, and it’s turned out to be rather influential on our mindset ever since:

We renamed the final column on the board from its default of “Done” to “Good Enough.”

Now, I know what you’re thinking. Or, at least, I know what I would be thinking if I was reading an article like this: The word done in this context usually does mean “good enough;” that’s why we have a definition of done, so that we have some shared understanding of what the word actually means for our purposes. We don’t need to split hairs. It doesn’t matter what the column is named as long as we all understand what we mean.

And I’m here to tell this hypothetical, critical version of myself: It does matter. Because words have meanings, and even if we try to redefine it to be less absolute, we still make certain associations and experience certain reactions when we hear and use the word done.

And I have seen first hand that having the final column on your project board be labeled “Good Enough” is a practical, visible reminder when you are deciding whether to close a ticket that it doesn’t have to be perfect. Even if we think of more fine tuning that needs to happen at some point down the road, we haven’t been shy about creating another ticket for it and throwing it onto the pile backlog. This allows us to prioritize that additional work independently from the core functionality. Better is lower priority than good enough. This is a familiar concept—the MVP—but applied unabashedly and indiscriminately, all the way down to the individual backlog item.

Granted, as I said before, this is an informal hobby project. Most of the time, we don’t even have proper acceptance criteria on these tickets, just a descriptive title and a few sentences of context where necessary. The QA process consists of us trying out whichever new feature we’re working on in realtime, just “smoke testing” to make sure it isn’t spectacularly and obviously broken. Our stakes are low. If we mess up, we aren’t risking revenue or creating unexpected downtime for anyone actively using the tool. But even if you’re not a startup or, say, just a bunch of pals whose idea of a good time is video chatting and writing software and drinking hard cider, the principle still applies.

The power of good enough is that it’s contextual. That’s what the word enough means. Saying that something is good enough implies that it’s good enough for something. Good enough for the first hundred users? Good enough to validate with stakeholders? Good enough for now? It’s not absolute in the way that done is. It allows us to close the lid on something without feeling like we can never reopen it.

To be clear, I’m not implying that you should always just close tickets, even if they’re half-baked. A story may not be good enough. As product nerds, it’s our job to know exactly how good is good enough, and what the aforementioned context is. It’s our job to make sure we’re not over-solving the problem, or solving extra problems that may not even exist. Tools like acceptance criteria and a definition of done help us gauge those things on a ticket-by-ticket basis, but in broader contexts, like when to shift gears toward a new epic, or when to go ahead and show something to stakeholders for feedback, we have to rely more heavily on our intuition. Our unreliable, emotionally invested, deeply human intuition.

Fig 1. Backlog of feature requests

Especially if we’re working on something we’re passionate about or proud of, it’s tempting to try to fix every bug, address every possible use case, file down every rough edge. But as long as your product could always be better, it will never be finished. It will never be truly done. And that’s okay. In fact, a steady stream of ideas and potential improvements is a good thing—it means your product has a future! (See Fig 1.)

But returns diminish. As a rule, each additional tweak adds less relative value to your product overall than the last one did. At some point it does become a better use of your time to move onto the next step than it is to keep polishing one spot. Even if we know we have the skill required to make something so shiny you could see your reflection in it, we save a lot of energy and risk less damage to our pride by recognizing that that’s almost never required.

When I first created the draft that eventually grew into this post, the title was “Why You Should Relabel Your ‘Done’ Column to ‘Good Enough.'” And I think you should, if you have that kind of power. But you don’t have to actually relabel your columns or your ticket status or whatever to take advantage of this kind of thinking. You can relabel the column in your brain, so to speak. When you hear yourself or someone else evaluating whether something is done, remember that done is not a useful objective. Thinking and speaking in terms of good enough leads us through a pattern that is useful: What does good enough mean for this thing in this moment, and are we there? If so, pull the lever, Kronk.

This Post Has One Comment

  1. Kerry

    Knowing when to stop and ship is always a struggle. Nice reminders that we can be okay with ‘Good Enough’.

Leave a Reply to Kerry Cancel reply