Lesson 15: Postmortem - What to Scale Up vs Cut for Full Production

You made it to the part most teams avoid.

Shipping a multiplayer vertical slice feels exciting because the hard parts are finally visible: people can join, move, fight, disconnect, complain, and sometimes even have fun. That momentum can trick you into one of two bad decisions:

• scaling too early because the slice "basically works"
• cutting too much because the slice exposed rough edges that were always expected at prototype stage

This final lesson is about making a calmer decision. You are not writing a dramatic postmortem for social media. You are creating a practical production memo that tells your future team what is worth carrying forward, what needs another pass, and what should stop consuming time.

Lesson objective

By the end of this lesson, you will have:

1. A postmortem structure built for multiplayer production decisions
2. A four-column review table for keep, rework, defer, and cut calls
3. A simple way to score systems by player value, technical risk, and production cost
4. A shortlist of next-phase bets grounded in playtest evidence instead of wishful thinking
5. A final course-close document you can reuse for future slices

Why the postmortem matters

Vertical slices are not small finished games. They are decision tools.

If your multiplayer slice did its job, it revealed:

• which systems already feel trustworthy
• where host-authority or transport choices are creating friction
• whether your loop is fun enough to justify more content
• how much production weight your team can realistically carry

Without a postmortem, teams usually default to momentum. They keep building whatever is already in motion. That leads to expensive habits:

• polishing weak systems because they already exist
• adding maps before the session loop is reliable
• scaling player count before the current count is stable
• rewriting architecture without proving the current design limits

The postmortem replaces vague momentum with explicit bets.

What this lesson is really deciding

At the end of a multiplayer vertical slice, you are usually deciding between four paths:

1. Continue toward full production with the current core intact
2. Continue, but rebuild a few critical systems first
3. Pause and run one more constrained milestone before committing
4. Stop or shelve the project because the current evidence is not strong enough

That sounds dramatic, but it is healthier than drifting.

The production-decision lens

Judge every major system through three questions:

1. Did players get clear value from it?
2. Can the team support it at production scale?
3. Does it still fit the fantasy and business scope of the game?

If a system scores low on all three, it does not deserve "maybe later" protection. It should be cut.

If it scores high on player value but high on technical pain, it probably belongs in the rework column.

If it is promising but not needed for the next milestone, defer it instead of letting it quietly expand scope.

The four-column postmortem table

The planner asked for one four-column review table. Use it as the center of the lesson and of your actual memo.

If you want one more helpful column in your own notes, add evidence privately. For the public-facing lesson, the simpler table is easier to skim.

Step-by-step postmortem workflow

Step 1 - Re-state the slice promise

Start with the promise you were trying to validate:

We aimed to prove that a small-group Unity multiplayer match could be easy to join, readable under moderate latency, and fun enough to justify a larger production phase.

That one sentence matters because it gives you a fair baseline. You are not judging the slice against a launch-ready live service. You are judging it against its intended proof.

Step 2 - Gather evidence before opinions

Pull from four sources:

• playtest feedback forms
• bug and crash notes
• profiler or logging observations
• team production notes from building the slice

You want evidence like:

• "4 of 6 sessions completed a full match without restart"
• "new players understood host/join after one pass through the menu"
• "disconnect recovery messaging was clear, but actual recovery was unreliable"
• "scoreboard caused confusion after reconnect in 3 sessions"

You do not want evidence like:

• "the vibe felt off"
• "networking seems scary at scale"
• "we should probably rewrite this later"

Opinions are fine after you anchor them to observed behavior.

Step 3 - Separate fun problems from production problems

A multiplayer slice can fail in two different ways:

• the experience is technically unstable
• the experience is stable enough but not compelling

Those are different decisions.

If players struggle because of disconnects, replication bugs, or unclear session flow, you may still have a strong game underneath. That points to rework.

If the build is relatively stable but nobody wants "one more match," that is a product problem. More engineering may not save it.

Step 4 - Score each system quickly

Use a lightweight 1-3 score for each category:

• Player value
• Technical risk
• Production cost

Example:

This prevents one loud opinion from dominating the roadmap.

A practical keep, rework, defer, cut rubric

Keep

Use keep when:

• players clearly benefit from the system now
• the system supports the core fantasy
• it is stable enough to extend without rewriting first

Examples:

• current authority model for a small player count
• match start and end loop
• a readable HUD that supports onboarding

Rework

Use rework when:

• the system matters to the game
• the slice proved the concept
• the current implementation will become a liability at the next scale step

Examples:

• reconnect handling
• timeout and error recovery messaging
• state sync or ownership edge cases that appear under stress

Defer

Use defer when:

• the idea is promising
• it is not needed for the next production milestone
• building it now would steal time from the core loop

Examples:

• ranked rulesets
• cosmetics
• clan or social features
• advanced progression

Cut

Use cut when:

• the feature did not materially improve player experience
• the team cannot afford it without harming the core
• it duplicates value already created elsewhere

Examples:

• a second onboarding path no one used
• a complex lobby layer that added friction
• speculative scale features unsupported by current audience goals

Example postmortem memo structure

