Designing Payment GTM Strategy
Challenge: Simplify payment flows to move faster and more easily scale payment solutions to new internal partners.
My role: As a Senior UX Designer, I partnered with our head of product in financial engineering to define the scope of research and determine key users to interview. I led the discovery phase and facilitated interviews with 52 stakeholders to audit and streamline the ecosystem, tools, ways of working, and build a shared language.
My team: Senior Service Designer (me), Product Partners, Tech Partners
Impact: Simplified financial data systems into intuitive service flows, capability catalogue, domain language, and stakeholder requirements, accelerating GTM timelines by 18%.
Summary: Faced with siloed tools and fragmented processes, both sides of Financial Engineering—payins and payouts—sought a unified, end-to-end view of their bespoke systems, tools, and stakeholders. Their goal: to streamline operations, enable better data flows, and improve overall efficiency. Over six months, I led a cross-functional research initiative spanning three business verticals and three revenue streams to audit workflows, identify pain points, and uncover systemic inefficiencies. Beyond mapping the ecosystem, I surfaced opportunities to improve ways of working and knowledge transfer, which informed a more scalable tooling strategy. The effort culminated in a stakeholder playbook and a set of shared domain definitions, which enabled more aligned, efficient collaboration and accelerated the implementation of key operational improvements.
My Process Overview
The Mapping
Although the Financial Engineering team had robust documentation on technical architecture, they lacked a cohesive understanding of how the payin and payout functions connected. Following a major layoff, they aimed to uncover points of synergy to improve data flow and knowledge transfer as they worked to unify resources. I kicked off the effort with a literary review of process diagrams across the ecosystem, then quickly moved into stakeholder interviews to calibrate the right level of detail for a meaningful, end-to-end blueprint of the ecosystem.
Through 52 cross-functional interviews I conducted, I mapped the tools and teams behind end-to-end revenue flow and ledger tracking. The work revealed major silos: payins were relatively standardized due to a unified entry point, while payouts lacked consistency and visibility across verticals. I analyzed where manual spreadsheet entry introduced risk and where mature, scalable tooling existed. With each revenue stream having grown independently, I focused on identifying reusable building blocks to inform future implementation and drive operational alignment.
The Blueprint Findings
While the payin side followed relatively standardized processes, complexity lived in payouts, where each vertical relied on bespoke tooling. I evaluated nine tools using a “jobs to be done” framework, analyzing ownership, capabilities, dependencies, and user scale—from individual creators to enterprise clients needing self-serve to white-glove support. My goal was to identify which tools could scale across segments and revenue streams, and at what cost. Less mature areas depended on manual spreadsheets , while others used configurable tools with broader potential. For example, while the royalty calculator remained bespoke, several other tools could extend beyond their original use cases. Notably, there was little tooling overlap between payins and payouts beyond the general ledger. This work laid the foundation for connecting both sides to drive efficiency and improve end-to-end data flow.
domain Solutions
During discovery, it became clear that domain concepts were not only disconnected between payin and payout—they weren’t even consistently understood within each side. To address this, I brought in a domain mapping SME to validate language across teams and establish shared terminology. We defined a domain as “a sphere of knowledge, influence, or activity,” and used this framing to create a high-level key showing how components of financial engineering relate to one another.
We introduced two domain types: vertical domains, which spanned the system and offered consistent interfaces, and horizontal domains, which mapped to either payin or payout flows and revealed parallel patterns in activity and team structure. To promote adoption, we aligned our model with existing commerce platform domains, ensuring shared understanding across stakeholders.
This framework became a strategic reference point, reducing cross-team confusion, improving onboarding, and informing early decisions around service boundaries and tooling ownership. It also enabled faster alignment during later-stage implementation planning, creating a scalable foundation for how financial engineering work would be organized and executed moving forward.
GTM STrategy
The Commerce Use-Case Framework provides a structured, scalable way for Spotifiers to navigate the commerce ecosystem. By mapping the full lifecycle of a business model—what is sold, how, to whom, and how it’s fulfilled, paid for, and accounted for—it clarifies the services and capabilities needed to take products to market. This framework became a critical planning tool, enabling teams to quickly assess feasibility and align on the best path forward.
By visualizing support through “Golden Paths”—pre-approved, scalable models, highlighted in green —teams could fast-track decisions and reduce time-to-market. Configurable but less mature paths were flagged for further discovery, while unsupported approaches were clearly marked as “off-road,” helping to proactively surface risks and dependencies. As a result, the framework improved cross-team clarity, reduced redundant conversations, and made it easier to scale new initiatives efficiently and confidently.
