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.
- Tracking & sharing user & stakeholder feedback
- Purpose: Customers and prospects often give product feedback on calls with sales members.
- Owner: The Sales team owns feedback from sales calls.
- 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.
We have a few different email lists that are used to send us feedback.
- 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.
- 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.
- 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.
- 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, the product manager on feedback rotation is responsible for labelling with the right team.
- Purpose: Anyone can tweet about @Sourcegraph for public feedback. All tweets are in #twitter on Slack.
- Owner: Marketing.
- 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.
- Purpose: We prompt customers to provide NPS ratings from within the Sourcegraph UI.
- Owner: The product manager on feedback rotation owns responding to or forwarding NPS 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 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
Feedbackbutton of the Sourcegraph UI.
- Owner: The product manager on feedback rotation owns responding to or forwarding 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.
- 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.
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.
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!