Why Your Game Feature List Needs a Hard Ceiling

An open feature list grows until it breaks something: the budget, the timeline, or the team. Setting a hard ceiling on features before production starts converts scope from an open-ended risk into a fixed constraint. The ceiling is a number, and everything above it is a trade, not an addition.

Why features grow without a ceiling

Feature growth is not a planning failure. It is a natural consequence of learning more about the game.

Every playtest reveals something missing. Every competitive review suggests something to add. Every stakeholder conversation introduces a priority. Without a boundary, each of these becomes a line item, and the list grows by one or two items per week for the life of the project.

At that rate, a six-month project accumulates twenty to fifty additions. Most are individually reasonable. Collectively they are a different game at a different budget, and nobody decided to build that game.

A feature list without a ceiling is a budget without a cap. Both end the same way.

How to set the ceiling

The ceiling is not a feeling. It is derived from three inputs.

Budget. Divide the production budget by the average cost per feature in your genre and team structure. That gives you a rough count. Round down.

Timeline. Map the production schedule in weeks and subtract testing time. The remaining weeks, divided by average feature velocity, give you a second count. Take the lower of the two.

Core loop dependency. List every feature. Mark which ones the core loop requires to function. Those are mandatory. The ceiling applies to everything else.

For a typical casual mobile game in the $50,000 to $100,000 range, the ceiling is usually eight to twelve features beyond the core loop. That sounds small because it is. Shipping a polished game with twelve features beats shipping a rough game with twenty-five.

The economics behind this are in What $50K Buys in Game Development.

The priority method

Once the ceiling exists, you need a way to decide what stays. Stack ranking works better than categorization.

Stack ranking forces every feature into a single ordered list. Position one is the most important, position N is the least. There are no ties and no equal priorities. This is uncomfortable and that is the point.

The ranking criteria should be explicit.

1. Does the core loop need it to function? If yes, it ranks above everything that is not core.
2. Does it affect the metric you are optimizing? Retention, CPI, session length. Features that move the target metric rank higher.
3. Is the cost proportional to the impact? A high-impact feature that takes two days ranks above a medium-impact feature that takes two weeks.

Features below the ceiling line are the cut list. They are not rejected. They are documented, prioritized, and available as trades.

Trades, not additions

The enforcement rule is simple: nothing enters the list without something leaving.

A stakeholder wants a new feature? Fine. Which current feature does it replace? If nothing is worth removing, the new feature is not worth adding.

This changes the conversation from "should we add this" to "is this better than what it displaces." The second question is harder and produces better decisions.

Three trade rules that prevent negotiation erosion.

• The trade must be the same size. A large feature cannot be traded for a small one without adjusting the balance elsewhere.
• The trade is decided by the same person every time. Rotating the decision fragments accountability.
• Trades are logged. A running list of what entered, what left, and why. This log is the scope history of the project and it is valuable at the post-mortem.

What to tell your board

Investors respond well to a ceiling because it demonstrates discipline.

Three things to communicate.

The ceiling exists and is derived from the budget. This shows the number is not arbitrary.

The priority method is explicit. Stack ranking with named criteria shows the team is making principled trade-offs rather than reacting.

Trades are logged. The board can see what changed and why without needing a meeting.

A board that sees a controlled scope with a clear process is a board that does not micromanage features. The alternative, where scope grows and the board finds out through a budget variance, is how trust erodes. The reporting structure is in Board Questions at Month Six.

When to raise the ceiling

Rarely, and only for one reason: the scope change is worth the cost and the cost is funded.

A ceiling raised without additional budget is not a raise. It is a cut disguised as ambition, because the additional features will come out of polish, testing, or team wellbeing.

If the game genuinely needs more features than the ceiling allows, the right sequence is: price the additions, present the cost to whoever controls the budget, get approval, raise the ceiling, and log the change. Skipping any step is how overruns happen.

The dynamics of mid-project scope changes are in Changing Scope Mid-Project.

What we would do

Set the ceiling before production starts, during discovery. Derive it from the budget and timeline, take the lower number, and write it into the project plan.

Stack rank every feature on day one of production. Post the ranked list where the whole team can see it, and update it when trades happen.

Then enforce the trade rule without exception. The first time an addition is accepted without a removal, the ceiling stops existing. Precedent matters more than policy.

The short version

• An open feature list grows by one or two items a week and breaks the budget by month four.
• Derive the ceiling from budget, timeline, and core loop dependencies, and take the lower number.
• Stack rank every feature in a single ordered list with no ties.
• Nothing enters the list without something of equal size leaving.
• Log every trade so the board and the team can see scope history.
• Raise the ceiling only when additional budget is approved and funded.

Count your current feature list and set the ceiling this week. If you want a studio that enforces scope discipline from day one, talk to us.

Related reading: One-Page Game Scope Template, Changing Scope Mid-Project, and Signs Your Game Project Is Off Track.