Your first Monday
Lesson 1 of 24, level 01Index
The founder forwards you 200 app store reviews with the message “what should we fix?” and nothing else. No brief, no context, no meeting. It is 9:40am on your first day.
Your desk, 9:40am.
Maya, founder
Forwarded you the reviews. What should we fix? Need a view by Friday, I present to the board Monday.
Dev, engineering lead
Heads up, we are mid-sprint until Thursday. Happy to talk after, but please do not add anything before then.
Priya, support
I have opinions. 400 tickets this month and I think it is all the same three things. Coffee?
What a product manager actually does
A product manager decides what gets built and why. You own the problem and the priority. You do not own the design, the code, or the people writing it.
Which means everything you get done, you get done by being the person with the clearest picture of reality in the room. Not by instructing anyone. That is the whole job, and it is why the first move is always to go and look.
The trap on day one is to have ideas. You have not earned an idea yet. What you have is a pile of raw signal, and the skill is collapsing it into a small number of claims you can point at evidence to defend.
- Signal
- Raw, unstructured, mostly noise. Reviews, tickets, calls, session recordings.
- Cluster
- The same complaint said forty different ways. Grouping is where judgement enters.
- Claim
- One sentence you would defend in front of the founder, with a quote behind it.
Your first useful contribution is a claim someone else can inspect. Treat the review pile as an evidence problem before treating it as a feature backlog.
Use your chosen course project throughout. The additional examples below are fictional practice cases; transfer the method to your own evidence.
Separate observation from interpretation
An observation is something you can point at: a review says the second account never appears. “Users do not trust us” is an interpretation. Keep the quote, source identifier and date in one column, then your interpretation in another. This lets a colleague disagree with your explanation without disputing that the event occurred.
Use a denominator before a ranking
Twenty complaints might represent one loud customer, one bank integration or twenty independent failures. Deduplicate people and distinguish reports from affected users. A frequency ranking without a population definition can promote the easiest problem to complain about rather than the most expensive problem to have.
Recommend the next decision
Your first memo need not name a finished solution. It can ask for one day to inspect failed callbacks because that investigation distinguishes an integration bug from a confusing interface. State the evidence you have, what it cannot establish, the cheapest next check and the person who can run it. That is progress a founder can approve.
From a report to a defensible next step
- Report: Exact source quote
- Check: Unique incident
- Claim: Narrow interpretation
- Next move: A disconfirming check
How Slack handled it
Slack
2013
Slack began as Glitch, a multiplayer game that failed. The team had built an internal chat tool to coordinate their own work and noticed they could not stop using it.
Stewart Butterfield killed the game and shipped the internal tool. Before launch they did not run a survey. They got a handful of friendly companies to use it and watched, obsessively, for the moment a team stopped being able to work without it. That threshold became their activation metric: 2,000 messages sent.
Nobody handed Slack a brief either. The signal was already inside the company and someone had to notice it, then be willing to throw away a year of work. Your first job is not to have ideas. It is to see what is already there.
Doing it with AI, and where it breaks
Paste all 200 reviews into a model and ask for a structured extraction: one row per review with a problem label, a severity guess, and the exact quote preserved. Then sort by label and count.
The model merges complaints that share vocabulary but not cause. “Cannot log in” and “app logs me out constantly” become one cluster, but one is an onboarding failure and the other a session bug, and they go to different teams. Hand read 20 rows and find the merged cluster. There is always at least one.
Your AI workbench
Start with your own notes or clearly labelled practice data. Remove private details before sharing. Replace the placeholders, run the prompt in your chosen AI tool, and keep the output beside its source.
Act as an evidence analyst. I will provide anonymised feedback with source IDs. Return one row per distinct reported incident: source ID, exact quote, observed behaviour, interpretation, missing context. Do not infer frequency beyond the supplied sample. Mark unsupported causes as hypotheses. Then propose the smallest check that could disprove each interpretation. Ask for the feedback before starting.
Before you use the output
- Check five quotes against their sources
- count unique incidents rather than rows
- remove any claim whose evidence cannot be opened.
Stuck? Try this next
If the model gives a polished summary, ask it to reconstruct the table with exact source IDs. If it cannot, restart with smaller batches rather than accepting the prose.
Keep a brief AI log: input used, useful output, what you checked, and what you rejected. The decision remains yours.
Build it
A ranked one page memo: what is broken, for whom, and what you would do first.
Claude or ChatGPTGoogle Sheets
The worked solution
Stuck, or want to compare?
There is a worked solution. Try the build first. Reading it before you have attempted anything is the fastest way to learn nothing.
Checkpoint
If you did the build, these take two minutes. If you cannot answer one of them, that is the part to go back to.
Moving on marks this lesson complete. Finish the build first, it is the part that counts.