Maya finds the product has three different date pickers, one per team, and that nothing in the company would have caught the fourth before it shipped
Three Date Pickers — Volume I, Understanding Humans Before Products · Human Systems · Investigation · Practitioner. Maya finds the product has three different date pickers, one per team, and that nothing in the company would have caught the fourth before it shipped
01 · Opening
Maya finds the product has three different date pickers, one per team, and that nothing in the company would have caught the fourth before it shipped
02 · The setup
A support ticket says the calendar behaves differently on the billing screen. Maya opens all three screens to check.
Maya thinks: Three date pickers. Different week start, different keyboard behaviour, one of them cannot be typed into.
03 · The setup
Date pickers in production — Reporting screen: week starts Monday; Billing screen: week starts Sunday; Scheduling screen: no keyboard entry; Teams that own them: 3
04 · The evidence
Maya: Did nobody know the other two existed?
Dev: I knew. Mine shipped in a week and theirs did not do what I needed.
05 · The evidence
Every version of the story is reasonable. Nobody was hiding anything and nobody had a reason to stop.
Maya thinks: Three teams, three deadlines, three sensible decisions. The product is the shape of that.
06 · The evidence
Priya: Scheduling is starting a booking flow next month. They will need dates.
Maya: So there is a fourth one coming and nothing would stop it.
07 · The evidence
Maya writes down every meeting where a fourth picker could plausibly be spotted, and the list is short.
Maya thinks: Sprint reviews are per team. The all-hands is a demo. There is no room where two teams describe what they are about to build.
08 · The evidence
Sam: Add a design review before release.
Maya: By release it is built. Asking someone to throw away three weeks is how reviews become a formality.
09 · The evidence
Three teams with three deadlines and no shared moment produce three of everything. This is not a failure of care — each team made a defensible local decision, and the inconsistency exists in the gaps between them where nobody is standing.
The tempting fix is a review before release, and it does not work. By then the thing is built, so catching it means asking someone to discard finished work, which happens once before the review quietly becomes a rubber stamp.
What the process has to catch is the moment somebody decides they need a date picker, which is weeks earlier and is a question rather than a demo. Anything that surfaces intentions rather than outputs will do it. Anything that inspects finished work will not.
10 · The evidence
Maya: One line in a shared channel when you are about to build a shared control.
Dev: That costs me thirty seconds. A review costs me three weeks of rework.
11 · You make the call
The story does not tell you first.
A. A design review before each release
B. Something that surfaces the intention to build, weeks before the build
C. A component library the teams must use
12 · What happened
The scheduling team posts one line before the booking flow starts. The reply takes an afternoon and there is no fourth picker.
Priya: We extended the reporting one. Two days instead of a week.
13 · What happened
Maya thinks: The three that exist will take a year to merge. The fourth cost one message.
14 · Complete
Inconsistency lives in the gaps between teams, and a process that inspects finished work arrives too late to be worth obeying. Next: when the same evidence supports three different stories.