The Single-Question Design Doc: A Tiny Planning Trick That Stops Features From Spiraling Out of Control

Every team has a story like this:

A simple feature request turns into “just one more thing.”
The spec grows, the mocks grow, the edge cases multiply.
Months later, the team is exhausted, the schedule is wrecked, and the original problem is barely recognizable.

That’s feature creep: the silent killer of good products.

The good news: you can fight it with something deceptively small—a single-question design doc.

This isn’t a new artifact, a heavyweight template, or another process ceremony. It’s a tiny planning trick that sits on top of the way you already write design and functional docs, and it works by forcing radical clarity on one thing:

What is the single question this feature must answer to be considered successful?

Get this right, and your scope has guardrails. Get it wrong—or skip it—and you’re inviting your feature to spiral out of control.

Design Docs vs. Functional Specs: Same Problem, Different Angles

Before we get to the single-question pattern, it helps to separate two kinds of documents that often get blurred together:

1. Design docs (engineers)

Engineers primarily write design documents for other engineers and for themselves.

They focus on how something will be built: architecture, trade-offs, data flows, failure modes.
They tend to be static snapshots: a record of the system at the time of design, plus key decisions.
They usually assume a technical audience that understands the stack, constraints, and jargon.

A good design doc is like a map of the terrain: it tells future engineers why the system looks the way it does.

2. Functional specs (product managers)

Product managers (and sometimes designers) typically own functional specs.

They focus on what the product does from a user and business perspective.
They are living documents: they evolve as the product does—requirements shift, priorities change, feedback rolls in.
They must work for a mixed audience: engineers, design, QA, marketing, stakeholders.

A functional spec is less a map and more a living contract: what we’re promising to deliver, how it behaves, and why it matters.

Both are essential. Both can be beautifully written. And both are routinely hijacked by feature creep.

Feature Creep: The Threat Hiding in Plain Sight

Feature creep is not just an annoyance; it’s a systemic risk.

Some of the most infamous software projects in history were derailed by it:

Windows Vista became a cautionary tale of expanding scope, changing priorities, and architectural complexity that dragged out the schedule and eroded user goodwill.
Google Wave, an ambitious rethinking of communication, collapsed under the weight of sprawling capabilities and unclear core value. It did many things, but not one thing compellingly enough.

The pattern is always similar:

The initial problem is vaguely defined.
Early docs try to please everyone rather than clarify trade-offs.
New ideas piggyback on the main feature (“as long as we’re in there…”).
The architecture bends to accommodate them.
The project becomes harder to reason about, test, and ship.

By the time you notice, it’s expensive—politically and technically—to cut scope.

You don’t eliminate feature creep by being more disciplined. You eliminate it by making it impossible to hide.

That’s where the single-question design doc comes in.

The Single-Question Design Doc: What It Is

The single-question design doc is not a replacement for your regular docs. It’s a focusing lens you add on top of them.

The entire doc is structured to answer one line:

“This feature exists to answer the question: ‘Can users X do Y under condition Z?’”

That’s it.

The rest of the document simply elaborates on that one question:

Why this question matters
How we’ll answer it
What we’re explicitly not answering (yet)

By reducing the feature to a single, sharp question, you:

Force early clarity on the problem.
Make scope boundaries visible and defensible.
Create a simple test for every “quick addition” later: Does this help answer the question?

If the answer is no, the idea is either:

A distraction (cut it), or
A separate feature (spin it out and prioritize separately).

How to Write a Single-Question Design Doc

Here’s a lightweight structure you can bolt onto your existing process. You can capture this in 1–2 pages before any deep architecture or UI work.

1. Start with the one question

Template:

Core Question
This feature exists to answer the question:
“Can [which users] [do what] when [in what context/constraints]?”

Examples:

“Can new trial users create and share a basic report within their first 10 minutes?”
“Can support agents see a customer’s last 10 interactions in a single view without switching tools?”

If you struggle to write this in one line, you don’t understand the feature yet.

2. Define success in terms of that question

Add a short Success Criteria section tied directly to your question:

80% of new trial users generate a report within 10 minutes of sign-up.
Support agents resolve 25% more tickets without escalating.

