Team 8: Natnael Tadesse, Christian Roy, Efrain Angon-Cruz, Liam Custer
Team Norms
These are the norms for how we work with each other:
- Communicate early and often: If someone’s stuck, falling behind, or can’t make something, they say so in the group chat right away instead of going quiet.
- Make sure feedback actually lands: When we give each other feedback, we check that the other person understood what we meant, not just that we said it.
- Don’t yuck my yum: Nobody shoots down an idea just because it’s not their thing. We hear it out first.
- Meet in the middle: We don’t all communicate the same way, so we each try to come toward the center instead of expecting everyone else to adjust to us.
- It’s okay to challenge each other: Pushing back on an idea or a clustering choice is normal and not personal. When we disagree, we go back to what’s actually in the interviews.
Interview Norms
These are the norms we agreed on for how we interview and how we handle what we collect:
- Ask about specific things that already happened (“tell me about the last time…”), not hypotheticals or what they usually do.
- Don’t pitch our ideas or solutions during interviews. We’re there to listen.
- Use the same follow-ups on every answer so we all dig the same way.
- Ask before recording. If they say no, take detailed notes instead.
- Raw transcripts and notes stay in our team Drive. The blog only gets anonymized quotes (PM A, PM B, etc.), no names or companies.
- Make the affinity map by hand before giving anything to AI, so the AI doesn’t shape how we first read the interviews.
- When we write things up, keep what people said separate from what they actually did.
Struggles from our cold interviews
Before round 2 we went through our cold interviews (PMs A, B, C and D) and listed what kept coming up:
- Coordination, status tracking and meetings eat a lot of the day.
- PRDs and specs go through a lot of rounds before they’re approved, and handing them off to eng and design causes friction.
- Unclear scope leads to rework. One PM had a week of design work thrown out because nobody checked scope until it was done.
- PMs need a lot of technical and domain knowledge fast, often without much support. One lost his mentor in his first week.
- A lot of calls don’t have a clear right answer, and PMs don’t always have the authority to make them.
- There’s not much uninterrupted time for actual product work.
Our new questions
PMs we already talked to went straight to these. New PMs got the average, good and bad day prompts first.
- Tell me about the last time a project went off track. What happened?
- Tell me about the last time stakeholders disagreed. How many rounds of feedback did it take to settle?
- When did work last have to be redone because the scope changed? What have you tried to stop that from happening?
- Tell me about the last time something took way longer than it should have.
- Tell me about the last time you spent a chunk of your day on something you wish someone else did.
- Have you built, set up, or tried anything to make part of the job easier? Walk me through the last time you used it.
- Think about the last PRD or spec you got approved. How long did it take, and who did it have to go through?
- The last time you had to get up to speed on something new, what did you actually do that first week?
Follow-ups we use on every answer: When did that last happen? What did you do next? What did it cost you (time, a deadline, trust)? What have you tried? Who else was involved?
Not every interview got through the whole list. The follow-ups with C and D covered 1 and 3, plus an early version of 4. E and F got early versions of 4 and 5, plus 6. G and H mostly stayed on the three day prompts. Questions 4 and 5 started out general (“what part of your job takes more time than you expected?”, “if you could hand off one part of your job, what would it be?”, “what irritates you?”). After the Torres reading we reworded them to ask about the last time it happened. The answers to the general versions were mostly opinions, and the useful parts only showed up when the PM tied them to something real, like spending two hours figuring out who owned a Jira ticket.
Round 2 interviews
Each of us did at least two round 2 interviews: follow-ups with PMs from week 1 and four new PMs (E, F, G and H). PMs A and B are from our cold interviews, and they’re included in the map and the counts too.
| PM | Who they are | Rounds | Format |
|---|---|---|---|
| A | Former PM intern (two summers) at a ~200-person software company | 1 + 2 | Recorded + transcribed |
| B | PM intern, two internships at large companies | 1 + 2 | Recorded + transcribed |
| C | Early-career PM who started out of school | 1 + 2 | Detailed Notes |
| D | PM working with eng, design and outside stakeholders | 1 + 2 | Detailed Notes |
| E | New-grad PM on a card product team at a large bank | 2 | Recorded + transcribed |
| F | Working PM (eng, design, sales, customer success, leadership) | 2 | Written up from notes |
| G | PM for 2+ years at a small consumer startup, leads other PMs on college launches | 2 | Detailed notes |
| H | PM for ~3 years on a data and privacy team at a large streaming company | 2 | Detailed notes |
Torres’s other article says to pick interviewees for variation instead of trying to get a representative sample. Across both rounds we have two interns, a new grad, a couple of early-career PMs, and PMs with 2-3+ years, at companies ranging from a small startup to a big bank and a big streaming company. We’re still light on senior PMs, so that’s who we want next.
Affinity map
We put every problem from both rounds on its own sticky (about 60), one color per PM, and grouped them by hand into seven clusters. We marked a cluster high potential when it came up across several people, it clearly hurt, and people were already working around it. That gave us three: chasing status and keeping everyone coordinated (5 of 8), context getting lost between teams (5 of 8), and getting a PRD or spec through the loop (4 of 8).
Ramping up and having no room for deep work also came up for 4 PMs each, but we marked them medium. Ramping up was mostly an intern and new-grad problem, and deep work is more about meeting culture than something a tool can fix. Scope changes causing rework is medium too: only 3 PMs, but all three had real stories about losing work. “Calls with no clear answer and no authority to make them” came up for 4 PMs, but nobody had a workaround and it’s hard to see what we’d build, so it’s low for now.
AI second pass
Once our map was done, we gave all eight transcripts and notes to an AI and asked it to find the recurring problems, who raised each one, and evidence for each.
What did it catch that we missed? It grouped PM E’s problem (engineers asking for API logs that product can’t see) with PM G’s (a launch underperforming and the data not explaining why) into one pattern: PMs can’t see why something broke. On our board those were in two different clusters, so we never connected them, and we added it to the long list. It also pointed out that the three PMs using AI to do more of the job themselves (A, B and E) are all interns or new grads. We had those tagged as workarounds but never looked at who they belonged to.
What did it flatten into something generic? Its biggest theme was “coordination overhead crowds out strategic work,” covering 7 of 8 PMs. That folds three of our clusters (status chasing, context getting lost, no room for deep work) into one, and they’d need pretty different fixes. It also counted A and E, who described meeting-heavy days but never complained about them, and it listed H under “PRDs take too many rounds” even though H said that back-and-forth is healthy, so it was counting mentions instead of pain.
Did it assert anything that isn’t in the transcripts? It didn’t invent any problems, but it put quotation marks around lines from G’s and H’s interviews that are actually our paraphrased notes, like G being a “translator between people.” That makes notes look like direct quotes. Its summary also said most PMs spend “the majority of their time” on coordination, which nobody measured and which goes past what eight interviews can tell us.
Long list
Counts are how many of the 8 PMs had at least one sticky in the group. People who described doing something every day but didn’t complain about it aren’t counted. “Story” means they told us about a specific time it happened, and “general” means it came up as a complaint without one.
| # | Problem | PMs | Evidence | What people already do about it | Quote |
|---|---|---|---|---|---|
| 1 | Chasing status and keeping everyone coordinated | 5 of 8 (C, D, F, G, H) | Mostly general | Blocking off time (F), looping in eng and design early (D) | “Why have I spent the last two hours figuring out who owns a Jira ticket?” (PM F) |
| 2 | Context gets lost between teams, so PMs end up translating and re-explaining | 5 of 8 (D, E, F, G, H) | Story (E), general (the rest) | Obsidian notes + a Slack-connected AI (E) | “We’re all talking about the same project, but obviously engineering’s going to be way more technical than business.” (PM E) |
| 3 | Getting a PRD or spec through the loop takes forever | 4 of 8 (A, B, D, F) | General, but A built a tool for it | AI spec drafter built on past specs (A) | “Converting that to a full spec can sometimes take ages.” (PM A) |
| 4 | Ramping up on domain and technical knowledge with little support | 4 of 8 (A, B, E, G) | Story (A, E) | AI-built learning site (E), meeting people on other teams (A) | “I’m not someone who really learns information just by reading it.” (PM E) |
| 5 | No room for deep work | 4 of 8 (A, C, D, F) | General | Writing ideas down after hours (C), blocking off time (F) | “The interruption itself takes two minutes, but getting my brain back takes twenty.” (PM F) |
| 6 | Calls with no clear answer, and no authority to make them | 4 of 8 (B, C, F, H) | General | Nothing we heard | “What did we just spend eight people’s hour doing?” (PM F) |
| 7 | Scope changes late and work gets redone | 3 of 8 (A, D, F) | Story (all three) | Stakeholder review before work starts, which doesn’t always work (D) | “None of this is usable. You went way over scope.” (PM A, quoting a senior PM’s feedback) |
| 8 | Can’t tell why something failed (added after the AI pass) | 2 of 8 (E, G) | Story (both) | Asking the Slack AI (E), which didn’t help | “I literally don’t have access to see that.” (PM E) |
Quotes only come from interviews we recorded or wrote up close to word for word. PM F’s interview was written up from notes, so those quotes are close to their words but might not be exact.
What people said vs. what they did, and surprises
The strongest signal was when someone had already built something. PM A said the spec back-and-forth was what he’d most want to hand off, and he actually built a tool for it (Gemini hooked into Docs, drafting from a Drive folder of past specs). He said the hard part was formatting, not the writing. PM E built three things: a learning site from her onboarding decks, an Obsidian notes vault that Claude reads as her “brain,” and a Slack connection so she can ask what her manager said. PM B uses AI to prototype instead of wireframing. Most of the other PMs told us what bothers them but hadn’t built or bought anything beyond personal habits.
A few places where what people said and what they did didn’t line up:
- PM D said they try to bring in eng and design early and have stakeholders review requirements before work starts. But in the story they told, a stakeholder still changed the scope mid-build and work had to be redone.
- PM E said her onboarding was “pretty good,” but what she actually did was build a whole learning site because she was buried in decks.
- PM E said Slack synthesis is what she’d most want to hand off, even though she already has an AI connected to Slack. The pain that’s left is having to prompt it every time, so “give PMs an AI that reads Slack” isn’t enough by itself.
- PM C said the work never really ends. They don’t fix that, they manage it with personal habits like writing ideas down after hours and protecting weekends.
Surprises:
- Coordination took up more of the job than we expected. We went in thinking deciding what to build would be most of a PM’s day, but most PMs described their days as tracking status, aligning people and updating others.
- PM B expected his internship to be meeting-heavy and only had 2-3 short meetings a day. His time went to writing and rewriting PRDs instead. Most of the other PM described meeting-heavy days.
- PM H described PRD back-and-forth as healthy, while A, B and D described it as a drain. So the problem might be pointless rounds, not rounds in general.
- Alignment was both the best and worst part of the job. Good days for A, D, F, G and H were the days people got on the same page fast. Bad days were when they didn’t.
- PM G’s bad day wasn’t a failed launch. It was a failed launch where the team couldn’t figure out why.
TAM for the PM market
We estimate there are about 1.5 million product managers worldwide. There’s no official count, so every number comes from LinkedIn, and the result depends on how strict the search is. Product Focus found just over 1 million people in PM roles in July 2021 [1]. Counting only the exact “Product Manager” title, there were about 700k in early 2023 and over 1 million by January 2024 [2], and a 2025 count of everyone listing the title came out to over 2.6 million [3]. That 2.6M probably includes old and loosely labeled profiles, so we went with 1.5M as a middle estimate. All of these undercount countries where LinkedIn isn’t widely used [1], and the best US number we found was about 200k active PMs in 2023 [4]. For spending, analyst reports on “product management software” range from $2.95B (2024) to $8.4B (2025) [5, 6], and we use Wise Guy Reports’ $6.29B for 2025 as a rough benchmark [7]. Estimates vary this much because each report defines the category differently, and most include tools like Asana and Wrike that whole companies use. So we also did a bottom-up check that only counts PM seats. Aha! Roadmaps costs $59-149 per user per month on annual plans [8], Productboard’s cheapest paid plan is about $15 [9], and a lot of teams add a feedback tool like Aha! Ideas for about $39 more [10]. At $708-1,176 per PM per year, 1.5M PMs gives about $1.1-1.8B (and at least $140-235M in the US). So we think the PM-specific part of the market is around $1-2B inside a software category of roughly $6B. This is potential spend, since it assumes every PM buys a seat. It also leaves out Slack, Docs and AI subscriptions, which is where the PMs we talked to actually built their workarounds.
Sources: [1] Product Focus via Retail Logistics International (2021): https://www.retaillogisticsinternational.com/new-research-reveals-global-eco-system-of-more-than-one-million-product-managers/ [2] Gabriel Steinhardt, “Future of Product Management: 2024 Forecast”: https://www.linkedin.com/pulse/future-product-management-2024-forecast-gabriel-steinhardt-bzj7f [3] Productify, “2025 Product Management Job Market Review”: https://productify.substack.com/p/2025-product-management-job-market [4] Mikhail Shcheglov, Corporate Waters (2023): https://corpwaters.substack.com/p/how-many-product-managers-are-there [5] Growth Market Reports: https://growthmarketreports.com/report/product-management-software-market-global-industry-analysis [6] Dataintelo: https://dataintelo.com/report/global-product-management-software-market [7] Wise Guy Reports: https://www.wiseguyreports.com/reports/product-management-software-market [8] TrustRadius, Aha! Roadmaps pricing: https://www.trustradius.com/products/aha/pricing [9] Quackback, Aha! pricing comparison (Productboard pricing): https://quackback.io/blog/aha-pricing [10] Vendr, Aha! pricing: https://www.vendr.com/marketplace/aha-faa15
Cold vs. round 2
Our cold interviews mostly gave us broad problems like ambiguity, coordination and PRDs taking forever. Round 2 gave us specific stories with a cost attached, like PM D’s stakeholder adding requirements mid-build so work got redone, or PM E’s one-card bug that turned into a chain across three teams. What didn’t change enough is that a lot of answers were still general complaints, and some of our questions were hypothetical until we reworded them, so next round we need to push harder on “when did that last happen?”
Reading
We used Torres’s idea of grounding interviews in specific past events instead of opinions, in questions like “Tell me about the last time a project went off track” and in the “when did that last happen?” follow-up we use on every answer.
Comments