When to Open a Feature — and When Not To

TL;DR. A Feature is the smallest unit of work that can be shipped end-to-end on its own — independently deployable, independently verifiable, independently observable in production. If a piece of work fails any of those three checks, it does not deserve its own Feature. Big Features get split along the same axis (independently shippable slices), never thinned along the dimension of effort. Every Feature should leave behind six artifact layers so the team can answer — weeks or months later — why it was built, what it was supposed to do, what reality looked like, where the gap was, how we chose to close it, and what landed in the codebase.

---

We get interrupted all day with requests of every size:

• "Fix this bug."
• "Add this field."
• "That page's styling is off."
• "We need a new module for the new product."

Each one feels small. But they aren't all the same kind of small. Some of them belong in a quick ticket; others require end-to-end ownership — from kickoff all the way through shipping.

This post answers a deceptively simple question: when should we open a new Feature, and when should we absolutely not?

1. The single rule#

Our internal test for "should this be a Feature" comes down to one sentence:

A Feature must be a unit of work that can be shipped end-to-end on its own.

A Feature is the smallest unit of work that is independently deployable, independently verifiable, and observable in production. If a piece of work fails any of those three checks, it does not deserve its own Feature.

Conversely, if a piece of work falls into any of the buckets below, it usually doesn't deserve its own Feature:

Counter-signal	Why it disqualifies a Feature
Cannot be shipped independently	Its release depends on something else that isn't done yet. Turning it into its own Feature won't bring a release — it'll bring an "I thought I shipped" illusion.
No observable business value	Neither going live, nor anyone checking on it afterwards. It's a pure internal refactor or tooling improvement — that belongs in a workday ticket, not in a Feature.
Just a fix on an existing Feature	It belongs as a ticket on the tail end of that Feature's life, not as a separate boat ticket.

Violate any one of those, and the work is downgraded to a lighter carrier: Ticket / Chore / Patch.

2. Do I open a Feature?#

Two consecutive questions, every time:

Reading it straight through:

1. Q1. Can this thing be shipped end-to-end on its own? Yes → OPEN, open a new Feature. No → go to Q2.
2. Q2. Is this a fix on a Feature we already opened? Yes → MERGE, fold it into that Feature's tail. No → DROP, downgrade to a ticket.

Only the OPEN path actually creates a Feature. The other two paths intentionally leave the Feature dimension untouched — and that's the point. The more disciplined we are about opening Features, the more each one is worth.

3. Too big? Split.#

Asking this question means you've already crossed the line into Feature territory. The answer is: split it into smaller Features.

It sounds circular, but it's right. A Feature is a unit of "shippable end to end," not a unit of "effort." Internally a Feature can be one engineer-week or a three-month campaign — but externally, in the business's view, it must be a complete, releasable thing.

If one Feature can't carry the scope in front of you, recut it. The question you cut along is not "can we do this in two weeks?" It's:

"After the cut, can each smaller Feature still be shipped on its own and produce observable business value on its own?"

Yes, split. No, don't split — leave it as a single Feature and finish it end to end.

The diagram below uses a real project to show what this looks like in practice. A perfectly reasonable-looking "After-sales Enhancements" gets recut into six independently shippable Features:

Before the split: three teams, two months, a PR nobody could close, ship date pushed three times, and nobody could tell you "did it work?" After the split: F1 shipped independently in three days, F2 in two weeks, F3 in one week — each with its own observable business echo.

This is what "independently shippable end to end" buys you as a cutting rule — it makes the split provable in facts, not just plausible in stories.

4. The lifecycle — why the Feature dimension matters#

Because the Feature dimension is the only unit of work where we can review business value from start to finish.

It spans every key phase. The diagram below shows the seven steps of one complete loop:

• Intent — why this piece of business is worth doing.
• Scope — what we expect, what reality looks like.
• Gap — the actual distance between expectation and reality.
• Design — what our target state looks like, what trade-offs we picked.
• Build — how we put it together.
• Ship — it actually reaches users.
• Observe — is it producing the business value we expected?

