CE Management of the Technical Win
Background
CEs are tightly aligned with the sales team and serve as technical experts, providing strategy and guidance to AEs during the sales cycle. Ultimately it is the CE that owns the “technical win” associated with an opportunity.
To be successful in driving technical wins requires the ability to:
- Help define and document customers’ use cases as confirmed during the qualification stage of the sales process
- Validate the technical viability of our solution against customers’ use cases using criteria provided by Engineering
- Understand how to leverage resources across the CE organization and other internal teams to secure the win
- Track and communicate the technical win status with the sales organization and other teams in a way that aligns with Sourcegraph’s company culture of remote and asynchronous communication
For the sales organization to scale effectively as our business grows, it needs to engage not only with opportunities that meet the Target Opportunity Profile criteria as already defined. It also needs to understand whether or not a customer’s use cases can be met by our product based on a set of defined technical qualification criteria and customer-defined success criteria.
Assets
| Name | Purpose | Sales Stage | Status |
| Salesforce Opportunity | The official record of activity associated with a sales opportunity in Salesforce. Opportunities are typically created at the interest stage (Stage 1) of the sales cycle. | 1-7 | Published |
| Customer Engagement Process (Pre-Sales) | This document outlines the process for engaging with a customer or prospective customer from the early stages of the sales cycle (Stage 0 - Prospecting) to when a deal is closed. It covers the objective, key players, verifiable outcomes and resources at each stage of the sales process. | 1-7 | Published |
| Sourcegraph Use Cases Master Doc | A document containing a variety of resources related to the high-level, strategic business challenges of our customers and prospects, which Sourcegraph can solve for with the technical and capabilities delivered by its products. Each use case is documented here with relevant personas, pitches, positioning, indicators of need/value, discovery questions, and other resources. | 1-7 | Draft |
| Customer Discovery Playbook | Provides CEs with a framework and tools to successfully prepare for and conduct your initial meetings with prospective customers (or even new stakeholders within existing customer organizations).
It also provides key areas for CEs to consider and specific steps to take to ensure the CE has the correct context and knowledge to properly support a successful customer engagement beyond the initial meetings. |
2-3 | Published |
| Technical Design Document
(Internal) |
A living document that is used to track information about customers - their needs, their technical environment, use cases, etc. At first, this document captures details about the customer prior to Sourcegraph, then during the trial phase, and subsequently as they move to production.
Store Completed TDDs Here |
2-4 | Published |
| Joint Success Plan
(External) |
This document serves as a single source of truth for both the Sourcegraph Account Team and a prospective Sourcegraph customer during the evaluation and buying process. It includes sections maintained by the sales team around a mutually agreed upon action plan and by the customer engineering team to document technical success criteria and the trial process.
Store Completed Success Plans [Here] |
3-7 | Published |
| Product Feature Compatibility Documentation | This page is intended as a reference of features by code host compatibility; each item will link to further documentation on the feature. | 3 | Published |
| Product Feature Maturity Documentation | This page is intended as a reference of features by maturity level; each item will link to further documentation on the feature. | 3 | Published |
| What Is Supported in Sourcegraph? | Guidance provided by Engineering teams documenting supported features and functionality as well as feature limitations. This is used by CEs to perform technical qualification of customer use cases and configurations during trial planning and prior to trial kickoff. | 3 | Published |
| Technical Qualification Discovery Questions | Based on the guidance provided by product and engineering teams, this document contains a list of questions to which CEs should have answers to assess whether a customer’s configuration or use case fits our product capabilities and supported scenarios. If it does not fit, the deal must be submitted to the Tech Review process and then validated based on product/engineering feedback. | 3 | In-Process |
| Post Sales Engagement Plan | CEs are responsible for the technical success of our customers. There are a variety of activities that CEs engage in around the time of deal close and afterwards. This template serves as an outline and plan for those activities over the course of the customer’s first year using the product. | 5-7+ | Published |
Process
Gates for Progressing Through Technical Win Phases
Customer Engineering has defined five (5) phases across which we will be tracking the status of the technical win. These five phases map to one or more of the seven (7) defined sales stages.
The following criteria are used to determine whether a technical win should progress from one phase to the next in the process. All criteria should be answered “yes” before progressing to the next phase.
Initial Conversations (Sales Stages: 0-2)
- Has the account team identified a champion in the account?
- A champion is a contact in the account with power and influence who will be selling internally on our behalf and has a vested interest in our success.
- As defined by the Customer Engagement Process, the champion typically confirms use cases, identifies the business/technical validation process and confirms the technical win.
- Has the CE confirmed the top 2-3 use cases for the customer?
- Does the CE understand the customer’s technical landscape and current tools?
Tech Design & Trial Planning (Sales Stage: 3)
- Has the CE defined the technical validation plan (demo, self eval, trial, etc.) which will be used to determine whether they have achieved the technical win?
- Has the CE completed technical qualification of the customer’s usage scenario?
- If the opportunity has non-standard or high-risk technical requirements as defined by the technical qualification criteria, has the CE gone through the Tech Review Process and received approval to proceed?
- CE has completed the Technical Design Document v2
Trial Deployment (Sales Stages: 3-4)
- CE has updated the Technical Design Document v2
- CE has completed the Trial and Deployment portions of the Joint Success Plan
- Is the trial or evaluation environment successfully deployed?
Trial Execution (Stage 4)
- Has the CE established a regular check-in with the customer champion?
- Has the account team delivered a trial/POC readout for the customer?
- Has the customer confirmed that we have achieved the technical win?
Post-Trial (Stages 5-7)
- CE has completed a v1 draft of the Post Sales Engagement Sheet
- CE has updated the Technical Design Document with details about the customer’s production deployment plans
- Welcome kickoff meeting is scheduled with the customer
Technical Design Document Creation and Review
As early as the Qualification stage (Stage 2), CEs begin to collect information about and work to understand the needs of prospective customers. The learnings from these discussions (business and technical challenges, current environment, and technical and functional requirements) are recorded in a Technical Design Document.
- Every prospective customer must have a Technical Design Document established starting as early as Stage 2 (Qualification) and completed by Stage 4 (Technical and Business Validation). TDDs are stored in a central repository for easy collaboration with other CEs, Sales, Support, and Engineering.
- All TDDs for Tier 1 accounts must be reviewed by a peer on the CE team.
- All TDDs with non-standard technical requirements must be reviewed by a peer on the CE team.
Tech Review Process
Deals flagged as having non-standard or high-risk requirements must go through the Tech Review Process before moving to Trial Deployment (late Stage 3).
How the Process Works
When a Tech Review is needed, the CE initiates this process by doing the following:
- Completes a peer review of the TDD and opportunity with a peer CE.
- Records a 5 min loom video (stored here) to give a short verbal overview of the deal, the key risks for the opportunity including tradeoffs and pros or cons where applicable, and articulate specific asks of Product, Engineering, and Support.
- Initiates the request in the #tech-deal-reviews channel via the ‘Request TDD Review’ shortcut in Slack and includes a link to the loom video and to the TDD.
- Documents the results of the Tech Review in the TDD.
Product Directors will review and assign the appropriate Product Managers (or others involved) to review the TDD. This asynchronous review should be completed within 3 business days.
If there are additional questions, the Product Team member can request a synchronous review. That review will be recorded and documented to show the decision-making process and provide additional context. CEs are responsible for scheduling the synchronous review and including the appropriate stakeholders.
Roles and Responsibilities
Customer Engineer
- Responsible for creating the Technical Design Document (TDD) for each new customer.
- Responsible for identifying any non-standard or high-risk requirements.
- Responsible for registering Product Gaps against non-standard or high-risk requirements as required.
- Responsible for communicating with their AE when non-standard or high risk requirements emerge.
- Responsible for initiating the process to get the TDD reviewed prior to the deal progressing toward deployment or trial.
- If a request is made for a synchronous review, the CE will schedule and facilitate.
Product, Engineering and Support
- When a deal review request is raised, Product Directors are responsible for designating appropriate individuals to review.
- Initial feedback on the review should occur within 3 business days.
- Any member from Product, Engineering, or Support may request a synchronous review.
Sales
- Responsible for providing necessary business context around the deal.
- Where applicable, responsible for prioritization decisions.
Surfacing Product Feedback
Because CEs work directly with Sourcegraph users in the course of assessing the technical fit of the product for a prospective customer, they will likely receive feedback about the product and identify product gaps which might potentially block adoption. All such feedback should be shared with the Product Team.
It is important to distinguish all customer feedback CEs receive from what would be considered a product gap. A product gap would be some feedback a CE collects from a prospect during the initial sales cycle, or from an existing customer, that could be within the expected scope of work for Engineering. This especially pertains to either new feature requests or enhancements to existing features that could likely be incorporated into our roadmap. In contrast, a product feature or functionality that does not perform as documented might be a bug and should be handled through Product Support.
All feedback and product gaps identified by CEs must be registered as a Product Gap in Salesforce with the appropriate taxonomy and documented impact. The Sourcegraph Handbook outlines how to document Product Gaps appropriately.
Weekly Tech Win Review
CE Leadership conducts a weekly review of the technical win status in all Stage 2-4 opportunities in the current Fiscal Quarter (FQ) and all Stage 3-4 opportunities in the next FQ. This review is executed either as a “stand up” style meeting where CE Leadership reviews each opportunity with the CE owner or it can be done asynchronously based on updates the CE makes to the status of the technical win in Salesforce. Each CE Manager will determine how Weekly Tech Win Review will be executed for their team.
Salesforce Technical Win Dashboard
For each CE, the Technical Win Dashboard in Salesforce shows a summary of all S2+ opportunities in the current FQ and all Stage 3+ opportunities in the next FQ assigned to that CE. Each opportunity is displayed on the dashboard with information specific to the technical win status of that opportunity:
| Field | Description |
| Opportunity Name | Name assigned to the opportunity. |
| Customer Engineer | This is the Customer Engineer assigned to the opportunity. |
| Account Executive | This is the Account Executive who is assigned as the owner of the opportunity. |
| Sales Stage | This is the sales stage of the opportunity. CEs are most active during Stages 2-4. |
| Opportunity Due Date | The date by which the Account Executive expects the opportunity to close. |
| Tech Win Phase | Current Tech Win Phase for the opportunity which is one of five (5) selections: Initial Conversations, Tech Design & Trial Planning, Trial Deployment, Trial Execution, and Post-Trial. |
| Technical Win Due Date | The date by which the Customer Engineer expects to receive customer confirmation of the technical win. |
| Technical Win Next Step | What next action is required by the Customer Engineer. |
| Mutual Action Plan | URL for the Joint Success Plan which includes the Mutual Action Plan (AE) as well as the Trial and Deployment Plan (CE). |
| Technical Design Document | URL for the Technical Design Document for this customer opportunity. |
| Technical Win Achieved | Yes/No - Customer champion has confirmed that we have met their technical validation criteria and we have the technical win. |
| Weekly Check-In w/Champion | Yes/No - Does the CE have a regular (weekly) check-in established with the customer during the trial execution? |
| Non-Standard Requirements | Yes/No - Does the customer’s configuration or use cases fall outside of the supported features or limitations of the product? |
| Tech Review Link | If this is a non-standard configuration, a link to the submission for Tech Review. |
Engaging Subject Matter Experts
Given the breadth of technical information and problems CEs face, it’s unrealistic to expect all CEs to be experts in everything. CE Subject Matter Experts (SMEs) will play a crucial role in engaging in more complex engagements where a deeper understanding of a particular technology, product, or industry is required. When the level of complexity of an opportunity starts to become too deep for a generalist CE, it is crucial that they engage the appropriate SME.
When engaging a SME, the CE does not abdicate ownership of managing the technical win for the opportunity. They are to remain assigned as the Customer Engineer on the opportunity in Salesforce and are responsible for coordinating the activity of SMEs and communicating the status of the technical win while SMEs are engaged.
When to Pull in Subject Matter Experts (SMEs)
- CEs should engage a SME when they need help to achieve the technical win.
- The opportunity should be properly qualified (sales stage S3+) before a CE engages a SME in the opportunity.
- The contributions needed from the SME should be well-defined and time-bound.
- CEs should first exhaust the resources available to them (product documentation, CE StackOverflow instance, Slack channels, etc.) before engaging a SME.
Types of Subject Matter Experts (SMEs)
- Peer CEs with expertise in a specific area of the product, a deployment methodology, or a 3rd-party solution which is being integrated with Sourcegraph
- Product Managers with more in-depth knowledge of a feature or capability of Sourcegraph and who can provide information around future plans
Engaging SMEs - Examples
Technology SME Example
Alex is a CE assigned to work an opportunity with XYZ Company and has a fruitful demo with them and things are moving towards a trial. During the trial-planning process, Alex discovers that XYZ Company has a strongly opinionated and very technical devops team, and that high availability for the Sourcegraph deployment will be required to get the technical win. They have questions about customizing their Kubernetes deployment and Alex doesn’t have deep Kubernetes experiences. In this case, they may choose to pull in a peer CE with that knowledge to talk with the customer.
- Does the effort directly contribute to the technical win? Yes.
- Is the opportunity qualified? Yes - Moving to trial.
- Is the request well-defined and time-bound? Yes - Single meeting w/customer.
Product SME Example
For ABC Company’s trial, Sourcegraph’s batch changes feature is a critical part of the deal. A few of the customer’s most influential developers asked a lot of challenging questions during the first demo. Alex thinks that setting up a special batch changes training session would be especially helpful to earn the technical win. Alex engages a batch changes SME to co-run the session with him so that he is well-equipped to give the best customer experience around batch changes.
- Does the effort directly contribute to the technical win? Yes.
- Is the opportunity qualified? Yes - Solution mapped to batch changes (S2+).
- Is the request well-defined and time-bound? Yes - Single meeting w/customer.
How to Pull in SMEs
There is no formal process today for engaging a SME. For engaging a peer CE as a SME in an opportunity, sending a message to ce-internal in Slack will likely help find the right resources.
Product Managers are a great option for a SME for product areas. It’s worthwhile to consider pulling them in for feature feedback, after the rollout of major updates, or for especially large opportunities. However, pulling in PMs for every opportunity is not a scalable process. CEs should default to peer CE SMEs whenever possible.