This is applicable if you are looking for Product Management roles, Program Management Roles, or Business/Ops/Strategy Roles
Imagine you are a product manager at a fintech app that gives small personal loans.
It is Monday morning. Big meeting with the CEO.
Your director is going through your weekly update in front of everyone. She tells the CEO that one of your features is ready.
Then your phone buzzes. It is the data science lead. That feature is not ready. It broke on Thursday night.
Your director has already moved on. The whole room now believes something that is not true. And it came from your update.
Here is the worst part. You did not even write that update. Your AI did. It writes it on its own every Friday. Last week, you were proud of that.
You use the same ChatGPT and Claude as everyone else. So what went wrong?
Let us go back two weeks.
Your app has one big problem. To get a loan, people upload their bank statement and type in their salary. Then they wait up to 24 hours for someone to check it. This is step 4 of the application, and 41% of people give up right here. Some of them needed that money the same week, for a hospital bill or a school fee.
Your plan is simple. Use AI to read the bank statement and fill in the salary in a few seconds. No waiting. You write the PRD. You also run the whole project with four teams.
Over the next two weeks, seven things will go wrong. Each one teaches you one AI skill. Most people learn only the first one, and then say AI is overrated.
PM, program manager, TPM, data scientist or engineer, the skills are the same for you. Each section ends with what it means for your role.
Skill 1: Prompting
This is what you see: Monday evening. Your VP wants the PRD by Friday. You open Claude and type one line.
Write a PRD for an AI feature that reads bank statements in our loan app.Ten seconds later, four neat pages. Personas, goals, metrics. You feel relief. Then you actually read it.
The personas are Busy Professional and First-Time Borrower. The main goal is to improve user experience. It does not know about step 4. It does not know about the 41%. It could be a PRD for any lending app in India. Your VP would see through it in one minute.
This is what you learn: the AI did exactly what you asked. You asked for a PRD. You never told it which one. A good prompt has four parts. Instruction: what you want. Context: what it cannot guess. Constraints: length, format and tone. Example: what good looks like.
This is what you do: same request, now in four parts.
Instruction: Draft the problem, goals and solution sections of a PRD.
Context: We are a personal loan app. Last month 1,20,000 users started an application and 38,000 finished. At step 4, users upload a bank statement, type their salary and wait up to 24 hours for ops to verify. 41% of users who reach step 4 leave. The new feature: a model reads the statement and fills in the income.
Constraints: Max 2 pages. Every goal must have a number. No personas. Add a section on what happens when the model is not sure. List open questions at the end.
Example: Attached is our UPI autopay PRD. My VP approved it in one round. Match its structure and depth.Now the first line of the draft is about step 4. The goal reads: cut step 4 drop-off from 41% to 25%. There is a section on what happens when the model is not sure.
Of the four parts, the example does the heaviest lifting. It carries your company’s standard without you having to explain it. So keep your two or three best approved documents in one folder. You will use them again and again.
A bad answer is usually a bad question.
For your role: a program manager attaches last quarter’s best status report as the example. A data scientist attaches the eval report the team liked.
Skill 2: Make AI disagree with you
This is what you see: Tuesday, you get a big idea. If the model is confident about the income, skip the ops check fully. No 24-hour wait at all. You ask Claude if this is a good idea.
It says yes. Five benefits. Faster approvals, lower ops cost, happier users. You walk into Thursday’s review feeling sharp.
The risk head asks two questions.
How often does the model read a transfer from a friend as salary?
What is the error rate on scanned PDFs from smaller banks?
The room goes quiet. You look at your laptop as if the answer might be there. It is not. The idea goes back.
This is what you learn: AI agrees with you by default. This is called sycophancy. Models are trained partly on human ratings, and people tend to rate answers that agree with them higher. Anthropic’s 2023 research found this pattern in five leading AI assistants. So when you ask whether your idea is good, you are asking something that already leans towards yes.
This is what you do: you save a reviewer instruction in your project, so it applies to every chat.
You are my reviewer, not my supporter.
1. Before you agree with anything, name the one assumption I have not tested.
2. Argue the strongest case against my plan first. Do not soften it.
3. If I push back, change your view only if I give new evidence, not because I objected.
4. If you cannot find a real flaw, say so. Do not invent one.
5. End with the one question my toughest stakeholder will ask.That evening, you run the same idea through it. The first line back: you are assuming a high confidence score means the income is correct, and you have no data on how often a confident answer is wrong.
It is the risk head’s question, almost word for word. Two days too late this time. Never again.
One caution. The pushback is useful, but any fact inside it still needs checking. If it quotes a number, ask where that number came from.
If your AI never disagrees with you, it is not reviewing your work.
For your role: a program manager runs the launch plan through it before the steering committee. An engineer runs the design doc through it before the architecture review.
Our next AI Product Manager & Builder Cohort is starting. For an early-bird discount, you can fill out the form here: AI PM Builder Cohort
[Alumni Shipping at Google, Microsoft, Uber]
Skill 3: Context engineering
This is what you see: Thursday night, 10 PM. You have opened eleven chats this week. In every one, you pasted the same paragraph. Loan app. Step 4. 41% drop. 24-hour ops check. My VP hates long documents. Risk signs off on anything with income data.
On the days you were tired and skipped it, the answers went generic again. You are explaining your own product to a machine for the eleventh time.
This is what you learn: the fix in skill 1 was never really about the prompt. It was about the context. Most of what AI needs is in your head, not in the chat. This is why people now call it context engineering. Write it once in a plain text file. Most AI tools let you attach a file like this to a project, so every chat inside it starts with it.
This is what you do: you do not write the file yourself. You let AI interview you.
Interview me to build a context file about my work.
Ask one question at a time, 30 questions in total.
Cover my product, users, metrics, stakeholders, how my manager likes documents, and what I never want to see.
If my answer is vague, ask me for a real example.
At the end, put everything into context.md.Twenty minutes later, you have this.
# context.md
## Product
Personal loans from Rs 20,000 to Rs 3 lakh. Android first.
Funnel: 1,20,000 starts a month, 38,000 completed. Worst step: step 4, income proof.
In progress: a model that reads bank statements and fills in income.
## Users
Salaried, 24 to 35, mostly tier 2 cities. Many on low-end phones and patchy data.
## Stakeholders
VP Product: wants one recommendation, not options. One page max.
Risk head: signs off on anything touching income or credit data.
Data science lead: reports accuracy on a fixed test set of 2,000 statements.
## What I reject
No personas in PRDs.
No goal without a number.
No bullet-point emails to my VP. She reads prose.Look at the last section. It does more work than everything above it. Saying you like clear writing tells the model nothing. Saying no goal without a number changes every draft it writes.
Explain yourself once. Not every morning.
For your role: a program manager adds team owners, escalation paths and the meeting calendar. A TPM adds the system names and which team owns which service.
Skill 4: Connect AI to the apps you already use
This is what you see: Friday, 7 PM. The office is almost empty. Your friends are already at dinner, and the WhatsApp group will not stop buzzing.
You are still on the weekly program update. Jira for the onboarding and data science tickets. Three Slack channels for what Risk and payments said. The launch tracker sheet in Drive. Copy everything into Claude. Copy the summary into an email. Two and a half hours so far, and half of it was copy and paste.
This is what you learn: your context file covers what is in your head. It does not cover what is in your apps. Connectors let AI read from Jira, Slack, Drive, Gmail and your calendar directly, and in some cases act inside them. Most of them run on MCP, which we covered in the last article. Once AI can reach your tools, you stop feeding it data. You give it a goal.
This is what you do: you switch on the Jira, Slack and Google Drive connectors. Then you write the goal, not the steps.
Using Jira, Slack and the Launch Tracker sheet in Drive:
1. List every ticket in LOAN-ONB and LOAN-DS that changed status this week.
2. Find messages in #loan-risk and #loan-payments that mention a delay or a blocker.
3. Write the weekly update: what shipped, what slipped and why, top 3 risks, and asks from leadership.The draft comes back in eight minutes. You read it, fix two lines and hit send. You still make it to dinner.
One rule here. Start with read-only access. AI connected to Slack can see every channel you can see. Let it send messages or move tickets only after you have watched it read correctly for a few weeks.
If you are copying and pasting into AI, you are still doing the AI’s job.
For your role: an engineer connects GitHub and the error logs. A data scientist connects the data warehouse, so AI runs the query instead of you pasting a CSV.
Skill 5: Automate your work without code
This is what you see: Saturday morning. Your director replies to the update, on the thread with all four team leads. This format is different from last week. Risks come first, and the asks are missing. Please keep it the same every week. I compare them side by side.
It is a small thing. It still stings because everyone saw it. And you know why it happened. You typed the prompt again from memory, a little differently this time.
This is what you learn: a task you repeat should not be a prompt you retype. It should be a skill. A skill is a saved file with the steps, the format and the rules, which the AI loads whenever that task comes up. Once a task is a skill, you can schedule it to run on its own. Neither needs any code.
Pick the task carefully. It should repeat, follow the same steps every time, and mostly not need your taste. The weekly update fits. The PRD does not.
This is what you do: on Monday, you ask Claude to turn Friday’s chat into a skill. You get a file like this.
# weekly-program-update/SKILL.md
When to use: every Friday, for the loan application program update.
Steps:
1. Pull this week's status changes from Jira projects LOAN-ONB and LOAN-DS.
2. Pull messages that mention delay, blocker or slip from #loan-risk and #loan-payments.
3. Read milestone dates from the Launch Tracker sheet.
Format, always in this order:
1. Shipped this week
2. Slipped, with the reason and the new date
3. Top 3 risks
4. Asks from leadership
Rules:
Max 300 words. Prose, no tables.
Mark the risk section DRAFT for me to edit.Then you schedule it. Every Friday at 3 PM, run weekly-program-update and send the draft to me.
The next Friday, the draft is waiting at 3 PM. You edit only the risks. You leave the office at 6 for the first time in months. You even tell a friend that your weekly update now writes itself.
Automate the gathering. Keep the judgment. Only you know which delay will worry your VP.
For your role: a data scientist turns the weekly model metrics report into a skill. A TPM turns the release notes into one.
Skill 6: Loop engineering
This is what you see: this is the Monday from the start of this article. Your director reads out that the scanned PDF parser has shipped. Your phone buzzes. The ticket was reopened on Thursday night, after the parser failed on statements from two smaller banks.
Why did your skill miss it? It saw the ticket move to Done on Tuesday and listed it as shipped. It never checked where the ticket stands now. A skill runs each step once and trusts the first answer. Nothing in it checks the work.
This is what you learn: a skill does the task once. A loop does the task, checks it, and tries again until it passes or hits a limit. In June 2026, Boris Cherny, who created Claude Code, said on stage that he no longer prompts Claude. He writes loops that do the prompting, and writing those loops is now his job. He was talking about code, but the shape works for any task you repeat. Do the work. Check it. Retry once. Stop and hand over to a human.
This is what you do: you add a check block to the same skill, in plain English.
Check before sending:
1. For every item under Shipped, open the ticket again and confirm its status is Done right now.
2. Match every date under Slipped against the Launch Tracker sheet.
3. If anything does not match, fix it and run the check once more.
4. If it still does not match, do not send to the group. Mark the item NEEDS YOUR CHECK and send the draft only to me.The next Friday, the check catches two tickets that were reopened on Thursday. The update flags them before anyone reads them out loud.
Notice who wrote the check. Only you know which mistake hurts most. For a weekly update, it is a wrong status in front of leadership. So that is the first thing the check looks at.
Automation without a check only helps you make mistakes faster.
For your role: an engineer’s loop is write the code, run the tests, fix, run again until they pass. A data scientist’s loop is run the eval set every night and flag any drop above 2%.
Skill 7: Learn anything with AI, on your own problem
This is what you see: the same week, data science sends a note. On their test set of 2,000 statements, the model has 96% precision and 82% coverage at a confidence threshold of 0.9. They want to lower it to 0.8. Coverage goes up to 90%. Precision drops to 93%. They need your sign-off by Wednesday.
In the meeting, you nod. Everyone nods. You are not sure anyone in the room really understood. And if you sign and it goes wrong, it is your name on it.
This is what you learn: the new default is to ask AI first, before a colleague or a search engine. But a definition is not what you need. A search for precision gives you a textbook example about cats and dogs, and you still will not know whether to sign. You need the idea explained on your own numbers, ending in your own decision. Your AI already has your context file, so it can do exactly that.
This is what you do:
Data science wants to move our income model's threshold from 0.9 to 0.8. Their note is attached.
1. Explain precision and coverage using our step 4 funnel, not a textbook example.
2. Tell me what the change does to wrong incomes and to statements sent to ops.
3. Give me 3 questions to ask the team before I sign off.
4. Then quiz me with 3 questions to check I understood.
5. For every claim, point to the line in their note you are using.The answer is simple. At 0.9, out of 2,000 statements, the model fills in 1,640 and gets about 66 of them wrong. At 0.8, it fills in 1,800 and gets about 126 wrong. So 160 more users skip the 24-hour wait, and 60 more wrong incomes go into credit decisions.
Now it is not a vocabulary problem. It is a product decision, and you can make it.
You walk into Wednesday with three questions. What does risk do when an income is wrong? Does the test set include scanned statements from small banks, the same ones that broke the parser? How many of those 160 users would have left while waiting for ops?
The data science lead pauses, and says that is a good question. Twice.
Do not learn the definition. Learn the decision.
For your role: a program manager uses this to understand a vendor contract before signing it. An engineer uses it to learn a new framework on the team’s own codebase.
Two weeks later
Two weeks ago, you typed one line into Claude and nearly sent a PRD that could belong to any company.
Today, the same Claude knows your product. It argues with you. It reads your Jira. It writes your Friday update and checks its own work before anyone else sees it.
You did not get a better tool. You got better at using the one you had.
This is exactly how we teach in the AI PM Builder Cohort. One real problem, built step by step, until it works.
About Author
Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking.
AI Learning Resources
12 Weeks LIVE AI PM Cohort (Alumni now ship AI at Google/Microsoft, etc)
Self-Paced AI PM Cohort Recordings (65 Hours of Content) | Use AIBUILDER20 for 20% Discount [Alumni Shipping at Google, Microsoft, Uber]
Quick AI PM Course (20 Hours of Content) [Rated 4.9/5 from 1000+ Product Managers from Google, Coinbase, Microsoft, etc]
AI Program Management Course (For Program Managers and TPMs)
AI Business Course (For General Management, Biz Ops & Strategy Roles)