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. The role and focus of product operations can vary depending on business maturity, customer needs and the product itself. A good product operations function will define, communicate, and improve practices that can be standardized, such as tools, planning, team gatherings, and training. A great product operations function will sit at the intersection of product management, UX/design, and engineering to enable cross-functional teams to consistently, flexibly and creatively deliver outcomes to customers/users via strong feedback loops and process automation. An excellent product operations function will create and implement systems to continually drive partnership between product management and teams across the business, inclusive of marketing, sales and customer success, resulting in accelerated feedback loops, collection/exposure of critical data and improvement of feature adoption.
At GitLab, Product Operations strives for the good, the great, and the excellent! We are in a unique position to define and lead what this newly emerging function can do for software companies.
We are continualy 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.
Vision: A world class product system, that GitLab and all of GitLab’s customers and users can benefit from.
Mission: Empower GitLab to be truly 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 grow 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.
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.
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 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 fo 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.
The post purchase survey (PPS) is launched in Qualtrics via Salesforce. Currently, any time a sales assisted contract is confirmed in Salesforce, Qualtrics is triggered to send out a survey to the customer contact on that subscription. The feature list in Qualtrics is maintained via monthly issues which leverage the feature by tier page. The feature by tier page is auto generated from features.yml. The quarterly scores from the PPS read-outs below flow into features.yml via the process outlined here, which is owned by Product Operations. We are working on flowing web direct and renewal subscriptions into this survey as well in FY22.
Product develoment flow: Q2 2020
We aim to minimize manual processes in favor of flexible automations that compliment intentional and precisely timed human touch points. The outcome is repeatable, customizable and efficient workflows that GitLab's product teams can leverage to build and release best in class features for Gitlab's users.
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.
Product operations welcomes contributions to this page! Please feel free to raise an MR and assign to the Product Operations PM for collaboration.