Use this for your actual project notes:

1. Slice goal

One paragraph explaining what the slice was meant to prove.

2. What worked

Three to five bullets only. These are systems you can confidently carry forward.

Example:

• players formed sessions with minimal coaching once host and join labels were clarified
• one complete match loop delivered enough tension and replay intent to justify expansion
• headless smoke tests plus simple logs made regression checks cheap

3. What needs rework

Focus on high-value systems with high failure cost.

Example:

• reconnect handling still creates too much uncertainty after host loss
• scoreboard and end-of-match feedback become unreliable after disconnect/rejoin edge cases
• error messaging is understandable, but not actionable enough for players

4. What we should cut or defer

This is the section that protects the team.

Example:

• cut second mode prototypes until the first mode consistently retains players
• defer cosmetic progression until session reliability and rematch flow improve
• cut transport abstraction work that is not tied to an active migration need

5. Next milestone recommendation

End with one explicit recommendation:

Proceed to pre-production with one map, one mode, current authority model, reconnect rework, and a session-completion KPI for the next milestone.

That sentence should make the next 4-8 weeks obvious.

Mini-task: make one production decision table

Create a note called multiplayer-slice-postmortem.md and include:

1. Slice goal
2. Three strongest signals from testing
3. The four-column system review table
4. One paragraph on what to scale up next
5. One paragraph on what to cut immediately

Keep the full document under two pages. If your postmortem turns into a novel, you are probably hiding indecision inside too much text.

Example recommendation scenarios

Scenario A - Keep moving

Use this when the loop is fun, the join flow mostly works, and bugs are painful but bounded.

Recommendation:

Continue with full production planning, but lock player count, preserve the current networking model, and spend the next milestone on reliability, rematch flow, and observability before adding content breadth.

Scenario B - Rework before scale

Use this when the fantasy lands, but your infrastructure is too fragile for more content or more players.

Recommendation:

Run one more technical milestone focused on reconnect, host migration alternatives, and session-state integrity before greenlighting a broader content roadmap.

Scenario C - Shelve or narrow hard

Use this when the loop is not compelling enough and the tech burden is already heavy.

Recommendation:

Pause full-production planning and either cut the scope down to a smaller co-op toy or archive the project while preserving reusable netcode lessons for the next prototype.

This is not failure. It is saved time.

Pro tips

• Write the postmortem within 24-48 hours of the latest meaningful playtest while details are still fresh.
• Force every "rework" item to name the specific risk it solves.
• Keep one mode, one map, and one player-count target alive until the next milestone proves they are stable.
• Protect your strongest fun signal even if it came from a messy build. Fun is harder to find than bugs.
• If a system only survives in the roadmap because someone already spent time on it, it belongs under review, not under protection.

Common mistakes

• Treating every unfinished feature as "defer" instead of choosing some real cuts
• Confusing noisy technical pain with proof that the fantasy is weak
• Expanding scope because one playtest went well
• Planning for a future audience size that the game has not earned
• Writing recommendations with no owner, timeframe, or milestone purpose

Troubleshooting

"Our team cannot agree on what to cut."

Go back to the slice goal and ask whether the feature was necessary to prove that promise. If not, it should not survive by default.

"A system is fun but technically ugly."

That is often a rework candidate, not a cut candidate. Preserve the player value and rebuild the implementation if the risk is real.

"We do not know whether the slice is good or just novel."

Look for repeat intent. Did players want another match? Did they understand the win condition? Did they recover from friction because the loop felt worth it? Those signals matter more than compliments.

FAQ

What should a multiplayer vertical slice postmortem include?

Include the slice goal, strongest evidence from playtests, a keep or rework or cut review of major systems, and a clear recommendation for the next milestone.

How do I decide what to cut after a Unity multiplayer prototype?

Cut anything that does not materially improve the core session loop, increases technical risk without solving a current problem, or distracts the team from reliability and fun.

Should we scale player count right after the slice works?

Usually no. First prove that your current player count is stable, legible, and worth replaying. Scaling too early multiplies confusion and debugging cost.

Recap

This course finished where good multiplayer production should begin: with evidence, not momentum. You reviewed the slice as a decision tool, separated core value from technical drag, built a keep or rework or cut table, and turned a promising prototype into a production-facing recommendation. That is how small teams protect both their time and their best ideas.

Course complete - what to do next

From here, choose one of these paths:

1. Run a short reliability milestone for reconnect, observability, and end-of-match clarity
2. Move into pre-production with one locked mode, one map, and one KPI-driven roadmap
3. Pause and reconcile the project against business goals before scaling further

Related links

• Lesson 11: Profiler with Networking Counters - Bandwidth, Tick, and GC Spikes
• Lesson 12: Automated Playmode Tests for Net Edge Cases - Connect, Disconnect, and Timeout Coverage
• Lesson 14: Ship a Friends-and-Family Playtest Build with Feedback Form and Version String
• Unity Netcode for GameObjects Documentation
• Unity Multiplayer Services Overview

You now have a complete multiplayer vertical-slice course, but more importantly, you have a reusable way to decide whether a prototype deserves the next year of your time.