The obvious problem is rarely the real one.

I build products by finding the problem underneath the request: an AI speaking coach for people who freeze under pressure, a CRM that 300+ salespeople actually adopted (10% to 70%), and an AI support assistant that knows when not to use AI.

See my work Resume ↗

Open to APM and PM roles in AI · available now User research to live product Based in India

Work

Selected case studies

Each one starts with research, makes clear trade-offs, and ends with something people could use.

Jobs-to-be-done research · MVP scoping · Funnel drop-off analysis

Outloud

An AI speaking coach for professionals who write English well but freeze when they have to speak it at work.

Live app15 users onboardedFound the #1 drop-off

Built with Replit · OpenAI API (GPT-4o mini) · PostHog · Claude (scoping, prompt design)

Read case study →

Adoption metrics · Phased rollout · Iterating from usage data

Salesforce CRM, from zero to one

Moving sales teams off scattered spreadsheets onto one CRM, and treating adoption, not launch, as the finish line.

Admin and product owner₹10 Cr+ tracked monthly₹40 Cr+ from closed leads

Built with Salesforce · Lovable · Figma AI

Read case study →

AI vs. no-AI trade-offs · Evals with trap cases · Human in the loop

AI support assistant

Five support jobs, one question each: should this be an AI agent, an AI skill, or no AI at all? Then I built and stress-tested the AI parts.

2 agents · 2 skills · 1 no-AI13/13 test casesFound an eval flaw

Built with Claude Code

Read case study →

Problem reframing · Prioritising by evidence · PRD with success metrics

Smarter ride pickups

Why riders and drivers miss each other at busy places, how to help them meet without a phone call, and the PRD to build it.

Problem reframedTested prototypeFull PRD

Built with Lovable · Claude (PRD Co-Pilot)

Read case study →

More work

AI prompt design · Solo · 2026

PRD Co-Pilot

A system prompt that turns Claude into a senior PM who drafts PRDs with me, without inventing facts. I took it through seven versions, then used it to write the ride pickups PRD.

Every claim is tagged by where it came from: my input, a source document, AI research, or an assumption.
Nothing is made up. No invented metrics, baselines, dates or quotes. Unknowns stay "TBD" with an owner.
I stay in charge. Its decisions stay "Proposed" until I confirm them, and it edits only the sections that changed.

See the tagging rules

[PM INPUT]Stated by me in the conversation

[SOURCE EVIDENCE]From a document I supplied, with the source named

[AI RESEARCH]Found independently, with a citation

[ASSUMPTION]A reasonable guess, flagged for validation

[EVIDENCE GAP]A claim is needed but no evidence exists

[PM INPUT NEEDED]A scope or priority call only the PM can make

Example: asked to "just say retention improves", it writes "Expected to improve 30-day retention [PM RECOMMENDATION — no baseline yet; instrument before launch]" instead of stating it as fact.

Built with Claude

About

From running programs to building products

As a program manager I learned to get engineering, marketing, finance and vendors moving in the same direction. Building Salesforce from scratch showed me I care most about the product itself: what to build, for whom, and whether it works.

So I did a product management program, and used it to ship something real. I'm now looking for an APM or PM role on an AI product.

AI Product Manager

APM or PM, in consumer, edtech or any domain with a real user problem.

2026

Product management program

Shipped Outloud as my capstone, designed and tested an AI support assistant, and ran a discovery study on ride-hailing pickups.

2022 – 2026

Program Manager, Times Internet

Owned the company's Salesforce CRM as admin and product owner, from zero to 300+ users: adoption up from about 10% to 70%, weekly support tickets down 80%+, and ₹10 Cr+ in revenue tracked monthly.
Managed licences and directed the developer and vendor on all Salesforce build work.
Connected Meta and Google Ads tools with marketing and product, including token setup for automated Meta posting.
Ran the evaluation and move from AppsFlyer to Singular for attribution.
Consolidated overlapping SaaS tools to cut cost.

