How I decide which feature to cut (notes from building Tingbase)

Every project I've shipped or tried to ship hits the same point: something has to go, and it's usually a thing I enjoyed building.

I'm making Tingbase in Unity 6 and C#. It's a 3v3 hero shooter where you swap between Tank, DPS and Healer. The core sentence for it is short: pick a role, enter a match, play until it ends. Anything that doesn't serve that sentence is a candidate for the cut.

The one question I ask first

If this feature goes, what does the player actually lose?

If the honest answer is "a bit of depth" or "a bit of variety", the feature was never required. It goes on the later list.

The follow-up is for when I catch myself saying "it doesn't work without this". Would a player notice it was missing if I never told them? If not, the absence is mine, not theirs. Players look for what you promised them, not for what you imagined.

Count the real cost

The visible task is always the small number. The real list is code, content, UI, sound, testing, integration with other systems, and then the second iteration after the first version is "done". When I write all of that down next to a feature, most cuts make themselves.

Time box it, or just call it

Two approaches I've seen work on real teams:

1. Give the threatened feature a short, dated window and clear conditions. If it misses them, it leaves. No re-arguing.
2. If even the time box would cost more than it saves (extra systems, already behind), call the cut right away.

Whichever one you use, say it in one plain sentence: how much time there is, what the feature is, and that it's out. "Parked for now" is a different sentence, and people hear the difference. On a solo project, the person most attached to the feature is you, so be honest with yourself here.

Turn it off, then write it down

In practice I turn the feature off, hand the build to someone, and ask if anything feels missing. If they only notice after I point at it, that's my answer.

Then I write it on the later list instead of deleting the note. Deleting it just reopens the argument a month later.

The longer version, with examples from other studios' production notes and a decision table, is here: How to cut a feature on yuvalgg.com