Designing SPOTIFY PAYMENT FOUNDATIONS and GTM STrategy

 

Challenge: Design unified foundations and shared primitives to scale payment systems across multiple business verticals and internal products—establishing navigation patterns and information architecture for disparate financial engineering teams.

My role: As Product Design Lead for financial engineering foundations, I partnered with engineering and product leadership to establish the information architecture and cross-product systems. 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: Product Design Lead (me), Product Partners, Tech Partners

Impact: Simplified financial data systems into service flows containing a capability catalogue, domain language, and stakeholder requirements, accelerating GTM timelines by 18%. The navigation framework and information architecture I established continues to serve as the foundation for Spotify's expanding commerce ecosystem, scaling across new markets and business models.

Summary: Faced with siloed tools and fragmented processes across 5 business verticals and 3 revenue streams, I designed the foundational information architecture and navigation systems to unify Financial Engineering's disparate subsystems. 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 set of shared domain definitions and a decisioning framework 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 conducting 52 cross-functional interviews, 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 red —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 ultimately accelerating timelines by 18%.