Connecting the dots
“You can’t connect the dots looking forward; you can only connect them looking backward.”
— Steve Jobs
Hardi Jain · AI and SaaS product manager
ENTERPRISE · STORY 07
Web checkout · mobile SDK · 16 engineering squads · platform execution
A problem that looked like engineering capacity turned out to be an execution system.
01 · THE CONTEXT
The payment experience was being built and maintained across multiple engineering squads.
As the platform evolved, the challenge wasn’t simply building new functionality. It was keeping multiple teams moving toward the same product outcome.
02 · THE PROBLEM
The product needed common components and experiences across Web and SDK, but delivering one standardized capability could involve several squads.
A dependency on one team could therefore affect the delivery of an entire capability.
03 · THE SYMPTOM
The bottleneck wasn’t necessarily how much engineering capacity existed.
It was how effectively that capacity could move across team boundaries.
04 · DISCOVERY
Rather than looking at individual sprint performance alone, the investigation moved across the delivery system: how work was written, where dependencies sat, and when teams planned.
05 · THE INSIGHT
You can define a standard component. But if each stage interprets or executes it differently, a product standard does not automatically become a delivery standard.
Platform consistency requires consistency in the system that delivers the platform.
06 · THE DECISION
Solving each dependency separately meant one dependency, one status call, one escalation, repeated indefinitely.
The alternative was a common delivery framework that every squad worked inside.
07 · THREE LAYERS
Work readiness reduced ambiguity before engineering started. Dependency alignment made dependencies visible before they became blockers. The quality gate meant standardization did not stop when development finished.
08 · HOW IT CONNECTED
Rather than a collection of disconnected team activities, the work moved through a single path with checks that everyone recognised.
09 · MY ROLE
The diagnosis mattered more than the fix. Adding people would not have helped; the friction was between the teams that already existed.
10 · BEFORE AND AFTER
The same product change, moving through a system that expects it rather than one that discovers it.
11 · THE DISTINCTION
This story asks how we made the organization capable of delivering the standard consistently. Cross-platform payment UX standardization asks how we identified and standardized the product experience itself.
They are not the same problem, and neither one solves the other.
12 · WHAT CHANGED
The execution framework improved delivery speed across the participating squads by 40%.
It also supported the broader standardization of 200+ components across Web and SDK, which reduced reported UX inconsistencies by 30%.
13 · THE SECOND-ORDER EFFECT
Standardized execution removed ambiguity, which made dependencies visible, which made coordination possible, which made delivery predictable.
That is what let platform standardization happen at all.
Adding more engineering capacity isn’t the only way to improve delivery. Sometimes the bigger opportunity is to remove the friction between the teams that already exist.
Product Manager · AI and SaaS
Connecting the dots
“You can’t connect the dots looking forward; you can only connect them looking backward.”
— Steve Jobs