Awards: Spot Award for Salesforce platform ownership · Customer Champion Award · Terrific Team Award

User researchReframed Outloud and ride pickups from what users said, not what I assumed

AI product judgmentDecided where AI helps and where a script is safer; designed guardrails for agents and skills

Evals and metricsTrap-case tests for AI agents; North Star and a live analytics dashboard for Outloud

Adoption and shippingSalesforce CRM to 300+ users at Times Internet; Outloud live on the web

Beyond the work

A few things that don't fit on a resume

Priyanka skydiving, giving a thumbs-up mid-jump

Terrified, and jumped anywayI went skydiving while thoroughly scared. Doing the scary thing anyway is also the idea behind Outloud.

Chess runner-up, 5K finisherOne is about thinking a few moves ahead. The other is about not stopping.

Friends everywhere, no effort requiredI travel solo and still never end up alone. Being weirdly good at striking up conversations turns out to be very useful in user interviews.

Fiction and a kitchenI read novels over textbooks, and cooking is how I switch off.

Contact

Hiring for an AI PM or APM? I'd love to talk.

Book a 20-minute intro call ↗

Or reach me at: priyankagoyalpg94@gmail.com · LinkedIn ↗ · Resume ↗

← All work

Case study · Outloud

I built an AI speaking coach, then found out why most users never said a word

Outloud gives early-career professionals a private, daily place to practise speaking English under pressure, with an AI conversation partner called Arya.

What this shows: Jobs-to-be-done research · MVP scoping (v1, v2, cut) · North Star and leading indicators · Funnel drop-off analysis · LLM guardrails

Try the live app ↗

My roleEverything: research, PRD, AI design, build, launch, analytics

ContextProduct management program capstone, 2026

StackReplit, OpenAI GPT-4o mini, Web Speech API, PostHog

The problem

Knowing the answer isn't the same as saying it

Many early-career professionals read and write English confidently, then go quiet in meetings. In a survey of 45, 82% rated their spoken-English confidence below "very confident". Coaching is expensive and public. Language apps teach vocabulary. Free content is passive.

The insight

The block isn't vocabulary. It's finding the words fast, under pressure, while worrying about being judged.

I ran two in-depth interviews and read eight open-text survey answers. People knew the words on paper and lost them live.

"What shakes my confidence is the anticipation that I won't know the words, and that the other person will judge me."

So users weren't hiring the product to teach English. They were hiring it to rehearse being watched, somewhere safe. Every decision below comes from that.

Key decisions

What I chose, and what I gave up

The app decides what you practise; the AI decides how the conversation goes

Chose: fixed 15-session curriculumGave up: open-ended AI chat

An open chat drifts and can't be measured. Splitting control kept conversations natural and progress comparable.

No live correction, and one thing to improve per session

Chose: a short report that leads with what went wellGave up: catching every mistake

Interrupting an anxious speaker makes the freeze worse. One clear fix is something people can act on.

Scores only on the progress page, and no gamification

Chose: trends over timeGave up: per-session scores, badges, leaderboards

A number after every session makes practice feel like a test, which is the feeling the product exists to remove.

What I built

A working app, not a mockup

Speak with Arya→Get one clear fix→See progress→Speak again

Onboarding asks five questions, including when you tend to freeze. Each day unlocks one voice conversation. Afterwards, a short report covers what went well, one thing to improve, a better way to say it, and a speaking tip. The progress page tracks fluency, articulation and language over time.

I built it with Replit's AI agent, using OpenAI's GPT-4o mini and the browser's speech recognition, and tracked every step in PostHog.

Onboarding asks when you freeze
One session unlocked each day
Live conversation with Arya
Report with one clear fix
Progress over time

What happened

The biggest drop is before anyone speaks

15people completed onboarding

60%started a first session

40%finished one

82%of attempts hit a voice or mic error

