GitLab Growth, 31 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: UX Showcase - Growth - Continuous Onboarding

Description

Kevin Comoli presents continuous onboarding for new and new-ish users

A

Can you can you'll see my screen, okay, cool uh and thank you, jackie, there's, a great intro by the way uh so hi everyone, I'm kevin product designer in growth and as jackie mentioned today, I'm going to be talking about our new user onboarding strategy and I'm going to be mainly focused on one of the building blocks of this strategy.

A

But before we get started, I just wanted to give you a little bit of context about how growth is envisioning like new user onboarding and basically, what do we mean by onboarding is the very first 90 days of a new user in the app so from sign up to hopefully multiple stages, adoption and within this 90 days time frame, we divided it into two different pieces, the first one being the first smell and the second one being continuous onboarding.

A

So the first smell is more about a one person job and the continuous onboarding part is more about multiple people coming together to try out the product. So the first smell is heavily focused on exploration and discovery, uh whereas um continuous onboarding is more of a like pilot team adoption and it's more going to be about a deeper practice phase.

A

So, as jackie mentioned today, I'm only going to be focused on continuous onboarding. If you want to learn more about personnel and how all this ties in nicely together check out mate's showcase.

A

Now thinking about continuous onboarding, I started thinking about how to draft a ux strategy, and one of the first questions arise was for whom so one of the two main personas that made sense at this point. Were the development team lead and the software developer?

A

um That doesn't mean that we'll completely discarding all of the other user personas that we won't get into product managers or product designers um we do like. We will do that, they're important too, and most likely in a team structure. It's you.

A

You will not always have development team lead and software develop where, like it's possible, that you get a bit of a mix right, um but we felt that these two were the most relevant uh to focus on right now, and we also know from our sign of data that they're the most represented role uh to date.

A

So picking this youth person, as I said thinking what could be their goal and a good way to start framing, this was to use mental models. um So what could be those questions that they would ask themselves during this practice phase, so some of them being like how complete is gitlab as a devops platform to up to how does gitlab deliver on its original promise? That is, ship software faster and better.

A

And hopefully, if we're able to correctly answer this question the first five at least, we would get the last two that might pop up, which is how do we convince leader in our organization to switch to gitlab, and how can we have other team um getting on board?

A

So once I had that, I started auditing the app to try to find some of the features that would help us solve those questions, um and I came up with a somehow like kind of long list of features, and it's absolutely not exhaustive and I'm not going to go through all of those dt's, because I don't want to bore you out.

A

But basically, what you have to know is that it's a mix of um paid and free features combined together and this kind of iconography that you have is hinting at some of the like good thing and bad thing uh about those features. So, for example, the warning sign is just stating that this feature is potentially overwhelming for the users the light bulb. Is it's a potential aha moment? So in this case the first one is um merchandise widgets that is tied into how the future interact with each other.

A

I think the merge quest widgets is a great example to see how everything ties in together um and then the forbidden sign is more about some of the feature that it's hard to access or that at least we don't surface very well during this first 90 days period. Only like it doesn't mean that they're completely unable to access it, but just that we could potentially do a better job at surfacing.

A

These features um during the 90 days, the first 90 days and after that, that kind of started hinting at what could be our goal during this practice phase? What could be the goal of continuous onboarding?

A

I came upon this idea that it would demonstrate the value of devops as a single application, so they can show it to other afterwards.

A

um If this sounds a lot like our marketing claim, it's because it's kind of the same thing um and as you may know, we are saying a lot up front to people that gitlab is about basically cutting down all those tools that you get and instead of using five or ten tools in your development process and workflow use gitlab, it's gonna be like faster. It's gonna basically solve a lot of your problem by using just one tool instead of trying to maintain the full tool chain.

A

So hopefully, if we do that well, uh what we could observe is uh moving from this pilot team adoption to a company-wide adoption adoption but again that's first case scenario, but I really think that we should think about continuous onboarding in this way as a step to something much bigger.

A

So now, all that is nice, but how can we actually get there, and I was researching on learning framework because I thought they would kind of relate- and I found this one that I think is used in behavioral psychology, if I'm not mistaken, but it's basically stating that whenever you learn something new or you're trying to acquire new skills, you will go through this four different stages, ranging from unconscious confidence, which means that you have no idea like what you're unaware of to unconscious competence, where you can do it without thinking.

A

um So with that in mind, I tried to kind of map out where continuous onboarding and for smell would sit there and ended up with this idea that, if done well, the first smell would move people up to the end of stage one so where they would get a better idea of what they could do with gitlab, but also some kind of like obscure idea, and they would have to practice further to refine their knowledge.

A

And this is where continuous onboarding would start so from stage two conscious competence, uh moving people to sorry, conscious incompetence, moving people to stage three conscious competence where they would be able to perform any tasks they want, but with effort, um I'm completely discarding stage four, because in a 90 days, time frame making them like unconscious like moving then up to unconscious confidence is very unlikely, um because this is very close to mastery and that sounded like an impossible goal to attain for us um now.

A

