Conversation
ignore if not helpful
|
Thank you! Sorry I did a weird fork thing! |
|
@Joelkw not on you! Our perms were bad! |
| ❗️Typically actually creating an Insight isn't required—the key is for the user to come away understanding that Insights can be created from the Insights page or from search results. | ||
| ❗️Typically actually creating an Insight isn't required—the key is for the user to come away understanding that Insights can be created from the Insights page or from search results. | ||
|
|
||
| The hardest part, and most valuable thing to help with, for most customers and non-Sourcegraph-power-users is refining the regular expression or literal search that actually helps them track what they need. You can direct them to the in-product templates, also [listed here](https://docs.sourcegraph.com/code_insights/references/common_use_cases), but even better is to leave time to work with them to set up the query they need. |
There was a problem hiding this comment.
| The hardest part, and most valuable thing to help with, for most customers and non-Sourcegraph-power-users is refining the regular expression or literal search that actually helps them track what they need. You can direct them to the in-product templates, also [listed here](https://docs.sourcegraph.com/code_insights/references/common_use_cases), but even better is to leave time to work with them to set up the query they need. | |
| ❗️ Customers may need help refining their query. If this comes up, look to schedule a dedicated session for that, as it can derail a 101 training just due to timing. Templates are included in the resources section for this unit, and should be leveraged. |
There was a problem hiding this comment.
@emchap personally, I would push back on this, recommending that a CE intentionally should tell someone saying "I want to make an insight, I just need help with my query" that "we'll come back to that in a future training" because we are so, so close at that point to helping them create their first insight and the value of that adoption, and of getting them to that first insight, is massive for further adoption and retention which drives the usage and expansion revenue.
"Let's help get them to make a first insight that matters to them, on the call/before they get pulled away from it" is basically the goal of any insights enablement (IMO, at least it is on most calls I join) so it feels odd to stop short.
I don't know what the time tradeoff is here (so maybe you're right, this could be the right tradeoff!), but short of introducing them to some other core functionality (batch changes, search) I see this as potentially more valuable time spent than going over most other features that they "may" or "could" use vs one they are ready to set up, right then and there, if we help them.
There was a problem hiding this comment.
@Joelkw This is the first enablement training that the entire userbase gets; we're balancing one user's Insights needs against needing to cram everything else the product does into an hour. (If more than 1 user is interested in the Insight, ideally the CE can just fold that usecase into their demo using that knowledge ahead of time.)
Insights is useful, but in general my experience is that moving to customer sharing their screen + explaining what they want to do + the CE maybe or maybe not knowing how to write that query on the spot is going to derail the limited available time—that's why historically I've tackled Insights enablement in dedicated meetings with individual users.
@sourcegraph/customer-engineering Does anyone have strong feelings about what has/hasn't worked for them? Def let me know if I'm offbase.
2 participants
@Joelkw made these.