Di Larmore | Product Leader

Most PM portfolios are lists of shipped features. This one is curated evidence of how I think.

This portfolio is designed as a collection, not a list. That's intentional.

Product management is fundamentally about curation—choosing what to build, what to kill, and what to ignore. A Pinterest-style layout signals that philosophy before you read a word.

And yes—if recent AI interest in Pinterest tells us anything, it's that curation is about to matter a lot more in an AI-saturated world.

Feature lists. Jira velocity charts. "Shipped 47 features" metrics.

Those measure activity, not impact. Instead, you'll find the problems I diagnosed, the trade-offs I navigated, and the outcomes I drove.

"The best PMs aren't the ones with the most features shipped—they're the ones who consistently find the right problem, align the right people, and make the right call with incomplete information."

A Fortune 500 entertainment and hospitality company asked me to lead legacy enterprise product EOL & replacement for Finance—support agreements were expiring in 6-9 months.

I asked for a week to evaluate before executing. That week changed everything.

I found data systems transferring information only through SFTP flat files, multiple applications with overlapping features, no unified data layer. The presenting problem was "replace declining products." The actual problem was architectural fragmentation.

I went back to my executive director with a proposal: instead of point-to-point legacy replacement, build a platform that could unify workflow, compliance, and data across these systems.

The company had recently experienced a major data breach. On my first Friday, I met with the VP of Architecture—a 19-year veteran who had blocked every cloud integration attempt.

Direct confrontation would have failed. Instead, I designed a hypothesis to test his risk tolerance without exposing the core.

The Pivot: Rather than argue about cloud security philosophy, I proposed building AP's digitized invoice workflow with Okta integration enabling O365 mailbox approvals.

The Outcome: He gave us the chance. That single decision—a low-risk architectural "Trojan Horse"—unlocked O365 integration enterprise-wide and cleared the path for the broader transformation.

7 core systems unified: Azure, Salesforce, Oracle ERP, Workday, O365, Okta, ServiceNow—integrated for the first time in company history.

Q1 2020. Executive mandate: "Add BNPL to capture Gen Z spend." Business case projected $22M-$80M.

I recognized a pattern. This wasn't an isolated request—it was the first of several incoming commerce integrations. The architecture we chose for this first integration would set the velocity for the entire roadmap.

The executive mandate was "Launch Klarna." The strategic reality was that Klarna was just the first of ten incoming payment vectors (Instacart, Google Shopping, AfterPay, and more).

I rejected a direct API integration, which would have been faster for Klarna but threw away work. Instead, I chose VCN (Virtual Card Number) integration—an abstraction layer that treats every 3rd-party provider as a standard credit card transaction at the gateway level.

The reframe: Build payment infrastructure that lets us meet customers wherever they want to buy—starting with BNPL, extending to any channel or partner.

What this unlocked: 3 BNPL providers + 4 marketplace channels on shared infrastructure. The brief was "add a payment option." The outcome was omnichannel commerce.

A large hospitality enterprise processed $485M annually in entertainment ticket sales across 18 property teams. Third-party sales (distributed through external vendors) represented the higher-margin channel but carried regulatory complexity: multi-state licensing requirements mandated pricing approval chains and contract term validation for every resale agreement.

No platform existed. Property teams ran sales through spreadsheets and email.

Why "Lift and Shift" Would Have Failed: Spreadsheets had no referential integrity. A contract could reference pricing that didn't exist. The 65% rework rate wasn't a process failure—it was a data model failure.

Because of multi-state licensing requirements, we built a Compliance-as-Code layer: the system wouldn't physically allow a ticket to be listed unless the pricing model matched the approved contract terms.

• Entity relationships enforced: Contract terms, pricing rules, and inventory had to mathematically match
• Validation at entry: Errors caught before submission, not after tickets went live
• Audit trail by design: Every pricing decision logged automatically

Property teams resisted headquarters control. But they hated audits more.

I pitched the platform as Audit Immunity: automated compliance logging that protected teams from regulatory exposure. The platform wasn't a control tool imposed from above—it was a protection tool they wanted.

Moving corporate travel from "Expense Capture" to "Point-of-Sale Control."

Integration ≠ Adoption.

We lose ~$25K/year per frequent traveler because the current system forces a choice: Loyalty status vs. Company policy.

If they don't book in Ramp, we lose the interchange revenue and the data.

Dynamic Policy Control. Shift enforcement from "Post-Trip Audit" to "Real-Time Guidance."