A small pilot with people I know, as of 29 September 2026. It shows whether the product works and where people get stuck, not long-term retention.

Most people who signed up never finished a conversation, and motivation wasn't the likely cause. Most attempts hit a voice or microphone error, and browser speech recognition is unreliable on iPhone Safari. For a product about the fear of speaking, a failed first attempt is the worst possible start.

Next experiment · result coming soonA check before the first session that steers users to a browser where voice works.

What surprised me

AI features need checking like any other feature

The voice was fine on my laptop and wrong on phones. Arya first sounded like a French speaker reading English, then robotic. I now test voice on the target device from day one.
The AI drifted from the design on its own. The transcript screen began suggesting a rewrite for almost every sentence, the opposite of "one clear fix". I only caught it by comparing real screens against the spec.

Looking back

What I'd do differently

Pick a North Star I can measure during the pilot. Week 4 completion stays the long-term goal; Week 1 completion is the one I can move now.
Test on phones from the start. The biggest problems only appeared on mobile.
Recruit beyond my network sooner. Real retention data needs people who arrive with the problem.

Next case study
Salesforce CRMRead →

← All work

Case study · Salesforce CRM at Times Internet

Setting up the CRM was the easy part. Getting 300 salespeople to use it was the product.

Sales teams at Times Internet ran leads, follow-ups and reporting in scattered spreadsheets. I took our Salesforce CRM from zero to one, and measured success by whether people used it, not by whether it launched.

What this shows: Adoption as the success metric · Narrow MVP and phased rollout · Iterating from usage data · Access and governance design

My roleSalesforce admin and product owner: discovery, MVP scope, licences, rollout, adoption. I directed the developer and vendor who built it.

Users300+ sales reps, managers and business heads

ContextInternal platform, Times Internet · two years · Spot Award for platform ownership

300+users onboarded

~10% → ~70%adoption, measured by daily and weekly active users

~100 → 10–20support tickets a week, an 80%+ drop

₹10 Cr+revenue tracked in the CRM every month, across business units

₹40 Cr+revenue from leads captured and closed in the new lead workflow, over two years

The problem

No single source of truth for sales

Each team tracked leads and opportunities its own way, in its own spreadsheets. Business heads had little visibility into the funnel, reports were built by hand, and it was hard to follow a lead through to a deal. As teams grew, so did the question of who should see whose data.

The job wasn't "implement Salesforce". It was designing a sales workflow teams would actually adopt, while giving leaders a funnel they could trust.

Discovery

Design the workflow first, then configure the tool

I worked with business heads and sales reps to understand how leads were captured today, what information each stage really needed, which fields were useful and which were just effort, where people fell back on spreadsheets, what managers needed to see, and which teams should be able to see each other's data.

The MVP

One journey, done properly

Lead capture→Qualification→Opportunity→Follow-up→Reporting

The first version covered only the lead-to-opportunity journey, with standard fields, automation for the obvious manual steps, role-based access, basic reports, and demos for every team. The aim was to prove the workflow worked for users before adding more.

The lead stage mattered most. Teams were still working leads out of Excel, so I redesigned the lead object around how they actually qualified leads. Once leads lived in the CRM, every closed deal could be traced back to its lead. Over two years, those leads closed into more than ₹40 Cr of revenue, money that was previously invisible because it lived in spreadsheets.

Start narrow

Chose: one core workflow, rolled out in phasesGave up: moving every sales process at once

A big-bang migration would have forced change on everyone before we knew what worked. A narrow first release turned launch into a way to learn.

Iterating

What changed once people used it

I treated the first release as a starting point, and used feedback and usage to find where people got stuck.

Fewer fields. We checked which fields reps actually filled in, and removed or demoted the ones that only added effort.
The right fields made mandatory. Only information that reporting and later steps depended on became required.
More automation. Manual steps we saw people repeating were automated next.
Tighter access. As adoption grew, we tightened hierarchy and visibility rules so people only saw their own teams' data.
Personal views. We showed reps how to build their own list views instead of relying on shared ones that admins could change.

