Customer-facing teams like sales, marketing, support, and customer success have a wealth of insights around what users really need, and product stands to benefit. But only if these insights come in the right form, are captured in one place, and routed to the correct product manager.

How do you communicate the value of submitting insights to colleagues and set the right guidelines for doing so?

Consider this a starting point for what you might share with colleagues to get them onboarded as effective contributors in productboard.

Why submitting insights will help the product team

  • Product ideas, requests, and feedback from the frontlines of the business are what we use to gain deep insight around what users really need, which informs our product vision.
  • In the short run these inputs help us prioritize what product objectives and features to work on next. By including the right context, you can also help us design/deliver features in the optimal way.
  • With a deep understanding of our users our product will meet their needs and delight them in the process. Our customers who are contributing these insights will also feel heard. They'll know we're really listening and continuously working to make our product more valuable for them.

What's in it for customer-facing teams?

  • Influence the direction of the product and the company
  • Delight customers and create more value
  • Close more deals win more renewals/expansions $$$

Best practices for contributing user insights to the product team

  • ✅Submit product ideas, feature requests, and feedback to the product team on a regular basis (when the context and details are still fresh!) through the following channels... (x, y, z)
  • ✅Attribute feedback to the right customer (user/company). Our product strategy may target the needs of certain customers so this information is necessary for it to be useful. We may also follow up with these individuals to ask for more context or even take part in a product beta.
  • ✅Whenever possible, include context around why a user is requesting something or what need that feature would help them address. This helps ensure we build the best possible solution, which may be even better than what the user thought to request. (e.g. Rather than simply relaying a customer's request for a Salesforce integration, help us understand what kind of data that would help transmit between the two systems, and what goals/jobs that would help the user achieve.)
  • ✅To ensure what you contribute gets to the right product manager, tag them in the following way (x, y, z) or assign your notes to the following product managers (a, b, c) depending on the topic or product area.
  • ✅After you've begun submitting inputs, keep an eye on notifications from productboard (by email and accessible when logged in to the application), in case product managers or designers mention you in a comment seeking further context or clarification.

Things to avoid

  • ❌ Avoid sharing non-critical feedback/requests with product managers ad hoc —  by the water cooler, in the elevator, or stopping by their desk throughout the day. Instead submit these into productboard where they can be triaged, analyzed, and prioritized most reliably and efficiently.
  • ❌ Don't assume a user really needs something just because they brought it up in passing. (Often users are merely curious whether a capability exists or have a neat idea they want to share.)
  • ❌Avoid attributing your own ideas to a customer or assuming what solution they need rather than sharing the context they expressed.

Approved channels for submitting feedback

Note to the product manager: These are examples. You might approve additional channels for your contributors to use as well and formulate your own guidelines on how to use them.

Vote on an idea (or submit a new one) on the Product Portal

  • ⏰ Use: Anytime
  • 🗝 Role Requirements: Contributor (to vote on behalf of a user/company)
  • 👍 Benefits: Most efficient for the product team to process (feedback on an idea are automatically linked to that feature)
  • 👆Tip: Remember to add any additional context that could help us identify the user's underlying need.
  • 👆Tip: Remember to access the Portal by logging in to productboard so you can attribute the feedback to a particular customer (otherwise if you access at the regular Portal sharing link you'll be treated like an end user submitting feedback).
  • 👀 More info for product managers

Log in to productboard and create a note

  • ⏰ Use: After a customer call / meeting
  • 🗝 Role Requirements: Contributor
  • 👍 Benefits: Ability to edit later on; able to tag the note, add images; file attachments; can @mention colleagues in comments
  • 👆Tip: Avoid entering the entire set of notes from a customer meeting or call. Share just the parts most relevant to the product team for understanding their un-met needs and the context surrounding them.
  • 👆Tip: If you happen to know which product manager owns the product area or topic that relates to your feedback, @mention them in the comments so they're sure to see it.

Chrome extension

  • ⏰Use: After a customer call / meeting OR to easily highlight and submit feedback in a web app that isn't integrated with productboard.
  • 🗝Role Requirements: Contributor
  • 👍Benefits: Able to add tags; can submit from anywhere; can easily load highlighted text from the browser into the extension; creates a link from the note back to the webpage it was created from
  • 👀More info for product managers

Intercom

  • ⏰Use: When Intercom conversation contains any product feedback / requests / or usability confusion that you consider valuable for the product team to review.
  • 🗝Role Requirements: Intercom access
  • 👍Benefits: After pushing a conversation, any subsequent replies will automatically be pushed into the same note in productboard
  • 👀More info for product managers

Note to product managers: It's common to choose a designated tag (e.g. pb, or product) as a trigger for those conversations that should be pushed to productboard.

Slack

  • ⏰When to use: When a customer's needs are being discussed in Slack (or if you already have a channel for colleagues to submit feature requests)
  • 🗝Role Requirements: Anyone in Slack (or Slack admins only, or productboard members only, depending on integration settings)
  • 👍Benefits: Push entire threaded conversations into productboard; link to a related feature; assign importance; add additional comments; apply tags
  • 👉Note: Product managers can push any conversation but public channels work best. It may also help to create a designated #product-feedback channel.
  • 👀More info for product managers

Note to product managers: Many teams opt to make pushing notes into productboard the responsibility of product managers. In this case colleagues may be asked to submit product ideas, requests, and feedback to a #product-requests channel. Product managers can also push notes to productboard from other channels as needed.

Email

  • ⏰When to use: When notable insight appears in an email thread forward it to feedback@acme.com (memorable email alias you set up to redirect product feedback to your obscure productboard address)
  • 🗝Role Requirements: Able to email the configured email alias
  • 👍Benefits: Automatically attributes the email to the original sender (especially helpful if forwarding an email from a customer)
  • 🙏Please: When forwarding an email, include a summary of actionable points you want the product team to consider. Delete as much content that is irrelevant for PMs before forwarding, e.g. back and forth messages on when you set up the next call.
  • 👀More info for product managers

CSV import

  • ⏰When to use: When looking to import data from CRMs, survey tools, and other solutions that support CSV export. Also: historic data if feedback and requests were captured in spreadsheets.
  • 🗝Role Requirements: Contributor
  • 👍Benefits: Able to edit notes later on; upload many notes at once
  • 👀More info

Closing note for product managers

When sharing these guidelines with contributor stakeholders, consider including examples and non-examples of how notes should/shouldn't look when they arrive in productboard — everything from how they should be named to what tags they should include or how the content should be formatted. Whatever will help your product team process more effectively and have the optimal insights on hand during prioritization and design.

Even after you've presented these guidelines remember that repetition is key — both in terms of reminding colleagues to contribute to productboard as well as reinforcing your guidelines. (Colleague shoutouts works wonders! Especially when you can be specific about what they've done to help provide the most valuable information and make it manageable for the product team to put to use.)

See also

Did this answer your question?