The interactive controls need JavaScript. You can still read both cases here. Write your choice, reason, date and what would change your mind before opening one evidence packet. Then record your current choice, new reasoning and next step separately. There is no right-answer score.
Where would you spend the week?
Fictional case · version 1
You work on a small scheduling app. Two people have one week for an improvement. They can complete one of the options below, but not both. The goal is to help new teams finish setting up their first schedule.
- Of 40 teams that started setup last week, 24 finished. This is one week of observations, not a trend.
- Five recent support messages mention confusing setup; four mention a slow import. The messages may come from overlapping teams.
- You do not yet know which unfinished teams tried importing, or why each stopped. Both changes can be released to a small group first.
Simplify the first-use screen: Make the sequence and next step easier to understand for every new team. Trade-off: Spend the week on a path some teams already complete; leave import delays unchanged.
Fix the slow import: Remove a known wait for teams bringing in an existing schedule. Trade-off: Spend the week on only the importing teams; leave confusing instructions unchanged.
Talk to unfinished teams: What did people say made them stop?
Four of the 16 unfinished teams agree to a short call. Three say they did not understand the next step; one says its import took too long.
The other 12 teams do not reply. These four conversations explain experiences, not how common each cause is.
Limit: The calls cannot establish the cause of all 16 unfinished setups or predict either change's effect.
Simplify the first-use screen: Three concrete reports make the instructions a plausible place to help. The people who replied may differ from the silent teams.
Fix the slow import: One report confirms that waiting can block setup. Choosing the import still needs a reason to prioritise its smaller observed group over the instruction problem.
Inspect the setup logs: Where did the observed groups get stuck?
Twelve teams tried importing: four finished setup and eight did not. The other 28 teams had 20 completions and eight unfinished setups.
The logs record clicks and timing, not intent. Teams that import may have larger or more complicated schedules.
Limit: The counts are small, and a difference between groups does not tell you how many teams a fix would help.
Simplify the first-use screen: Eight teams stopped without importing, so the import fix leaves a visible group unaddressed. Logs alone do not show that instructions caused those stops.
Fix the slow import: Eight of 12 importing teams stopped, compared with eight of 28 other teams. That concentration warrants a closer look, but the groups differ and this is not a causal test.
Check the engineering estimate: How reversible and testable is each change?
The team can turn a simpler screen on or off for a small group in a day after the work is finished.
The slowest imports use an old file format. The proposed fix supports those files, but another day would be needed to check unusual formats before a broad release. A limited release still fits this week.
Limit: Feasibility changes the cost of learning; it does not reveal which problem matters most to new teams.
Simplify the first-use screen: A quick rollback makes a small trial easier. Ease of release does not establish that the screen is the most important problem.
Fix the slow import: The fix targets a documented slow path and fits a limited release. Its format-testing work must remain part of the next step, rather than disappearing from the plan.
How would you hand work over?
Fictional case · version 1
A support team works two shifts with a 15-minute overlap. Three requests were handled twice last week. For the next five workdays, the team has time to try one handover method. The goal is fewer missed or duplicated next steps without making every shift longer.
- The three duplicate requests were among 60 handed over last week. Nobody has yet checked why each happened.
- One teammate wants a short written template; another says a conversation would surface details people forget to write down.
- Both trials need a named owner for each open request. Neither method replaces the existing request record or changes customer commitments.
Try a written handover: Keep the owner, next step and uncertainty visible when someone starts later. Trade-off: Require time to write and read; a template can still hide an ambiguous exception.
Try a short daily overlap: Ask follow-up questions while both shifts are available. Trade-off: Use the shared 15 minutes; absent teammates still need a written trace of decisions.
Review the three requests: What actually went wrong in the duplicated work?
Two request records had no next owner. The third had an owner, but a conditional instruction was read as definite.
No customer outcome has been reviewed. The team cannot yet tell how costly these duplicate actions were.
Limit: Three examples can guide a trial, but cannot establish that either method will prevent future mistakes.
Try a written handover: An owner field directly addresses two omissions, if someone checks it. The conditional instruction needs clear wording, not just another field.
Try a short daily overlap: A conversation could expose the ambiguous condition and agree ownership. Those agreements need to reach anyone who is not there.
Check next week's availability: Can everyone use the proposed handover?
On two of the five days, one incoming teammate will start after the overlap. Their schedule cannot change for this trial.
Everyone can read the existing request record. Nobody has measured how long a useful written handover takes.
Limit: Availability rules out assuming perfect attendance. It does not prove that written instructions are clearer.
Try a written handover: An asynchronous record includes the late starters. The time required and whether they actually read it still need checking.
Try a short daily overlap: Three shared days can still support questions. On the other two days, this choice needs a specific way to transfer decisions to the late starter within the time budget.
Try one fictional request: What happens in a small rehearsal?
In a synthetic rehearsal, a teammate writes an owner and next step in three minutes. A second person spots an unclear exception and needs a two-minute conversation.
The rehearsal uses an invented request chosen by the team. It is not a measured result from live work.
Limit: One selected rehearsal demonstrates a possible failure mode, not a reliable time saving or success rate.
Try a written handover: The record made the next step visible, and exposed an exception worth clarifying. Plan a way to ask that question when shifts do not overlap.
Try a short daily overlap: A short conversation resolved one ambiguity. Keep a written trace and check whether ordinary requests consume the same amount of time.