More fields doesn't mean better data. Asking for less, and requiring only what matters, improved both.

Adoption

Roll out, observe, improve, expand

Rollout happened in phases, with demos, process walkthroughs and feedback rounds at each step. Every cycle asked the same questions: is this used, is the information useful, where are people stuck, and what still needs manual work?

I tracked adoption through daily and weekly active users, backed by two signals of real work: how many deals reps entered and how many activities they logged. Logging in proves little; entering deals shows the CRM has become where the work happens.

Adoption rose from about 10% to about 70%, and more than ₹10 Cr of revenue was flowing through the CRM each month by the time I left in Oct 2026. Weekly support tickets fell from around 100 to 10–20, which mattered just as much: people could use the CRM on their own instead of needing constant help.

What I learned

Adoption is a product problem

A complete system isn't a successful one. The real measure was whether sales teams worked in it every day.
The MVP is for learning. Some of the most useful changes only became obvious once people used it.
Governance is a feature. At scale, access rules and consistent processes mattered as much as functionality.
Ownership continues after launch. Adoption, feedback, friction, iteration and governance were all part of the job.

Next case study
AI support assistantRead →

← All work

Case study · AI support assistant

I was asked to automate five support jobs with AI. The best call was leaving one alone.

For Northwind Analytics, a fictional B2B software company with 1,200 customers and one shared support inbox, I decided which jobs should be an AI agent, an AI skill, or no AI at all. Then I built and tested the AI parts.

What this shows: AI vs. no-AI trade-offs · Agent vs. skill design · Evals with trap cases · Prompt-injection guardrails · Human in the loop

My roleSolo: capability design, prompt design, build, testing

ContextProduct management program assignment, 2026. The company is fictional.

Built withClaude Code: 2 skills and 2 agents, each working on its own

The question

Agent, skill, or no AI?

Northwind's support team had five recurring jobs. For each one I asked the same thing: does it need real language understanding, or taking actions without a person approving each one? If neither, a plain script does it better.

Agent: works through a job on its own, with no human approving each step.
Skill: produces one bounded piece of work, like a draft, that a person reviews.
No AI: the data is already structured, so a script is faster, cheaper and can't make things up.

Job	Call	Why
Read, categorise and route new tickets; escalate outages, legal and security	Agent	Tickets are free text, and routing happens on every ticket with no one approving it.
Draft replies in the company's tone, never quoting an unapproved refund or price	Skill	One draft at a time, checked against a policy document. A person always sends it.
One-page briefing before a call with an at-risk customer	No AI	Billing, usage and ticket counts are all numbers. A script pulls them with zero risk of an invented figure.
Weekly grading of closed tickets, with recurring problems summarised	Agent	Judging tone and correctness needs reading. Spotting patterns across a batch is a multi-step job.
Check a bug report against the changelog; if new, write it up for engineering	Skill	Customers describe bugs in their own words, so keyword search misses matches. The output is one write-up.

The key decision

Where hard numbers feed straight into a conversation with a customer, a script is safer than a model.

The at-risk customer briefing looked like an obvious AI job: pull data from three systems and summarise it. But every input is a number, such as revenue, logins or invoice status. A model adds cost and delay, and it might invent a figure that a rep then repeats to an unhappy customer.

A clean fact sheet with a few computed flags, such as "usage down more than 40%", lets a trained rep draw their own conclusions in the time it takes to read it. I recommended a script, and noted when AI might be worth adding later.

How I designed it

Guardrails before features

