Senior Platform Product Manager

I build AI-powered
developer platforms

that create leverage at scale

At Microsoft, YouVersion, and Dell, I shipped platforms that hundreds of millions of people use every day. GenAI context engines, API infrastructure, search personalization. I’m looking for Senior PM roles where platform investments compound.

View my work ↓ Resume ↗

1B+

Users on platforms I’ve led

Years in platform PM

30%

Avg dev productivity gain

$9M+

Revenue from API platforms

Platform Coverage

Where I operate

Eight years of platform PM across six areas. All of it grounded in the same thing: making developers faster and making systems worth building on top of.

AI / ML Platform Products

GenAI context engines, LLM tooling, RAG systems, ML-powered search and personalization

GenAI context engine · M365 search personalization

Deep

Internal Developer Platforms

SDLC analytics, self-service tooling, CI/CD optimization, developer onboarding

Merge Reporter · Support Portal · CMS overhaul

Deep

API Design & Infrastructure

REST APIs, SDK tooling, versioning strategy, API monetization, storage platforms

PowerMax Storage API · M365 ecosystem integrations

Deep

Developer Experience & Tooling

DX audits, friction analysis, self-serve tooling, documentation strategy

API Doc Reviewer · developer journey research

Deep

Data Platforms

BigQuery, Snowflake, dbt, Amplitude — instrumentation and analytics infrastructure

SDLC analytics · recommendation engine pipelines

Strong

0-to-1 Platform Launches

Recommendation engines, flash sale infra, CMS platforms, AI context engines built from scratch

Lazada rec engine $8M · flash sale platform $12M

Deep

Selected Work

Case Studies

Real platform problems with structural root causes, documented tradeoffs, and outcomes tied to decisions I made.

MicrosoftAI SearchPersonalization

Building the Intelligence Layer: AI Search and Personalization Across M365

Fourteen M365 apps each had their own search stack with no shared personalization. Ranking models optimized for the crowd, not the individual. I led the team that built the centralized personalization service, getting six competing app teams and a skeptical data science org aligned and shipping in six months.

20%

Search accuracy lift

30%

Time-to-file reduction

100M+

Users impacted

Read full case study →

Key Decisions

Built one centralized service instead of per-app personalization, so we could use cross-app behavioral signals

Sequenced signals by availability: access recency and coworker graph first, topic modeling in phase two

Measured accuracy with task completion rate, not click-through, which is too easy to game

YouVersionGenAIDeveloper Platform

The Knowledge Layer: GenAI Context Engine for a 1B-Install Codebase

Engineering knowledge at YouVersion lived in undocumented code, Slack threads, and the heads of senior engineers. Debugging sessions stretched for hours because context was nowhere to find. I scoped and shipped an AI context engine that changed that, and earned daily adoption from an engineering team that started out skeptical.

30%

Debug time reduction

Daily

Usage in 6 weeks

1B+

App installs supported

Read full case study →

Key Decisions

Chose RAG over fine-tuning so engineers could see the source of every answer, which is what built trust

Chunked code by function boundaries, not character count, for better retrieval quality

Indexed only codebase and docs at launch, kept Slack out to control noise

Dell TechnologiesLazadaAPI Platform0-to-1

Platform Foundations: API Monetization and 0-to-1 Commerce Infrastructure

Before Microsoft and YouVersion, I built two platform products from scratch: a storage API platform at Dell that added $9M in new revenue, and a recommendation engine ($8M) plus flash sale platform ($12M) at Lazada. Both were zero-to-production at scale with real business stakes on the line.

$9M

API platform revenue

$20M

Rec engine + flash sale combined

$6M

Annual cost savings

Read full case study →

Key Decisions

Dell: Simplified the API surface to reduce client integration steps, which drove an 18% conversion improvement

Lazada: Picked collaborative filtering over rule-based recommendations for better cold-start behavior on new SKUs

Flash sale infra: Used queue-based inventory reservation to eliminate oversell at 12x normal traffic

Thought Leadership

Point of View

Hard-won perspective from building platforms where adoption was never guaranteed.

Developer Adoption Is a Product Problem, Not a Communication Problem

Most platform teams treat low adoption as a marketing problem. Better docs, more Slack announcements, lunch-and-learns. But when adoption stays flat, it’s almost never because developers didn’t hear about your platform.

“Every workaround a developer builds is a product spec for what your platform should be. Every script they write to avoid your API is a message about the friction you haven’t removed yet.”

From the article

AI Project

Pulse·AI

A working product I built and shipped. Conversational SDLC intelligence running on Cloudflare’s edge-native stack.

Cloudflare WorkersRAGD1 + VectorizeWorkers AI

Conversational SDLC Intelligence for Engineering Teams

Engineering managers spend an hour every week pulling together team health data from Jira, GitHub, and CI tools. Pulse·AI puts a plain-English interface on top of those signals. Ask your team data the way you’d ask a colleague. No dashboards, no manual report-pulling.