What are the different uh key steps and main problem that we encounter trying to move people uh on this knowledge pyramid?

A

uh Well, one of the first understanding that we want them to get is how feature interact with each other to create workflows so not promote features just because we have features but concretely show why they make sense in a broader workflow and some of the small features that are going to help us doing. This are the metropolis widget issues, uh ci cd,.

A

Review like settings: basically, all that is not making the best job at surfacing uh all the information to start with those features. So how can we change that key step is going to be to establish a learning pattern?

A

uh Some of the key features is that we don't know yet we have absolutely no idea, um because this is really new and most likely this will be a combination of multiple things that will help us establish a learning pattern and some of the main problem that ties into that is that feature setup in general is inconsistent through the app. So there are multiple places in the app where you can start setting up features or get started with any features and they're not always the same place.

A

So how do we kind of help them understand this and then the last key step would be to retrieve a tangible output, so they can then convince other team or buyer personas um to adopt gitlab and some of the key features that would help us do. This are value stream and analytics, and one of the main problem is that it requires a sustained usage of the app. So if you just use gitlab for 7 days or maybe 10 days, it's going to be hard for you to reach your tangible output.

A

um So once all this was framed, uh it felt really broad and we wanted to make it actionable.

A

So I wanted to narrow it down and focus on two to three mental models that I felt were somewhat like relevant to each other, so they're kind of different, but at the same time they kind of intertwine and one of the a good way to start doing with that was to frame potential user journey and again approaching it from a like two axis, so the first would be for the development team lead the other for the software developer.

A

The goal of the development team would be to set up the team for a successful pilot. The goal of the software developer would be to start to contribute as soon as possible, and both of them would go through different stages.

A

um So I started working on the user journey, for the team leads by no means. This is something that is set in stone or it is a road map. The idea was just to try to come up with some kind of best case scenario, um but also um try to ensure that all of those like column, stickies that you see would be iteration so that obviously we will never ship something like that in one go. But what we want is try to get our way through all this um same thing with the software developer.

A

So I think a good example to speak in terms of iteration is that if the journey starts at the male client, how can we start zooming in there? What can we do to improve that and so on and so forth?

A

uh So some of the next steps on this uh well for now we want to validate and refine, because this is very conceptual. um So one of the concrete steps that we want to take is to start collecting on-boarding jobs, to be done. Information in the first smell so that we can kind of estimate a ratio of people that would fit this strategy.

A

And if we kind of discover that this is pretty slim, then that means we need to adjust our strategy, because it's not realistic, um then another step that we're going to do quickly after that is to try to experiment on those opportunities identifying the user journey.

A

If we refine the user journey based on the onboarding job to be done and another step would be to keep a close eye on the cross-stage usage research.

A

So this is one of the research that is tied in with our ux department or kr, and I absolutely cannot remember the exact name of the issue, but I linked it there and it's basically to start looking at how we can facilitate crosstalk adoption for users and the last one would be to use other stages just to be done and first time experiences so that we start expanding but also use other stages, job to be done to nurture the thing we do because they're completely connected- and this is where we would need, I think, to stop- um collaborating with other stage groups, because I don't think growth alone is going to be able to pull that off.

A

Basically, so that's it! Thank you for your attention. Do you have any question.

B

Hey this is holly and I'll type. My question out, but this is amazing research and thank you so much for sharing, I'm really excited about it. My question is being in plan. I noticed the plan was one of the stages that could potentially be affected at some point in this.

B

What can we do in the other stage groups to kind of help prepare for giving you maybe insights or feedback that you need to continue with this kind of research, because I know onboarding in particular, I think is- is a challenge for some of the users of the plan stage- project management in particular, so I'd love to to help and collaborate with you any way that I can on this.

A

That's super good to hear so yeah. One of the first thing is, I kind of talked about this um role. I don't know if.

C

A

Going to be able to share it properly here, but basically it sums up all of the job to be done from your stage, and I mean in all these stages and for me what I was thinking is start looking into this and obviously ask anyone if they're still relevant and start ideating on that. So then, maybe maybe I don't know which format this would take, but basically create an issue maybe and start a designer from plan to see how we can move forward with that.

B

That's awesome, thank you. I know and plan in particular we're looking currently at validating some of our jobs, so they might be changing. So that seems like a great place to start. Thank you for.

A

Sharing this, this.

B

Is fascinating, thank you.

C

C

Any other comments or.

C

Questions we have one more minute, then we have to move on to the next one. Thank you so much kevin. I'm also super super excited about the onboarding work and um even though the growth team is kind of focused on onboarding, obviously everybody can work of work on onboarding and need to think about onboarding so reach out to us anytime. If you have ideas and we want to leverage the ux co-working channel a lot to share outer concepts and research results, and you know we're trying to figure out what people like.

C

So um there are a lot of onboarding tours out there and sometimes that's the first thing you think of. But our question is well: will our users actually use those tours or are there other models for onboarding that we need to explore and understand so any knowledge or information that anyone has please share back with us and we'll do the same while we're working on this.

C

Thank you, kevin.