You are currently viewing Product Decision Records – An Important Tool for Enterprise Product Managers

Product Decision Records – An Important Tool for Enterprise Product Managers

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:

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.


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.

Review Trigger

Usually, a time period, change in underlying assumption or known breaking point.



See Video

Note: Feature Image courtesy of SERC,

Dinker Charak

Dinker has over a decade of experience in building products across diverse domains such as Industrial Automation, Home Automation, Operating Systems, High Energy Particle Physics, Embedded Systems, Online Video Advertising, Messaging, K-12 education and Private Banking. He also founded Gungroo Software. He books '#ProMa: Product Management Tools, Methods & Some Off-the-wall Ideas' and 'The Neutrinos Are Coming and Other Stories' are available globally. He also manages, an Indian Sci-fi portal.

This Post Has One Comment

Comments are closed.