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.
Name
Typically, a number and a brief summary. Eg:
PDR001: Have Two Passwords instead of Usually One Password During Login
Date
Many collaboration tools allow you to enter Date using their own component. Try using those as it adds date as structured content.
Status
Possible values are:
| Status | Description |
|---|---|
| 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. |
Scope
Mention the Product version or the duration as the scope of the decision
Context
Describe the context of the decision.
Decision
The decision itself.
Consequences
Effects of the decision. Both the desired one and any possible undesired side effects.
Review Trigger
Usually, a time period, change in underlying assumption or known breaking point.
Author(s)
Optional.
See Video
Note: Feature Image courtesy of SERC, Carleton.edu.
