Team 8: Efrain Angon-Cruz, Christian Roy, Natnael Tadesse, Alexis Tuchinda
1. The Three Problems
From our interviews, three themes have emerged: scope adjustments and feedback loops, coordination and status tracking, and context sharing across teams. All three reflect a common challenge: product managers spend significant time keeping teams aligned, often through manual communication and repeated back-and-forth.
Problem 1: Scope Adjustments and Feedback Loops
The problem: Product managers must incorporate stakeholder feedback, clarify requirements, and adjust project scope without forcing teams to redo work that could have been avoided through earlier alignment. Additionally, when feedback arrives late or decisions require multiple rounds of clarification, engineers and designers may already have invested time in work that no longer meets the team’s needs.
ICP: Product managers working closely with engineers and designers on active, cross-functional projects with evolving requirements and frequent stakeholder feedback. Engineers and designers are also important users because they directly experience the consequences of unclear requirements and late changes.
3 out of 8 interviewees had experienced this problem.[1] Although this is a smaller share than for our other two problems, it provides an initial signal that the problem exists.
Current workarounds and competitive landscape:
- Slack and meetings: Teams communicate changes and clarify requirements, but decisions can get buried in conversations or arrive after implementation has begun.
- Jira and project management tools: These tools organize tasks and track progress, but updating a task does not necessarily communicate why a requirement changed or how that change affects work already underway.
- Manual feedback and review: PMs relay stakeholder feedback, resolve ambiguities, and follow up with engineers and designers to ensure changes are understood.
- Spreadsheets and homegrown processes: Teams may maintain their own change logs, requirement trackers, or review checklists, adding another source of information to maintain.
- Doing nothing: Teams may accept rework as an unavoidable cost of collaboration rather than invest in improving the process.
Competitive gap: Existing tools can document requirements and facilitate communication, but there may be an opportunity to connect new feedback to previous decisions and ongoing implementation. The objective would be to surface misalignment earlier and prevent avoidable rework, rather than simply make scope changes easier to record.
Preliminary BMC analysis — Jira: Jira’s project and issue-tracking model addresses the organization and tracking of work. Its broad functionality makes it a natural existing alternative, but tracking an issue is not necessarily the same as resolving ambiguity between stakeholder feedback and implementation. Our potential differentiation would be an earlier intervention in the feedback process, helping teams identify consequential changes before work must be redone.
Market sizing:
Using our previous market-sizing estimate of approximately 1.5 million product managers worldwide from Milestone 2 as a working TAM:
- TAM: Approximately 1.5 million PMs worldwide.
- SAM: Approximately 562.5K PMs, using the 3/8 interview result (37.5%) as a preliminary proxy for the share experiencing the problem. This is an extrapolation from our small interview sample, not a validated national prevalence estimate.
- SOM: Approximately 5,625 PMs, assuming an initial target of 1% of SAM.
Problem 2: Coordination and Status Tracking
The problem: Product managers spend significant time collecting status updates, answering questions, and coordinating work across Slack and other communication channels, making them a bottleneck in information flow. When information is distributed across conversations, project boards, and meetings, PMs must repeatedly chase people for updates or manually consolidate information. This creates communication overhead and makes it harder for teams to understand project progress without interrupting one another.
ICP: Product managers coordinating cross-functional teams around shared deliverables, particularly those managing several interdependent workstreams in larger organizations. Engineers and designers also experience the effects when updates are delayed or project dependencies are unclear.
5 out of 8 interviewees had experienced this problem, giving it a stronger initial prevalence signal than the scope problem.[1]
Current workarounds and competitive landscape:
- Slack: Used for updates and questions, but PMs may still need to chase responses and reconstruct progress from fragmented conversations.
- Notion, Jira, and status boards: Provide places to document work and track tasks, but keeping them current can introduce additional manual work.
- Meetings and direct messages: Used when asynchronous updates are incomplete or difficult to interpret.
- Spreadsheets and homegrown dashboards: Help teams consolidate status information, but require manual maintenance and can become outdated.
- Doing nothing: Some teams tolerate delayed updates, duplicated questions, and the resulting coordination burden.
Preliminary BMC analysis — Jira: Similar to the first problem, our potential differentiation could be a more proactive solution, where deliverables based on others’ progress are automatically created and sent to PMs off of a schedule they choose such that they can stay regularly updated on projects and status without having to hunt people down.
Competitive gap: There may be an opportunity to reduce unnecessary coordination and meetings without creating another layer of employee surveillance. Instead of tracking individual activity, a solution could help teams retrieve relevant updates, identify unresolved questions, and understand dependencies using information they already produce.
Market sizing:
- TAM: Approximately 1.5 million PMs worldwide.
- SAM: Approximately 937.5K PMs, using the 5/8 interview result (62.5%) as a preliminary proxy for the share experiencing the problem.
- SOM: Approximately 9,375 PMs, assuming an initial target of 1% of SAM.
Problem 3: Context Sharing Across Teams
The problem: Engineers, designers, and other collaborators often lack the context behind product decisions, leaving PMs responsible for repeatedly explaining what was decided, why it matters, and how it relates to ongoing work. Information may exist in a Notion page, a Slack thread, or a meeting, but the person who needs it may not know where to look or how the pieces fit together.
ICP: Product managers and cross-functional collaborators working across multiple tools, handoffs, and interdependent workstreams. This problem may be particularly relevant in larger organizations with more stakeholders and specialized teams.
5 out of 8 interviewees had experienced the problem and marked evidence of payment as well.[1]
Current workarounds and competitive landscape:
- Slack: Provides a searchable record of conversations, but relevant information is fragmented across channels and threads.
- Notion and other documentation tools: Preserve decisions and requirements, but depend on people documenting information consistently and others finding the right material.
- Obsidian and personal notes: Help individuals organize information, but may not provide a shared source of context across a team.
- Glean and enterprise knowledge platforms: Connect information across organizational applications, helping employees find relevant knowledge. However, finding information does not necessarily mean receiving the right explanation for a particular workflow.
- Meetings and direct communication: Remain the fallback when existing documentation does not provide enough context.
- Homegrown documentation and informal knowledge sharing: Teams may maintain internal wikis, shared notes, or personal systems, or simply rely on experienced colleagues to remember and explain previous decisions.
Competitive gap: There may be an opportunity to move beyond storing and retrieving information toward connecting decisions, requirements, and conversations in ways that support ongoing work. The product would need to offer a clear advantage over existing knowledge platforms rather than simply duplicate their search functionality.
Preliminary BMC analysis — Glean: Glean’s enterprise knowledge platform provides a useful comparison because it connects information across organizational applications. Its broad knowledge-access offering establishes an existing alternative for organizations trying to make information easier to find. Our potential differentiation would need to be more specific: delivering actionable context within a particular cross-functional workflow, rather than simply returning relevant documents or search results.
Market sizing:
- TAM: Approximately 1.5 million PMs worldwide.
- SAM: Approximately 937.5K PMs, using the 5/8 interview result (62.5%) as a preliminary proxy for the share experiencing the problem.
- SOM: Approximately 9,375 PMs, assuming an initial target of 1% of SAM.
2. Comparing the Three Problems
| Dimension | Scope adjustments and feedback loops | Coordination and status tracking | Context sharing |
| Evidence strength | 3/8 interviewees experienced the problem | 5/8 interviewees experienced the problem | 5/8 experienced the problem |
| Current workarounds | Slack, meetings, Jira, manual feedback, spreadsheets, and informal change logs | Slack statuses, Notion, Jira, meetings, spreadsheets, and manual follow-ups | Obsidian notes, Slack, documentation, Glean, meetings, and homegrown knowledge bases |
| Competitive gap | Identify misalignment earlier and prevent avoidable rework | Reduce coordination overhead without surveillance or additional reporting burdens | Connect fragmented information and deliver actionable context when needed |
| ICP | PMs, engineers, and designers working through changing requirements and frequent feedback | Cross-functional PMs coordinating multiple interdependent workstreams | PMs, engineers, and designers who depend on shared context across tools and handoffs |
| Market Sizing |
|
|
|
| Buildability | Requires connecting feedback to existing requirements and identifying consequential changes within the current workflow | Automatic update generation and distribution could reduce manual reporting and some status meetings | Requires connecting data sources, retrieving relevant information, and providing reliable, role-appropriate explanations |
| AI fit | High: Compare feedback with existing requirements, identify conflicting changes, and surface downstream effects before implementation | High: Synthesize updates, answer status questions, and identify unresolved dependencies without requiring manual reporting | Very high: Synthesize fragmented information, connect decisions, and translate context across roles |
3. Which Problem Are We Leaning Toward?
We are leaning toward Problem 1: Scope adjustments and feedback loops.
Although scope adjustments had the lowest interview count in our initial comparison, we see a potentially more concrete and consequential problem to investigate. When requirements change or stakeholder feedback arrives late, teams may need to redo work that has already been completed. This creates a tangible cost that we can investigate through specific examples: what changed, when the team discovered the change, how much work was repeated, and what could have prevented it.
The problem also gives us a more focused starting point than building a general-purpose coordination or knowledge platform. Rather than trying to make every team communicate more efficiently, we could concentrate on one critical workflow: helping teams identify and resolve misalignment before it becomes expensive to rework. Existing project management and communication tools provide ways to record tasks and exchange feedback, but our hypothesis is that there is still a gap between receiving feedback and understanding its implications for work already underway.
4. One Idea From This Week’s Reading
From How to Identify Your Ideal Customer Profile, we applied the idea of re-evaluating role fit against our ICP using interview evidence.[2] We expanded our customer profile to include engineers and designers who experience the same underlying problems from different perspectives, complementing our original PM interviews with our experiences as software engineering and policy interns in industry. For sake of limiting our initial market, we only reported TAMs, SAMs, and SOMs that were immediately PMs. However, our ICP includes engineers and designers.
Sources
[1] Affinity Mapping from our Milestone 2
[2] Rachitshy, Lenny. “How to identify your ideal customer profile (ICP),” 2023. p13 in PDF.
