GitLab Learning & Development, 9 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Product Strategy - L&D Sessions

Description

The GitLab Learning & Development team discuss GitLab's Product Strategy with Sid (GitLab CEO and co-Founder), Hila (Growth PM Director), and Scott (Chief Product Officer).

Learn more by visiting the Product Strategy Page: https://about.gitlab.com/direction/#product-strategy

A

Alright hi everyone. This is josh from get lab learning development, and this is a video to talk about gitlab's product strategy. I'm joined here with sid gitlab, ceo and co-founder scott, our chief product officer in gila growth pm director, to discuss this topic, so you know to really kick things off. You know I'm curious if you can give briefly give an overview of the product strategy and the correlation between the number of stages, customers use and their propensity to upgrade to a paid package and really, how does that adding a stage triple conversion.

B

Yeah, so the start of this is the growth team is asked to understand how we can improve the free to paid conversion rate. We have a large amount of free customers. We want to see how we can drive more of them to become paid customers. So we did some data analysis trying to understand what our type of customers are more likely to convert. What are some behaviors that will lead to that, and one thing that really jumped out is the number of stages organization.

B

Use has a really really strong correlation with the free-to-pay conversion rate, and very specifically, we saw that organizations using three stages are two two times more likely to convert than those who are four times more likely to convert than those who you only use um two stages, uh and a lot of those um usage also happen fairly quickly in the first 30 days as well. So that's kind of a lot of the data analysis and reasoning behind that.

C

I can jump in too, um if you think about git lab as a single application.

C

Part of the magic is that many different types of personas at a company can jump into the same product and collaborate to make communication really effective and reduce cycle times, and that's when companies really start to see git lab pay off, because in many places we're replacing multiple tools and the barriers between those tools can be really painful, and so some of our stages, like, for example, plan, tend to be adopted not just by the developers, but also by product managers and designers and other folks.

C

There's. Our security stage might be adopted by security engineers, and so once those other personas start to get in the game too, and collaborate well with developers.

C

It's obvious uh how gitlab can really help them, and so I think that's another reason why, when you see stage adoption, you also see folks tend to want to up tier into a higher higher versions of gitlab.

A

And so you know what are what are ways. We really harness the unique power of a single application.

D

Yeah, I think uh we have some features that are really hard to implement. If you don't have something in a single application, like value stream analytics see the entire flow from idea to reality, see all of them and then see where things are getting stuck.

D

Also for, like compliance and auditing, it's really beneficial to have every action, every user, every type of work, all the way from packages to monitoring to the planning, all in the same in the same application- and I think also what we see in a lot of companies- is that if a product grows, it has like the testing and the proper security tools run. What we see at customers who use gitlab 100 of their projects, have all the tools, even if you're, just starting out, you already have feature flags available too.

D

You already have all the security tests and the fuzzing. It's not something you bought on later. So I think that's a big advantage of a single application. Scott.

C

Yeah I'll say it's a similar in spirit, uh maybe said slightly differently.

C

If the devops life cycle and even our stage representation of it is kind of linear, but when, since we're all in the same application, enable people to do things that might relate to one stage as we call it, but the experience of it takes place elsewhere.

C

So the way that we can really differentiate ourselves here is by enabling, by focusing on the workflow and the job that the customer needs to do we're not constrained by being focused on one specific stage.

C

So, for example, security testing, which oftentimes happens later in the life cycle for most companies, can be done now right during the mr and those you know, the results from those scans can show up right in the mr, when the developer is doing the work and that's a unique way that we can develop and offer security testing, because we're also earlier in the cycle in source code management and merge in the merge request. Workflow.

B

Yeah, I think there are. There are a couple aspects I think about this question. One thing is my team: think a lot is about how we can guide users to use more stages, because the platform concept is new. Using multiple stages in one platform is not necessarily a kind of existing behavior, or they all know what to do at what time. So we need to think about how to guide them.

B

um Some some analysis- and we were just talking about with scout and sid- is identify the key path that most companies move through for us is likely create to verify and release, so how we can really hide that highlight that golden pass to a lot of customers and between those golden paths between those stages. What are the bridge feature uh kind of the the thing they can use to jump over to the next stage?

