Victoria Reina

PlayMPE's billing and distribution rules had historically been managed manually, meaning pricing logic had become a highly customized affair. Bringing checkout & payment into Caster meant standardizing that logic and streamlining billing operations for our services team without breaking existing workflows.

I drove the project from requirements through post-launch — gathering acceptance criteria, coordinating phased development, documenting known limitations, preparing internal FAQs and training materials, and managing staged rollout communication. I also worked directly with developers to define where scope would grow and where analytics events were needed before future decisions could be made.

Business logic complexity is directly correlated to product and development complexity. Also, productizing manual processes is as much about surfacing what nobody has written down as it is about writing requirements. The most valuable work happened before a line of code was written — understanding the edge cases that everyone assumed someone else had already handled.

PlayMPE's reporting experience needed a full rethink — but the scope was too large to ship at once. The challenge was breaking meaningful work into phases that delivered value incrementally while maintaining a coherent vision across multiple launches.

I scoped and sequenced the Reporting initiative across Phase 1, Phase 2, Phase 3, and the Full Report launch. This included creating FigJam walkthroughs, maintaining a central training session as the reference point for each phase, coordinating marketing and client-facing communication assets, and iterating based on post-launch feedback — including handling temporary workarounds for missing columns while fixes were in progress.

Multi-phase delivery only works when each phase has a clear why. Users and internal teams lose confidence if a launch feels incomplete without context. Framing each release as part of a larger story — and giving people a consistent place to go for updates — made the iteration process feel intentional rather than patchy.

Music releases were reaching their initial recipients, but stopping there. There was an opportunity to let Player users share releases with one another, extending reach for Caster senders without requiring them to do anything differently.

I launched Share a Release across both Caster and Player, coordinating functionality that spanned two separate product surfaces. This required understanding value from both the sender and recipient perspective, preparing demo recordings and release notes for each side, setting expectations around known launch hiccups, and coordinating post-launch feedback across both pods.

Cross-product features expose gaps in how teams think about their product's edges. The hardest part wasn't the feature itself — it was making sure both pods understood why the other side's behavior mattered to their users. The framing work was as important as the coordination work.

Radio tracking data from MTR lived in a separate product, disconnected from where Caster users were already analyzing their release performance. Making that data accessible within Caster reporting required coordinating across two product teams with different owners, different user contexts, and different rollout timelines.

I coordinated the integration of MTR airplay data directly into Caster's release reporting view. This included defining the different CTA states within Caster; one for users with purchased tracking and the other for users without. I also communicated a feature-gated rollout plan to internal teams while supporting cross-functional understanding across both pods.

Integrations between products with separate owners require a clear owner for the seam. Someone has to hold the user experience across the handoff point — what a user sees, what they can do, and what happens when they don't have access yet. That's a PM responsibility, not a design one.