Cloudflare WorkersD1 SQLiteVectorizeKV Cachellama-3.1-8bRAG

Live Demo ↗ GitHub ↗

Product Decisions

Conversational instead of dashboards

Dashboards assume you know what you’re looking for. A manager walking into a tough 1:1 needs answers, not more charts to interpret.

No individual comparisons by design

Comparing engineers to each other was deliberately excluded. It incentivizes gaming the metrics and breaks psychological safety.

Show the inputs, not just the answer

Every response surfaces the signals behind it. A system you can inspect is one you can actually improve. Opaque scores are not.

Architecture Rationale

Cloudflare-on-Cloudflare

Zero cold starts. Engineering signals stay inside Cloudflare’s trust boundary. Nothing gets routed to third-party AI providers.

RAG via Vectorize for session continuity

Team signal state gets embedded as snapshots. Later queries pull similar historical context, so the tool gets more useful over time.

North Star Metric

Weekly active usage in the 48 hours before team syncs. If engineers open it before standups without being asked, the tool has formed a habit.

About

The through-line

Every role I’ve had follows the same pattern: find the fragmented, painful system and turn it into infrastructure other teams build on top of. At Lazada it was a recommendation engine and flash sale platform that teams across Southeast Asia scaled into $20M in revenue. At Dell it was a storage API that added $9M in new revenue while cutting infrastructure costs by $6M a year. At Microsoft it was a personalization layer serving the entire M365 suite. At YouVersion, an AI context engine that engineers now use every single day.

I think in systems, not features. I measure success in adoption rates, latency improvements, and engineering hours pulled back from toil. I work best in tight partnership with engineering teams, translating technical constraints into product calls and product needs into things engineers can actually build.

I hold an MS in Computer Science with a concentration in HCI and AI from Northeastern, and a Product Management and Design Thinking certificate from Stanford.

Email me ↗ LinkedIn ↗ Resume ↗

2025 – Now

Sr PM, Developer Platform & Internal Tools

YouVersion · 1B+ installs, 75M MAU, 157 languages

2022 – 2024

Technical PM, M365 Intelligence

Microsoft · AI search, personalization, ecosystem integrations

2021 – 2022

Technical PM, Storage Solutions

Dell Technologies · PowerMax Storage API · $9M revenue

2018 – 2021

PM, Platform & Growth

Lazada · Recommendation engine + flash sale platform · $20M combined revenue

Let’s build
something great.

Based in Houston, TX and open to relocate. Looking for Senior PM roles building the infrastructure engineering teams run on.

maranonrachelle@gmail.com ↗ LinkedIn ↗ Resume ↗

Building the Intelligence Layer: AI Search and Personalization Across M365

M365 is a platform where search is the connective tissue across every application. When a user searches in Teams, Word, or Outlook, they are not searching inside one app. They are querying a shared intelligence layer. When that layer works well, the whole product feels coherent. When it does not, the friction compounds everywhere.

Our ranking models were tuned on aggregate behavior. They were good at returning what most people searched for, most of the time. A lawyer’s search patterns look nothing like an engineer’s. A first-year analyst works with completely different files than a VP. We had no mechanism to use any of that. Each app maintained its own local signals, and none of them talked to each other.

The technical path was clear. The organizational path was not. Fourteen app teams each owned their search stack and had their own roadmap priorities. The data science team ran their own research agenda and were skeptical of product-driven direction. Infrastructure was cautious about adding latency to search response times. I had accountability without direct authority over any of them.

Each group needed a different conversation. For data science, I reframed it as a shared research question: how much lift do cross-app signals provide over in-app signals alone? For infrastructure, I made latency a first-class constraint from day one, committing to p99 under 50ms before we had a design. For app teams, I made integration self-serve so they could ship without waiting on us. The work nearly stopped at month four when two major teams deprioritized their integration work. I put together a cost-of-delay analysis for VP Engineering showing what each quarter of delay meant in accuracy lift. That got things moving again.

The Knowledge Layer: GenAI Context Engine for a 1B-Install Codebase

YouVersion runs the world’s most-used Bible app: 1B+ installs, 75M monthly active users, content across 157 languages. The engineering team maintaining that product is not large relative to the scale. Every engineer carries significant context, and the codebase reflects years of decisions made by people who have since moved on or simply forgotten the original reasoning.

Junior developers spent hours in Slack asking questions senior engineers had answered many times before. Senior engineers got pulled out of deep work to answer them. Debugging sessions that should have taken twenty minutes stretched into half-days because the relevant context was three Slack threads and a two-year-old comment in a pull request. The root cause was not bad documentation habits. It was the absence of infrastructure that made knowledge retrievable at the moment someone needed it.