B

I think scott mentioned security scan or there there might be other many other things we need to identify between the stages to connect them, and the last thing I would add is gitlab is a collaboration tool.

B

um In the end, we, when we think about stage adoption uh in interesting inspect aspect, is to think about how team size and how multiple people collaborating this on this platform um kind of impact that, because, if you look at data other than create most of other stage, adoption happens after like a team member was invite a second team member was invited and joined so like there is more needs for collaboration and other features. Other stages become more natural to adopt. So that's another.

B

That's another thing to uh think about as well, and I think one more thing I will add is other than how do we guide users to use more stages? We also need to think about how do we visualize the value to whoever is using the product? Sid mentioned the value stream uh analytics that make a lot of sense. um I think we maybe potentially can do something even more smarter and interesting uh when we think about marketing right. How do we convince users that using gitlab is better than using three tools?

B

Maybe it's a calculator to help. You visualize calculate how much money you can save how much efficiency you can gain from using a product like this.

A

Yeah, it's a great point. I I think it kind of you know a lot of what you said. Gila flows into you know my next question just around you know how can really increasing wider community contributions? Help gitlab achieve its vision to deliver a single application for the entire devops life.

A

Cycle you know said I can carry us your perspective on that.

D

Yeah thanks, um I think um what what's really important to us is co-creation with our customers, and it is important because we don't know everything and we're frequently replacing diy devops something people made themselves and then the product might not be as good but you're very sure. It addresses all the needs of a customer.

D

um We have really good product managers, but they never know everything. That's going on at our customers, that's impossible. So when we miss something, people can vote with a line of code and they can just contribute it to the product, and it's a really strong signal to us. Okay, they really need this, um and most of the time like we managed to make it work. We we help them.

D

We have merged request coaches to get their contribution over the finish line, and uh I think it's a super power and I think it's it allows gitlab to be something that replaces diy. Devops companies used to buy a bunch of point solutions and build on that. We say: look you replace it with one solution, but that means we have to have like. We have to cover many more edge cases.

D

We don't just have to kind of beat the functionality of the point solutions. We have to beat the functionality of the point solutions, plus the diy devops, that they did on top, so the bar is very high and we can't get there as a single company. We need people to work with us and there's a big advantage. If customers like contribute to gitlab, they start seeing that as their own tool, that's going to make gitlab very, very sticky and and guarantees that over a long time will be successful.

D

So we especially want contributions from our biggest customers that we need to that. We really want to retain that, for whom it's essential, that we have retained them.

C

Yeah I'll just pile on that last point about larger companies contributing uh most large company customers have sort of this painful relationship with the product team, where the enterprise customer gives their wish list sometimes the line, sometimes maybe it doesn't with what the product team wants to do and it can be frustrating for both parties.

C

In this case the company actually has some control here. If there's something they really need, they can contribute it in conjunction with git lab, and even if we're our main line roadmap isn't directly aligned to what they need. They have some control to go, make that change, and so customers really love having that that safety valve that that release valve in case there's something they really need, and that's uh that's unique relative to many enterprise software relationships. Companies might have.

B

um I have the next question, so I'm always curious to hear uh sid and scott your thoughts about the dev op market. What do you think will be the end state, because we here at gitlab, we talk about single devops platform. It's it's really kind of great has a lot of unique advantages.

B

On the other hand, we also see there are a lot of existing point solutions and there are new point solutions emerging every day. So what do you think will be the end state for this market and what is the biggest risk in this? Like single devops platform assumption um we are operate under.

D

Yeah, I think I I think devops platforms are going to be superior to point solutions and it's already clear to many users of gitlab, um and I think that the most popular kind of point solutions will become the default in the platforms like whatever functionality they have it's going to be in the platforms, um it's kind of like cars like anytime some some some aftermarket option became popular. It became possible to order it in the car and if a lot of people order with the car, it becomes the default.

D

um At the same time, we got to make sure that we stay open. Customers don't want to be locked in, so we need open, exporting, integrations apis to keep people wanting to use a single platform. Scott.

