Roadmap Signals
An internal product intelligence tool that turns scattered customer feedback into ranked product signals, action-ready PM artifacts, and a weekly roadmap memo.
How to Review This Project
Start on the Signals page and follow one signal through the workflow. The demo uses 259 synthetic feedback items for a fictional B2B SaaS product called FlowPilot. Click into a ranked signal, review the customer evidence behind it, check the score breakdown, and open the generated action artifact. That flow shows the main idea behind the project: raw feedback becomes a product signal, the signal becomes a decision, and the decision becomes a usable PM handoff.
The Problem
Early-stage SaaS teams often hear customer feedback from support tickets, sales notes, churn reasons, surveys, and customer calls. The hard part is turning that feedback into consistent product action.
A founder might hear one urgent complaint on a sales call, see a few related support tickets later, and remember a similar issue from a churn survey. Those signals are valuable, but they are easy to lose when they live across different tools and conversations.
Roadmap Signals is built for that early stage where a team has real customer feedback, but the process for turning it into product decisions is still forming.
What I Built
Roadmap Signals is a lightweight internal product intelligence tool for a founder, solo PM, or first product hire at an early-stage B2B SaaS company.
The product stores customer feedback, identifies recurring product signals, scores each signal by strength, and turns the strongest signals into action-ready PM artifacts. Those artifacts include product improvement tickets, bug escalation tickets, support/docs artifacts, and customer discovery plans.
The app currently processes 259 feedback items into 10 ranked product signals. Each signal includes supporting evidence, a score breakdown, routing rationale, status, and a generated artifact. The app also creates a weekly PM memo that summarizes top signals, active decisions, wins, and next steps for planning. The dataset was designed to cover the full range of signal types and routing decisions, including cases that should route to a discovery plan rather than the roadmap.
How It Works
Capture feedback — Feedback enters through CSV upload or manual quick-add, with context like source, customer segment, plan type, product area, severity, and date.
Identify product signals — The system groups related feedback into recurring patterns, so scattered comments become clearer product signals.
Score each signal — Each signal is scored across frequency, severity, segment importance, recency, evidence quality, and actionability.
Route to the right action — The app decides whether the signal should become a product improvement ticket, bug escalation ticket, support/docs artifact, or customer discovery plan.
Generate the handoff — The system creates the artifact a PM would use to move the issue forward, with evidence, rationale, open questions, and next steps.
Why I Built It This Way
The main product decision was to focus on what happens after the system finds a pattern.
A basic feedback tool can say customers are confused about onboarding. I wanted Roadmap Signals to take the next step and ask what the team should do with that information. Sometimes the answer is a product ticket. Sometimes it is a bug escalation. Sometimes it is better support content. Sometimes it is a discovery plan because the evidence is interesting but still incomplete.
I also wanted the product to make those decisions consistently. The artifact routing is handled by code, while Claude writes the artifact content and rationale. That means a billing confusion issue routes to support/docs, a high-severity bug routes to a bug ticket, and a feature request with incomplete evidence routes to discovery. The AI helps with the writing, but the product logic controls the workflow.
The score is also meant to be transparent. A PM can see whether a signal ranked highly because many customers mentioned it, because it affects an important customer segment, because the evidence is strong, or because there is a clear next step. That makes the score something a team can actually discuss and push back on, rather than just a number they have to accept.
Before running the full dataset, I took note of what I expected the system to find: which issues should surface as the strongest signals and what kind of action each one should trigger. When the pipeline ran, it matched my expectations on 9 out of 10 signals. The one difference was actually interesting: access-control complaints ranked higher than I predicted because the larger dataset had more feedback from enterprise customers than my initial test data showed. The system found something real that the smaller sample could not see.
How I'd Evolve It
Next I would test the workflow with founders, first PMs, and customer-facing teams at early-stage SaaS companies. I would focus on whether the generated artifacts feel specific enough to use in real planning and where users would edit or override the system.
After that, I would add focused integrations that support the core loop. Zendesk or Intercom would improve feedback intake. GitHub Issues or Linear would let teams send product and bug tickets into their existing workflow.
The biggest v2 opportunity is follow-up tracking. After a team marks a signal as fixed or addressed, Roadmap Signals should keep watching new feedback and show whether the issue is actually decreasing. That would make the product feel more like a lightweight feedback operating system.