Team: Alexis Tuchinda · Christian Roy · Efrain Angon-Cruz · Natnael Tadesse
Don’t want to read? Find our pitch deck slides here.
The Problem: When Feedback Arrives Too Late
Product managers (PMs) are responsible for turning stakeholder needs into requirements that engineering and design teams can execute. But what happens when feedback arrives after work is already underway, or when the people implementing a feature do not have all the context behind a decision?
Our team explored these challenges through interviews with eight product managers. We wanted to understand where PMs experience friction in their day-to-day workflows and identify a problem that could be addressed with a practical, AI-enabled solution.
Our interviews surfaced three recurring challenges: scope and rework, communication and coordination, and context sharing. Three of the eight PMs (37.5%) described problems with scope, feedback, or approvals, while five of eight (62.5%) highlighted communication and coordination difficulties. The same number reported challenges with context sharing.
We ultimately focused on scope misalignment and late-stage feedback. Unlike general communication inefficiencies, rework has a tangible cost: wasted engineering and design hours, repeated review cycles, and delayed implementation. We saw an opportunity to help teams identify misalignment before it becomes expensive to fix.
What We Learned from Product Managers
Our interviews revealed that the problem is not necessarily a lack of communication. Rather, feedback and requirements can change throughout a project, and teams do not always have a reliable way to connect those changes to work that is already underway.
Three interviews illustrated this challenge particularly well.
A PM at Autodesk described the frustration of friction during handoffs between product requirements and engineering or design. A PM at Netflix explained that a product or product requirements document (PRD) is unlikely to be perfect on its first review, making clarification and stakeholder alignment an ongoing process. Meanwhile, a PM at Patreon described getting nearly all the way through a project only to have the final portion repeatedly sent back because of previously unknown, company-specific design standards.
Together, these experiences point to a recurring pattern: requirements and expectations are not always fully aligned when implementation begins, and important feedback may surface only after significant work has been completed.
The problem is especially relevant during PRD reviews, scope changes, and handoffs between PMs, engineers, designers, and other stakeholders. When new information arrives late, teams may have to revisit earlier decisions, reassign work, or repeat reviews.
The consequences extend beyond the PM responsible for coordinating the project. Engineers and designers may have to redo work, stakeholders must spend additional time reviewing revisions, and implementation is delayed.
Why Existing Workflows Fall Short
We mapped the current workflow to understand why this problem persists despite the availability of established project management and communication tools.
Much of the feedback that teams receive is distributed across Slack conversations, meetings, documents, and task management systems. A stakeholder might clarify a requirement in a discussion, while the original PRD remains unchanged and the corresponding Jira ticket continues to reflect an outdated scope.
These tools serve important purposes, but they do not necessarily connect new feedback to the requirements it affects or the person responsible for implementing those requirements.
For example, Jira can track tasks and their progress, but a task tracker does not automatically explain why a requirement changed or identify all the work affected by that change. Notion and Google Docs can store specifications, but they do not inherently check every new piece of feedback against the agreed scope. Slack and meetings facilitate discussion, yet important decisions can become buried in threads or arrive after implementation has started.
Other approaches have limitations as well. Asking stakeholders to review work earlier can help, but it does not guarantee that requirements will remain stable. Spreadsheets and manual change logs can document decisions, but they require ongoing maintenance. Knowledge search tools can help people find information without necessarily routing feedback to the appropriate owner.
As a result, teams often rely on manual coordination or simply accept rework as a normal cost of collaboration.
The gap we identified is specific: there is no reliable connection between incoming feedback, the scope a team has agreed upon, and the person responsible for acting on that feedback.
Defining Our Target User
Based on our findings, we identified execution-focused PMs who manage engineering and design teams as our primary target users. Engineers and designers are also important stakeholders because they directly experience the consequences of changing requirements.
The problem may be particularly painful in larger, cross-functional organizations, where requirements evolve and multiple stakeholders contribute feedback. However, this remains a hypothesis that requires further validation.
We expect the greatest friction to occur during PRD reviews, late-stage scope changes, and handoffs between teams. The potential costs include repeated review cycles, delayed implementation, and wasted engineering and design hours.
Importantly, our research is still preliminary. We interviewed only eight PMs, and our findings should be treated as early evidence rather than a definitive estimate of how widespread the problem is. We also have not yet validated the full financial or time cost of rework. Further interviews and testing will be necessary to establish how frequently the problem occurs and which teams experience it most acutely.
Estimating the Market Opportunity
To understand the potential market, we developed an initial estimate of our total addressable market (TAM), serviceable addressable market (SAM), and serviceable obtainable market (SOM).
Our estimates use 1.5 million product managers worldwide as the TAM, based on a middle estimate drawn from several sources that report different counts of PMs on LinkedIn. We then applied our interview finding that three of eight PMs experienced rework associated with late scope changes, or 37.5%, to estimate a SAM of 562,500 PMs. Finally, we assumed an initial target of 1% of that group, giving us a SOM of 5,625 PMs.
These figures provide a starting point for thinking about market size, not a validated forecast. Our sample is small, and the percentage of interviewees who reported the problem may not reflect the broader PM population. LinkedIn counts also have limitations: they may undercount professionals in countries where the platform is less widely used, while broader estimates may include outdated or loosely categorized profiles.
Nevertheless, the exercise helped us translate a qualitative problem into an initial market hypothesis that can be refined as we collect more evidence.
Three Potential Solutions
We considered three product concepts, each addressing a different part of the workflow.
1. Product Hub — our leading concept
Product Hub would provide a shared space where feedback is collected, assigned to reviewers, and routed to the appropriate owners. AI would help organize incoming feedback, identify who should act on it, and suggest updates to the project scope for the PM to approve.
This concept directly addresses the gap between stakeholder feedback and the people responsible for implementing changes. It also offers a relatively focused starting point: instead of attempting to automate an entire product management workflow, we could test whether AI can reliably route feedback to the correct people.
2. Drift Watch — detecting scope changes
Drift Watch would compare work against the agreed scope and alert PMs when implementation appears to diverge from the requirements. Its purpose would be to catch misalignment before it leads to repeated revisions or substantial rework.
This remains a potential follow-on concept because it depends on being able to compare changing work against an accurate representation of the agreed scope.
3. The Log — preserving decisions and their rationale
The Log would maintain a record of scope decisions and explain why they were made. AI would extract decisions from Slack threads and meeting notes, making it easier for teams to recover the context behind previous choices.
Although this could improve accountability and context sharing, we considered it a later candidate because it overlaps more directly with existing documentation and knowledge management platforms.
We chose Product Hub as the first concept to prototype because it offers a clear, testable function without requiring us to solve every aspect of scope management at once.
Our first inexpensive experiment would be to provide the system with one PM’s real feedback and evaluate whether it routes each item to the correct person. This would allow us to test a core assumption before investing in a more complex product.
What We Learned from the Readings
Our approach was also informed by two readings on identifying customers and developing product strategy.
In “How to Identify Your Ideal Customer Profile,” Lenny Rachitsky emphasizes the importance of identifying the customer segment that is best suited to a product rather than defining the audience too broadly.
This idea influenced how we considered who experiences the problem. By examining the actual workflow, we recognized that engineers and designers can experience the consequences of misalignment directly, even though PMs remain our primary target persona. This helped us distinguish between the person coordinating the problem and the other people affected by it. In direct conversation with Marty Cagan’s Inspired corroborates that trying to address every possible user and workflow at once would make it harder to determine whether our product solves a real problem.
Instead, we chose to center PMs and their challenges with communicating feedback, delegating work, and managing scope changes. This narrower focus gives us a clearer way to evaluate whether our proposed solution delivers value before expanding to adjacent use cases.
Using AI Critically in Our Research
AI also played a role in our own research process, although we were careful not to treat its outputs as definitive evidence.
We first built our affinity map manually and then used AI to conduct a second pass across all eight interview transcripts. The AI surfaced a pattern we had initially missed: PMs often struggle to understand why something broke down in a workflow.
However, it also merged clusters that represented different problems requiring different solutions. In addition, it placed quotation marks around some paraphrased interview notes, creating the risk of presenting a summary as a verbatim statement.
We therefore checked the quotations ourselves and used the AI output as a supplementary analytical tool rather than a replacement for our own judgment. We also used AI to help draft and edit slide wording.
What Comes Next?
The next stage is to test whether the concept works in practice. We need to determine whether AI can accurately route real feedback, whether PMs find that capability useful, and whether it meaningfully reduces the coordination and rework they experience. We also need more evidence about the frequency and cost of late-stage revisions.
Ultimately, our goal is not to build another task tracker or replace the tools teams already use. It is to address a more specific gap in the product development process: helping teams recognize and act on changing expectations before those changes turn into unnecessary work.
By starting with a clearly defined user, validating our assumptions, and testing a focused solution, we hope to build a product that makes cross-functional collaboration more effective without adding another layer of administrative overhead.