C

Yeah, I I agree. It's a huge space right now. The point solutions have the majority of the spend and platforms are a minority. I expect that this to shift and platforms will become the majority. I'm sure there will always be point solutions, because it's such a complex problem, space and so big, but I do think majority of spend- will be focused on platforms and gila asked about risk.

C

I think the risk the biggest risk in my mind, is loss of usability, we're trying to accomplish a lot in a single application in a single product and it can be complex and challenging to make so much feature functionality available without making it overwhelming. So our big challenge is to offer a single app that does a lot of jobs but enable a user to get what they want when they want it in a way that they don't feel overwhelmed.

B

Yeah, thank you, scott and sid. um I have the next one as well. I think in our strategy section we talk about self-service, purchase funnel and that becoming uh increasingly important part of our strategy.

B

Do you have any vision in your head, which kind of customers should be guided to the self-service purchase funnel um versus the traditional like sales funnel? Do you envision? We begin to route leads to like the sales funnel or the self-service funnel differently, based on certain characteristics of the company. Maybe it's how big it is, or whether it's a one person or a small team. um What is your vision there.

D

Yeah, I I want to emphasize that I think that sales assisted is not like a different funnel but kind of a turbo on a funnel like we should never kind of say: oh well, you we're not going to serve you via e-commerce, we're not going to we're going to have a separate thing process for you, it's more that we can um it. It serves as an accelerant like.

D

Yes, you can do e-commerce, but we can also, if you want to talk to someone uh you're you're free to, and we welcome that, and we can help you further. We send automated emails, but also a personal one, so as much as possible prevent that you did. You have to make that determination, because it, I think, you're going to get that wrong a lot of the times different people have different needs at different times. I think it's really hard to get that right, and then you spend a lot of energy there.

D

Instead of making the actual reach out more help helpful.

C

Yeah, um I I I.

A

C

Couple things: first of all: if a customer knows they want to buy, make it simple if they're already familiar with us, they already understand the value like we have millions of open source users and in many cases they know that they want it they're already familiar with it, so allow someone who knows they want to buy to do so very, very quickly and very simply, if somebody may not know they want to buy.

C

I can imagine having data that we would use as signals to push them down the path that we think is going to be the best experience for them.

C

For example, maybe they signal they've used us before or they haven't, or maybe they signal how large they are. Those might be signals that they're better fit for more of a self-service buying experience versus. Maybe we put, we encourage them to contact sales. I can imagine different you user experienced journeys based on what we think will lead to the best outcome, but I agree with sid that we should start with sort of making.

A

C

You know allow them to opt in to talk to sales if they want allow them to purchase in a self-service manner if they want and as we get more sophisticated, we could probably make some decisions about what we think the best path will be.

B

Thank you. um I think the next question is uh something we definitely talk a lot and think a lot here at gitlab. um How do you think about the value of free users to gitlab, because we have been setting goals around improving free to paid conversion rate, which is totally valid? But whenever we talk about that, there is almost like a hidden assumption that the main value of free users is that they one day become a paid customer, but I think for gitlab, probably there's much more to it.

B

So I'm curious to hear your perspective on that. One.

D

Yeah, I think, there's a lot of benefits and free users, and maybe we should document this a bit more. I think that's one thing is kind of mind: share, slash awareness, kind of recognition like oh yeah, good luck, the other thing is familiarity with the product. Like people know what it does. People know the other one is training kind of people know how it works, they're already trained on it. Another one is advocacy where people like become fans of the product and advocate for it.

D

So a lot of our free users use it for personal use and it might translate in a workplace where, in the workplace and decision needs to be made to for to buy a devops platform that they add for advocate for gitlab. So we we have this kind of personal use. The organizational use crossover.

D

Another thing is contributions, free users might contribute code that makes it better and therefore kind of make the product better for everyone, and, last but not least, due to free users, you have more total users, so it's more likely that third-party products add support. uh You want to be on a platform that is supported by something else that you might use.

A

Great well, this was really insightful. I really appreciate your time said: scott and gila thank.