Product management at Microsoft, mostly on surfaces where millions of people arrive with something they need to finish. My work sits on both sides of the roadmap: the craft that keeps a mature product excellent, and the AI direction deciding what it becomes.
Case study — current
A mature product with an enormous, enormously varied audience, and a genuine question about what AI should become inside it. I drive both tracks: the fundamentals people feel every day, and the Copilot direction.
Performance, reliability, editing craft, accessibility. Compounding work with no launch moment, and the single largest determinant of whether people trust the product. Protecting this budget against whatever is newer and louder is part of the job, not an obstacle to it.
Where AI goes inside the product: what it drafts, rewrites, and restructures, how it grounds itself in the user's own material, and where it should stay out of the way entirely. Scoped to what the model does reliably today rather than what demos well.
A presentation is a personal artifact. It carries someone's argument, in their voice, to an audience that knows them. Generic AI output fails that bar instantly — it produces something the user has to rewrite from scratch, which is worse than a blank slide, because it also cost them their trust.
So the product question was never "can the model make slides." It was: what does the model need to know about this person's material, and how do we show our work well enough that they can accept, edit, or reject an idea in seconds?
Draft from the documents, notes, and templates the user already has, so the output arrives in their structure and their language instead of a plausible average of the internet.
What we ask the model, how much context we give it, and the shape we require back are product decisions with visible consequences — not implementation details to hand off.
Evaluation sets built from realistic user material, with an explicit definition of a good result, so quality debates resolve on evidence rather than on whoever demoed last.
Uncertainty made visible, easy rejection, nothing destructive without a way back. The feature has to stay usable on the model's worst day, because that's the day that decides whether someone opens it again.
Every new AI surface is keyboard- and screen-reader-complete when it ships. Retrofitting accessibility onto a generative interface is significantly harder than designing it in.
The through-line
A great AI feature and a great product for everyone are the same job.
Most of my work sits in that gap — scoping what a feature promises, defining the bar it has to clear, and deciding deliberately how much of a quarter goes to what's next versus what's already load-bearing.
Also shipped
Different products, the same underlying problem: make a powerful system feel obvious to someone who did not read the manual.
Microsoft · Automation
Workflow automation at organizational scale. The place I learned what agentic behaviour actually costs: every automation that acts on someone's behalf needs a story for permissions, auditability, and the moment it does the wrong thing quietly.
Automation · GovernanceMicrosoft · Low-code
Creation flows that let people who don't write code ship working software. Direct preparation for AI product work — both are about collapsing the distance between intent and a result, without pretending the complexity underneath went away.
Low-code · CreationMicrosoft · Media
Playback and media experience across Windows and Xbox. Consumer scale, where polish is not decoration: a half-second of latency or one confusing control shows up immediately in how people behave.
Consumer · PlaybackMicrosoft · Media
Music listening built around library, discovery, and flow — an early lesson in recommendation systems, and in how quickly people abandon a product that guesses wrong about what they want.
Consumer · DiscoveryWhat I bring
The parts of this job I'm actually good at.
Deciding what a product will and won't promise — including what a model can actually do reliably today — and keeping a large group of capable people pointed at it when priorities compete.
Evaluation sets, explicit success criteria, and the willingness to hold the line when the pressure is to ship something that merely demos well.
Making the fundamentals-versus-new-bets trade-off explicit and defensible, so a mature product keeps getting better while it also moves.
I ship screen-reader-first apps independently. It makes me faster and more specific about inclusive design in everything else I spec.
Centrale-trained. I can hold a real conversation about retrieval, latency, and cost trade-offs instead of relaying them between teams.
Brazilian, French-educated, building in the U.S., in three languages. Useful on distributed teams and on products that ship globally.
Background