Building products is hard and expensive. Teams often learn they've made a false assumption about what users really need only after a new feature ships and goes underutilized. Worse, the synthesis work that catches those false assumptions used to take weeks: reading feedback, tagging it, finding the pattern buried inside it.
Productboard Spark changes that. Spark reads your feedback the moment it arrives, connects it to what's already on your roadmap, and surfaces the opportunities worth acting on, evidence attached. This article shows you how to build a feedback-to-impact workflow with Spark doing the heavy synthesis, so your team spends its time on judgment calls instead of data wrangling.
In this article:
- 1. Collect customer feedback in a single repository
- 2. Let Spark route and triage feedback automatically
- 3. Turn feedback into insight at scale with Spark
- 4. Decide what to build next with evidence-backed opportunities
- 5. Go from opportunity to spec without starting from a blank page
- 6. Close the feedback loop
- Final tips for putting Spark to work
1. Collect customer feedback in a single repository
Everything starts with getting your feedback into one place. Use Productboard to consolidate user feedback, feature requests, and research notes into a single repository instead of scattering them across inboxes and spreadsheets.
When you're getting started, import historical feedback from a number of sources. You can also bring feedback in from email, Slack, the Productboard extension for Chrome, customer support tools like Zendesk and Intercom, Salesforce, and more.
The moment a piece of feedback lands in Productboard, Spark starts synthesizing. All you need to do is give it something to read.
Make collecting and sharing insights an organization-wide effort
Every team in the above image serves customers, and every team has feedback worth capturing. As a product manager, you're the connective tissue across all of them, so meet your colleagues where they already work:
- Open as many channels into Productboard as possible: Slack, support tools like Zendesk and Intercom, email forwarding with an easy-to-remember address, and Zapier templates for any internal tools your colleagues already use.
- Use any of our feedback integrations, the Productboard extension for Chrome, Portal, or the Notes API. If it's easier for support to submit feedback via Zendesk, let them. If leadership prefers sending Slack messages, that works too.
Show your team what good feedback looks like
Productboard helps you develop a standard for quality feedback with fields for who provided it (company, user) and what it relates to (tags). Formatting options in the description field help you keep feedback readable.
Encourage colleagues submitting feedback to always ask why, seeking the underlying need instead of a bare feature request. Spark uses that context to connect a single piece of feedback to broader patterns, so the more context that comes in, the sharper Spark's synthesis gets.
Consider making feedback templates available with headers for required information (product area, request, user impact) plus reminders for attribution and tags. You can also route a survey tool like SatisMeter, which is fully integrated with Productboard, or use Productboard's built-in form system and portals.
For more, see Enabling contributors to effectively contribute insights and Getting started as a contributor in Productboard.
2. Let Spark route and triage feedback automatically
Feedback is only useful once it reaches the right product maker. To do this effectively:
- Dissect your product into distinct product areas with tags, topics, or keywords, and align on an owner for each area.
- Get feedback assigned automatically with Productboard's automation capabilities, or use the Portal, which associates new feedback to the right feature idea.
- Assign feedback in bulk from Insights boards that map to a maker's product area.
- Assign what's left from the unassigned feedback view.
Spark can take this even further. Instead of waiting for a rule to fire or a person to bulk-assign a board, Spark reads incoming feedback, classifies it, and links it to the right feature the moment it lands, before anyone opens Productboard.
Open your triage queue to find the work already done — hundreds of tickets read, classified, and organized. Work used to pile up, but now it trends down on its own.
For more in-depth tips, see Route feedback to the right person efficiently and Customer feedback management in Spark.
3. Turn feedback into insights at scale with Spark
As you process feedback, highlight insights, and link them to related feature ideas:
- Reduce context-switching by filtering for related feedback using tags, topics, or keywords, and save the view to return to later.
- Review your feature hierarchy regularly to speed up linking. Clean up duplicates, reorganize where needed, and archive features you won't work on in the foreseeable future.
Point Spark at your feedback repository and it can surface the pattern three different customer segments have been describing in three different sets of words, the kind of signal that's technically been sitting in your data for months but was never visible until it was pulled together.
On a larger corpus, Spark can also run a jobs-to-be-done style analysis, showing you the handful of jobs customers are actually hiring your product to do, and how well you're delivering on each one. That's a different kind of insight than a trending tag, one that highlights the structure underneath hundreds of individually reasonable requests.
This builds on the same idea behind Insights trends and smart topics, extended to a scale no one has time to process by hand.
For more, see Turn customer feedback into actionable insights, faster and at scale.
4. Decide what to build next with evidence-backed opportunities
Learn what matters most to your customers and spot the larger patterns that should inform your roadmap:
- See top-requested feature ideas on a grid board, sorted by the Customer Importance Score, or filtered by a segment or company.
- Quantify feature value using total revenue from current customers, with aggregated customer fields.
- Use trending needs to inform the objectives you set to prioritize.
- Explore the qualitative insights behind every feature idea before you commit to a direction.
Spark doesn't wait for you to open a board. It proactively ranks opportunities by evidence, not gut feel, and hands you a briefing that already cites the customer conversations, tickets, and threads behind each one. If a fast-growing pain theme in your feedback has no corresponding item on your roadmap, Spark flags the gap directly, so a request that's been quietly building for two quarters doesn't stay invisible for a third.
See Spark: Explore weekly opportunity briefings for details.
5. Go from opportunity to spec without starting from a blank page
Deciding what to build is only half the job. The other half, writing something engineering can build from without a dozen follow-up meetings, is where teams lose the most time.
Open a Spark spec from any opportunity and Spark writes the first version for you. This draft is grounded in your product's current state, the customer evidence behind the opportunity, and your existing strategy.
Spark asks the judgment-call questions only a PM can answer (should this be exposed via a public API? How should it surface during onboarding? ...) and handles the rest on its own. Teams see a delivery-ready first draft in minutes instead of days, with you steering the parts that matter and Spark handling the parts that follow from context it already has.
See Write product specifications with Spark for details.
6. Close the feedback loop
Sometimes it feels like there's a gap between the product team and the customers you serve. Portals help bridge it.
Post one or more timestamped updates to a portal card to keep users informed of a feature's progress. Updates are visible to everyone who visits the card, plus colleagues in your workspace, and can be emailed to everyone who requested the feature or submitted feedback linked to it.
Looking ahead, Spark is working toward closing this loop even further by comparing what actually happened after launch to the goals set in the spec, and surfacing that comparison back to the team automatically. This capability is still developing, so treat it as a preview of where the workflow is headed rather than something to build a process around today.
For more, see Close the feedback loop with Portal card updates.
Best practices
- Find a senior sponsor or champion to support the process.
- Clearly define expectations for each member of your team.
- Define success metrics. Two worth considering: the unassigned insights board reaching zero weekly, and makers keeping their active product area insights boards at zero weekly. Spark makes both easier to hit, since it clears most of the queue before your team ever sees it.
- Monitor your team's processing and rebalance the load if someone's getting too much feedback.
- Block time, or set a recurring reminder, for your team to review what Spark is surfacing. The insight is worthless if no one looks at the briefing.
- Keep repeating the benefits of staying close to user needs. No one wants to build features that go unadopted, and now there's less excuse for it to happen.
- Recognize and reward colleagues who submit valuable feedback. A little healthy competition never hurts, and better raw feedback means sharper Spark output for everyone.