Project Context
You’re the program manager for ShopSwift, a global e-commerce marketplace doing $6.5B GMV/year with 18M monthly active buyers. The company’s checkout stack has grown organically over 7 years: multiple payment service providers (PSPs), market-specific fraud rules, and a patchwork of fulfillment and tax integrations. Checkout reliability is a board-level metric because a 30-minute incident during peak hours can cost $1.2M in lost GMV.
Leadership has approved a migration to a new internal service called PayFlow Orchestrator that standardizes payment routing (cards, wallets, BNPL), fraud decisions, and retries. The goal is to reduce payment failures and speed up experimentation. The catch: the existing checkout workflow is poorly documented, and different teams have different mental models of “how checkout works.” Your immediate mandate is to visualize the current state vs. future state workflows in a way that drives alignment, exposes hidden dependencies, and enables a realistic execution plan.
The migration must launch in 8 markets (US, Canada, UK, Germany, France, Japan, Australia, Brazil) by end of Q2 (12 weeks) to support a signed partnership with a BNPL provider that requires PayFlow integration. The cross-functional team includes 10 backend engineers (Payments + Order), 3 frontend engineers (Web + iOS/Android), 2 data engineers, 1 designer, 1 QA lead, 1 security engineer, 1 compliance analyst, and you.
Stakeholder Landscape (Competing Priorities)
- VP Payments: Wants PayFlow live this quarter to unlock BNPL revenue and reduce authorization failures.
- Director of Fraud & Risk: Worried the new orchestration will change fraud decision points and increase chargebacks; demands explicit control points and auditability.
- Head of International: Wants Japan and Brazil included in the first wave due to growth targets, even though they have the most market-specific payment methods.
- Checkout Engineering Manager: Concerned about engineering capacity because the team is also on-call for the legacy stack and has a backlog of P0 reliability work.
- Legal/Compliance: Requires PSD2/SCA correctness in EU and strong data handling guarantees for Brazil (LGPD).
Constraints
- Timeline: 12 weeks to first production rollout; BNPL contract includes penalties if missed.
- Zero downtime: Checkout must maintain 99.95% availability; no planned maintenance windows.
- No net-new headcount: You can re-prioritize within teams but cannot hire.
- Multiple clients: Web, iOS, Android each have distinct checkout flows and release cadences.
- Legacy complexity: The current system has 3 different payment capture paths (immediate, delayed, split shipment) and market-specific tax/invoice rules.
What You Need to Produce (Deliverables)
- Current-state workflow visualization: A clear representation of the end-to-end checkout flow (including exception paths) that engineering, fraud, and compliance all agree is accurate.
- Future-state workflow visualization: The target flow with PayFlow, showing what changes, what remains, and where controls move (fraud checks, SCA, retries, refunds).
- Gap analysis & trade-offs: Identify what must be built vs. deferred for Q2, and explicitly call out risks of deferral.
- Launch plan: A phased rollout plan by market and platform, including monitoring and rollback.
- Alignment mechanism: How you will use these artifacts to drive decisions (reviews, sign-offs, change control) and keep them updated.
Complications (Realistic Curveballs)
- Hidden dependency discovered in Week 3: Germany’s checkout uses a legacy “invoice later” method that triggers a separate credit-check service owned by another org with a 6-week backlog.
- Scope pressure in Week 5: The VP Payments asks to include Apple Pay in the first launch wave because a competitor announced it, but the mobile team says it will jeopardize the timeline.
- Operational risk in Week 7: A production incident in the legacy checkout consumes 2 backend engineers for a full week, reducing migration capacity.
Interview Prompt
Walk me through how you would visualize current state vs. future state workflows for this migration in a way that enables execution. Be specific:
- What notation/artifact(s) would you use (e.g., BPMN, sequence diagrams, service maps, state machines), and why?
- How would you capture happy path + failure modes (timeouts, retries, partial captures, SCA step-up, fraud declines, inventory changes)?
- How would you validate correctness across stakeholders who disagree on the flow?
- How would you use the visuals to drive roadmapping and trade-offs (what’s in/out for Q2)?
- How would you keep the workflows “living” as engineering discovers edge cases during implementation?
Assume you have to present your current/future state artifacts to execs in Week 2 and get approval to proceed with the Q2 plan.