Product Decision Records… or "How to save time for future you"

When you work in Product, feature requests are common and can come from many places. Sometimes users ask directly (or they rant on Twitter / X), sometimes sales teams will ask for them… and sometimes internal team members will suggest a new feature. Wherever they come from, these requests always need consideration and alignment to the long term vision, and medium term goals that have been decided upon. Which can often mean that feature requests get rejected (’how’ to reject them is another post entirely!).

"Yeah, we decided not to do that because… erm... it was just a bad idea"

Aside from being misaligned, there are a number of reasons that the feature might get rejected, but what I’ve been thinking about recently is what happens to those rejected feature requests. I hypothesise that one of two things normally happens:

1. The feature is written up in a JIRA ticket and then thrown into the backlog
2. Nothing happens and the world moves on as quickly as possible

The problem with both of these is that you lose all the context of the discussion and the reasons for choosing not to develop it. This invariably means that the next time that feature is requested, the same discussions happen in the same amount of granularity every time. At most someone might say “Yeah, we decided not to do that because… erm... it was just a bad idea”.

In technology projects we almost always write an ADR… an Architectural Decision Record. An ADR provides a concise summary of a significant architectural decision made during a project's lifecycle. It captures the context, the decision, the rationale behind it, and any potential implications or alternatives considered. They serve as a valuable reference document, helping teams to understand and maintain consistency in architectural choices over time.

Anyway, it occurred to me that this could be applied to Product, as well as architecture. Somebody comes with a feature idea, you document what it is and why they want it. You can then identify the pros and cons of developing the feature, and most importantly the ‘Why’ around that decision. Either way the feature can still be accepted or rejected but at least you have historical context on your side.

Rejected features should absolutely have the opportunity to get developed and the PDR (Product Decision Record) enables future you to understand why the decision was made based on the maturity of the business, and the market that it operated in at that time. A past rejection can absolutely be revisited and added to the ‘In scope’ roadmap with the knowledge of the discussions and decisions that went before.