What Belongs in a Pre-Build Decision Log and Why It's Not the Same as a Backlog

Most product builds run into trouble before the first sprint card is written. The decisions that derail a build rarely happen in development. They happen in the weeks before, when assumptions go unrecorded and everyone in the room believes they heard the same thing.

A pre-build decision log changes that. And the reason it matters so much is precisely because it gets confused with a backlog. Teams assume they already have the right document, so they skip creating one. What they actually have is a list of features to build. What they are missing is a record of why those features exist, what was decided before them, and what was ruled out along the way.

The backlog tells a team what to build. The decision log tells them what was true when the direction was set. Both matter. But only one of them protects you when someone walks into sprint two and says "actually, I think we should reconsider the onboarding flow."

Without a log, that conversation resets everything. With one, the team can point to the reasoning, the alternatives that were weighed, and the moment the decision was made. The discussion moves forward rather than backwards.

A decision log captures what was true when choices were made, protecting teams from mid-build memory loss.

This article walks through what belongs in a pre-build decision log, how it differs from the documents teams already use, and why building without one makes every conversation about scope more expensive than it needs to be.

What a Pre-Build Decision Log Actually Is

A pre-build decision log is a structured record of every meaningful choice made before development begins. It captures what was decided, why, who was in the room, what alternatives were considered, and what information the team was working from at the time.

The emphasis on "at the time" matters. Decisions look different in hindsight, especially when they turned out to be wrong. A good log preserves the context that made a decision reasonable when it was made. That is not the same as defending poor thinking. It is about giving future versions of the team an honest account of what was known and what was unknown.

The log sits upstream of everything else. It pre-dates the backlog, the design system, the technical architecture, and the sprint plan. It is where the foundational choices live: who the product is for, what problem it addresses, which tradeoffs were accepted, and what the team agreed to treat as out of scope.

Who maintains it

The log belongs to the whole project team, but someone needs to own it. That tends to be whoever is leading the discovery or pre-build phase, whether that is a product lead, a strategist, or a consultant. The key discipline is logging decisions as they happen, not reconstructing them a week later from meeting notes. Memory is a poor archive.

What it is not

It is not a research report. It is not a set of meeting minutes. It is not a risk register, though it has something in common with one. It is a living reference document that anyone on the team can open mid-build and immediately understand what was decided and why.

Why It Differs Fundamentally from a Backlog

A backlog is a prioritised list of work to be done. It is future-facing, and it changes constantly as the team learns more. Items move up and down, get broken apart, get merged, or get dropped entirely. That flexibility is a feature of a backlog, because build realities shift and teams need to adapt.

A decision log works on a different principle. Its entries are not meant to change. They are meant to be stable records of what was agreed at a specific point in time. If a decision changes, the log gets a new entry noting the change, the reason for it, and when it happened. The original entry stays intact.

This distinction matters enormously in practice. When a team looks at the backlog, they are asking "what do we build next?" When they look at the decision log, they are asking "why are we building this at all, and who signed off on the direction?"

Backlogs can be rewritten by whoever has the most conviction in the room. Decision logs carry a record that makes rewriting harder, because the rewrite has to acknowledge and explicitly override what came before.

Teams that conflate the two end up with backlogs that grow heavier and stranger over time, stuffed with context that belongs in a separate document. Or they end up with no historical record at all, and every revisit to an earlier choice becomes a conversation that starts from scratch.

The Four Components Every Entry Must Contain

A decision log entry with missing components is nearly as unhelpful as no entry at all. When someone opens the log six weeks later, they need enough information to understand the decision without having to track down the people who made it.

Every entry should contain exactly four things.

The first is the decision itself, stated plainly. One or two sentences describing what was agreed. No ambiguity, no hedging. "We will build the onboarding as a five-step guided flow rather than a single long form" is a decision. "We discussed onboarding options" is a note.

Every log entry must record the decision, the reasoning, the alternatives, and who was accountable for making it.

The second is the reasoning. Why was this the right call given what the team knew? This is where you reference user research findings, technical constraints, business requirements, or any other information that shaped the thinking.

The third is the alternatives considered. What else was on the table? This is the component most teams skip, and it is the one that saves the most time mid-build. When someone proposes a different approach in sprint three, the team can look up whether that approach was already discussed and why it was set aside.

The fourth is accountability. Who made the decision, and who was present when it was made? This is not about blame. It is about knowing who to speak to if the context behind a decision needs further explanation.

Date every log entry at the moment the decision is made, not when it is written up. The gap between those two moments is often where context goes missing.

Decisions Worth Logging Before a Single Sprint Begins

Not every conversation in a pre-build phase rises to the level of a log entry. The filter is simple: if the decision shapes what gets built, who it is for, or how success gets measured, it belongs in the log.