Escalation comes first. The triage agent checks for outages, legal and security issues before it routes anything, and stops once it escalates.
Ticket text is untrusted. The agent ignores any instruction hidden inside a customer's message, which protects against prompt injection.
No figure without the policy. The reply skill reads the live policy document every time and only quotes a refund or price the document supports. Otherwise it flags the question for a person.
"Unknown" instead of a guess. The bug skill marks missing details as unknown and labels any repro steps it had to infer.
A strict output format. Triage returns fixed JSON, so a ticketing system could read it without surprises.

How I tested it

Every test set has a trap

Passing easy cases proves little, so each test set included a case built to fool the AI.

Capability	Passed	The trap
Ticket triage	5 / 5	A user writes "urgent" and can't log in, but mentions her coworkers can. It must not be escalated as an outage.
Reply drafting	2 / 2	Two refund requests that look alike: one must quote the figure, the other must withhold it.
Quality review	4 / 4	One serious one-off mistake that must not be reported as a recurring pattern.
Bug triage	2 / 2	A CSV export bug that sounds like a known PDF bug. It must be treated as new.

A real run

The trap ticket, and what the triage agent did with it

From: a Starter-plan customer · Subject: Can't log in - urgent, need this fixed today!! "I've been trying to log into my dashboard since this morning and keep getting an error message. This is really urgent because I have a client presentation in a few hours and need to pull data. None of my other coworkers have mentioned an issue though, not sure if it's just me."

Claude Code output: escalate false, category Account/Access, priority high, reason cites that coworkers are unaffected

Result: not escalated, routed to Account/Access with high priority. The reason quotes the line about coworkers, so the agent judged the scope of the problem instead of reacting to the word "urgent". A second, differently worded version of the same trap got the same decision.

A second real run

The look-alike bug, and what the bug skill did with it

From: a Business-plan customer · Subject: Export not working on our big dashboard "When I try to export our 'Regional Fleet Overview' dashboard to CSV, nothing happens. The button greys out for a second, then nothing. No file downloads and there's no error message. It's our biggest dashboard (about 20 charts). Exporting smaller dashboards to CSV works fine."

Claude Code output: not a known issue, NW-1042 considered and rejected because it is PDF-only; new engineering write-up with inferred steps and unknown fields marked

Result: treated as a new bug. The skill considered the known PDF export bug, then rejected it because that issue is PDF-only. The write-up labels inferred steps, marks the browser and timestamps as unknown, and ends as a draft for a person to review. I only typed "New ticket:" with the email. Claude chose the bug skill on its own and ran triage alongside it.

What surprised me

Two runs disagreed, and the cause was my test setup

I ran the quality-review agent twice: once with the ticket text pasted in, and once reading the files itself. The overall verdicts matched, but two escalation grades flipped.

Digging in, I found two problems. My test files included answer-key notes that a real ticket would never have, and the agent read them. And the grading rubric never defined what should trigger an escalation, so the agent had to guess on borderline tickets.

The lesson: an evaluation is only as good as its test data and its rubric. I documented both fixes rather than picking the run that looked better.

If I took it further

From a working demo to something I'd trust

A much bigger test set. Thirteen cases show the design works. I'd want 50 or more real tickets per capability before relying on it.
Track missed escalations separately. Missing a real outage costs far more than a false alarm, so that is the number to watch.
Run it in shadow mode first. Let triage run alongside the human team for a couple of weeks and compare decisions before it routes anything for real.

Next case study
Smarter ride pickupsRead →

← All work

Case study · Ride-hailing pickups

Riders and drivers weren't lost. They just hadn't agreed where to meet.

After booking a ride, people in busy places still wonder where to stand and whether the driver will find them. The brief: how should Uber understand this problem before proposing solutions?

What this shows: Problem reframing · Survey design · Personas · Prototype testing · Prioritising by evidence and effort · PRD with success metrics

Open the prototype ↗

My roleSolo: research, synthesis, personas, prototype, testing, PRD

ContextProduct management program assignment, 2026

ToolsSurveyMars, Lovable, Claude (PRD Co-Pilot)

The approach

