Company Context

You’re the PM for Merchant Console at PayPilot, a Series D fintech that provides payment processing and fraud tooling for ~220,000 SMB merchants in the US and EU. PayPilot’s core revenue comes from take-rate + premium add-ons (chargeback protection, advanced reporting). The Merchant Console is where merchants reconcile payouts, manage disputes, and configure fraud rules.

The console currently serves 3.5M monthly active users (MAUs) across web, with ~420k weekly active merchants. The product is business-critical: when merchants can’t reconcile payouts or respond to disputes quickly, they churn to Stripe, Adyen, or Shopify Payments.

PayPilot’s web frontend is a mix of legacy AngularJS (1.x), Angular (v10), and a newer React codebase built by a growth team. Engineering leadership wants to standardize on one modern framework for the next 18–24 months as the company rebuilds the Merchant Console to support new products (instant payouts, multi-entity reporting, and EU PSD2-related flows).

User & Market Scenario

Primary user personas

Competitive landscape

• Stripe Dashboard is perceived as fast and consistent; merchants cite “trust” and “polish.”
• Shopify Payments wins on integrated commerce workflows and simple reporting.
• Adyen is powerful but complex; mid-market merchants complain about steep learning curve.

PayPilot’s differentiation is best-in-class dispute automation and lower total cost for SMBs. However, recent NPS verbatims show UI quality is becoming a deciding factor.

Problem / Opportunity

Over the last 2 quarters, Merchant Console reliability and delivery speed have degraded:

• Page load time (P75) on the Disputes dashboard is 4.8s (goal < 3.0s).
• Frontend error rate is 1.6% of sessions (goal < 0.8%), driven by inconsistent state management across frameworks.
• Release cadence slowed from weekly to every 3 weeks due to integration overhead and duplicated components.
• Support tickets tagged “reporting UI confusion” increased +22% QoQ.

Engineering proposes two options:

1. Standardize on React for all new UI and gradually migrate Angular surfaces.
2. Standardize on Angular (modern) and migrate the React surfaces back into Angular.

Leadership asks you a deceptively simple question: “React vs. Angular — what should we do?”

As the PM, you must treat this as a product decision, not a personal preference debate.

What You Need to Deliver (in the interview)

1. Clarify the user problem you’re solving by standardizing (who benefits and how).
2. Define decision criteria that connect framework choice to outcomes (speed, quality, consistency, hiring, accessibility, performance, etc.).
3. Propose a recommendation (React, Angular, or a hybrid policy) and explain the trade-offs.
4. Outline an MVP migration / standardization plan for the next 2 quarters (what gets rebuilt first, what stays, what gets wrapped).
5. Define success metrics and how you’d validate the decision within 90 days.

Constraints

• Timeline: must ship a new Disputes experience in 12 weeks (regulatory pressure: new card network dispute reason codes).
• Team: 18 frontend engineers total across 3 squads. Skill distribution: 10 Angular-heavy, 6 React-heavy, 2 full-stack generalists.
• Platform: design system exists but is fragmented (Angular component library is ahead; React library is incomplete).
• Compliance: console must meet WCAG 2.1 AA accessibility standards; audit in 6 months.
• Risk tolerance: cannot exceed 2 hours/month of console downtime; must support rollback.

You can assume backend APIs remain unchanged for the next quarter.