AI/ML engineer turned product manager. I define the product, prototype it, and measure whether the AI works.
Selected work
BossWorks · 01
I developed an evaluation framework that scores agent responses against defined criteria, so quality is measured instead of guessed.
BossWorks · 02
Owned the product end to end: AI-generated business plans, financial planning, budgeting, and execution workflows.
BossWorks · 03
Built a multilingual AI news summarization feature as an AI/ML engineer, then productized it: wrote the PRD, defined success metrics, and handed it to the team.
BossWorks · 04
Funnel analysis showed multilingual users searching in 2 to 3 words and finding no relevant experts. I shipped real-time semantic suggestions, multilingual matching, and filters.
BossWorks · 05
Defined conversation flows, prompt strategy, and expected model behavior with the AI/ML engineers.
BossWorks · 06
Built working prototypes in Cursor that followed the front-end code rules, iterated on them live with the PM, and handed developers code they used directly.
AI Lab
Experience
Current
Product Manager
Apr 2026 to presentBangalore, India
Live with 2 large enterprise customers: financial settlement and accounting for the food supply chain.
Product and AI
AI/ML Engineer → Associate Product Manager
Shipped an AI launch platform, a multilingual news feature (+12% DAU), and an agent evaluation framework.
Feb 2024 to Mar 2026Bangalore, India
Foundation
Data Analyst Intern
Forecasting accuracy up 20%. Reporting turnaround down 40%.
Jun 2023 to Aug 2023Shahdol, India
My approach
Sit with users and stakeholders until the workflow behind the request is clear.
Requirements, business rules, guardrails, and success metrics before anyone builds.
Validate in Cursor, Claude, and Lovable before engineering starts, so requirements get sharper and iteration cycles shrink.
Define success up front, then check it. For AI features that means accuracy, grounding, and safety. For everything else, adoption and speed.
My toolkit
Product thinking · Roadmaps · Backlogs · Prioritization · Sprint execution · Cross-functional delivery · PRDs · Funnel analysis · User research · Stakeholder management
AI agents · Prompt engineering · RAG · AI workflows · AI product design · Workflow automation
Python · SQL · Data analysis · Product metrics
Claude · Cursor · Lovable · Bolt · Jira · Figma · Notion
A little about me
My journey started in data science and AI/ML, where I learned to work with complex systems and turn data into useful insights. Over time I moved closer to the product: understanding users, shaping experiences, and working with teams to bring ideas to life.
Today I enjoy the space where product thinking and applied AI meet: figuring out where intelligence genuinely helps, designing the right workflow around it, and making sure the experience works in the real world.
CHRIST University, Bengaluru · 2022 to 2024
Pt. SNS University, Shahdol · 2018 to 2021
2023 · Top 6 finalist
1st rank, BSc Computer Science · Academic scholarship in 12th grade
The next chapter
Let's talk about products, AI, and ideas worth building.
Product requirements document · v1
Voice of Customer Copilot reads app-store reviews and tells a product manager what to fix first. It ranks problems by how serious and how widespread they are, flags releases that made things worse, and writes a weekly brief where every claim comes with real quotes.
The value is trust, not summarizing. Every insight shows its evidence, every number comes from code, and when the data is thin the product says "not enough evidence" instead of guessing.
A PM on a consumer finance app gets around 130 reviews a day and can't read them all. The usual process is skimming recent 1-star reviews on a Monday. That leaves three questions open: which complaints are real, which are growing, and how to defend the choice to engineering or leadership.
I looked at 36 days of public reviews for one investing app (4,600 reviews) to see how much signal there actually is:
| Primary | Maya, a product manager who owns a squad (trading, payments or onboarding). She ships every one to two weeks, has little time, doesn't trust AI summaries, and needs evidence she can forward. |
|---|---|
| Later | Engineering leads (bug triage), support operations, leadership |
Maya has five decisions to make, and the product is built around them:
The first two carry most of the value, so I built them first.
| Speed | A fix list in under 15 minutes. Today it takes roughly two hours of manual reading. |
|---|---|
| Evidence | Every claim traces back to a verbatim review quote. |
| Reliability | Critical issues caught: at least 90%. Problem-finding score (F1): at least 0.75. Sentiment agreement (kappa): at least 0.70. I wrote these bars down before seeing any results. |
| Releases | Spot a release that made things worse within days. The alarm should stay quiet when nothing changed. |
| Discipline | Use AI only where it beats a simple non-AI baseline, and prove it with numbers. |
In scope for v1: one app, one review source (Google Play), English and Hinglish, one persona, a weekly or on-demand batch.
Out of scope: competitor tracking, churn prediction, replying to reviews, other review sources, private analytics such as funnels and crash logs, real-time alerts.
Reviews → clean → filter → AI reads each review → code decides severity → group into themes → code ranks and checks releases → weekly brief.
| Code | Removing personal data, the filter, checking every AI answer, severity, all counts and rankings, the release statistics, the brief |
|---|---|
| AI | Reading each review (category, sentiment, problems, quotes, true/false facts) and deciding which small groups of problems mean the same thing |
| Why this split | Reviews are free text with mixed Hindi and English, sarcasm and half sentences, which suits AI. Counting, ranking and statistics must be exact and repeatable, which suits code. |
Each review gets one of 12 categories: order execution, payments and funds, login and account, crash or bug, performance, UX friction, feature request, charges and pricing, customer support, fraud or money-loss claim, praise, other. The last four never enter the fix list. Fraud and money-loss claims get their own section, labeled as claims.
The rule behind every requirement: AI reads, code decides and counts. A model never produces a number you see.
| Clean and filter | Remove names, photos and developer replies at the first step. A rule-based filter drops reviews with no signal (about 77% of them). It must miss at most 2% of real complaints. |
|---|---|
| Read each review | The AI picks a category, sentiment, the specific problems, a word-for-word quote for each, and answers eight true/false questions (money lost, money stuck, order went wrong, a main action blocked, and so on). Code checks the answer. A quote that isn't really in the review is rejected and redone. |
| Severity | Code decides, using rules I wrote. The AI only supplies the true/false facts. Money lost, an order that went wrong or a security issue means critical. |
| Themes | Similar problems are grouped. A theme needs at least 5 reviews to be ranked. Smaller groups show as "emerging, low evidence". |
| Ranking | Priority = severity points × trend. The formula and weights are visible, and the PM can change them. |
| Release check | Flag a version only with at least 30 reviews on each side, a statistical test, and a rise of at least 1.5×. Otherwise say "not enough evidence". |
| Weekly brief | Written by a template from code-computed numbers. A self-check confirms every number matches and every claim has a quote. |
| Fintech safety | Money-loss and fraud claims are always attributed ("a reviewer says…"), never stated as fact. No personal identifiers anywhere. |
I wrote a checklist of 94 checks, one stage at a time, because a single overall accuracy number hides where a bad insight came from. Each check says how it's measured, what the bar is, and where it stands today: 48 measured, 25 partly measured, 21 not done yet. I wrote the bars down before I saw any results. These are the ones that matter most:
| Stage | What I check | Bar |
|---|---|---|
| Cleaning | No names, photos, developer replies or personal details left in the stored data or the app | None found |
| Filter | Real complaints it wrongly skips (I label a random sample of the skipped reviews) | At most 2% |
| Reading | Problem finding (F1), categories (macro F1), sentiment (kappa), and whether it beats a keyword baseline | 0.75, 0.80, 0.70, clear lift |
| Quotes | Every quote appears word for word in the review. Rejected answers are logged and sorted as altered, reworded or invented | 100% |
| Severity | Critical issues caught, and critical calls that were right, against my own ratings. Never two or more levels off in the dangerous direction | 90% and 70% |
| Themes | Is each ranked theme one problem with one owner? I read them myself. Also how many problem reviews land in a ranked theme | 85% coherent, 60% coverage |
| Ranking | Formulas tested, I agree with the top 5, and a PM can explain the priority score | 4 of 5 overlap, 2 of 3 PMs |
| Release check | Stays quiet when I shuffle versions so any difference is chance, and catches an injected jump. I report how big a change it needs | Near-zero false alarms |
| Weekly brief | Every number matches the code, and every claim has a real quote from the review it cites | 100% |
| Made-up content | Instructions hidden inside a review, and gibberish or emoji-only reviews, must not change the output | No change |
| Cost and speed | Tokens per review, cost per 1,000 reviews by model, time per page and per live review | Reported |
A few rules I kept: tune on practice data and score the held-out set once, always show how many cases a number rests on, compare against a simple baseline, and write down every change I made after seeing results. The references are kept separate: my own severity ratings, a second labeler on 200 reviews, and two independent labelers on 99 reviews. Results are in the case study.
Case study · Independent project
A PM at a consumer finance app gets about 130 app-store reviews a day and has no good way to tell which complaints are real, which are growing, and which are worth fixing. I built a copilot that reads the reviews, ranks the problems, flags releases that made things worse, and writes a weekly brief with real quotes as proof.
The AI was the easy part. The harder part was deciding where AI should not be used, and finding out where it was wrong.
I worked with 4,600 public Play Store reviews of an investing app, collected over 36 days. I wanted to know how much of it is useful. 78% are 5 stars and 71% are three words or fewer. Only about 336 are real complaints, which is around 9 a day.
So the PM isn't short of reviews. They're short of a way to find those few and see which ones are growing. Skimming recent 1-star reviews on a Monday can't tell you that, and it can't help you defend a choice to engineering.
One rule shaped everything: the AI reads, and code decides and counts. No number on the screen comes from a model.
| Clean | Code removes names, photos and developer replies |
|---|---|
| Filter | Code rules drop reviews with nothing to learn from (77% of them) |
| Read | AI labels each review: category, sentiment, the problems, a word-for-word quote, and eight true/false facts |
| Check | Code rejects any label whose quote isn't actually in the review |
| Severity | Code, using rules I wrote |
| Themes | Word matching first, then an AI step that merges groups that mean the same thing |
| Rank and brief | Code ranks themes, checks releases and fills a brief template |
1. I took severity away from the AI.
My first version asked the model how serious each problem was. I rated 70 cases myself and compared. The model caught only 11 of the 27 issues I had rated critical (41%), and rewriting the instructions didn't help (37%).
So I changed the job. The model now answers eight yes/no questions: was money lost, is money stuck, did an order go wrong, is a main action blocked, and so on. Then code applies rules I can read and change. On 30 new reviews I rated myself, it caught 7 of 7 critical issues, and 7 of its 9 critical calls were right (78%). It landed within one level of my rating 97% of the time. Only 7 of those reviews were critical, so I call this encouraging, not proven.
2. My own scoring rule was wrong, and I found out.
My first rule counted a problem as "found" only if the two quotes overlapped heavily. It gave a score of 0.38, which looked terrible. The real cause was that one labeler quotes whole reviews and the other quotes short phrases. 101 of 185 correct matches were being counted as misses. I changed the rule to compare the shorter quote against the longer one, wrote down why, and the score became 0.85. I made that change on practice data only. The held-out test set stays untouched.
3. Word matching alone didn't group problems well enough.
It turned 252 problems into 147 themes, and only 6 had five or more reviews. That's too scattered to rank. I added a step where a model decides which small groups mean the same thing. It can only merge groups that already exist, and never across categories. The result was 95 themes, 10 of them ranked, and the share of problem reviews inside a ranked theme went from 27% to 56%. When I read the ten ranked themes myself, seven were clearly coherent and three were a bit broad.
4. The release alarm is cautious on purpose.
It flags a version only with 30 or more reviews on each side, a proper statistical test, and a rise of at least 1.5 times. To test it, I shuffled which version each review belonged to, so any difference was pure chance. It raised a false alarm 0.9% of the time (18 of 2,000). I also injected real increases. With 80 reviews per version, a doubling of complaints was caught 74% of the time. A 1.6× rise was caught only 23% of the time. So "no flag" doesn't mean "no problem", and the app tells you that.
I used three kinds of reference and kept them separate, because they are not equally trustworthy: my own ratings (the strongest), a second labeler on 200 reviews, and two labelers working independently on the same 99 reviews.
| Problem finding on 200 reviews (precision / recall / F1) | 0.83 / 0.86 / 0.85. A keyword-rules baseline scored 0.55, and ranking by star rating alone scored 0.04. |
|---|---|
| Category score (macro F1) | 0.83 |
| Sentiment agreement (Cohen's kappa) | 0.97 |
| Two independent labelers on 99 reviews | Sentiment kappa 0.96, severity weighted kappa 0.81, problem finding F1 0.75 |
| Quotes the model made up | 1 in 67 (1.5%) in a first look, caught by code. Another 3 were lightly altered and also caught. |
Every number can be recomputed with one command. I wrote the pass/fail bars down before I saw any result.
About 1,090 tokens per review. On a free tier that's $0. On a paid tier it ranges from about $0.22 per 1,000 reviews (cheapest) to about $8.60 (top tier). At this volume, cost isn't what decides the model. Quality on mixed Hindi-English text and on severity is.
Try the live app ↗ · Code on GitHub ↗
AI Product Manager · Bangalore, India
namratasingh0712@gmail.com · linkedin.com/in/namrata-singh798
AI Product Manager with ~3 years across AI/ML engineering and product, building B2B and B2C AI products. Shipped a financial settlement platform live with 2 large enterprise customers, and AI features that drove a 12% DAU increase and 35% better expert discovery.
Product Manager, Terrantic
Apr 2026 to present · Bangalore, India
AI/ML Engineer → Associate Product Manager, BossWorks
Feb 2024 to Mar 2026 · Bangalore, India
Data Analyst Intern, Reliance Industries Limited
Jun 2023 to Aug 2023 · Shahdol, India
Voice of Customer Copilot
AI copilot: app-store reviews to a ranked fix list · Python, Streamlit
Live demo ↗ · Case study
Text-to-SQL Query Conversion
LLM pipeline for natural-language data access · Python, SQL, Streamlit
| Product | Product Discovery, PRDs, Roadmapping, Prioritization, Backlog Management, Funnel Analysis, User Research, User Testing, Stakeholder Management, Agile, Rapid Prototyping, Product Metrics |
|---|---|
| AI | AI Agents, Agentic Workflows, LLM Evaluation, Prompt Engineering, RAG, Semantic Search, AI Product Design, Workflow Automation |
| Data and tools | Python, SQL, Data Analysis, Claude, Cursor, Lovable, Bolt, JIRA, Figma, Notion |