The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Product operations is a critical function of scaled, product-led organizations. Product operations' function and focus might change based on the company's maturity, client demands, and the product itself.
A good product operations function will define, communicate, and improve standardized practices including tools, planning, team meetings, and training.
A great product operations function will sit at the crossroads of product management, UX/design, and engineering, allowing cross-functional teams to consistently, flexibly, and creatively deliver outcomes to customers/users through strong feedback loops and process automation.
An excellent product operations function will design and implement systems to continuously drive collaboration between product management and teams across the business, including marketing, sales, and customer success, resulting in accelerated feedback loops, critical data collection/exposure, and feature adoption improvement.
Product Operations at GitLab aspires for the good, the great, and the excellent! Given that all our practices and workflows are transparently published in our handbook, we have a unique opportunity to define and demonstrate what Product Operations can achieve for software companies, and we take this opportunity to heart. We run Product Operations as an independent function under the Product umbrella. This allows the function to maintain a broad and unbiased view to develop strategies/tactics serving the Product team as well as the whole business without favor toward any particular group.
We are continually working to apply the following strategies and tactics:
And we do this all through an open core product with an all-remote, global team. This means that our definition of Product Operations is a community contribution product system that drives efficiency and results without the traditional boundaries that restrain most product development methodologies.
A world-class product system, that GitLab team members and the wider community can benefit from.
Empower GitLab to be product-led and customer-centered, by iterating on Agile/Lean best practices with a remote-first mindset, one MR at a time.
We embody all GitLab values, with a deep appreciation for collaboration. Product Operations is only as good as the sum of its contributions from the whole product development team and its stable counterparts. Teams that share accountability for (product) ownership invent better solutions and gain traction with less internal friction. These teams bond and rally around achieving a shared definition of success.
We prioritize results and efficiency by valuing outcomes over outputs. This mindset is propelled by our core product development flow, which rallies us around the goal of delivering business impact to GitLab's customers and users with every iteration. Anything that doesn’t contribute to this overarching goal is waste and will be removed from our product system.
We continually align around our product principles, with a focus on understanding the customer problem rather than assuming we know the solution. A single problem will have multiple solutions with varying impact potential. Customer-focused teams maximize value by prioritizing one problem to generate multiple solutions, rather than assuming a singular solution to solve multiple problems.
We build feedback bridges between Product and other teams, such as Marketing, Sales, Customer Success, UX/Design, and Engineering The most important success metric for any (product) team is the time it takes to move through the Think-Make-Check (or Build-Measure-Learn) cycle. Teams that iterate successfully and quickly through this cycle have continual access to qualitative and quantitative data through every phase of development and across every function in the business.
We support high-functioning, cross-functional teams by creating flexible frameworks that support confident decision making along with the permission to fail, which in turn fuels velocity. When teams have psychological safety, they are more likely to take risks and move faster, which ultimately leads to bigger ideas and better MVCs toward those ideas. These teams lose judgment in favor of trust.
Continuing GitLab's leadership in the "all remote" work revolution. While the Covid pandemic has given remote working an unexpected relevance and urgency for organizations worldwide, even prior to the pandemic remote working had begun taking precedence due proof around the core, repeatable benefits*:
As a successful all-remote organization, GitLab is already familiar with the benefits of workplace flexibility. We know that remote teams have the ability to move fast, in both parallel and non-parallel workflows, achieving optimal efficiency. And by dogfooding our own all-remote guide and all-remote cultural tips, we've demonstrated remote teams are not just more productive, but happier and more innovative when autonomy and ownership are combined, allowing a focus on goals/outcomes rather than hours/outputs to measure success. With remote-first working practices more at the forefront than ever, GitLab as an opportunity to continue leading by example, helping organizations across various industries, not just technology. We can help teams lose the disadvantages of in-office work, such as office politics. And we can help teams translate the benefits of in-office culture, such as the empathy that comes from human connection, to an all-remote environment. Product Operations will work cross-functionally to ensure GitLab's product team best practices are continually handbook first such GitLab and non-Gitlab teams can benefit from our learnings, in alignment with our value of transparency.
*Statistics reference via Forbes
Productizing our product development successes for the benefit of our users as well as the benefit of GitLab as a business. As an open core product, we have the unique advantage that what we build for ourselves at GitLab can be productized for our customers and improved upon by our users. This means that every strategy/tactic we leverage to optimize our internal processes, be it an automation such as release post item generator or workflow optimization such as scaling our release post, can and should be built into our product for our users. Building it into our product can be as simple as an update to our transparent and highly referenced handbook or iterating on our release feature over multiple cycles to optimize our release notes process. Product operations will treat all of Gitlab's product development practices, such as a product development flow, as a product to be optimized, dogfooding with the intention of improving existing or introducing new GitLab features to operationalize successful outcomes for the benefit of GitLab and non-Gitlab teams.
Finding the right balance of synchronous versus asynchronous collaboration as an all-remote team. GitLab has a unique culture of combined independence and ownership as a fully remote organization. We've carved the path for successful remote work with our transparent handbook first approach, which has also propelled a highly productive asynchronous team with an everyone can contribute mindset. However, as GitLab has gone from fewer than 350 to over 1200 employees, we've seen some of our asynchronous processes fail serve us at scale.
At scale, leaning too much toward asynchronous results in opportunity gaps to collaborate on optimal outcomes within and across teams, and even operational chaos. Too much synchronous communication creates the overly burdened "red tape" operational inefficiencies that traditional companies suffer from across large teams and various time zones. So as we grow our team and our userbase, we have to continue adjusting the levers to establish the right convergence and divergence points, for product development teams and across the business.
Creating and maintaining a psychologically safe space as we grow our headcount. To date, GitLab has succeeded with a culture that is reasonably flat and values that promote level agnostic collaboration and contributions across the organization regardless of functional role. We've embraced a bias toward action, raising MRs to make micro improvements that can be quickly improved, revised or even removed, minimizing the fear of failure.
As we grow larger teams to support bigger enterprise customers, especially as an all remote team, it becomes more challenging to build human to human relationships within in and across teams to building trust and safety. And because every change we introduce into our system or into our product can have significant positive and negative impacts on thousands of our users, with real revenue ramification for larger customers, functional roles get more defined and the stakes become higher. This opens the door to hierarchy driven systems, competitively motivated behavior and fear based decision making, which don't promote risk-taking, voicing alternative opinions and creativity, which are the types of behavior that lead to innovative breakthroughs.
There is no one formula for this challenge, which all maturing organizations face. We'll have to continually lean into opportunities to build empathy amongst our teams by building frameworks to provide resources that foster positive emotions of curiosity, confidence, and inspiration.
Providing access to actionable product usage data for GitLab product development teams As GitLab's userbase grows, collecting quantitative data to identify patterns and trends while leveraging qualitative data to better understand the reason behind those patterns and trends will be key to delivering meaningful impact to customers. However, GitLab is committed to user data privacy and respects user-requested boundaries on data collection. Alternatives to product usage data, such as user surveys and testing can help fill some of the gaps but are not as scalable or unbiased. And while leveraging product usage data from SaaS users can yield meaningful insights for Self-managed users as well, it's not always an apples to apples comparison. We need to continually work on finding the balance between user privacy and providing the product teams access to the business intelligence they need to deliver meaningful impact to customers. Concurrently, we need to minimize the complexity and manual nature of effort needed by product development teams to access the most meaningful data available to them in the system by prioritizing instrumentation and providing standardized dashboards for teams to leverage and customize.
Supports Outcome driven products
🏹 Automate the release post workflow to communicate product release notes more efficiently.
Why? Minimize the amount of work necessary for product managers to contribute to and manage their release notes.
How are we measuring success?
Improve design of release notes and related documentation such as deprecations, removals and migrations
Why? Make it easier for GitLab customers to discover new features and be informed of any product changes relevant to them.
How are we measuring success?
Supports Feedback loops
Automate deployment, data collection and analysis of post purchase survey to increase accuracy and efficiency.
Why?
How are we measuring success?
features.yml to 0Expand data types collected by post purchase survey to include web direct sales.
Why? To provide an additional sensing mechanism to product management for category direction, maturity and feature optimization and to inform investments in across marketing, sales and customer success teams.
How are we measuring success?
Supports Scaling product knowledge
Increase GitLab's footprint as thought leaders in Product Management and Product Operations.
Why? So GitLab customers and the broader tech community can benefit from and contribute to our best practices.
How are we measuring success?
/direction/product-operations/ from position 18 to position 5 in Google search resultsSupports Outcome driven products
**Evolve Gitlab's prioritization framework and supporting documentation to reduce complexity in process and increase focus on desired outcomes.
Why? To empower Sections, Stages and Groups by giving them clear guidance and flexibility so they can prioritize work to achieve optimal balance between product growth, product optimization and product maintenance for their customers and users.
How are we measuring success?
Supports Feedback loops
Implement a solution to collect survey responses from paid account self-managed users.
Why? To better understand the sentiment of self-managed users given they make up X% user population.
How are we measuring success:
*Redesign Product Handbook content to make it easier discover or find specific content types Supports Scaling product knowledge
Why? So product managers, cross-functional team members and the wider GitLab community can find helpful references and workflow to due their job.
How are we measuring success?
Supports Scaling product knowledge
Increase GitLab's footprint as thought leaders in Product Management and Product Operations.
Why? So GitLab customers and the broader tech community can benefit from and contribute to our best practices.
How are we measuring success?
The focus areas below are evergreen for Product Operations. One year plans to improve GitLab's product system always map to the areas of focus below.
We aim to minimize manual processes in favor of flexible automation that compliments existing human workflows. Doing so enables Product Division team members to operate more efficiently, spending more time delivering value to GitLab's customers and the wider community.
We lean into opportunities to grow internal and external communication channels for GitLab's product development teams and their stable counterparts. The outcome is the collection and exposure of actionable user feedback and data that can be utilized across the business to deliver impactful results to GitLab's users.
We collaborate to identify best practices for product development and create transparency of knowledge across teams in an ongoing and remote-friendly way. The outcome is a collection of written, video and interactive content in the GitLab handbook that is easy to consume and adopt for GitLab's product managers as well as product managers throughout the tech community.
The areas of ownership below highlight workflows and processes for which Product Operations acts as DRI.
The areas of advisement below highlight workflows and processes for which Product Operations continually acts as trusted advisor.
Product operations welcomes contributions to this page! Please feel free to raise an MR and assign to the Product Operations for collaboration.