Journeys

Introduction

As a company we have to be great at providing multiple journeys. The contributor, user, and buyer journey involve different people going through them, different metrics, different hand-offs, and different teams providing them. Most companies never master a journey, a few companies master one: Ubuntu mastered the contributor journey, Atlassian the user journey, and Oracle the buyer journey. Our ambition is to master all three.

The hard thing is that during a journey you have multiple hand-offs between departments and teams. These hand-off points need to be well defined and work for both teams. It is essential to measure all steps of the journey to see where an improvement would have the greatest effect.

Contributor journey

A contributor is someone who contributed to GitLab with code, documentation, a blog article, a tweet, a talk, a meetup, and/or helping on the issue tracker/forum/irc.

1. Find GitLab (technical blog post)
2. Reach out to GitLab on social media (social media response)
3. Find information about contributing (contributor landing pages)
4. Start installation of GDK (multiple good options to run)
5. Finish installation of GDK (error free, good troubleshooting)
6. Submit a merge request (good documentation)
7. Get acknowledged (find first contributor)
8. Finish merge request (acknowledge first contribution, merge request coach)
9. Help someone else (forum, issue tracker)
10. Get recognized for a large contribution (named swag)
11. Get recognized as an core contributor (core contributor program, we need to know their location, maybe do this as part our forum)
12. Get invited to an event (match contributors with incoming requests for speakers, meetup organization, speaker content)
13. Write a blog post (help with editing)
14. Get activated after being inactive for a while (reactivation program)

People might skip parts of this journey, for example by never contributing code. That is perfectly fine.

User journey

Stage	Measured By	GitLab Owner
Aware	?	Marketing
Download	# Downloads	Marketing?
Install	# Usage Pings ?	Distribution
Single User Experience	Usage Ping	UX
Invite Other Users	Usage Ping	?
Adopt All Features	Usage Ping	? Product & Marketing
Invite Other Departments	Usage Ping	?
Internal Reference	?	?

User adoption journey

Our customers get the most value out of the GitLab product when they use multiple stages. The user adoption journey covers the most common path our users follow to adopt GitLab’s product stages.

Buyer journey

Stage	Measured By	GitLab Owner	Activities
Awareness	Impressions/Share of Voice	Marketing	Blog, SEO, Ads, Campaign, AR, PR
Initial Contact	Get in touch with us	Marketing	Trial, chat, or contact sales
Consideration	Willingness to talk	Marketing and Sales	Initial Qualifying Meeting
Enter Buying Cycle	Pipeline stage movement	Sales	Progress through pipeline stages
Decision/Purchase	Dollar amount in contract	Sales, Finance, Legal	Sign our paper/submit PO
Adoption	Usage ping of different DevOps stages	Customer Success
Reference	Scale of reference-ability: e.g. more points for video; then blog; public reference; private reference	Customer Advocates	Published material or entry to reference database
Contribute	More than a reference, the customer contributes to the GitLab project or community	Community Advocates	Code; feature requests; Customer Advisory Boards

Buyer’s journey content stages

Refer to our handbook page on buyer’s journey definitions for a more detailed explanation.

Awareness (Beginning stage)

Users and buyers realize that they have a problem or challenge which could be solved through some sort of outside software or service. At this stage, they are trying to define the scope and the relative impact and size of the problem.

The focus is on educating potential buyers about the problems they are facing, the business impact of their problems, and the reality that others are successfully solving the same problem.

Consideration (Middle stage)

Users and buyers understand the problem they are trying to solve and the business impact/value of addressing the problem and are now actively seeking and evaluating potential remedies to their business issue. In this stage they are focused on identifying options that meet their specific requirements and needs.

The focus is on positioning GitLab as a viable and compelling solution to a potential buyer’s specific problem.

Decision/Purchase (Later stage)

Users and buyers have concluded that they need to invest in solving a specific business problem and are now comparing and evaluating specific options. In this stage, they are evaluating and comparing different options in order to identify the ideal solution for their specific situation.

The focus is on key information that a buyer needs to justify GitLab as their chosen solution.