The hardest part was not technical. Engineers are very good at ignoring tools they do not trust. An AI that confidently returns wrong answers about your codebase is worse than no AI at all. Every scoping decision I made was in service of one constraint: do not ship something that breaks trust faster than it builds it.

Choosing RAG over fine-tuning was the most important trust decision. When engineers could see the exact code snippet or documentation the engine pulled from, they could evaluate the answer rather than just accept it. By week three, people were using it not just to answer known questions but to explore parts of the codebase they had never worked in. That shift from retrieval to exploration told me the tool had crossed from useful to trusted.

Platform Foundations: API Monetization and 0-to-1 Commerce Infrastructure

I owned the PowerMax API roadmap, focused on scalability and data integrity for large infrastructure clients. Client onboarding required too many integration steps, which created friction that showed up directly in conversion rate. Working with engineering, I simplified the API surface, improved error response clarity, and built consistent versioning across endpoints. Conversion improved 18%, generating $9M in new revenue. Separately, I scoped a Kubernetes container storage solution that cut data migration time 25%, and led an architecture optimization that reduced maintenance overhead by $6M annually.

Southeast Asia’s largest e-commerce platform had no personalized recommendation layer. Product discovery was entirely browse-based. I led the build from zero: mapping behavioral data pipelines, choosing collaborative filtering over content-based approaches (better cold-start behavior for new product listings), and defining success around discovery rate rather than click-through, which is too easy to optimize away from actual value. The engine improved product discovery 15% and drove $8M in revenue growth across regional markets.

Flash sales required infrastructure that did not exist: traffic spike handling, inventory atomicity, and countdown-driven UX at scale. The key architectural decision was queue-based inventory reservation over optimistic locking, which eliminated oversell errors at peak load. I coordinated engineering, sales, and operations to build this from scratch. User participation grew 12%, the platform generated $12M in annual revenue, and the system handled 12x normal traffic on launch with no downtime.

Developer Adoption Is a Product Problem, Not a Communication Problem

There is a pattern I have seen at every company where I have built internal platforms. You build the thing, announce the thing, write the documentation, run the lunch-and-learn. Then you check adoption numbers three months later and they are embarrassingly flat.

The instinct is to treat this as a communication problem. Better docs. More Slack announcements. Get leadership to mandate usage. The team writes better docs, sends more messages, sometimes gets the mandate. The numbers move a little, or not at all.

Flat adoption almost always means you have a product problem. You are trying to solve it with communication.

Three Root Causes of Platform Non-Adoption

The friction cost problem. The platform is too hard to integrate relative to the value it delivers. Developers will tell you. But the instinct is to write a better getting-started guide rather than ask: why does this take three documents to explain? What would it take to get a developer to their first successful call in under thirty minutes with no help at all?

The trust deficit problem. Developers do not believe the platform will be maintained, reliable, or return correct results. Trust deficits are silent. Developers will not tell you they do not trust your platform. They will just keep using their scripts.

The relevance gap problem. The platform solves a problem developers do not actually have, or solves it at the wrong moment in their workflow. Timing in developer workflows is not a detail. It is the product.

A Diagnostic Framework

Can a developer get value in under thirty minutes, without asking anyone for help? If no, you have a friction cost problem. Not a communication problem.

If you asked a developer why they are not using your platform, would they give you a usage reason or a trust reason? Those require completely different interventions.

Are you solving a problem developers have, at the moment they have it? The best platforms appear at exactly the right point in the workflow and disappear when they are not needed.

The Hardest Part

Developers are the most capable users in the world at working around things they do not like. They will write scripts. Fork your tool. Build their own version in a private channel without ever telling you, because solving the problem themselves is faster than teaching you how to fix it.

Every workaround a developer builds is a product spec for what your platform should be. Every script they write to avoid your API is a message about friction you have not removed yet. The teams that read that signal as a product problem and fix it are the ones whose platforms get used. The teams that read it as a communication problem keep writing announcements.

I build AI-powereddeveloper platforms

Where I operate

Case Studies

Building the Intelligence Layer: AI Search and Personalization Across M365

The Knowledge Layer: GenAI Context Engine for a 1B-Install Codebase

Platform Foundations: API Monetization and 0-to-1 Commerce Infrastructure

Point of View

Developer Adoption Is a Product Problem, Not a Communication Problem

Pulse·AI

Conversational SDLC Intelligence for Engineering Teams

The through-line

Let’s buildsomething great.

Building the Intelligence Layer: AI Search and Personalization Across M365

The Knowledge Layer: GenAI Context Engine for a 1B-Install Codebase

Platform Foundations: API Monetization and 0-to-1 Commerce Infrastructure

Developer Adoption Is a Product Problem, Not a Communication Problem

Three Root Causes of Platform Non-Adoption

A Diagnostic Framework

The Hardest Part

I build AI-powered
developer platforms

Let’s build
something great.