The Problem
PMs had the data. Getting to insight took half a day.
Product managers were sitting on thousands of pieces of user feedback — and defaulting to gut feelings anyway. The barrier to deep analysis was so high that teams either ignored the data or spent half a day manually building a spreadsheet to present a single insight to leadership. Neither path led to confident decisions.
01
The input
Thousands of unstructured ideas, votes, and comments — more feedback than any PM could read in a week, let alone synthesize into a roadmap argument.
→
02
The workaround
Power users were exporting rows to spreadsheets, manually tagging themes, and building pivot tables. A process only accessible to the most data-fluent admins.
→
03
The goal
Move UserVoice from a feedback storage tool to a strategic partner. Reduce time-to-insight from hours to seconds. Shift the conversation from "what was said" to "what should we do."
What Research Taught Us
The first build was powerful. It was also too complex to use daily.
We built a sophisticated graph-forward Theme Explorer based on a reasonable assumption: PMs are analytical, they want to see the data. Testing with customers at Procore, Zendesk, Greenhouse, and others returned a consistent verdict — impressive, but not actionable. Three findings reshaped everything.
Finding 01
The Complexity Ceiling
The Theme Explorer felt like a pivot table. Powerful for data scientists, too dense for the average PM. 4 out of 4 prototype users couldn't explain what "Activity" meant without prompting.
Finding 02
The Desire for Control
Users didn't want a black box. They explicitly asked for human-in-the-loop controls — seed themes, merge categories, remove irrelevant ideas. AI that works silently isn't trusted.
Finding 03
The "So What?" Factor
Users loved seeing revenue and urgency trends. They couldn't translate those graphs into a roadmap narrative. PMs were still building slide decks by hand to present analysis to leadership. The tool wasn't closing it.
Design Evolution
From spaghetti chart to structured narrative.
The visual shift between Theme Explorer and Impact Reports isn't just aesthetic — it's a design argument. Every element that changed reflects something research taught us about how PMs actually make decisions.
Early concept · The original hypothesis
In progress · Real customer data
Why real data changed everything: Theoretical prototypes produce theoretical feedback. To get reactions that actually moved the design forward, we ran sessions where users looked at Impact Reports generated from their own customer data — their real ideas, their real themes, their real urgency scores. The feedback shifted immediately. Instead of "I think I'd use this," we got "this section is wrong" and "I'd never say it that way." That specificity is what informed the final round.
Key Design Decisions
Four decisions that defined the product's character.
Every design decision in Impact Reports was filtered through one question: will a PM feel safe putting this in front of their VP? Here are the four that mattered most.
Decision 01
Icon-anchored metrics
Urgency, revenue, vote count, and account coverage — moved out of a data table and into a fixed block at the top of every report, each anchored with a custom icon. The icon does cognitive pre-work: a PM registers the urgency signal before reading a word. The same icons appear consistently across every report, so the visual language becomes familiar fast.
Decision 02
Nudging to action
A report that ends with a summary isn't done — it's stalled. Every section closes with a prompt pushing the PM toward a concrete next step: update users on what's next, take action on this idea list, run a follow-up. The report becomes a decision surface, not just a document.
Decision 03
Built to share, not just to read
A PM who can't edit a report won't send it. Editability isn't a workaround — it's what makes the report shareable. The AI generates. The PM shapes it. And once it's theirs, they share it: with their team, their VP, their users. 1 in 4 reports generated was shared. That number only works if the output feels like something worth putting your name on.
Decision 04
Challenge the Hypothesis
Not every section in the report followed the typical summary format. Challenge the Hypothesis was one that didn't — it surfaced research prompts designed to pressure-test the PM's own assumptions rather than just confirm them. The concept came from leadership, but the design challenge was making it feel useful rather than confrontational: prompts that pushed back without feeling like an attack on the person who ran the report.
Systems Design
One system. Every surface it had to live on.
Impact Reports shipped with a component library built from scratch — not inherited from the Theme Explorer. Every element had to work across the in-app report, PDF export, print, and share modal simultaneously. That constraint is what made the system coherent: when a component has to survive four contexts, every decision gets pressure-tested.
Components that fueled the report
Outcome
From gut feelings to data-backed decisions.
The efficiency gain was significant, but the more meaningful shift was qualitative — PMs moved from "feature debates" to "problem-solving discussions," using the suite to upend roadmap assumptions when the data didn't support them. Impact Reports became the anchor for UserVoice's AI subscription tier.
Impact Reports · The product in use
Feedback that once took half a day to assemble — without touching a spreadsheet
A personal tool became a team artifact
Habitual use at steady state — not just exploration
A PM who shares a report is willing to put their name next to the AI's output. That's the trust problem solved.
Impact beyond reports. The goal was never to replace Themes and Trends — it was to connect them. Impact Reports became a second path into the same data: one that reads like a document instead of a dashboard. From inside the Ideas grid, PMs could surface an Impact Report or a Theme Report depending on what question they were trying to answer. Two AI modes. One workflow.
Impact Report and Theme Report · Linked from the same Ideas list
Reflection
What I'd carry forward.
Build for the moment of sharing, not just the moment of use. The 25% sharing rate was the signal we hadn't designed for explicitly — and it turned out to be the most meaningful outcome. A report that travels beyond the person who ran it validates the format, the trust model, and the AI's output all at once. I now think about "who else will see this?" as a primary design constraint, not an afterthought.
Reports age. The tool shouldn't. Impact Reports is a snapshot — you run it, present it, it ages. The next version needs to surface the delta automatically: what shifted since the last report, what's new, what changed. The insight doesn't freeze when the report is generated.