Understand the problem first

I surveyed 12 regular ride-hailing users aged 25 to 30 across Uber, Ola and Rapido: how they use the apps, where they get picked up, what goes wrong, what they do about it, and what they would change. I added desk research on the Indian market and the rules that limit pickups, such as airport zones and no-stopping areas.

Independent concept study. Not affiliated with or endorsed by Uber.

The insight

The obvious fix was better GPS. The data said the problem was coordination: two people with no shared meeting point.

9/12had a pickup problem in their last five rides

2/12blamed inaccurate GPS

5/12blamed multiple gates and entrances

9/12phone the driver first

The map usually put rider and driver in the same area. The trouble was the last 50 metres: which gate, which side of the road. People described places by landmarks, never coordinates.

"The map showed the same location, but there were multiple gates and the driver was waiting at a different one."

Phone calls were covering for something missing in the product, and 10 of 12 riders said they would walk a short way for a pickup that works.

Who it's for

Two riders, two different problems

The routine commuter

Home to office several times a week. Still moves the pin to the same gate every time.

"I usually get picked up from the same gate, but I still have to adjust it every time."

The urban navigator

Books from metros, malls and airports. Can't agree a meeting point with the driver.

"The mall had multiple exits and we kept missing each other."

The concept

From a pin on a map to a meeting point both sides can see

Remembered pickups at familiar places. If you're always picked up at Gate 2, the app suggests Gate 2.
Recommended pickup points with a landmark at busy places, ranked by how often pickups there succeed, walking distance and driver access.
Re-routing when plans change. If a barricade or crowd pushes you away, the app offers a new spot and tells the driver, with no call needed. (Deferred to phase 2 in the PRD.)

Remembered pickup at home
Recommended points at a metro station
The driver sees the same gate and landmark
Re-routing when the rider can't get there

Testing it

What people said, including what didn't work

Landmarks won clearly. "It's easier to find a driver using a landmark than by trying to interpret a map."
Recommended pickups were the favourite. "I didn't have to move here and there to find the driver."
The "riders who booked here" count split opinion. One tester trusted it; another said it made no difference. The landmark does the real work.
The prototype wasn't self-explanatory. The first tester couldn't tell what to do when she opened it, so I walked her through it on a call. A real rollout needs a clear first-use moment.

The PRD

Turning research into a plan engineers could build

Next I wrote a full PRD, drafted with the PRD Co-Pilot I designed. Every claim in it is tagged by its source, and every number comes from my survey or is marked "TBD". The key calls:

Build two of the three ideas, and defer re-routing

MVP: landmark recommendations + remembered pickupsPhase 2: re-routing

I ranked each idea by strength of evidence and cost to build. Landmarks had the strongest evidence. Re-routing had the weakest evidence and needs real-time tracking, so it waits for research that sizes the problem.

Drop the "riders who booked here" count

Chose: landmark and walking distance onlyGave up: social-proof numbers

Testers were split on it, and showing counts without real data behind them would mean shipping made-up numbers.

Leave airports out of v1

Chose: malls and metro stations firstGave up: airports

I considered including them, then reversed. Airports restrict pickups to official zones, which landmark suggestions don't fit, and my research didn't cover them.

Let drivers flag a bad landmark, but keep a person in the loop

Chose: flags go to manual reviewGave up: automatic removal

A wrong landmark makes pickups worse, not neutral. There's no data yet on how reliable driver flags are, so nothing is removed automatically.

How I'd measure it: pickup-related calls per trip, split by pickup type, because calls are the workaround this product replaces. The rollback trigger is a rise in calls compared with a control group. I chose calls over time-to-pickup because traffic and distance make time a noisier signal. Baselines and targets are "TBD" until a beta measures them.

Still open: I only researched riders, so driver research is a known gap. And 12 people is enough to find a direction, not to size it, so the beta is limited to a few cities.

Next case study
OutloudRead →