Retail bank's mobile release bottleneck
A mid-sized retail bank serves 2.1 million customers. Its mobile banking app is rated 3.2 out of 5, and releases occur every 26 weeks. Fourteen approval gates sit between a code commit and production. Nine teams contribute to the app, but no one owns the end-to-end customer journey. Business analysts write requirements; development hands off to operations. About 60% of change requests are marketing content updates, yet those updates wait in the same release queue as loan features. Login failures spike during salary-day peaks, and loan application abandonment is 47%. A competitor now ships weekly. The CTO proposes an 18-month, 20-engineer migration to Kubernetes and microservices. The CIO wants a three-week business case and asks you to advise. Budget is approved only for platform engineering; no product management role exists. Customer support tickets cite slow login and unclear loan status; net promoter score fell eight points in two quarters.
1. What is the most likely binding constraint on mobile delivery, and what evidence in the setup supports your view? Avoid assuming the constraint is the deployment platform.
Read the worked answer
The binding constraint is the approval-and-handoff operating model, not compute capacity. Evidence: a 26-week release cadence with 14 gates; nine contributing teams with no end-to-end owner; business-analyst-to-development-to-operations handoffs; and marketing content waiting behind loan features in the same queue. Sixty percent of changes are low-risk content, which suggests the release process is batching work that could be decoupled. Kubernetes would not remove approvals, create customer accountability, or shorten wait states. A value-stream map should confirm where elapsed time sits: gate reviews, environment queues, and handoffs. Useful measures are lead time from commit to production, deployment frequency, change failure rate, and mean time to restore. The 47% loan abandonment and salary-day login failures also point to reliability and journey ownership gaps, but the system constraint is the release model, not the runtime platform.
2. Recommend two actions for the first 90 days and one metric for each. Explain why they are safe even if the CTO's platform program proceeds.
Read the worked answer
Action one: appoint a product manager for the mobile journey and form a cross-functional team with development, operations, design, and risk. This clarifies prioritization and customer accountability. It is safe under any platform because it changes ownership, not infrastructure. Metric: lead time for mobile changes, split by content and feature work. Action two: decouple low-risk content updates through a content management system and feature flags, with automated risk-based approvals. This reduces queue contention and gate load without a re-platforming dependency. Metric: percentage of content changes shipped without a full release, plus change failure rate as a guardrail. Also run a two-week value-stream map to baseline wait states. These actions are reversible, produce evidence for the business case, and do not preclude Kubernetes. If the platform program proceeds, they supply the product owner and baseline metrics needed to judge whether the platform actually improves delivery.
3. The CIO must respond to the CTO's 18-month, 20-engineer Kubernetes proposal in three weeks. What decision rule should she use, and what should she approve now?
Read the worked answer
Decision rule: fund the proposal only if it targets the validated constraint and has a thin-slice proof with stop/go criteria. Ask four questions: which customer journey improves, which lead-time or reliability metric should move, what is the cost of delay, and what is the smallest reversible step? Approve a six-to-eight-week discovery and thin slice, not the full 18 months. Baseline the value stream, pick one journey such as loan status, and test the minimum platform capability needed: continuous integration and delivery, observability, and environment automation. Fund a product manager and a platform product owner. Set gates: if the pilot does not improve lead time or reliability against baseline, stop or reshape. Keep most budget contingent and require a total cost of ownership and exit plan. This preserves optionality, avoids a big-bang bet, and gives the CTO a fair path if the platform is genuinely the enabler.