Some decisions that consistently belong there are listed below.

• The primary user group the product is designed for, and any secondary groups that were explicitly deprioritised
• The core problem the product addresses, written as a problem statement rather than a feature description
• Features or capabilities that were considered but ruled out of the initial build, with the reason they were excluded
• Any constraints accepted upfront, whether technical, regulatory, budgetary, or time-based
• The definition of success for the first version, and how that was agreed upon
• Any research findings that directly shaped a direction, and any findings that were acknowledged but not acted upon

That last point carries real weight. When research surfaces something that challenges a planned direction but the team decides to proceed anyway, that decision deserves a log entry more than almost any other. The reasoning needs to be visible, because without it, the ignored finding looks like an oversight rather than a deliberate call.

Emotional design choices belong here too

At WAA, we work across the intersection of behavioural psychology and product design. That means decisions about emotional tone, trust signals, the psychological framing of user journeys, and the cognitive load a product places on new users all belong in the log. These are design decisions with real consequences, and they deserve the same rigour as technical architecture choices.

If a decision felt uncomfortable to make, that is a strong signal it belongs in the log. Comfortable decisions rarely need defending later.

Sprint-Two Revisionism and How It Derails Builds

Sprint-two revisionism is the pattern where a stakeholder, now able to see something tangible on screen for the first time, begins to revisit decisions that were made weeks earlier in a room full of good intentions and clear reasoning.

This is one of the most common and most costly patterns in product builds. And it is not always cynical. Sometimes a stakeholder genuinely sees something in a prototype that shifts their thinking. Sometimes a new person joins the project and, without access to the prior context, assumes a direction they dislike was never properly considered.

Without a decision log, the team has no defence. Every previously settled question becomes open again, and the build begins to drift. Scope expands. Energy gets spent relitigating old ground. The team loses confidence that anything they build will stay built.

With a decision log, the conversation changes. A stakeholder who wants to revisit the onboarding flow can be shown the entry from week two that explains what was considered, what was decided, and why. If they still want to change direction, that is a legitimate conversation. But it starts from the existing decision, not from zero.

The cost of undocumented pivots

When a team changes direction mid-build without logging the change, the original decision remains in the record as if it were still active. Future team members read the log and find two contradictory states with no explanation of what happened between them. The log becomes unreliable, and then it gets ignored entirely, which is worse than not having one.

When a decision changes mid-build, add a new log entry rather than editing the original. The history of the change is often as useful as the change itself.

Applying the Log to a Scale-Up Energy Platform

Consider a scale-up building a consumer-facing energy management platform. The product helps households understand and reduce their energy use through real-time data and behavioural nudges. In the pre-build phase, the team makes a series of decisions that will shape everything that follows.

One early decision is to focus the initial build on renters rather than homeowners. The reasoning is that renters face higher energy anxiety because they have less control over their home's infrastructure. Research conversations confirm this as a real pain point, and homeowners, while interested, have more existing tools available to them. That decision goes in the log, along with the note that homeowners are a planned phase two audience.

A second decision is to suppress detailed consumption data behind a secondary screen, showing only a simplified daily summary on the main dashboard. User sessions during discovery show that exposing granular data immediately overwhelms most participants and causes them to disengage. The log captures this finding and records the decision to use progressive disclosure as the design principle for data presentation.

A third decision rules out in-app messaging features for the first version. The team considers it but decides the support burden would be too high without a proper operational structure behind it. Messaging gets noted as deferred, not abandoned.

By sprint three, a new commercial stakeholder joins and argues for adding a detailed data dashboard to the main screen. The team opens the log. The entry from week one explains exactly why that was considered and set aside. The conversation takes twenty minutes rather than three days. The build continues.

Conclusion

A pre-build decision log is not a bureaucratic overhead. It is a memory system for a team that is about to spend months building something together, where the early choices will echo through every later conversation.

The backlog tells everyone what to build. The decision log tells everyone why the build looks the way it does. Both documents need to exist, and neither one can do the other's job.

The clearest signal that a team needs a decision log is the moment someone says "I thought we agreed on this" and someone else says "I don't remember it that way." At that point, the team is no longer working from shared facts. They are working from competing memories, and whoever has the most conviction or the most seniority tends to win, regardless of what was actually decided.

At WAA, we work with product teams across their pre-build phases, and we see the pattern consistently. The teams that invest in documenting their decisions before development begins move faster once it starts, because they spend less time relitigating settled questions. The teams that skip this step often find themselves rebuilding things not because the first version was technically wrong, but because nobody wrote down what they were trying to do.

If you are heading into a build and want to think through what your pre-build process should look like, let's talk about your decision-making process.

Frequently Asked Questions