These metrics keep you honest when future ideas show up. If they don’t move these numbers, they’re not part of this feature.

3. List explicit non-goals

Non-goals are your cheapest defense against scope creep.

Non-Goals (for this iteration)

Advanced report filters beyond the core template.

Custom branding for exported reports.

Offline access.

Some of these may be great ideas. They’re just not answers to the core question right now.

4. Sketch the minimal architecture that answers the question

Now your engineering design doc comes in.

You’re not trying to model the final, all-singing, all-dancing system. You’re trying to design the smallest coherent architecture that can answer the core question.

This is where architecture descriptions matter:

Capture how the key components interact.
Record the decisions you’re making and why.
Note what you’re deliberately postponing.

Architecture documentation is not busywork; it’s your safety rail. It formalizes what the system is and isn’t right now so that future additions don’t quietly mutate the design into something brittle and incoherent.

5. Keep the doc static—but link it to living specs

The single-question design doc is more like a snapshot:

It captures the core question, the initial decisions, and the intended scope.
Once agreed, it shouldn’t change often.

Your functional spec, on the other hand, stays dynamic:

As you learn, you refine UX details, edge cases, and interactions.
The spec evolves, but always under the constraint of the original question.

When something truly doesn’t fit, you don’t silently update the question—you consciously decide you’re now working on a different feature.

How This Helps Different Roles

For engineers

You get clear problem boundaries before making big architectural bets.
When someone asks for “just a quick extra feature,” you can refer to the question and non-goals instead of arguing taste.
Your design docs stay lean: they explain how you answer one question, not how you might answer ten hypothetical ones someday.

For product managers

It becomes easier to push back on opportunistic scope increases: “That’s a different question. Let’s track it as a new feature.”
Your functional specs are anchored: changes must serve the core question or they’re deprioritized.
Stakeholders understand what this release is for without wading through pages of requirements.

For the team as a whole

Alignment improves because everyone can repeat the same one-liner about the feature’s purpose.
Trade-offs become easier: if two paths answer the question, you choose the simpler one.
You’re more likely to ship something concrete, learn from it, and iterate—rather than chasing an endlessly expanding vision.

Catching Feature Creep Early

The earlier you detect feature creep, the cheaper it is to fix.

Tell-tale signs:

Your core question needs “and also…” to make sense.
The non-goals section is empty or vague.
You’re adding new flows that don’t change your success metrics.
Architecture diagrams start to include components “we might need later.”

The remedy is always the same: go back to the single question.

Ask:

Is this still the question we care about most?
If not, should we finish this feature as is and start a new one, or consciously pivot?

What you avoid is the worst of all worlds: half-answering five questions and never fully answering one.

Consistent Architecture Docs: Your Long-Term Defense

Over time, your product will grow. New features will come and go. People will leave and join.

Your architecture descriptions—the way you systematically document system structure and decisions—are the long-term memory of your product.

When they’re consistent:

You can see how each feature’s design ties back to a specific question and set of non-goals.
You avoid ad-hoc add-ons that quietly turn into critical, unplanned dependencies.
Planning future work becomes easier because you can see what the system was meant to do at each stage.

Pairing consistent architecture documentation with single-question design docs gives you two powerful constraints:

Intent: Why this thing exists and what question it answers.
Structure: How it’s implemented and what changes will break it.

That combination is what keeps products focused instead of fragile.

Conclusion: One Question, Many Problems Solved

Feature creep isn’t a moral failing or a sign your team is undisciplined. It’s a natural outcome when:

Problems are fuzzy,
Documents try to do too many jobs at once, and
Architecture decisions aren’t explicitly tied to clear goals.

The single-question design doc is a small, practical antidote:

Define one clear question your feature must answer.
Tie success metrics directly to that question.
Write down explicit non-goals.
Design the smallest architecture that can answer it.
Let functional specs evolve—but never silently change the question.

Adopt this pattern and your features stop spiraling into uncontrolled scope. They start shipping earlier, simpler, and closer to what users actually need.

And when someone suggests “just one more thing,” you’ll have a calm, objective response ready:

“That’s a good idea. It just answers a different question. Let’s write a new doc for that.”