The Non-Goals ARE the PRD

Open any PRD and skip straight to the Goals section. Read it carefully. Now ask yourself: did anyone on the team actually disagree with any of this?

Probably not. Goals sections are ratifications, not decisions. By the time a PM writes them down, every stakeholder has already nodded in a meeting or a Slack thread. The goals section records consensus. It does not create it.

Non-goals do the actual work. They are where real decisions live — decisions about what you consciously chose not to build, not this cycle, not ever, and crucially: why. Those decisions are the hard ones. Those are the ones that bleed out of memory and reappear six months later as scope creep, feature arguments, and the familiar 'I thought we were going to do X' in a sprint review.

A non-goal is not a list of features you ran out of time for. That's a backlog, and it belongs somewhere else. A non-goal is a recorded decision about something you deliberately chose not to include — with the reasoning attached.

The reasoning part is load-bearing. Decisions made in meetings decay fast. The meeting itself leaves almost no artifact: someone takes notes, the notes get stale, the context falls out. Slack threads are even worse — searchable in theory, unfindable in practice. What you're left with is a loose consensus that everyone remembers slightly differently.

A non-goal with a because-statement is the only artifact that holds the decision and the condition that produced it in the same place. Without the condition, you can't tell whether the decision should be revisited when circumstances change. Without the decision, you're relitigating a closed question every time a new stakeholder enters the room.

A non-goal isn't an apology. It's a decision.

Most teams that write non-goals at all write them badly. There are three failure modes.

The first is writing non-goals as deferrals with no reason attached. 'Batch imports are out of scope' tells the team nothing. Out of scope because of engineering capacity? Because the use case is rare? Because you haven't figured out the right model yet? Without the why, the team has no anchor when a customer asks for batch imports in month two. Scope creep doesn't start with a bad actor; it starts with a vacuum where reasoning should have been.

The second failure mode is hedging language. 'We don't currently intend to support multi-currency invoicing' is a non-goal written to protect the author, not inform the team. The word 'currently' does all the work — it means nobody can be right or wrong. Real non-goals are declarative. They take a position.

The third failure mode is absence. No non-goals section at all. This is actually the most common case, and the most expensive. When you ship without non-goals, you have no record of what you considered and rejected. Six months later, nobody can tell whether the missing feature was overlooked or deliberately excluded. The conversation restarts from zero every time.

The format that holds is simple: state the thing you're not doing, then state why, then state the condition under which you'd revisit it.

Here is an example: 'We won't support batch imports because 90% of users onboard one record at a time and building batch infrastructure now locks us into a data model before we understand the edge cases. We'll revisit this when the cohort of users with more than 50 records represents more than 15% of active accounts.'

Now the team knows three things. One: the decision. Two: the reasoning that produced it. Three: the trigger that should reopen the question. Anyone joining the project mid-cycle can read that line and understand not just what was decided but what would have to change for the decision to change.

The revisit condition is often what teams skip, and it's the most useful part. Without it, a non-goal either becomes doctrine (nobody touches it even when the condition has obviously changed) or it gets quietly ignored (nobody wants to formally reopen a closed question without permission). The revisit condition is the permission slip. It says: if this, then we talk.

Spend more time on your non-goals than your goals. Your goals will get agreed. Your non-goals will get argued — and that's precisely where the real product thinking lives.