Five Features. Full Stop.

Scope creep rarely announces itself as scope creep. It shows up as a reasonable sentence.

"Can we also add invites?" "Should we include analytics?" "What about an admin dashboard?" "If we are already building this, we might as well add billing, export, and notifications."

None of those ideas are obviously wrong. That is why they are dangerous. Bad ideas are easy to reject. Good-but-not-now ideas are what turn a clear V1 into a slow, expensive project that never reaches the market.

The buyer does not want a PRD generator

A product manager with stakeholder pressure is not waking up thinking, "I need a document generator." An agency owner watching a fixed-fee project expand is not looking for prettier requirements. A technical lead staring at a vague handoff is not asking for more words.

They want the bleeding to stop.

They want the request turned into a boundary. They want a defensible answer to "why is this not in V1?" They want engineering to build from a decision, not from a conversation that can be renegotiated every week.

Why five features works

A five-feature cap changes the planning conversation. Without a cap, the team asks, "What else should this product do?" With a cap, the team asks, "What are the five things this product must do to prove the business case?"

That second question is harder. It is also the question that protects budget.

Five features is enough to define a real workflow. It is not enough to hide indecision inside a backlog. That tension is the point. If a feature cannot survive the top-five cut, it probably does not belong in the first build.

The goal is not to make the product smaller forever. The goal is to make V1 clear enough to ship, measure, and learn from before the roadmap eats the project.

What a forced scope brief must include

A useful scope brief is not just a list of features. A list of features is how scope creep sneaks back in. A scope brief has to create decision pressure.

The out-of-scope list is where the money is saved

Most teams treat "out of scope" as an afterthought. It should be one of the most important parts of the brief.

The out-of-scope list creates the commercial boundary. For product managers, it protects sprint capacity from stakeholder appetite. For agencies, it protects margin from unpaid expansion. For technical leads, it protects engineering from vague requests that become rework.

If a feature is not explicitly excluded, it can be smuggled back into the project as an assumption. Naming the cut makes the boundary visible.

Why AI makes this problem worse unless it is constrained

General AI tools are generous. Ask for a PRD and they will usually give you more: more features, more edge cases, more pages, more implementation ideas, more future-state architecture.

That feels valuable because it looks complete. But completeness is not the same as clarity. A 20-feature AI-generated PRD can be worse than no PRD at all if it gives engineering too many directions and no decision hierarchy.

The better use of AI is not to generate more possibilities. It is to enforce the constraint you would struggle to enforce yourself.

How Specd applies the rule

Specd turns a vague request into a constrained scope brief. The product is built around the five-feature limit, explicit out-of-scope decisions, acceptance criteria, and build order.

That means the output is not trying to be a beautiful document. It is trying to become the thing your team can point to when someone tries to add the sixth feature.

Five features. Full stop. Now go build.