Tracking & sharing user & stakeholder feedback

Our passionate users and stakeholders, both internal and external, provide a constant stream of thoughtful feedback and love engaging with us to help them and their teams solve their toughest problems. This trust and feedback is a gift, and we take it seriously and listen carefully to what users tell us.

This page is most relevant to product team members. If you want to know how to best share feedback with the product team, please see surfacing product feedback.

Sources of feedback

Tracking & sharing user & stakeholder feedback

Sales feedback

Purpose: Customers and prospects often give product feedback on calls with sales members.
Owner: The Sales team owns feedback from sales calls.

The product team can access recordings using Chorus AI. You can find relevant calls using Chorus’s search and tracker features, which allow you to use keywords to explore call transcripts.

CE feedback

Purpose: CE teammates work closely with customers and often collect explicit customer feedback, general patterns of feedback they notice with a customer(s), and feedback from using the product themselves.
Owner: CE owns raising customer or prospect feedback as product gaps. Product owns triaging those product gaps, and keeping CE updated about prioritisation decisions, if the items ends up on the roadmap.
Pipeline: Each time a product gap submission is added to salesforce, it is posted in #feedback, @-mentioning the PM of the relevant product area. This is powered by a Zap.

Other resources (internal only) the CE team owns:

The product gaps dashboard tracks features that are impacting deals.
Account overview dashboard.
Account plan documents provide the business context for the accounts.
Technical Design Documents reflect what the latest state of the customers’ environment.
Customer notes are running notes from customer Chorus calls.

Email lists

We have a few different email lists that are used to send us feedback.

hi@sourcegraph.com

Purpose: This email list is used as the reply-to for our release emails, and is a general way for people to reach out and get in touch.
Owner: The product team owns replying to all incoming emails, and routing them as appropriate to Support, Sales, Hiring, etc.

feedback@sourcegraph.com

Purpose: This email list is used to request feedback from inside of Sourcegraph, and to give to customers to reach our product team with their feedback directly.
Owner: The product team owns replying to all emails, and triaging all feedback delivered.

support@sourcegraph.com

Purpose: This email list is for customers to request help and connects to Zendesk.
Owner: The Customer Support team is responsible for all support issues and will pull in as needed engineering teams or product to help answer questions.

GitHub issues

Purpose: Anyone within or outside of Sourcegraph can file issues (like bugs or feature requests). Issues are often a developer’s default place to leave feedback.
Owner: For issues filed by Sourcegraph teammates, the filing teammate is responsible for making sure the issue is labeled with the team’s label. For issues filed by someone outside Sourcegraph, product managers are responsible for labelling with the right team.

See How to reference customer names in public tickets.

Twitter

Purpose: Anyone can tweet about @Sourcegraph for public feedback. All tweets are in #twitter on Slack.
Owner: Marketing.

Slack

Purpose: Slack is a fast way for existing customers and Sourcegraph teammates to provide feedback.
Owner: We ask that teammates surface product feedback in #feedback. Product managers own routing and logging this feedback.

Support tickets

Purpose: A path for existing customers to get responsive support.
Owner: CS team owns support tickets in Zendesk. If product team members want more insight into the support feedback, they can review the support dashboard or scan the customer issues repo, and cross-reference both with slack searches in support channels. Additionally, at the end of every quarter, the Head of Customer Support provides the product team with a qualitative summary and links to details of the major support trends from the prior three months.

Hubspot forms

NPS Survey

Purpose: We prompt customers to provide NPS ratings from within the Sourcegraph UI. On Sourcegraph version 3.41 and above, we also prompt about use cases.
Owner: Product managers own responding to or forwarding actionable NPS feedback.
Pipeline: This is powered by two Zaps: one for Sourcegraph 3.40 and below, and another for Sourcegraph 3.41 and above that also handles use cases data submissions. Submissions that have written feedback (as opposed to only a rating), are saved as a productboard note and posted in #feedback. Submissions with only a score are posted in #feedback-nps. In addition, if the feedback contains obvious keywords (eg. ‘Code Insights’), the PM of the relevant area will be automatically @-mentioned on slack. The CE and AE owners of the deal are also mentioned if they have added their handle to this spreadhseet. This is based on account ownership as available in this look.

Purpose: Users can submit feedback from the Feedback button of the Sourcegraph UI.
Owner: Product managers own responding to or forwarding any actionable happiness widget feedback.
Pipeline: This is powered by a Zap. Submissions that have written feedback (as opposed to only a rating), are saved as a productboard note. In addition, if the feedback contains specific keywords, the PM of the relevant area will be automatically @-mentioned on slack.

Browser Extension Uninstall Feedback

Purpose: We ask everyone who uninstalls the browser extension why they no longer want it.
Owner: The browser extension product manager (currently the Integrations team product manager) owns responding to this feedback.

Productboard

We aggregate all of this feedback in productboard. This lets us look at all of the sources of feedback to better understand which features will have the biggest impact on the product. It helps with prioritization and making sure we’re building the next most important thing. It also helps us maintain a long-term source of truth for feedback: some of our sources of feedback are subject to removal over time due to retention policies, so adding specific insights to productboard captures it for the future.

In case you have longer google docs (eg. customer discovery notes) that don’t fit in productboard cards:

put the doc (or a shortcut) in the customer feedback notes folder, using the following naming convention YYYYMMDD - Customer - Subject (e.g. 20222806 - Acme - Code security).
create snippets for key insights into Productboard

Adding feedback to productboard

All of the above sources of feedback (with the exception of HubSpot forms) require the team help forward that data into productboard using an available integration:

Slack integration: Hover on a message containing feedback, select the more actions menu (three vertical dots), and then choose ‘Push to productboard’. This will post a message to the thread/channel that’s visible, so keep that in mind if customers are in the channel.
browser extension: Use the browser extension for quick entry from a web page, or to just simply enter information when you think of it.
forwarding email address: You can forward email threads, or write notes as emails to push information to productboard.

Whenever possible, please use productboard links to share specific user feedback with others and in documents like RFCs. If something is worth sharing and doesn’t already exist in productboard, it’s the perfect opportunity to add it to productboard!