Most plans look convincing until somebody asks how a real person moves through them. A feature list can say “private rooms” and “invite links” while leaving the difficult behavior undecided: Who creates an invite? Can it be revoked? What happens when it is reused? How does a returning player reach the same room without creating a second identity?
Episode 2 follows Nadia, a product owner building a phone-first, chat-only online Mafia game for friends. Her Vision session has already produced one accepted outcome from four roadmap items: private rooms, live game chat, secret classic roles, and automated rounds. Now she takes that same outcome into Kana’s Planning session.
The plan starts with a decision, not a longer feature list
Kana keeps the decisions from the Vision session attached to the outcome. Nadia does not have to explain the game from scratch or reconstruct why private access matters. The Planning session focuses her attention on choices that still change what the team will build.
Role scaling is a useful example. The accepted outcome says the game supports six to twelve players and includes Mafia, Detective, Doctor, and Villager roles. It does not yet say how many Mafia players to assign at each room size or when the host may start. Those choices change lobby validation, role assignment, and the first night transition.
Kana makes that uncertainty visible before task execution. Nadia chooses a concrete rule: one Mafia at six or seven players, two at eight to ten, and three at eleven or twelve; one Detective and one Doctor; everyone else is a Villager; and the host can start once at least six players are ready.
The value is not the wording of the risk. The value is that a security and experience concern becomes a decision that another person can inspect, challenge, and trace into the plan.
Four player capabilities replace one vague promise
Kana breaks the accepted outcome into four reviewable capabilities:
- Create and join a private Mafia room
- Chat with the private room
- Start an eligible room with secret classic roles
- Complete timed, server-authoritative Mafia rounds
Each task delivers a recognizable piece of the player experience. Room access comes first. Chat and game setup build on it. The final task owns the day-and-night game loop. This is more actionable than distributing “frontend,” “backend,” and “database” work before the product behavior is clear.
The dependencies remain visible, so reviewers can question the order without losing the accepted outcome those tasks jointly deliver.
Task → journey list → scenario acceptance criteria
Kana’s progressive flow is deliberate. First review the task breakdown. Then review the journeys inside each task. Then review acceptance criteria as scenarios for each journey.
For the first task, the journey is “Create a private room and invite friends.” Kana turns it into scenarios covering the host, invited players, room isolation, and safe observability.
Those journeys become scenario acceptance criteria:
- Can a host create a room that accepts only six to twelve players?
- What happens when an invitation is expired, revoked, or the room is already full?
- Can a session ever read or change another room’s membership or invitation data?
- Do admission failures produce useful diagnostics without storing raw tokens or session secrets?
The scenarios are small enough to question and concrete enough to test. They expose missing behavior before implementation turns assumptions into code.
Blueprints contribute where a scenario needs them
A blueprint is useful when it helps reviewers reason about behavior—not when it merely fills a diagram gallery.
The private-room journey points to seven contributing blueprints. Together they keep behavior, data, APIs, experience, architecture, and quality aligned. A reviewer can open the blueprint detail when it is relevant while keeping the scenario that needs it in view.
Different scenarios may need different contributing blueprints. The Planning session preserves those relationships so the next review can stay focused on the evidence needed for each decision.
When the plan changes, Kana shows what may no longer match
Plans evolve. A task title, journey, rule, or acceptance criterion can change after related artifacts have already been drafted. Kana records specification drift so the affected work does not silently look current.
That gives Nadia a practical answer to a common planning failure: “We resolved this last week—why did the implementation still follow the old rule?” The mismatch remains visible until somebody reviews and resolves it.
What Nadia has at the end of the Planning session
Nadia finishes with a connected plan rather than a stack of generated documents:
- four dependent tasks sliced by player capability;
- a journey list for each task;
- scenario acceptance criteria for the moments that protect the game experience;
- contributing blueprints tied to the behavior they help explain;
- visible risks, decisions, and specification drift.
That outcome is ready for the Review session, where a human reviews the work progressively: task breakdown, journey lists, scenario acceptance criteria, and contributing blueprints.
Meanwhile, Nadia can keep adding roadmap items in the Vision session, group them into later outcomes, and prepare those outcomes for Planning while this first plan moves through Review. One outcome does not have to freeze the rest of the product.
Continue the series
Episode 3 follows the same Mafia game into the Review session and shows how progressive approval keeps the reviewer focused on one level of product evidence at a time.
Want to take your own product from an accepted outcome to reviewable work? Join the Software Factory waitlist.