• 4-Act strategic narrative (Problem → Strategy → Execution → Fit)
• Competitive landscape analysis (Navan, TravelPerk, Concur)
• Interactive prototypes: Group Travel Dashboard, Soft Block UI, AI Concierge
• 90-day execution plan with success metrics
• Role fit alignment to JD requirements

This is not a case study. This is a strategic roadmap I'd execute in the first 90 days.

Thesis: WhatsApp owns the negotiation. AI agents turn unstructured intent into structured transactions.

WhatsApp has 500M+ users in India. WhatsApp Pay has captured less than 1% of UPI transactions.

The thesis was sound: payments embedded in conversation should outcompete standalone apps. But payments alone weren't enough.

Instagram is the Engine of Aspiration. The moat is taste. It answers: "Who do I want to be?"

WhatsApp is the Engine of Resolution. The moat is context. It answers: "How do I get this done?"

Commerce in emerging markets is messy: "Is this in stock?" "Can you deliver by 5?" "Does it come in red?" This unstructured negotiation happens before any payment. WhatsApp captures it. Payment apps don't.

Business messaging requires humans. That doesn't scale. AI agents solve the cold-start problem.

An AI agent reads the unstructured negotiation and turns it into a structured transaction—payment captured, delivery scheduled. A standalone payment app can process the payment. It can't understand why the customer bought.

Thesis: IG owns the Taste Graph. The opportunity is activating it—not building a mall.

Instagram is where purchase intent forms—more than any other platform.

And yet: users screenshot outfits, reverse-image search on Google, hunt products on Amazon. IG generates the demand. Someone else captures the sale.

IG is the Engine of Aspiration. The moat is taste. Passive scrolling creates desire based on identity. It answers: "Who do I want to be?"

The Shop tab failed because it asked users to change behavior. Embedded commerce succeeds because it adds capability to behavior that already exists.

The Taste Graph is the moat. Amazon knows what you bought. IG knows what you like. No direct commerce competitor combines ten years of social engagement data with a visual-first feed at IG's scale.

Four laws that guide how I work.

01

Diagnosis Before Execution

Most teams rush to build. I rush to understand. The problem you're handed is rarely the problem you should solve.

Law: "The ask is rarely the opportunity."

02

Outcome Ownership

Shipping is easy. Changing behavior is hard. I own the outcome, not just the output.

Law: "Output is vanity. Outcome is sanity."

03

Radical Alignment

I treat stakeholders as co-authors, not approvers. Alignment isn't a phase—it's continuous.

Law: "No surprises."

04

Decision Velocity

Perfect information never comes. I look for 70% confidence, then commit and iterate.

Law: "Strong opinions, loosely held."

Four laws that guide how I work.

01

Diagnosis Before Execution

Most teams rush to build. I rush to understand. The problem you're handed is rarely the problem you should solve.

Law: "The ask is rarely the opportunity."

02

Outcome Ownership

Shipping is easy. Changing behavior is hard. I own the outcome, not just the output.

Law: "Output is vanity. Outcome is sanity."

03

Radical Alignment

I treat stakeholders as co-authors, not approvers. Alignment isn't a phase—it's continuous.

Law: "No surprises."

04

Decision Velocity

Perfect information never comes. I look for 70% confidence, then commit and iterate.

Law: "Strong opinions, loosely held."

Four laws that guide how I work.

01

Diagnosis Before Execution

Most teams rush to build. I rush to understand. The problem you're handed is rarely the problem you should solve.

Law: "The ask is rarely the opportunity."

02

Outcome Ownership

Shipping is easy. Changing behavior is hard. I own the outcome, not just the output.

Law: "Output is vanity. Outcome is sanity."

03

Radical Alignment

I treat stakeholders as co-authors, not approvers. Alignment isn't a phase—it's continuous.

Law: "No surprises."

04

Decision Velocity

Perfect information never comes. I look for 70% confidence, then commit and iterate.

Law: "Strong opinions, loosely held."

Four laws that guide how I work.

01

Diagnosis Before Execution

Most teams rush to build. I rush to understand. The problem you're handed is rarely the problem you should solve.

Law: "The ask is rarely the opportunity."

02

Outcome Ownership

Shipping is easy. Changing behavior is hard. I own the outcome, not just the output.

Law: "Output is vanity. Outcome is sanity."

03

Radical Alignment

I treat stakeholders as co-authors, not approvers. Alignment isn't a phase—it's continuous.

Law: "No surprises."

04

Decision Velocity

Perfect information never comes. I look for 70% confidence, then commit and iterate.

Law: "Strong opinions, loosely held."