Team 8 (Bumblebees): Alexis Tuchinda · Christian Roy · Efrain Angon-Cruz · Natnael Tadesse
At our Sanity Check pitch, we chose late feedback and scope misalignment as our problem and Product Hub as our lead concept. This week we wrote a value proposition, built an opportunity solution tree (OST) and a story map, and decided what to change based on what we learned.
Value proposition
Catch scope changes when feedback arrives rather than after the work is done.
For execution-focused PMs who run engineering and design teams, Product Hub is one place where stakeholder feedback comes in, gets checked against the agreed scope, and goes to the person who owns that work.
Today, feedback is spread across Slack, meetings, PRDs, and Jira, and none of them connect a new comment to the requirement it changes. Jira tracks tasks but not why they changed. Notion holds specs but doesn’t check feedback against them. Glean finds information but doesn’t send it to an owner. And most PMs we talked to said their real workaround is “I just suffer.”
Opportunity solution tree
https://drive.google.com/file/d/11EEfscNZ2GoEqSHlfJr12rOtsGZKVsjA/view?usp=sharing
Our outcome is faster project completion through better team coordination. Our interviews pointed to three big opportunities: PMs need visibility into progress, teams get caught off guard by feedback and changes, and communication is scattered. We brainstormed 10 solutions, each with cheap experiments to test them. Product Hub is built mainly from feedback routing, real-time alerts, and pinging team members with context, plus the scope check from Drift Watch.
Story map and top user stories
https://drive.google.com/file/d/1XSmPr2A0CFG1NrD3wK8s-3Co-42ocmJS/view?usp=sharing
The map follows a project from sign-up to a resolved piece of feedback. Everything above the MVP line is release 1. Progress tracking, grouping related feedback, and AI next steps wait for release 2.
Top user stories:
- As a PM, I want to set up a project with requirements and team roles, so feedback has a scope and owners to check against.
- As a PM, I want to assign an owner to each approved requirement, so everyone knows who owns what.
- As a stakeholder, I want to describe feedback in plain language and confirm which requirement it affects, so it lands in the right place.
- As a PM, I want AI to flag feedback that conflicts with the agreed scope and explain why, so I catch changes before work is redone.
- As a PM, I want AI to suggest an owner that I can confirm or change, so routing stays accurate.
- As an engineer or designer, I want to be notified with the feedback and the affected requirement, so I can adjust before building the wrong thing.
What we’re changing
- Drift Watch moves inside Product Hub. Scope checking is now a step in analyzing feedback, not a separate product.
- Scope setup is part of the MVP. Routing can’t work without requirements and owners, so our first test now uses a real project’s scope and roles, not just raw feedback.
- Progress tracking is cut from release 1, so we can test routing first.
- Account setup and support are now on the map, and a “report a wrong route” button doubles as our way to measure routing accuracy.
From the reading: Torres warns against making up opportunities, so the new opportunity we added (hidden company standards) came straight from our Patreon PM interview, not from our own guesses.
