Every decision has a context. Many times that context is ephemeral. In an enterprise setting products last a long time and teams see a lot of churn. Thus it is important to note the context under which a decision regarding the product was taken.
Every decision needs a review. All decisions are taken at a moment in time and have a context. Thus it is important for decisions to be revisited every so often. This is to ensure the decision is still valid.
Every decision has a scope. All decisions affect a part of the product design or a version of the product. The decisions will also be to address some aspects based on the context of the decision. Thus all decisions have a time/space scope that should be considered during reviews.
Every decision has consequences. All decisions are made to lead to intended consequences. It is important to regularly review if the decision is still leading to the intended consequences. And then there are always unintended ones that time reveals (if your product has that life or adoption).
Thus it is very important to create decision logs for your product. It is an important tool to help teams that work on the products after you understand the decisions and make better calls as the product evolves. These calls may include what to retain, what to change and what to kill.
And many Enterprise Product Managers have found these to be useful (unfortunately) during Cover your ass arising due to some crisis.
Product Decision Records is one such format to log decisions.
Product Decision Records
I have used the following format to log decisions on the collaboration tools used by various orgs.
Typically, a number and a brief summary. Eg:
PDR001: Have Two Passwords instead of Usually One Password During Login
Many collaboration tools allow you to enter Date using their own component. Try using those as it adds date as structured content.
Possible values are:
|Open||Still under discussion. But has been logged to facilitate a formal discussion and approval.|
|Accepted||Approved. Either in the implementation stage or already implemented.|
|Rejected||Not to be implemented. While it may have been rejected, it is important to log what was rejected.|
Mention the Product version or the duration as the scope of the decision
Describe the context of the decision.
The decision itself.
Effects of the decision. Both the desired one and any possible undesired side effects.
Usually, a time period, change in underlying assumption or known breaking point.
Note: Feature Image courtesy of SERC, Carleton.edu.
Support My Work on ddiinnxx.com
If you found the content useful, consider making a small payment like you would pay for a book. This acts as an encouragement to create more free tools & useful content.