Executive Business Reviews (EBRs)
View the CSM Handbook homepage for additional CSM-related handbook pages.
Overview
An Executive Business Review (EBR) is a strategic meeting with stakeholders from both GitLab and the customer. It is an extension of the account planning process and part of the CSM’s regular business rhythm. The EBR Review aims to demonstrate to the customer leadership and stakeholders the value they are receiving in their partnership with GitLab.
The EBR is interactive, with discussions on the customer’s desired business outcomes, ROI metrics, progress against these metrics, and alignment on strategic next steps. The key element of an EBR is providing customer stakeholders the opportunity to speak on what matters to them and creating a success plan to achieve their business goals.
Alignment with Stakeholders: The Importance of the EBR
The Executive Business Review (EBR) is an essential opportunity to align on strategic goals, assess progress, and plan for future success. It typically brings together both GitLab and customer leadership to ensure mutual understanding and continued collaboration. During regular meetings, introduce the EBR to key customer stakeholders, highlighting its value in driving business outcomes and fostering stronger partnerships.
GitLab encourages participation from decision-makers and influential stakeholders, as their insights and feedback are crucial to a productive EBR. Scheduling can take time, so initiating this discussion at least three months in advance is recommended to ensure availability. After the conversation, provide a follow-up summary outlining the EBR’s purpose and key scheduling details.
Stakeholder Recommendations
Customer Stakeholders that would benefit from an Executive Business Review
| Customer Stakeholder Recommendations | GitLab Potential Attendance |
|---|---|
| Application Security (for example, SVP, VP, Director) | Customer Success & Leadership |
| Engineering Leadership (for example, SVP, VP, Director) | Sales & Leadership |
| Site Reliability Engineering Leadership (for example, SVP, VP, Director) | Engineering & Leadership |
| Chief Technology Officer | Product Management & Leadership |
| Chief Information Security Officer | Solution Architects & Leadership |
| Chief Product Officer | |
| DevOps Leadership (for example, SVP, VP, Director) | |
| Product Leadership (for example, SVP, VP, Director) |
Executive Business Review Process and Overview
This section outlines the EBR process, highlighting key stages: preparation, delivery, and follow-ups. While the process can be tailored to meet specific customer needs, this guide provides a typical flow to ensure strategic alignment, seamless execution, and timely action on key outcomes.
- Internal Alignment (3-4 months prior): CSM and the account team set goals, timing, and participants to ensure a successful EBR.
- Initial Customer Discussion (3-4 months prior): CSM engages with the customer to define focus areas and align attendees.
- Scheduling (2-3 months prior): Confirm date and attendees, and secure participation from GitLab leadership.
- EBR Planning (1 month prior): Build the EBR content, aligning with internal and customer stakeholders to ensure strategic focus.
- Internal Review (3-4 weeks prior): Finalize the presentation with internal GitLab teams and adjust based on feedback.
- Customer Review (2-3 weeks prior): Validate the agenda and content with the customer to ensure alignment with their expectations.
- Final Prep (2 weeks prior): All GitLab participants align on objectives and final details for the EBR.
- Delivery: The EBR is conducted, focusing on strategic alignment and driving outcomes for the customer.
- Follow-ups (Within 1 business day): A follow-up email is sent to review action items, ensuring timely completion. The Success Plan is also updated to reflect insights from the EBR.
Final Review with the Customer
Throughout the EBR’s development, the CSM & account team collaborate with their customer contacts. A final review of the EBR is conducted with the account team and customer contacts to ensure content & talk track align with expectations and are properly structured. Proactive communication is coordinated to keep the EBR planning on track and include all necessary participants.
Sample Agenda: Reviewing ROI, Impact Analysis, and Future Goals
The EBR session focuses on evaluating the customer’s GitLab adoption ROI, its impact on their business, and alignment on future goals. It provides an opportunity to review progress, address challenges, and plan next steps to ensure ongoing value and strategic alignment.
Sample Agenda:
- Welcome and Introductions – Overview of key attendees and meeting objectives.
- Customer Journey – Overview of the reason for purchase and GitLab enablement/ROI journey.
- ROI & Value Review – Assess the measurable impact of GitLab solutions on business outcomes.
- Adoption & Success Metrics – Review current adoption progress and identify areas for improvement.
- Future Goals & Roadmap Alignment – Discuss upcoming initiatives, long-term goals, and how GitLab can support them.
- Action Items and Next Steps – Confirm key takeaways and follow-up actions to drive future success.
Additional Conversation Points
These questions facilitate discussion and help uncover key business objectives:
- What are your largest current initiatives and areas of focus?
- Looking ahead, what are your top 2-3 priorities for the coming year?
- What significant changes have occurred since last year?
- Where do you envision your organization in the next few years? What are your long-term goals?
- Regarding security, how does your team handle the triage and resolution of issues? Who is involved, and how does this impact cycle time?
- How are security vulnerabilities affecting your development processes and timelines?
- Can you walk us through your cloud and app modernization strategy?
- What visibility do your leaders have into progress, and how are you gathering this information?
- For initiatives without clear metrics & due dates: What does success look like for this effort? How will you measure progress and outcomes?
EBR Length
The recommended EBR length is typically 90 minutes; however, this is flexible based on customer needs and content. An EBR should provide time for key focus areas and customer objectives, ensuring maximum benefit to all involved.
EBR Location: Maximizing Value through Flexibility
EBRs can be flexible to online or onsite. An in-person EBR is ideal to maximize interaction and discussion among participants. Additional sessions should be scheduled around the EBR itself, such as:
- Enablement sessions aligned with ongoing adoption efforts or future adoption plans.
- Meetings with customer stakeholders for GitLab use cases to align on use case adoption & value.
Follow-ups
Summary Email
Within 1 business day, the CSM sends a follow-up email thanking participants, summarizing key takeaways, action items, and next steps, with assigned responsibilities and deadlines. The email will also include the slide deck and any agreed-upon materials.
Action Items
Action items and next steps, captured in the EBR deck and discussion, must be promptly addressed. The CSM ensures follow-ups are completed by the responsible parties to maintain momentum.
Success Planning
No EBR is complete without updating the success plan. Within a few days of the EBR, while information is fresh, the CSM updates the customer’s success plan with the confirmed objectives and action items. All sections of the success plan should be updated based on the EBR discussion & takeaways.
FAQ
Q: Is this EBR just another sales pitch for renewal? A: No, it is not. The EBR is a strategic touchpoint focused on aligning GitLab with the customer’s organizational objectives, not a renewal conversation. Renewal discussions are separate and follow a different process.
Q: Who should attend the EBR from the customer side? A: Key stakeholders who influence or oversee strategic initiatives should attend, ensuring the session aligns GitLab solutions with long-term objectives.
Q: How is an EBR different from regular cadence calls? A: Cadence calls are often project-focused, whereas an EBR provides a strategic review of long-term goals, current successes, and future roadmaps, involving leadership from both sides.
Q: How are feature requests handled during the EBR? A: The EBR focuses on strategic goals, but notable feature requests aligning with objectives may be acknowledged. In-depth feature discussions are usually handled separately.
Q: What kind of preparation should a customer do before the EBR? A: Reviewing GitLab usage and identifying upcoming initiatives or goals helps ensure a productive discussion on how GitLab can best support objectives.
For further details, visit: GitLab Success Plans Documentation
418f2492)
