Design a Feature to Get More Clients Integrating via J.P. Morgan's Payments API Portal

Quick Overview

A product design question for a J.P. Morgan PM role: propose a new feature for the bank's Payments Developer Portal that brings more clients to adopt its payments APIs. It tests how a candidate defines adoption for an enterprise API, finds where client integrations stall, and chooses success metrics and guardrails.

Design a Feature to Get More Clients Integrating via J.P. Morgan's Payments API Portal

Company: J.P. Morgan

Role: Product Manager

Category: Product Design & Strategy

Difficulty: medium

Interview Round: Other

You are the product manager for J.P. Morgan's Payments Developer Portal, where client engineers find, test and integrate the bank's payments APIs. Design a new feature that would increase customer adoption. ```hint Follow one client to its first live payment For a payments API, adoption shows up as live payments, not page views. Trace a client's path from the first portal visit to the first production payment, find the step where most clients stall, and ask who owns that step. ``` ### Clarifying Questions - Whose adoption matters most: existing corporate treasury clients connecting their ERP, platforms and fintechs that embed payments for their own users, or prospects who do not bank with J.P. Morgan yet? - What counts as adoption: more portal sign-ups, more clients making a first successful sandbox call, or more clients sending live payments in production? - Where do integrations stall today: choosing the right API, getting sandbox access, the agreements and security setup needed for production keys, or building the integration itself? - Is the feature limited to the portal, or can it also change how relationship managers and implementation teams onboard clients? ### What a Strong Answer Covers - A definition of adoption that fits an enterprise payments API, and a chosen client segment with the reason for choosing it. - The integration journey from first visit to first live payment, separating developer friction from the bank-side and compliance steps that a portal cannot simply remove. - A specific feature with an MVP scope, compared against alternatives and prioritized. - Success metrics for adoption, leading indicators along the journey, and guardrails on security, payment errors and support load. - Risks particular to a bank, such as security, entitlements, regulatory differences and internal system dependencies. ### Follow-up Questions - After launch, sandbox sign-ups rise but the number of clients going live stays flat. How do you find out why? - How would you balance a self-serve path against the relationship managers and implementation teams who run large client onboardings today? - What would you change in the design for fintech platforms that embed payments for many end customers?

Overview: A product design question for a J.P. Morgan PM role: propose a new feature for the bank's Payments Developer Portal that brings more clients to adopt its payments APIs. It tests how a candidate defines adoption for an enterprise API, finds where client integrations stall, and chooses success metrics and guardrails.

J.P. Morgan logo
J.P. Morgan
Nov 25, 2025
mediumProduct ManagerOtherProduct Design & Strategy
0
0

You are the product manager for J.P. Morgan's Payments Developer Portal, where client engineers find, test and integrate the bank's payments APIs. Design a new feature that would increase customer adoption.

Clarifying Questions Guidance

  • Whose adoption matters most: existing corporate treasury clients connecting their ERP, platforms and fintechs that embed payments for their own users, or prospects who do not bank with J.P. Morgan yet?
  • What counts as adoption: more portal sign-ups, more clients making a first successful sandbox call, or more clients sending live payments in production?
  • Where do integrations stall today: choosing the right API, getting sandbox access, the agreements and security setup needed for production keys, or building the integration itself?
  • Is the feature limited to the portal, or can it also change how relationship managers and implementation teams onboard clients?

What a Strong Answer Covers Guidance

  • A definition of adoption that fits an enterprise payments API, and a chosen client segment with the reason for choosing it.
  • The integration journey from first visit to first live payment, separating developer friction from the bank-side and compliance steps that a portal cannot simply remove.
  • A specific feature with an MVP scope, compared against alternatives and prioritized.
  • Success metrics for adoption, leading indicators along the journey, and guardrails on security, payment errors and support load.
  • Risks particular to a bank, such as security, entitlements, regulatory differences and internal system dependencies.

Follow-up Questions Guidance

  • After launch, sandbox sign-ups rise but the number of clients going live stays flat. How do you find out why?
  • How would you balance a self-serve path against the relationship managers and implementation teams who run large client onboardings today?
  • What would you change in the design for fintech platforms that embed payments for many end customers?