Team norms:
- Clear communication (on work progress, deadlines, etc)
- Be responsive in responding to text messages in the group chat
- Consensus for most decisions, unless in a rush/your own component
New questions:
- What are specific pain points or challenges that you came across?
- How do you think AI can support PMs, and how is it changing the industry?
- How do PMs make decisions under ambiguity and get other people to act on those decisions when they don’t have direct authority?
- How do you know when you have enough information to stop researching and just make a decision?
- When you receive conflicting feedback from several people, how do you decide what to ignore?
- How do you keep track of all the assumptions behind a decision?
Affinity map (by hand, first).
AI second pass.
Our map came had two clusters: decisions under uncertainty and conflicting stakeholder perspectives. The AI found four more patterns across influencing without authority, meetings crowding out focused work, onboarding into scattered context, and urgent work pushing out important work. It also noted the workarounds PMs already use, such as building a cheap prototype when being wrong is cheap or asking an internal chatbot for context. Those workarounds are strong signals of real pain, and our map didn’t capture any of them. Additionally, our sticky notes kept distinct kinds of uncertainty separate: new information arriving mid-decision, choosing whether to iterate or kill or invest, and judging whether a change for one customer is worth it. The AI merged all of these into one broad “ambiguity” theme. It also absorbed “unclear decision ownership” into general alignment problems, and it reduced the idea that a hardware product has several customers (the buyer, the construction company and the field worker) to ordinary stakeholder management while our map treated that as its own insight. Did it assert anything that isn’t in the transcripts? Yes, in a few places. The AI said most interviewees struggled with deciding under uncertainty. For some of them that was a stretch – a PM saying they prefer data, or describing a test that wasn’t statistically significant, isn’t the same as reporting this pain. It also treated a “single source of truth” as a broad need when only one interviewee asked for it, and it labeled some offhand comments as workarounds when the interviewee never described them that way.
Long list.
| # | Candidate problem | People | Did / Said | Anonymized quote |
| 1 | PM work is extremely communication-heavy and meeting-heavy | 6/6 | Did/Said | “Looking at the schedules of more established PMs, I’m guessing it goes up to four or five hours a day in meetings.” |
| 2 | Aligning people with different goals, expertise, and opinions is difficult | 6/6 | Did/Said | “A big part of their role is morale… getting the engineers excited about your product and getting other teams excited about it.” |
| 3 | PMs constantly have to decide what deserves attention with limited time/resources | 6/6 | Did/Said | “Prioritizing has been another one: making sure I’m doing the most important, urgent thing at any given time.” |
| 4 | PMs often have to make decisions with incomplete or ambiguous information | 5/6 | Did/Said | “Whatever decision we make isn’t going to be perfect, so we have to use the limited data we have to make the best decision possible.” |
| 5 | It is easy to spend significant effort before realizing an assumption was wrong | 5/6 | Did/Said | “Finding out we’re wrong early is actually a really good outcome.” |
| 6 | PMs must translate and filter information between people with different expertise | 5/6 | Did/Said | “The customer tells you what problem they have, but they cannot always tell you technically what the solution should be.” |
| 7 | Rapid prototyping can help PMs test ideas quickly and find problems early but It comes with no clear direction | 5/6 | Did/Said | “Rapid prototyping is a good idea because it lets us test the idea quickly before spending too much time building it. But we often have no direction” |
TAM: The PM Market
LinkedIn data shows over 2.6 million people worldwide who list “Product Manager” as their title (Productify). Prices for PM software vary a lot. Jira Premium costs about $14.54 per user per month (Automation Atlas). Productboard Pro costs $59 per maker per month on annual billing, and enterprise deals run closer to $300 to $400 per maker (Featurebase). We assume a blended $40 per PM per month, so 2.6M PMs × $40 × 12 months ≈ $1.3B a year for PM-specific software.
Reflection
Our cold interviews were broad and conversational. Many of the PMs we started with were people we already knew, so the conversations tended to drift into career paths and small talk and the most useful insights were often ones interviewees offered on their own rather than ones we went looking for. In round 2, we were more structured and consistent. We asked everyone the same core questions so we could compare answers across people and companies, and we also turned themes from the first round into hypotheses to test. When early interviews pointed to ambiguity and building buy-in as central to the job, we asked later interviewees about those themes directly and checked whether their experiences matched, and as a result of that our follow-up questions improved too. Instead of collecting general descriptions of the role, we pushed for concrete examples of how PMs actually make decisions and handle setbacks. Of course we still have room to grow as we sometimes framed questions around our own assumptions in ways that could steer the answer, and a few conversations drifted away from the PM’s day-to-day work, but it was overall a huge improvement from week 1’s interviews.
One idea from this week’s reading
This week’s reading on story-based customer interviews changed how we asked questions. We realized that direct questions about what someone likes or how they usually work tend to get idealized answers, while asking for a specific recent story grounds the conversation in what people actually did so we moved away from general prompts about the PM role and asked interviewees to walk us through particular decisions or setbacks. Those stories helped bring out out context that general questions had missed, including who was involved, what got in the way and how the decision finally got made, and the reading also helped us notice when an interviewee drifted into generalizations, and to steer them back to the specific example when that happens.
