At the highest level, the goal of product marketing is to communicate the value of our product or services to our target audience.
Product marketing has three primary responsibilities.
Analysis: Product marketing is responsible for researching and analyzing the market, competition, product, and customer to find unique insights that aid the sales process.
Messaging: Product marketing is responsible for defining and managing the value proposition, messaging, and positioning of new and existing products and features.
Enablement: Product marketing is responsible for listening to the sales teams to understand the challenges and opportunities they face in the sales process. Additionally, product marketing supports the sales team with collateral, training, and go-to-market strategy.
Priority Focus Areas
Moving from GitLab CE to GitLab EE
Website Messaging and Flow
If you're interested in learning more about the specific deliverables or read more on the insights that were shared, take a look a the documented feedback in this presentation.
The goal is to enable sales and marketing/PR to work one release ahead of the product release cycle. The proposed process to get us there is below.
After the kickoff meeting Job and the Product Marketing Manager will agree on priority features
A sister marketing issue will be created in the marketing project for each priority feature
In the sister issue, the developer working on the feature will work to answer the following:
Who are we building the feature for
What pain will the feature solve
How will the user/team/admin benefit from having the feature (focus on measurable benefits)
How will this feature change a user/team/admins workflow (e.g. this used to be a 10-step process now it is 1-click)
What are the current limitations
Prod. Marketing will answer the following
What is the competitive landscape
What are the key selling points
How will we message it
The goal of our release checklist is to highlight what should be completed with each release.
Verify that the work for the last release was documented and issue was closed
All recordings that do not contain senstive information will also be shared in Gitlab's public YouTube channel.
Customer Case Study Creation
Illustrate successful and measurable improvements in the customer’s business
Show other users how customers are using GitLab
Align content so that GitLab solutions reflect the challenges our customers, prospects, and the market requirements
Develop and grow organisational relationships: speak at events on our behalf, promote their business
Support our value proposition - Faster from idea to production
Creating the Customer Case Study:
Explaining the Case Study process to a Customer & Creating the Case Study:
Below is an example email template that you can send customers to after the AE has introduced you to the customer. The email below will help the customer to get a better sense of what we are asking of them.
It's nice to e-meet you, we'd love to hear more about your journey to GitLab and potentially write a customer story on COMPANY NAME.
Here are the steps that we'd work with you on.
20-30 minute phone call to hear more about your industry, business, and team. (In the call, we would also like to hear more about your decision making process to first choose GitLab and then eventually purchase EE.)
Review of the draft customer story
Final review of the customer story Then once the customer story is agreed upon by you or someone on your team we will publish it on GitLab's channels.
Please let me know if you're open to kicking off the customer story process on X date
####Collecting Metrics: Possible quantitative metrics that the customer can be asked to share with GitLab include:
Reduced cycle time
Number of deploys in a given time frame
Reduced number of bugs or Reverts
Recuced number of admin hours
Cost savings % through purchasing GitLab: Reduce the cost of managing a number of different people, projects, and platforms.
Reduction in internal support tickets requests: Reduction in the number of support tickets team submitting to fix challenges, compared to initial SCM tool
The customer case study should then be written by Product Marketing team, and the draft sent to the customer for their input, and approval.
Other sections in the case study can be found on the customer's website or by searching the web - Sidebar summary, The Customer.
Following approval from the customer, the Design team should be sent a doc of the case study to include in the case study design template. The case study can then be published on our website.
Case Study Format:
Headline: The name of the customer and the benefit they gained from implementing our solution
Sidebar Summary: Summarize key points
Customer Name and Logo
Customer Details: Country, Website
Organisation Type - Public/Private & Industry
Annual Revenue - If publicly available
Summary of Key Benefits
The Customer: A brief introduction of the customer, not the solution.
The Challenge: What was the customer trying to change or improve. What regulations or market conditions drove the customer to search for a new solution. Share the steps the customer took to solve the problem, including other products and services they investigated.
The Solution: Detail the solution and how it aligns to the customers requirements. Also detail other solutions that GitLab interfaces with. Also include customer quote.
The Results: Detail how GitLab supported the customer to solve their problems. This is where the use of benchmarking metrics such as such as time saved, reduced costs, increased performance etc. are required.
About GitLab: Short paragraph on GitlLab - about, solutions etc. Call to action of solutions offered.
Possible Additional Supporting Documents:
Customer Deal Summary – High Level PowerPoint summary after deal first signed.
Customer Success Overview
Infographic – Single page A4 summary with diagrams and measureable benchmarks
Publish on website
Video - Short video summary if customer is willing to participate - Perforce example
Blog Post - Blog post to launch customer case study