Notice the dashed line in the bottom-right: retrospective knowledge flows back into the next Feature's product-level knowledge. This is the most under-rated capability of the Feature dimension — not only does it ship end to end, it also turns "what we got right / wrong last time" into the product knowledge for the next round. No other unit of work can do this.

It's only inside the Feature dimension that we get to string these views together end to end, instead of flicking between different tickets, different boards, and different docs at every phase.

5. The six artifact layers#

We expect every Feature to naturally leave behind the following six artifacts, so that the Feature can tell its own complete story when we look back:

#	Artifact	Question it answers	Cost of absence
1	Product-level knowledge	The product context this Feature lives in; the product question it answers.	Six months later, nobody remembers why we started.
2	Feature-scoped expectation	The success-state definition we agreed to at kickoff.	No acceptance anchor; nobody can say "did it succeed?"
3	Feature-scoped as-is	The reality we observed before starting — data, pain points.	Future retrospection can only guess at the background.
4	Identified gap	The actual distance between expectation and as-is, and which gaps we're closing in this Feature.	Design phase drifts; we end up solving the wrong gap.
5	Technical solution	The design and trade-offs we chose to close the gaps.	When code gets hard to maintain, we can't tell whether the original trade-offs were worth today's cost.
6	Code	The final result of the solution, and how it maps back to the plan.	We can't even tell whether the plan was ever actually implemented.

Each layer has its own use:

• If the business under-performs, look at product and expectation: was the problem defined wrong?
• If the design drifted, look at gap: which gap were we actually solving?
• If the code is hard to maintain, look at technical solution: was yesterday's trade-off worth today's cost?

As long as these artifacts come along with every Feature, every failed Feature is reviewable and every successful Feature is reusable.

Hard rule. When a Feature is closed, it must link to all six artifacts. If you're closing with only code and none of the other five, the work never deserved to be a Feature in the first place — it should have been downgraded to a Chore / Patch, folded into an existing Feature, or sent back to intake to fill out the artifacts.

6. What it does to your workflow#

Once a Feature truly is "shippable end to end," a few benefits fall out naturally:

• Predictable cadence. Each Feature has its own kickoff, discovery, design, build, ship. We can forecast delivery around Features, not around scattered tickets.
• Clear ownership. One Feature, one owner, end to end. No more "everyone picked up a few cards and nobody can claim the Feature."
• Correct unit of retrospection. One Feature is a natural unit of a retro — closer to business truth than a Sprint.
• AI with bounded reach. AI can accelerate discovery, draft plans, and scaffold code inside the Feature dimension — but only as long as it's anchored to the Feature's gap and expectation. No more AI writing purposeless code across an endless sea of tickets.

That's why we've been emphasizing the Feature dimension in the product shape lately. It's not a Todo under another name, and it's not a Project under another name — it's a slice of work that owns business value end to end.

7. A 60-second checklist#

Before opening a new Feature, run through this quickly:

• Can this thing ship independently tomorrow? (Yes → Feature candidate.)
• Can someone tell whether it succeeded within the first week after release? (Must be observable.)
• If it's "too big," what axis do I cut along? After the cut, can each slice still ship end to end?
• When this Feature closes, will all six artifact layers be present? (Product / Expectation / As-is / Gap / Solution / Code.)
• If any of the above fail, it is not a Feature — it's a Ticket / Chore / Patch. Downgrade.

8. In one sentence#

• When do we need a Feature? When a piece of work can be shipped end to end, verified independently, and observed independently in production.
• When don't we? When it can't be shipped independently, can't be observed independently, or is just a fix on an existing Feature — in any of those cases, use a lighter carrier: a ticket, a patch, or fold it back into the Feature it actually belongs to.

Decision rule, one line: can this thing be shipped end-to-end on its own?

Too big → split, until each slice is still shippable end to end. Too small → merge, until the merged thing is still shippable end to end.

We don't want a team that runs everything through Fabriq. We want a team where every Feature can tell its own story: why it was started, where it stood, and how it landed.