The True Definition of Done
The word done takes on different meanings in different contexts, even within the scope of a single product. How do you know when something is truly done? And what does that actually signal for everyone involved?
Earlier this month, 20 product managers from various companies in Boston got together for breakfast at Intrepid Labs to discuss the ambiguous definition of done and what it can mean as a product manager.
When you’re writing user stories as a product manager, hopefully you’re including a “Definition of Done.” If you don’t lay this criteria out clearly, your engineers might not solve the problem you’re hoping to solve, or worse—they could get trapped in an endless time loop often referred to as “refactoring.”
More important than the actual criteria, however, is the fact that everyone involved understands the implications of meeting them. It dictates scrum board behavior, sprint velocity, QA processes, and DevOps. We use specific terminology to distinguish Ready, Done, and Shipped because they all imply different follow-on responsibilities.
And there’s the rub.
Declaring something as done means you can move onto the next step. That’s not always a good thing. As Beth Beiriger at Invaluable explained, her team ran into trouble when her designers said their mockups were done. Inevitably, the finished product looked and behaved a little differently than the mocks. Had a salesperson closed a deal based on that mock or a marketer included it in a blog post, they would have set an unmanageable expectation for customers. As a result, the team has transitioned to a living style guide, because design is never done.
Moving on also means you’re deprioritizing the Old Thing. That can be tricky in an Agile environment. There’s constant pressure to feed your engineers and you’ve got more validation from customers, so it’s easier to add 10% more polish to the Current Thing than switch to the Next Thing. That’s the fast track to feature creep and missed opportunities.
How do you know when to move on to the Next Thing?
This is one of the hardest responsibilities for a product manager. You’ve got to convince all your stakeholders—executives, engineers, designers, customers—that it’s time to stop doing what you know is working and try doing something that might not work.
This is where vision helps. Ask yourself if the Current Thing helps you get where you want to be in 18 months, or 5 years. If you pulled 80% of your resources off the Current Thing and put it onto the New Thing, would you get there faster? If the question isn’t easy to answer, that’s a sign.
Your product is like a steak. If you wait until it’s obviously done, you waited too long. It’s better to pull it off the grill a little earlier than you normally would. If it’s good, your customers will let you know. If not, you throw it back on for another minute.
Once a story is declared done from a development standpoint, the work is hardly over. For a product manager, you’re not done with a product (or feature) until you’ve put it out to pasture. After the initial development, it’s time to get with product marketing and coordinate the rollout. At a certain point in the rollout, you need to work with sales and marketing on the launch. Once it’s launched, you begin the long tail of customer support, price changes, bug fixes, and compatibility updates. Once you’re done supporting it, it’s time to sunset it. Then, and only then, are you done with a product.
For a product manager, you’re not done with a product until you’ve put it out to pasture.
Done, it turns out, has no fixed or universal definition. Returning to our steak metaphor, some PMs like to ship filet mignon cooked blue rare, and others prefer a marinated New York strip cooked medium well. Your job is to talk to the kitchen and the front of the house to understand everyone else’s definition of done and coordinate between them.
It’s important to decide upfront how you’ll know when to move on, and make sure the whole team understands what that means. Pick metrics that align with your goals, and consider inflection points: “We’ll observe DAU and reassess after 2 weeks.” “We’ll decide what’s next after we’re live to 25% of our European customers.” “Once we hit $25,000 in related bookings, we can determine whether we need v2.”
As the product manager, you own the tough decisions of when to move on. If you can’t stand the heat…