Most products are shaped before a single line of code is written. Who is this for? What are we refusing to be? What problem are we not solving? The answers decide a surprising amount of what happens next.
The trouble is that these decisions can arrive in conversation and disappear just as quickly. Three weeks later, everyone remembers agreeing. Unfortunately, they remember agreeing to different things. A very efficient way to manufacture a roadmap argument.
Write the decision, not the meeting transcript
Consider an illustrative support assistant. The first proposal is “use AI to improve support”. That sounds agreeable because it has not committed to much. One person imagines suggested replies. Another imagines an agent that changes customer accounts. A third has already put a percentage saving in the business case.
A useful decision record would say that the first release drafts replies for support staff, using approved help content, and cannot change customer records. The intended benefit is less time finding and composing the right answer. Sending the answer remains a human action.
Now there is something concrete to disagree with. That is progress. Disagreement about a visible boundary is more useful than agreement about a fog bank.
| Decision | Example |
|---|---|
| Person and problem | Support staff need accurate answers faster |
| First capability | Draft from approved help content |
| Explicit exclusion | No autonomous account changes or sending |
| Evidence to collect | Accepted drafts, corrections and handling time |
| Review trigger | A new data source or permission to act |
The exclusions are part of the product
“Not in scope” is often treated as a disappointing answer. It can be the most useful sentence in the document. An exclusion tells the team what it does not need to design, test, support or promise yet.
It also tells you what would make the old decision obsolete. If the assistant later receives permission to update an account, that is a change in behaviour and risk. It deserves a fresh decision, not a quiet addition to an existing ticket.
The NIST AI Risk Management Framework provides a voluntary reference for considering risks through the design, development, use and evaluation of AI systems. The small decision record above is my proposed product practice, not a prescribed NIST template.
Keep the uncertainty in the record
A decision should not pretend the evidence is better than it is. “We expect drafts to save time” is a hypothesis. “We measured a reduction” requires an actual measurement. Keeping those sentences separate prevents a reasonable assumption from acquiring a fake history.
This is where evaluation design becomes part of the early product work. What would count as a useful draft? What mistakes would make the time saving irrelevant? What evidence would cause the team to stop or change direction?
The record does not need to become a second product. Keep it short enough to read before the meeting. Put a date and an accountable owner on it, and revisit it when the underlying assumptions change.
That is also why product management cannot stay inside neat lanes. A boundary that looks like engineering scope may also determine the support model, the commercial promise and who has to answer when something goes wrong.
Before adding another feature, find the decision that made it necessary. If nobody can find it, start there.
