Product owners say resident-facing permit pages 'must feel instant on mobile,' but engineering has no numeric targets. How should architects translate that requirement?
Select an answer to reveal the explanation.
Short Explanation
'Feels instant' is poetry until you put a stopwatch on it. Turn the wish into p95/p99 numbers residents would actually feel on a phone, then watch those KPIs. Without numbers, every complaint is both an emergency and a shrug.
Full Explanation
Qualitative wishes that resident-facing permit pages “must feel instant on mobile” cannot guide architecture or operations without numbers. Defining measurable latency KPIs and SLOs such as p95/p99 page or API latency on mobile networks, and tracking them in CloudWatch or RUM against error budgets, translates product language into engineering targets. That approach works because continuous improvement, capacity decisions, and release gates need thresholds residents would recognize as “instant,” not vibes or hallway opinions. Keeping the requirement qualitative and paging whenever a resident tweets fails as anecdotal operations that neither prove nor disprove regressions. Replacing latency goals with CPU utilization targets only fails conceptually: compute metrics are not user experience and can look healthy while mobile pages crawl. Declaring success if the homepage loads eventually within one calendar day fails any meaningful citizen mobile expectation for permitting. Exam caveat: choose SLIs that reflect critical journeys on representative mobile network conditions; lab Wi-Fi p50 is not a substitute for field mobile p99 on cellular. Operational check: instrument RUM or synthetics for the permit submit and status journeys, publish p95/p99 SLOs with error budgets, review burn in sprint planning, and reject releases that violate the budget without an explicit mitigation.