Team Norms:
- Text your team if you are going to be late
- Set Routine Meeting in person:
- Send When2Meet to find weekly meeting (1.5hrs)
- Open and over communication
- Team Check-in 5 days and 1 day before deadline
- Set roles/task on assignments
Affinity Map:
AI Second Pass Notes:
1. Alignment is most of the job, and it is done by hand
Every function has different goals, vocabulary, and incentives, and getting everyone to the same understanding takes constant manual effort.
- Erin: Same terms mean different things; even the same message from leaders gets interpreted differently. Lots of Slack, Doc comments, ad hoc Zoom. Designers missed the kickoff, so context was rebuilt afterward.
- Lucy: Alignment is one of her biggest jobs; approvals sound trivial but are hard. Primes herself before each meeting, states what makes the meeting a success, and notes that unaligned people often don’t say so.
- Thomas: Bad days come from stakeholders wanting different things. Falls back to the underlying problem instead of arguing solutions.
- Evan: “You can’t overcommunicate.” Weekly check-ins and two engineering standups a week.
- Myan: Concept review exists to confirm product, eng, and design agree on what will be built.
- Maria: Much of the work was educating people and getting them to build with her.
- Pragya: Hard to know whether you really understand where the other side is coming from (the orange story).
- Will: Needs clear ownership and a single point of contact; translates technical limits across teams.
- Isabella: Every decision carries invisible context from eng, research, legal, and leadership.
2. A good day is visible progress plus shared understanding
People describe good days the same way: something unclear becomes clear, the team is on the same page, and users react well.
- Thomas: A good day is when an unclear problem becomes clear enough to act on, with eng, design, and product aligned; customer reactions are rewarding.
- Myan: Productive days show forward progress; a balance of meetings and uninterrupted time; positive user feedback after a release is the most rewarding part.
- Maria: Positive customer feedback and the feeling of being on the same page.
3. Meetings crowd out the work, and the work moves to evenings
Meetings are mostly for gaining context, and focused work gets pushed to off-hours. Replacing meetings with async creates its own overload.
- Will: About eight hours of meetings in a day, mostly absorbing information.
- Lucy: “A crap ton of meetings”; schedules focus time in the evenings for PRDs, design, and code.
- Pragya: Works an hour or two at night to read and write; splits mornings (strategy) and afternoons (1:1s).
- Myan: Too many meetings leave no work time and mean staying later; heavy Slack is not a fix.
- Erin: The bulk of the work happens outside formal meetings, in Slack and Docs; meetings are used to push decisions.
- Maria: Bad days were admin spinning-the-wheels days.
4. Other teams’ changes and constraints surface late
Problems come from outside the PM’s own view: another team’s release, legal or compliance, suppliers, or engineering cost.
- Myan: A billing team’s release broke a feature that relied on older code; users reported it before the team found the cause.
- Will: One supplier slipping on GPUs can fail the whole schedule; features trade off against power and heat.
- Erin: Legal and compliance issues appear midway; different legal partners interpret the same thing differently. Hack: bring legal in earlier next time.
- Pragya: Her team sits between infrastructure and application teams; changes need both. “Changing the engine of the plane while flying it.”
- Thomas: Customer wants a feature, engineering says it’s expensive.
- Isabella: Constraints from eng cost, research, legal, and leadership metrics.
5. Information and context are scattered; AI helps when it sits where the context already lives
Decisions, research, and notes sit across docs, Slack, tickets, and heads. Tools differ by function. The AI tools people like are the ones already attached to their documents.
- Isabella: Context is in docs, notes, Slack, reports, and memory; she reconstructs the story each time. History of why decisions were made lives in people’s heads and is lost when people switch teams. Wishes for a “product memory.”
- Erin: Designers in Figma, researchers in Docs, GitHub rising; commenting and narrative context vary by tool. Docs is the common denominator. Thinks Claude with connectors could be a shared layer but hasn’t tried it.
- Myan: Tracks tasks, tickets, Slack channels, follow-ups, and other teams’ work; works best when information is visually separated. Notion AI works because docs and notes are already in Notion.
- Pragya: Sana Agent works partly because it has Workday knowledge and context.
- Lucy: Internal LinkedIn AI tools pull in company context; she joined an initiative to build a shared-context tool. External tools are restricted.
- Evan: Confluence, Google Docs, Grafana in parallel.
- Will: Docs and Excel, with Gemini or Copilot generating tables, timelines, and slides.
6. AI gets you most of the way; humans re-check, and stakes decide how much
People use AI for notes, drafts, research, and prototypes, and nearly everyone reviews the output. The tolerance depends on whether the cost of error is high.
- Pragya: Three months of work down to two weeks, about 80% of the way; still reviews AI meeting notes for accuracy and tone. Payroll needs 100% accuracy, so AI is limited there (probabilistic vs deterministic).
- Erin: AI gets her roughly an 80% answer faster, but gives an amalgamated view.
- Lucy: Drafts first, has Copilot refine, then rereads; at least two rounds of checking. Built a custom skill to sound like herself.
- Isabella: Trusts AI for brainstorming and summarizing, much less for facts; spends the saved time checking whether the AI removed something or assumed something false. Prototypes are good enough to show an idea, not to ship.
- Myan: Uses AI to review PRDs and tickets from an engineer’s or designer’s perspective; retrieves sources during scoping.
- Will: Main advantages are meeting notes and email summaries.
- Maria: Delegating too much creates “slop”; use AI to augment capacity, not to make decisions.
7. Cheap building pulls people into solution mode and away from the customer
AI makes it fast to produce something polished, which shifts conversations from “should we build this?” to “how do we improve it?”, and tempts teams to skip real users.
- Isabella: A polished prototype makes people discuss button placement before asking whether to build; she gets attached to what she built. Wants a tool that asks “what user need does this connect to?” (productive friction) and pushes back like a skeptical partner.
- Erin: A PM asked why talk to customers if an AI persona has all the answers. Hope that personas can shortcut the say-do gap and recruiting.
- Maria: Discovery of customer needs should stay with a human PM; decision-making should not be delegated.
- Lucy: “Product managers are actually problem managers”; understand the problem before the solution.
- Thomas: When teams disagree, go back to the problem instead of defending a solution.
8. Summaries capture what was said, not what mattered
AI notes and summaries remove the capture burden but leave the judgment problem: which decision, which signal, which assumption changed.
- Isabella: Hundreds of meeting summaries, but three weeks later she still doesn’t know what was decided, who disagreed, or what to revisit. Summaries flatten a comment from the biggest customer and one random interview into two bullets.
- Pragya: Relies on Sana for notes, which removes cognitive load, but still checks before sending.
- Myan: Notion AI for notes, summaries, and documentation.
- Will: Also gets email summaries; previously triaged by category (Action Required, Information Only, Need Follow-Up).
9. Prioritizing across conflicting inputs has no objectively right answer
PMs weigh urgent customers, sales, engineering cost, research, and leadership direction, and often have to decide with incomplete information.
- Thomas: Is this one customer’s request or a roadmap-level problem? After Dreamforce, separating important feedback from noise. Meetings sometimes end without an answer.
- Isabella: Customer, sales, eng, research, and leadership all pull differently; the best decision is sometimes not to build.
- Myan: Triages incoming feature requests and bugs: valid or not, priority, whether eng or design is needed.
- Will: Prioritizes problems as P0/P1/P2 and presents alternatives to leadership.
10. The PM role changes by company, domain, and stage
Several people say there is no single definition of the job, and responsibilities shift with the organization.
- Will: Tesla is engineering-led, Google is product-led; authority and responsibility don’t always match.
- Pragya: At one company PM and project management were intertwined; at Workday they’re not. Startups mean many hats.
- Maria: In London fintech there was no playbook for PM and she had to educate people on what it meant.
- Myan: PMs also do QA because there is no dedicated QA team; still unclear after CS 177 what PMs do across companies.
- Erin: Didn’t understand PM, XD, and PD roles until years at Intuit.
- Evan: Project work was largely siloed, with limited cross-functional collaboration.
11. Everyone ends at human judgment as what stays valuable
When asked about the future, people converge on critical thinking, human connection, and deciding what not to build.
- Pragya: Human skills and business influence matter more as you get senior; optimistic that good PMs will command a premium.
- Maria: The PM function of connecting parts of the business will persist.
- Erin: Critical thinking and spending time with real, messy people.
- Lucy: Judgment in rereading and owning how your communication lands.
- Isabella: The next step for AI is helping people make better decisions around outputs, not just producing them.
Mentioned by only one person
- Isabella: AI changes more than asked and doesn’t know which parts you consider locked.
- Pragya: Almost no overlap hours with a team in India; PMs anxious about how fast AI tools change and which to learn; “high-agency” PMs treat AI skill like critical thinking.
- Lucy: Balancing AI writing features with anti-AI sentiment from users.
- Thomas: In B2B you also think about your customer’s customer.
- Evan: At very large scale a 0.01% drop is treated as harmful.
- Myan: Hybrid schedule: in-office days make quick questions easier.
- Will: Hardware stages (prototype, EVT, DVT, PVT) change specs and timelines as they go.
Additional Questions:
- What did it catch that we missed?
AI caught a pattern that we originally did in the affinity map: a good day is visible progress plus shared understanding (Thomas, Myan, Maria). It also found that “changes and constraints from other teams come too late” actually appeared in six out of nine people (Myan, Will, Erin, Pragya, Thomas, Isabella), while we originally only noticed one person and even categorized Pragya’s version under communication. Overall, AI’s categorization was more fine-grained. But its “only one person mentioned it” section is a double-edged sword, because when summarizing pain points, we need the strongest signals more.
- What did it flatten into something generic?
It merged “information/context is scattered” and “tool/platform fragmentation” into the same pattern, but these are two different problems: the former is more organizational, while the latter is more tool-related. The ways of addressing them are different, and combining them together affects how we handle the pain points that need to be solved.
- Did it assert anything that isn’t in the transcripts?
It didn’t assert anything that is not in the transcripts, but it did not process the audio we uploaded and did not inform us about it.
Long List:
| # | Candidate problem | Raised by (of 11) | Existing hack | Anonymized quote |
| 1 | Cross-functional alignment: same words, different meanings; approvals are hard to get | 8 (Erin, Lucy, Thomas, Myan, Maria, Pragya; soft: Evan, Will) | Slack and Doc comments; agendas with a “this meeting succeeds if X” line; concept-review meetings; “put it on paper so people can respond” | “Even when we hear the same thing from the same leaders, we may interpret it differently.” |
| 2 | Meeting overload, no deep-work time; real work moves to evenings | 4 (Will, Lucy, Pragya, Myan; soft: Maria) | Evening focus blocks; mornings for stakeholders, afternoons for 1:1s; AI note-takers | “If you spend eight hours in meetings, when are you going to do your actual work?” |
| 3 | Hidden dependencies and unknown unknowns (another team’s release, legal, suppliers) | 4 (Myan, Will, Erin, Pragya) | Bring legal in early; roadmap review sessions. Mostly reactive. | “Usually it’s the unknown unknowns that pop up.” |
| 4 | AI output must be re-verified (hallucination, wrong voice, dropped constraints) | 6 (Pragya, Lucy, Isabella, Erin, Maria, Juergen) | Human review passes; draft first, then refine; human-in-the-loop guardrails | “I don’t feel comfortable just sending the notes as-is.” |
| 5 | Telling signal from noise across conflicting inputs (customers, sales, eng, research) | 5 (Thomas, Isabella, Myan, Will, Juergen) | Triage; “go back to the actual problem”; manually reconstructing the story; AI summaries (which flatten) | “Sometimes I don’t need a shorter summary. I need help understanding which signals actually matter.” |
| 6 | Scattered context and lost decision history; the “why” lives in people’s heads | 3 (Isabella, Erin, Myan; soft: Lucy) | Notion; Google Docs as common denominator; manual reconstruction | “A lot of that history lives in people’s heads.” |
| 7 | AI pulls teams into solution mode and away from customer discovery | 3 (Isabella, Erin, Maria; soft: Lucy, Thomas) | Discipline only: stay in the problem space; insist on real user contact | “Why even talk to customers if this already has all the answers?” |
| 8 | Tool fragmentation across functions | 4 (Erin, Isabella, Myan, Lucy) | Pick one lowest-common-denominator tool (Docs) | “There are a lot of surfaces to keep up with.” |
| 9 | AI tools lack control: change more than asked, forget locked decisions | 1 (Isabella; Lucy’s custom voice skill is a related hack) | Remember each version yourself and re-prompt the constraints | “It’s really good at executing what I ask for, but it doesn’t always know what I actually need.” |
TAM for the PM market:
While our interviewees were unable to give exact cost spent on specific tools, the team was able to make an estimate of the amount of money spent by the PM based on the time they spend on the meetings and learning new tools. Since the main problems we identified surrounded team cross-communication, that is how we will build our estimate. We estimated around 4 hours spent on meetings + 1 hour spent learning AI tools, for 3 days out of the work week. Based on Indeed an average PM salary is $136,464. This means that roughly $984.12 is spent per week and for the 52 weeks in the year equates to around $51,200.
Comparing cold and round 2 interviews:
Our round 2 interviews allowed us the opportunity to delve deeper into subjects that we scratched the surface of during our cold interviews. As opposed to first finding out large problems of the cold interviews, we were able to elaborate more deeply and ask more unique questions to understand the root of some of these problems more intricately. One idea from this week’s reading we used was asking our interviewees about asking them open questions instead of closed questions. These questions allow interviewees to walk us through a story and explain relevant details instead of just answering “Yes”/”No” to a question. An example of an open-ended question is “Walk me through your day-to-day workflow”.
