Product Management Question of the Week - September 6, 2022

Guess what time it is? That’s right, it’s time for your Product Management Question of the Week!

This week we’re exploring the definition of done. In agile planning you sometimes hear scrum masters talk to their teams about what the definition of done actually is. This usually refers to how you know you’ve gotten to a point where you are ready to ship your product knowing that you’ll continuously deliver features and updates on an ongoing basis.

So while it’s done enough to ship, that leads to the question of if a product is ever really “done.” Is there ever a time when you can officially say your product is totally complete? Why or why not?

Share your thoughts in the comments below!

Never but kinda.

From my understanding, DoD is a checklist for engineers to ensure it passes milestones. Example: Unit tests, code review, UAT, meets design standards, works on mobile and tablets, compliant with ADA accessible standards, etc. That being said DoD can be changed before each sprint starts.

For product, you can NEVER consider it complete because the milestones of completion would be based on user feedback that always changes (over the years not days). As time passes, people change, technology changes, and how people interact with technology changes (I’m probably missing other things that change too. Feel free to help me out here or anywhere). I do however believe an iteration of a product can be considered done in a quarter (or longer) and that you can take in user feedback and understand behavior to improve the next iteration of the product.

Simple answer: a product can be considered done when all the expectations they had from the stakeholders are met (including the company which owns, the investors, the customers, etc.). The period to reach such a stage varies as expectations/requirements evolve and the duration typically prolongs to a longer duration. Products have sunsetting (done & dusted) of versions of the product or the entire product itself based on a variety of expectations - technology, risks, changes in customer needs, market forces, etc.

Done is when the agreed upon outcome is achieved by the implemented solution. This should be measurable (clicks are reduced by 50%), but can also be a “state” like “user is able to see their profile info.” There’s no point in checking off everything in a checklist if the original problem isn’t solved.

I would divide the product into versions.
And each versions should be divided into the features/user-stories.
So that we could each the whole elephant, by biting part by part.

The whole product is kinda an alive system and it continues to be developed constantly.

But speaking of the requirements specifications, and the roadmap - the is a certain end, while it is finally marked as done)