We narrowed our long list into three problems:
- Testing falls on the PM when there’s no QA team or tooling
- AI output can’t be trusted for high-stakes writing or specialized terms
- PMs can’t see what other teams are launching, so unrelated launches break their work
ICPs
| Problem 1 | Problem 2 | Problem 3 |
| Smaller teams where the PM needs to act more like an FDE and they need to do some of the work to ensure that software quality is good | Larger, late-stage teams that have critical information spread in different places and specific team knowledge that is implicit and not explicitly written somewhere | Larger companies for sure, late stage startups or larger enterprises with lots of feature sets |
SAM/SOMs
| Problem 1 | Problem 2 | Problem 3 | |
| TAM | 2M PMs globally | 2M PMs globally | 2M PMs globally |
| SAM | ~360,000 PMs (2M x 18% of PMs overall reported doing QA tasks/test definition) | About 1.07M PMs, from 2M × 53.6% × 100% AI use.
.-This shows that all PMs at large companies already use AI. So AI use doesn’t shrink this market. You could narrow it to PMs who regularly write high-stakes. |
About 1.07M PMs, from 2M × 53.6%
– PMs are spread across company sizes the same way all workers are. Census doesn’t count PMs separately. |
| SOM | ~1,000 (targeting 10% of ~10,000 software start-ups in the SF Bay Area, and capturing 1 potential PM customer per startup) | About 1,000 PMs.
– Start with the same 1,459 Bay Area companies. Win 10% of them. Pilot with about 7 PMs per company. |
About 1,500 PMs.
– Start with 1,459 Bay Area companies with 1,000+ employees . Win 5% of them, about 73 companies. Roll out to about 20 PMs per company. |
Comparison Table
| Problem 1 | Problem 2 | Problem 3 | |
| The Problem
One sentence, in the PM’s words |
Testing falls on the PM when there’s no QA team or tooling | AI output can’t be trusted for high-stakes writing or specialized terms | PMs can’t see what other teams are launching, so unrelated launches break their work |
| Evidence strength
Said it, did it, or paid for it? How many interviews? |
People: 4
Did – “My company also doesn’t have any QA. So then that falls on the product… is going in and, like, testing it out, like, at least, like, the front-end, like, user flows.” (P5) |
People: 4
Said – “If I write something that’s really information sparse, which is kind of the default for an LLM. Even if I get that information out really quickly, it’ll take someone so long to read it they won’t bother, and so no one knows what’s going on.” (P2) |
People: 3
Said – “oh my god, I wish I could have, like, a snapshot into, like, what other teams are, like, up to.” (P5) |
| Current workarounds
What do PMs do today? Spreadsheets, Slack, “I just suffer.” |
Manually run tests and report results
Internal dogfooding, asking teammates to test |
Writing critical docs by hand, checking every output
Copy-paste from AI chat after reading it |
Over-communicating in Slack
Searching across documentation for PRDs/in-progress work Setting up Zoom meetings to align and check-in with PMs on adjacent teams |
| Competitive gap
Where do today’s options fall short? Use your map and your competitor’s BMC. |
QA tools are usually designed for technical audience, not PMs | Hallucinations | Documentation/systems of record (Notion) need to be manually kept up-to-date
Too much to review when info is in Slack Looms/walkthroughs take time from both creator + viewer |
| ICP
Who has this problem worst? Role, company stage, trigger. |
Smaller teams where the PM needs to act more like an FDE and they need to do some of the work to ensure that software quality is good | Larger, late-stage teams that have critical information spread in different places and specific team knowledge that is implicit and not explicitly written somewhere | Larger companies for sure, late stage startups or larger enterprises with lots of feature sets |
| Market size
SAM and SOM. Mark every guess. |
TAM: 2M PMs globally
SAM: ~360,000 PMs (2M x 18% of PMs overall reported doing QA tasks/test definition)
SOM: ~1,000 (targeting 10% of ~10,000 software start-ups in the SF Bay Area, and capturing 1 potential PM customer per startup) |
TAM: 2M PMs globally
SAM: About 1.07M PMs, from 2M × 53.6% × 100% AI use. .-This shows that all PMs at large companies already use AI. So AI use doesn’t shrink this market. You could narrow it to PMs who regularly write high-stakes. SOM: About 1,000 PMs. – Start with the same 1,459 Bay Area companies. Win 10% of them. Pilot with about 7 PMs per company.
|
TAM: 2M PMs globally
SAM: About 1.07M PMs, from 2M × 53.6% – PMs are spread across company sizes the same way all workers are. Census doesn’t count PMs separately. SOM: About 1,500 PMs. – Start with 1,459 Bay Area companies with 1,000+ employees . Win 5% of them, about 73 companies. Roll out to about 20 PMs per company. |
| Buildability
Could your team build a working version this quarter? |
Yes | No | Yes |
| Al fit
Strong, maybe or weak? One reason. Could Al make a solution possible that wasn’t before? |
Maybe – automation of rule-based tests has deterministic results and AI is good at interpreting natural language prompts, but decision-making behind what to test and bar for quality is most of the task and is best with human judgment | Weak – using AI to judge quality of AI responses does not resolve trust issues | Strong – increasing context and connectors enables data synthesis across sources much faster than what humans can do alone, accelerated search |
| Solution Ideas |
|
|
|
Which problem you’re leaning toward and why + one idea from the reading
We’re leaning towards problem 3–PMs can’t see what other teams are launching, so unrelated launches break their work–because it is particularly prevalent in larger organizations where cross-team visibility becomes increasingly difficult. PMs already rely on multiple workarounds, such as over-communicating in Slack, searching through documentation, and scheduling additional meetings, which suggests that existing tools aren’t adequately addressing the problem. We also see a strong opportunity for AI to surface relevant updates across existing tools and proactively identify dependencies between teams, reducing the need for manual coordination.
In comparison, Problem 1 primarily affects smaller teams without dedicated QA resources, potentially limiting the size of our target market. It also faces competition from existing automated testing tools. Problem 2, while relevant to larger organizations, would be more difficult to address within a quarter, as building an AI system that reliably understands specialized terminology and implicit organizational knowledge requires significant context and validation. Problem 3 offers a stronger balance of market opportunity, technical feasibility, and AI differentiation, making it the most promising direction for our team to pursue.
The idea we applied from Rachitsky’s How to Identify Your Ideal Customer Profile was narrowing our target customers based on company size and specific pain points, which helped us prioritize Problem 3 for PMs at larger organizations where cross-team coordination is particularly challenging.
