Product Management Portfolio
I'm Anuraag Burman, a product leader in Singapore. For ten years I've worked on the moments where money changes hands - subscriptions, fintech, loyalty, incentives - first as a founder, now at Delivery Hero / Foodpanda across APAC and Europe.
I also build, hands-on. RAG pipelines in production, agentic workflows that act on their own, open-source infrastructure that other people's AI now runs on. I started my career as an architect and never lost the habit of making things - because building the thing yourself changes how you decide what to build.
Built and led a 5-person product team, reporting to the CEO. 30% app adoption growth, 60% internal tool adoption.
Mortgage + insurance comparison. 35% lift in digital applications, 20% drop-off cut.
E-commerce for construction materials. $12M revenue, 30% quarterly growth.
Health app. Medical records, medication reminders, doctor discovery.
A series of small decisions, each pulling me deeper into the AI ecosystem and expanding what I could build on my own.
Made AI part of daily product work - Claude, ChatGPT, and custom Gemini Gems embedded into specs, analysis, and stakeholder work. Then shipped the first working product with Lovable and Replit, and formed a clear thesis on which tools are for exploration and which are for production.
Built thewaypoint.ai on a component architecture with 21st.dev. The mental model shifted from designing screens to composing systems of reusable parts - the same shift that separates one-off builds from products.
Shipped the Subscriptions Knowledge Base on GCP Vertex AI with Auth0 SSO — a live RAG system serving a real support organisation. Retrieval pipelines, serverless hosting, and multiple models orchestrated in one product.
Shipped PortfolioIQ end-to-end — Supabase, Redis, live market data, deployed on Vercel — then went a layer deeper: an open-source MCP server connecting Claude to Calendar, Gmail, Tasks, and Reminders. TypeScript, Swift, OAuth2, security-first, MIT-licensed.
First agentic pipeline in production: Gemini Flash classifies incoming support tickets and routing decisions execute in under 3 seconds, with human review reserved for low-confidence cases. AI moved from answering questions to doing the work.
Each project started with a question that mattered to me as a product leader. Tap any card to explore.
AI dictation that cleans up your speech as you talk, fully on your own Mac. The Wispr Flow experience without the subscription or cloud.
Dictation makes you choose: built in tools type your ums and uhs verbatim, while Wispr Flow cleans it up but costs fifteen dollars a month and uploads your voice. I wanted both, for free.
What is a product like Wispr Flow actually charging you for once the models it runs on are small enough to sit on the laptop in front of you? People clearly love writing with their voice. I wanted to know whether that still needs the cloud, or whether the whole experience could quietly move onto a device I already own. LocalFlow is me answering that by building it.
I assumed this would be a weekend toy. Download a speech model, bind a hotkey, done. Making it feel instant turned it into a real product. The first surprise was cost. Wispr Flow charges fifteen dollars a month for this in the cloud. I got the same experience on my own laptop for zero, which reset how I think about build versus buy. The harder lesson was product, not tech. The models worked in an afternoon. What decided whether anyone kept using it was the ten seconds of permissions and setup before a model ran. So I stopped tuning the AI and fixed the friction around it. Chasing the real bottleneck instead of the obvious one is what I keep.
The only real cost is the one time model download, about 3 GB, plus the electricity your Mac already draws. Everything after runs on hardware you own, so every word you dictate costs nothing. The same experience Wispr Flow rents to you, you get to own.
Why build this locally instead of just calling a cloud API?
I ranked it the way I would any product call: privacy first, then cost, then speed. Voice never leaving the device kills the biggest objection to using dictation at work. Zero cost beats fifteen dollars a month forever. And skipping the server round trip makes it feel instant. The whole bet was that local models on Apple silicon are now good enough that the user gives up almost nothing and gets all three.
Why Parakeet for the transcription instead of Wispr?
On Apple, Parakeet turns speech into text in about half a second, where Wispr large v3 takes over a second. In dictation, that gap is the entire feel of the product, so it was an easy call. Wispr is stronger across languages, so I left the model swappable in config, but for an English first daily driver I optimized for the thing the user actually feels, which is speed.
How does it type into any app, from Slack to VS Code?
It borrows the clipboard for a moment. Save whatever you had copied, drop in the clean text, fire a paste into the focused app, then put your old clipboard back a beat later. It is the one method that works reliably in every app and text box, and the save and restore step means the user never loses what they had sitting on their clipboard. Small detail, but that is the kind of thing that decides whether people trust the tool.
What was the biggest product problem you ran into?
Onboarding, by a mile. macOS makes you grant microphone, accessibility, and input monitoring access, each in a different corner of System Settings. None of the model quality matters if someone gives up during setup, and I nearly did on my own machine. If I took this further, the first run experience is where I would spend most of the design time, not the AI. That surprised me, and it is the most useful thing I learned.
What would it take to turn this into a real product?
Three things. Package it as a proper menu bar app so nobody touches a terminal. Walk people through permissions instead of leaving them to find the toggles. Then ship the roadmap: a custom dictionary for names and jargon, tone that adapts to the app you are in, and voice commands. The hard part, proving the core loop works, is done. What is left is packaging and polish, which honestly is where most of the real product lives.
A prevention-first AI health coach that turns wearable data into one plain-language decision a day, right in your chat
People drown in wearable metrics but starve for interpretation. Most trackers are abandoned within six months — and the prevention value of continuous data goes unrealised.
We generate more health data than we can act on. Wearables surface dozens of metrics, but the value has shifted from the number to the interpretation — most products either dump raw data or hide it behind a black-box score no one trusts. So trackers get abandoned within months, and the signals on your wrist that predict long-term health go unused. What if the coach lived in the chat you already use, gave you one decision a day, and proved every claim against your own data?
The moat isn't the model — it's the eval harness. The moment coaching quality became a number I could gate on — safety, data-faithfulness, relevance — every prompt change stopped being a vibe check and became a test. Second: design the interfaces first. Every external dependency — the LLM, WhatsApp, Google Health, the database — sits behind a Protocol with a mock, so the whole product runs and is fully tested offline, and going live is a config swap, not a rewrite. Third: prevention is a different product than engagement. Optimising for daily actives would reward anxious checking; the real win is one calm, grounded decision a day that never pretends to be a diagnosis.
How do you build a health product that can swap its data source, model, and channel without a rewrite?
Put every external dependency behind a narrow interface. Wearable data becomes one DailyMetrics shape; the LLM, channel, retriever, and database are each a Protocol with a mock. The whole system runs and is fully tested with zero API keys — and going live is a config swap, not a rewrite.
How do you trust an AI coach not to make things up — or give unsafe advice?
A golden-set eval harness scores every message on safety, data-faithfulness, and relevance, and fails the build if safety drops below 95%. That gate is the line between "an LLM said something" and an evaluated product — and it let me change prompts with tests instead of guesswork.
How do you coach on health data without feeding health anxiety?
Optimise for one calm decision a day, never daily actives. The coach refuses to diagnose: it frames everything as a deviation from your own normal ("6 bpm above your usual 58") and gates escalation behind an age- and history-aware check so it won't alarm low-risk users. "Worth mentioning to a doctor," never "you have X."
How do you ship a multi-surface AI product solo and still trust it works?
Test-first, across twelve TDD loops. Because every dependency is mocked, the whole journey — onboard, log a meal from a photo, log a workout, get a grounded insight, ask why — runs in a single offline test. "Does it still work?" becomes a two-second answer.
An agentic pipeline that eliminates manual triage — AI classifies, routes, and acts in under 3 seconds
Manual ticket triage consuming hours of ops time weekly, with error rates that spike during peak periods and no path to scale without adding headcount
Ops teams in large product organisations spend significant time each month manually reading and classifying incoming tickets — work that's repetitive, error-prone at scale, and grows linearly with volume. Could a PM, without raising a single engineering ticket, build and own an AI system that does this automatically?
Building an agentic pipeline taught me that orchestration is a product discipline, not an engineering one. n8n makes the workflow visible and ownable — any ops lead can modify routing logic or adjust prompts without filing a ticket. The harder insight was Jira's boundary behaviour: webhooks fire on every field change, so filter logic and event schema design matter as much as the AI step. Gemini Flash classifies; n8n executes; Jira acts. The PM's job was knowing exactly where each begins and ends.
Why n8n over a custom API?
No engineering dependency. The ops lead can update routing rules, fix prompts, and monitor the workflow without raising a ticket. The whole system can be iterated in an afternoon — which matters when routing accuracy improves incrementally through real-world testing.
Why a confidence threshold, not full automation?
Below a certain confidence level, the cost of a misroute (downstream SLA breach + ops time to fix) exceeds the cost of a human review. The threshold creates an explicit safety net: low-confidence tickets escalate to a human, high-confidence ones route automatically.
Why three routing paths instead of two?
Some tickets belong to a completely different team in a different system — not just a different queue. These need a distinct action (clone + close) rather than a simple assignment. Collapsing them into one path makes the accuracy metrics look good while the actual problem continues in the receiving teams.
Why AI classification over rule-based logic?
The domain boundary rules are too nuanced for deterministic if/else trees. Bug tickets describe symptoms in natural language and the correct owner depends on context — the same screen can have frontend or backend causes. Gemini Flash with structured org context handles this better than any decision tree the team could maintain.
Building the infrastructure AI actually runs on
AI assistants are context-blind — no calendar, tasks, or email without manual copy-paste
AI assistants are powerful but context-blind. They have no access to your calendar, tasks, email, or reminders unless you manually paste everything in. Could you build the infrastructure layer that makes AI genuinely useful for daily workflows?
This was the first project where the output wasn't an app or a website. It was an MCP server: the protocol layer that lets AI tools connect to real data sources. Building it meant writing tool definitions that Claude Desktop calls at runtime, designing OAuth2 authentication flows for multi-account Google access, handling macOS system APIs (Swift/EventKit) when the obvious approach (AppleScript) silently failed, and implementing input validation and rate limiting before any tool was written.
Why local-first, not cloud?
All personal data stays on the user's machine. A hosted version would be easier to onboard but would require storing OAuth tokens server-side. For a tool handling sensitive personal data, that's a trust ask most users won't accept.
Why MCP, not a standalone app?
Claude Desktop is already the interface. Building a separate dashboard would fragment attention and require a UI layer. MCP lets Claude reason about the data, not just display it. One conversation replaces six apps.
Why de-scope Apple Notes and WhatsApp?
Notes are freeform and deeply personal. WhatsApp has strong user expectations around message privacy. Both carry more risk than value in Phase 1. Deliberate scope decision, documented before build started.
Why multi-account Google from day one?
Most professionals have a personal and a work Gmail. Treating multi-account as Phase 2 would mean retrofitting the entire data model later. The server auto-discovers all authenticated accounts at runtime.
Why Swift/EventKit over AppleScript?
AppleScript's Reminders bridge silently hangs on large reminder lists. No error, no timeout. EventKit accesses the database directly via macOS framework. The first approach failed in testing; the pivot happened in the same session.
Why security-first build order?
Input validation (Zod schemas), rate limiting, and secure token storage were built before any tool was written. Retrofitting security into existing code is how vulnerabilities ship. Building it first meant every tool inherited the guardrails automatically.
AI stock intelligence, built end-to-end in a weekend
Retail investors have institutional-grade markets but none of the analytical tools to match
Individual investors face the same financial markets as institutions but none of their analytical infrastructure. Earnings calls, SEC filings, and macro data pile up faster than any one person can parse. Could a single PM, without raising a single engineering ticket, build an AI layer that synthesises this into actionable signals — in a weekend?
Writing a thorough PRD before touching any code is what makes AI-assisted development fast. The skill isn't coding. It's specification, architecture decisions, and understanding cost tradeoffs between models like Sonnet and Haiku. That clarity is the same skill that makes cross-functional programmes work at scale.
Keeping costs near zero removes the friction of learning. It forces you to understand how cost works in AI products: how much each API call costs, what caching does to your bill, and how cost-per-response can be controlled through architecture.
Why kill OpenAI?
Claude Sonnet does vision just as well. One vendor = one API key, one bill, one set of docs. Simplicity compounds.
Why Supabase?
Postgres + auth + storage in one free tier. Row Level Security means the database enforces permissions, not my code.
Why cut Polygon.io?
Finnhub's free tier already covers quotes, fundamentals, and news. Product lesson: audit before you add.
Why Claude Code?
10 sequential prompts. Each builds on the last. The PRD I wrote is what made this fast.
Why Stitch then Figma?
Stitch for "give me a starting point." Figma for "make this production-ready." MCP connected the two worlds.
Why Vercel?
Push to GitHub, get a URL. Every deployment step you eliminate is time for making the product better.
Enterprise RAG that replaced tribal knowledge
Support teams rely on tribal knowledge to resolve queries — slow, inconsistent, unscalable
Could AI replace the tribal knowledge that support and ops teams rely on to resolve subscription queries across markets?
The product decision that mattered most wasn't the AI model. It was designing the information architecture so the right answers surfaced for the right queries. That's a product problem, not an engineering one.
New builds added as they ship.
Four industries, three countries, two companies co-founded, and one consistent pattern: read the market, identify the highest-leverage problem, and move decisively.
Eur 150M+ GMV in subscription strategy. 36% churn reduction. A 30-point conversion swing. EUR 60M in cost savings. Wallet adoption from 3% to 27% order share. 99.8% payment reliability.
Two companies co-founded before Delivery Hero. In a startup, you build the thing yourself. In a large org, you align engineering, design, data, ops, and regional stakeholders around a shared outcome. Both require clarity.
Six projects built, five in production. Enterprise RAG. Full-stack SaaS. Open-source MCP server. The progression from using AI to building the systems AI runs on creates a different kind of product intuition.
PortfolioIQ: concept to deployed. Knowledge Base: Turkey launch to platform-wide. MCP Toolkit: frustration to daily open-source tool. Clear specs, right tools, knowing what to decide now vs defer.
Always happy to talk product strategy, AI-native development, or building at the intersection of product and engineering.