## Privy PMM Task 01062026
Prepared by Maryam (maz) Mazraei ([Website](https://mmaz.co/), [X](https://x.com/mmazco), [LinkedIn](https://www.linkedin.com/in/maryam-mazraei/), [Github](https://github.com/mmazco))
Prepared for Debbie Soon, Head of Marketing, Privy
Privy Product Marketing Take-Home Task ([Full doc](https://docs.google.com/document/d/1vwkPOJ6BvXgrgQ4-PZn0NaQAcpa2UVHgBZ93PAUfD-I/edit?usp=sharing))

## Task 1 Launch narrative (short)
In ~1–2 pages (or equivalent slides), outline:
● The core message of this launch
● The problem we solved before vs now
● The primary audience this launch is for (and who it’s not for)
● How this reinforces Privy’s broader positioning (e.g. wallets as programmable global accounts)

## Spending is now a native wallet capability
With the emergence of native card issuance for embedded wallets, 'Privy Cards' has the capability to drastically collapse the integration overhead for developers, meaning spending is now a native wallet capability, not a separate product.

### The evolution of holding -> moving (+ spending)
Today, if a developer wants users to hold stablecoins and spend them via card, they face a fragmented ecosystem: embedded wallet provider, card issuer, BIN sponsor, crypto-to-fiat conversion, KYC/AML, banking partner, on/off-ramp, liquidity provider. Roughly something like five to eight separate vendors are required to consider for such a mammoth engineering task which makes it costly and time consuming.

Resulting in a fractured user experience where wallet lives in one place and the card lives in another. Developers have to manage complex settlement reconciliation across systems that don't speak to each other. Users have to go through multiple identity checks and other annoying UX loops. Realistically, the time it would take for this approach to even execute a payment stands no chance in the real world!

By collapsing this user flow and integration headache, the potential of this is for the wallet to become a programmable account abstracting issuing, conversion and compliance.

*Note on the holding -> moving use case:* Privy wallets have always let users hold value and move it. 'Privy Cards' unlocks an additional user behavior and infrastructure capability to move 'value' through the card networks that already power additional forms of spending such as real world payments etc.

### Core audiences
Developers building products where users hold digital value and need to spend it in the real world including:

* Fintechs building stablecoin products: neobanks, savings apps, payroll platforms that want to give users real-world spending without rebuilding card infrastructure and on existing platforms.
* Consumer crypto apps and apps for real-world payments: trading platforms, rewards apps, gaming products where users hold value in-app but can't currently spend it outside the ecosystem.
* Enterprises exploring onchain money movement: corporate treasury, contractor payouts, expense management with programmable money on familiar rails.

**This is not a direct to consumer product or feature release.** Consumers and users of those listed above are downstream beneficiaries of this release. This is to reinforce that Privy remains the infra layer thus 'Privy Cards' is just an addition improving the existing infra for developers to unlock more mainstream payment user behavior (globally). This is to not to compete with [Stripe Issuing](https://stripe.com/en-sg/issuing) or card networks if anything use the full Stripe stack including Bridge orchestration and Privy as the wallet layer to work with existing rails.

#### How the native card issuances collapses the stack
My given assumption and example of how Privy's native integration can collapse the overall development cycle and UX flow (hypothetical).

*User signs up*
→ Privy (KYC + wallet + card = one integration)

*User deposits USDC* (when native issuance is implemented as right now this is not possible in existing Privy infrastructure capability)
→ Privy handles on-ramp

*User swipes card at Starbucks*
→ Privy handles everything

### How this reinforces Privy's positioning
Privy's thesis has always been that **wallets are programmable global accounts**, reinforcing that identity, ownership and programmability can exist in one primitive.

Privy frames embedded wallets around two core user needs: **Holding Value** (buy, hold, sell, trade) and **Moving Assets** (P2P, cross-border, payroll, disbursements). 'Privy Cards' expands what "moving assets" can mean where value can now flow via existing global networks like Visa/Mastercard to power a mass market without changing user behavior.

This matters differently for each audience, my assumption is that it can enable the following for these use cases:

* Fintechs can let users spend stablecoin savings or receive payroll and immediately access it via card = no offramp friction.
* Consumer crypto apps can let users spend trading profits/liquidity, gaming rewards, or creator earnings anywhere cards are accepted.
* Enterprises can issue expense cards funded directly from onchain treasury, or let contractors access payouts instantly.

*The through-line:* Privy wallets already let users hold and move value. Privy Cards unlocks a new distribution of money (value) flow, one that connects onchain balances to everywhere Visa and Mastercard are accepted globally.

## Task 2 Launch blog post (800–1,000 words)
Write the primary launch blog post announcing Privy Cards. Guidance:
● Assume this is published on Privy’s blog on launch day
● Write for developers and product-minded readers
● Focus on why this matters, not deep implementation details
● Credible, confident, and grounded in line with Privy brand voice.
● You may reference Visa/Mastercard or partners at a high level, but this should clearly be a Privy-led story

## Introducing Privy Cards: spending is now a native wallet capability
As stablecoins become the foundation for a new generation of financial products, wallets have become the core account system for holding and moving value. At Privy, we help developers build experiences with one simple API to spin up embedded wallets, manage keys securely, and integrate any onchain system.

Users can hold crypto assets and stablecoins and move them across applications. But what they can't easily do is spend those assets (not without leaving the app).

Today, we're excited to announce Privy Cards: native card issuance for embedded wallets. Developers can now issue Visa and Mastercard debit cards directly tied to Privy wallet balances. This means any developer building on Privy can now:

- Configure card behavior through Privy: set up regions, limits, supported assets, controls
- Let users spend stablecoins or supported assets anywhere cards are accepted
- Abstract issuing partnerships, conversion, and compliance into a single integration

### Fragmented infrastructure for a simple outcome
Here's what developers face today when they want users to spend their onchain balances via card:

You start with your embedded wallet provider. Then you need a card issuer, a BIN sponsor, crypto-to-fiat conversion, KYC/AML, liquidity providers and so on. That's five to eight separate vendors, each with their own API, their own compliance requirements and their own contracts.

The result is predictable. The wallet lives in one place, the card lives in another. Users go through identity verification multiple times. Developers manage settlement reconciliation across systems that weren't built to talk to each other. What should take days takes months.

We've heard this from teams building stablecoin savings products who want users to spend their yield directly. From trading platforms where users hold profits they can't easily access. From enterprises running contractor payouts who want recipients to have instant access to funds.

The ask is always the same: *why can't spending just be part of the wallet?*

### Cards as a wallet capability
With Privy Cards, developers can now issue Visa and Mastercard debit cards directly tied to Privy wallet balances in one integration. Meaning no additional vendors, all powered through Privy's wallet infrastructure and Stripe's payment stack including Bridge orchestration.

This isn't a separate product bolted onto your existing Privy implementation. It's a capability of the wallet itself. Users hold value, move value, and now spend value, all from the same account.

Here's what this means in practice:

**For developers:** Configure card issuance through Privy. Privy abstracts the issuing partnerships, conversion, and compliance complexity. Letting you focus on your product.

**For users:** One wallet, one balance, one account. Removal of fragmented apps and pre-funding a card account. Use your wallet as you would your debit card to make payments in the real world.

### From wallet to world in one integration
Privy Cards is built for developers whose users hold digital value and need to access it in the physical world.

**Fintechs building stablecoin products.** If you're building a neobank, savings app, or payroll platform on stablecoin rails, your users eventually need to spend. Privy Cards means they can without you rebuilding card infrastructure or managing additional vendor relationships. A contractor receives payment in USDC and can spend it at the grocery store that afternoon!

**Consumer crypto apps.** Trading platforms, rewards programs, gaming products, anywhere users accumulate value they currently can't access outside your ecosystem. With Privy Cards, trading profits, gaming rewards, and creator earnings become spendable anywhere cards are accepted.

**Enterprises exploring onchain money movement.** Corporate treasury, expense management, contractor payouts. If you're moving money onchain for the speed and programmability, Privy Cards lets that value flow back out through familiar rails.

Privy Cards is part of our infrastructure development roadmap for developers, to connect them with the global market. Privy remains the core wallet infrastructure layer, working with existing rails, including the broader Stripe ecosystem and major global network providers such as Visa and Mastercard, to give developers a unified way to build financial products.

### Wallets as programmable global accounts

We've always believed wallets are more than just holding or moving crypto. They're **programmable global accounts where identity, ownership, and programmability sit one primitive.**

Privy has helped developers build for two core user needs: **Holding Value** (buy, hold, sell, trade) and **Moving Assets** (P2P, cross-border, payroll, disbursements). Privy Cards expands what moving assets can mean. Value can now flow through the card networks that already power global payments meeting users, merchants, businesses where they already are, with behavior they already understand.

Privy wallets already let users hold and move value. Privy Cards unlocks a new distribution of money flow, one that connects onchain balances to everywhere Visa and Mastercard are accepted. Wallets aren't just for crypto anymore. They're how the next generation of financial products will be built.

### Get started
Privy Cards is available now for early users (landing page link). Reach out to our team if you'd like to discuss your use case.

## Task 3: Launch plan (high-level)
In bullets or a simple table, outline:
● Launch objectives (what success looks like)
● Key KPIs you would track to evaluate success (directional is fine)
● Primary audiences and channels
● Key launch assets (e.g. blog, docs update, social, email, sales enablement)
● Day 1 vs Week 1 priorities
● One thing you would intentionally not include in the initial launch, and why

## Launch objectives

- Primary goal: drive developer awareness and early adoption of Privy Cards
- Other goals: reinforce Privy's positioning as the wallet infrastructure layer
- Sales goals: generate qualified inbound from fintechs, existing consumer crypto apps, and enterprises exploring card issuance

*Note on release approach:* for a large release like this, I would personally approach it via a early user campaign/release (similar to Privy's [flexible custody](https://privy.io/blog/introducing-flexible-custody-better-custody-models-for-global-businesses) release announcement). This approach helps build up momentum, ensure Privy engineers are not too stretched and early users are satisfied.

### Key KPIs

| Metric | What we trying to measure for success
| -------- | -------- |
|Blog post page views + CTA conversion|Top of funnel|
|Relevant docs page views|Developer/implementation intent (helps measure to support GTM and CX in-house)|
|Cards API request/any sandbox activations?|Activation/implementation signal (conversion)|
|Demo requests mentioning Privy Cards|Separate sales flow perhaps or unique utm links for tracking demo requests|
|Social engagement (X thread, LinkedIn)|Supports top of funnel|

### Primary audiences and channels
*Note:* this is high-level and pretty generic, if I were to do a early user campaign then the audience will be more focused and gradually expand based on full feature release with product and eng confidence sign off.

| Audience | Channel |
| -------- | -------- |
|Crypto-native developers/builders|X, docs, newsletter, community channels|
|Fintech and enterprise product leads|LinkedIn, newsletter|
|Existing Privy customers|X, newsletter, tg, |
|Developer community|X, docs, tg, discord, dev community channels

### Key launch assets
*Note:* example of an app implementation and gtm campaign I led at Agora for World Foundation Mini App called World Vote (https://world.org/worldvote) which required cross team collaboration with Agora, Tools for Humanity and World Foundation. This pre-launch campaign I designed got up to 10k sign-ups in the World app.

**High level assets include:**
- Dedicated landing page and release blog post
- Cross channel and cross team collaboration for partner announcement on their dedicated channels (maybe support with their comms language)
- Product feature demo and product demo animation to show full feature potential for more narrative purposes
- Short video interview with head of eng or product lead on feature release
- Visuals for social assets and newsletter
- Newsletter copy and case study copy
- BD/sales/GTM one-pager and docs

### Day 1 vs week 1 priorities

| Day 1 | Week 1 |
| -------- | -------- |
|Blog live |Follow-up content (use case deep-dives)|
|X thread + LinkedIn|Conversation/lead follow-ups|
|Email newsletter |Inbound/outbound sales follow-up|
|Docs updated|Collect feedback/iterate docs if needed|
|Channel distribution|Continue pushing messaging across channels|
|Internal alignment (product,gtm,CX)|Clear strategy and plan on closing leads or follow ups|

### One thing intentionally NOT included
Pricing: matches Privy's current approach as I don't see information on this on any of the posts. Assuming usage-based pricing for developer use case pertaining API business model remains the same but not sure how this is evaluated for potential customers like enterprise assuming requires a typical SaaS model and has enterprise tiers. Plus based on the complexity of this particular release, there's considerations such as volume, region, and use case.

## Task 4 Short-form translation
Write the following:
● X thread (5–7 tweets) for a crypto-native / builder audience
● LinkedIn post (1–2 short paragraphs) for a fintech / enterprise audience

*Note:* I use Typefully for X threads for team visibility and drafting.

## X thread
1/ From wallet to world in one integration

Today we're launching Privy Cards: native card issuance for embedded wallets

Your users can now spend their onchain balances anywhere Visa and Mastercard are accepted 🧵

[image banner]

2/ The problem: if you want users to spend stablecoins via card today, you're stitching together 5-8 vendors

From choosing a wallet provider, card issuer to KYC and banking

Current approach results in months of work, fragmented UX and multiple UX loops

3/ Privy Cards collapses this

With one integration, cards as you know it get native wallet capability

→ Cards tied to wallet balances
→ Configure regions, limits, assets, controls
→ Privy handles issuing, conversion, compliance

4/ What this unlocks:

→ Fintechs: users spend stablecoin savings or payroll instantly
→ Consumer crypto apps: (trading apps) profits become spendable at retail. (gaming/creator apps) rewards usable IRL
→ Enterprises: expense cards funded from onchain treasury

5/ Wallets are programmable global accounts

Privy Cards expands what "moving assets" means

Value now flows through the card networks that power global markets

Hold → Move → Spend = One SDK

6/ Privy Cards is live for early users
Docs: [link]
Blog: [link]

### LinkedIn post

**From wallet to world in one integration.**

Today we're announcing Privy Cards: native card issuance for embedded wallets.

If you're building a stablecoin product: a neobank, payroll platform, savings app, or any application where users hold digital value. You've likely faced this problem: your users can hold assets, they can move them, but they can't easily spend them without leaving your app or stitching together a patchwork of additional infrastructure.

Until now, enabling card-based spending meant coordinating 5-8 separate vendors, each with their own API, compliance requirements, and contracts. What should take days takes months.

Privy Cards changes this. Developers building on Privy can now issue Visa and Mastercard debit cards directly tied to wallet balances in one integration with no additional vendors. Configure regions, limits, supported assets, and controls through Privy. We handle issuing partnerships, conversion, and compliance.

For fintechs, consumer apps, and enterprises exploring onchain money movement. This is spending as a native wallet capability, not a separate product.

Privy Cards extends our thesis that wallets are programmable global accounts. Users already hold and move value through Privy wallets. Now value can flow through the card networks opening access to the global market to our customers whilst keeping user behavior the same.

In partnership with Stripe, Visa and Mastercard, early users can access Privy Cards today.

More here: [blog link]
Visual: video demo/full flow animation

*Note:* supposedly posts between 1,300 and 1,400 characters generate the highest engagement rates on Linkedin according to [supergrow.ai](https://www.supergrow.ai/blog/how-long-should-a-linkedin-post-be)