This playbook contains useful tips and tricks an Incubation Engineer may employ for SEG and project success.
Each Incubation Engineering project has its own handbook page which is linked from our list of current projects.
The following sections are should be included:
Outline the problem that we're trying to solve for our users.
How do we intend to solve the problem? What is our overall vision for this project and how it will fit into GitLab?
What is the iterative approach that we'll be taking for each project? How do we measure and demonstrate success? Link to epics and issues as required.
Outline our marketing strategy. How do we intend to find early adopters, build communities, and get potential users interested in our projects?
If you're building a feature that should have a distinct name then please reach out to #marketing for assistance, and take into account our Product and Feature Naming Guidelines.
JTBD is an important part of the process of establishing an SEG. Not only does writing job statements help the SEG to clearly identify their areas of focus, but it also helps to communicate the roadmap and rationale to the rest of the organization and the broader GitLab community.
Each SEG should add a section to their handbook page and create a table with 3 to 5 job statements for their area. Each row in the table should include the following columns:
Job statements should be written from the perspective of the user and describe the problem they are trying to solve. As in "When [situation], I want to [job], so I can [outcome]." See the JTBD page in the UX handbook for guidance on writing job statements.
The Maturity Rating should align with how maturity is measured in GitLab (minimal, viable, etc.), and should be measured using the same criteria as described in the Product handbook.
The Research Issue should be a confidental issue in the SEG project with information that has been gathered by the SEG or other sources and should capture what has been learned about a specific JTBD. This can include notes or recordings from customer conversations, competitive research, or any other public industry information.
The Roadmap Issue (or Epic) should be a public resource for the SEG to communicate the planned roadmap and current state of development.
An example of this structure can be seen on the Mobile DevOps Handbook Page.
List the the product development groups, if any, that the SEG project may impact as a link to the appropriate handbook page. In the early stages this may not be known and may change as the SEG project evolves, please update when there are changes.
Links to articles (both internal and external to GitLab), issues and epics that provide further information on our approach.
It's important to use the correct market terminology, and to define terms that may be unfamiliar to readers.
In order to maintain consistency, the process below should be followed when starting a new SEG from an incubation backlog project:
meta project within that new group. For example: mlops/metameta project. This issue will replace the existing backlog project issue and be used to post bi-weekly demo recordings from the new SEG. For example: jamstack| Add all labels from the original backlog issue to the issue you just created. For example: original issue | new issue |
seg_issues_list in the handbook direction generator module in the handbook. See this MR for an example.Every 2 weeks a meeting between the CEO and VP of Incubation Engineering is scheduled. In advance of that meeting Incubation Engineering team members are expected to showcase their work in a short video. Beside the YouTube guidelines, there are some guidelines for said video:
Incubation Engineering - latestThere are 2 playlist in general:
And then there are the SEG specific playlists, you might need to make one and follow the naming convention:
Incubation Engineering - <SEG>
Incubation Engineering team members benefit from shadowing customer / prospect events. This is aligned with the FY22-Q4 Engineering OKR "Increase focus on customer results..".
Field marketing has welcomed all Incubation Engineering team members to shadow upcoming field marketing events. These events are conducted with new prospects, existing customers and individual GitLab / DevOps enthusiasts.
Incubation Engineering team members may discover issues for upcoming events, and may request an invitation by commenting in the event's issue.
The following issue boards are to be used to discover upcoming events:
Highlighting EMEA because majority of Incubation Engineers reside here. Other regions can be discovered in the Boards dropdown by searching for "Field & Corporate {region_name}".
Additionally, Field Marketing has active Slack channels where events are planned and prepped for. If useful, please consider joining:
…on Slack. Other relevant channels may be discovered via Slack search.
User and customer conversations are considered to be an important part of product development, and they are equally important when it comes to Incubation Engineering projects. Direct conversations with users will provide insights into their perspectives, expectations, and behaviors that would not be possible otherwise. Incubation Engineering team members should look for every opportunity to discuss their projects with users and leverage what they've learned to inform JTBD and influence product direction.
Incubation Engineering team members should aspire to be involved in at least a couple of conversations each month. These conversations can take many forms - from direct conversations, to joining customer calls with folks in other departments, to conversations at a meetup or conference.
Take advantage of GitLab resources with guidance on how to facilitate customer interviews and look for opportunities to join calls with other product leaders to learn about their approach.
For Incubation Engineering team members not familiar with customer conversations, it is perfectly okay to simply shadow calls and to say nothing throughout the call. Introduce yourself if invited, and help GitLab team members by keeping notes.
Those comfortable with external interactions may offer their services to the Field Marketing event lead by means of answering questions and interacting with the participants when the GitLab speaker requests support.
incubation or experimental feature without distracting / taking away from the GitLab user experience?incubation feature.Incubation Engineers should familiarize themselves with the GitLab AppSec Review process and preferably have the AppSec review triggered early for each merge request when appropriate.
Incubation Engineers are often required to create prototypes or demo applications as they are iterating on ideas and gathering feedback. Below are some security guidelines to keep in mind while building these applications:
gitlab-incubation-engineering-demos. This is preferred because projects in a subgroup will inherit configurations from the parent group (group access tokens or group CI variables for example), which can result in unintended behavior when an project hasn't accounted for the inherited configurations appropriately.For UX support, see how Product Designers engage with Single Engineer Groups (SEGs).
When releasing features, ensure you engage the Application Security team if your feature matches the guidelines of what should be reviewed, and follow the guidelines for documentation.
Once you expect your publicly visible feature to be in the next release, it's time to write a release post. Start this process as early as possible, it's easier to move it to the next review cycle than to rush the process.
Due to the SEG-nature of our group the process is slightly different from the default. As you wear both the Engineer's and PM's hats, the process is faster, but you'll also lack a second pair of eyes. Check out the PM Contributors section of the release post Handbook page for the default process. Here is a Incubation-adjusted TL;DR:
This MR gives an example on how to add a brand new API endpoint
/lib/apirequests/api/entities/requests/api/Engaging with the Community and getting feedback is tricky when starting an SEG, and more so if the SEG focuses on an area GitLab has not previously engaged in. Here is a list of things that have helped others find communities:
Find the Discord and Slack channels of your community and engage in conversations.
To recruit external users, creating "Opportunities" in Polywork is a useful resource. But: asking for interviews straight away is too high a level of engagement for users. A more successful strategy is to create a Google Form without too many freetext questions, then linking it as an Opportunity in Polywork. Polywork embeds Google Forms, so the users don't have to leave the site.
If you ask for contact details for follow up questions, you have a set of recruits that may be more open to follow up in-person interviews if needed. (Note: Contact details are PII data. Do not use it beyond the usecase indicated on the form, do not save it elsewhere and delete immediately after use. Refer to our Privacy Page for details)