Working remotely is becoming more popular these days in lots of industries, and product marketing's on board. Not being in the office has its upsides (no commute, no obligatory coffee round) but it has its downsides as well. To get the low down, we asked experienced remote worker and Gitlab’s Senior Product Marketer, William Chia, to answer all your questions on how to manage a remote working structure.

Gutted you missed the live thing? Then make sure you’re ready for the next one here.


Q. I recently started a remote role as PMM for Travis CI. How do you maintain focus on the goals your team is trying to achieve and keep them focused on strategic outcomes when you have little physical contact?

A. One of the most successful tactics for remote work is to write everything down. This is especially true for strategic outcomes. I have found at GitLab I am more aligned with my team and the company than I've ever been because everything is documented.

At GitLab we are also uniquely transparent in that we publicly post almost everything. You can see our strategic goals for this quarter here, and here's what I'm currently working on.

When working remotely, the transparency isn't required, but the documentation is. Writing things down can even help co-located teams. Nothing’s more frustrating than missing the meeting and not knowing what's going on. When you write it down you scale the communication.


Q. Product marketing requires cross-functional coordination and often influencing those who don't report to you to do things that align with overall goals; how do you accomplish this remotely? How do you build those relationships and keep a pulse on how other departments are moving? How do you figure out when you need to step-in/coordinate? How do you make sure your work is visible to your manager and other key stakeholders?

A. In some ways this is easier in an all-remote environment, and in some ways much more difficult. Maintaining a high amount of cross-functional ‘surface area’ is needed for both. So the same tactics of spending time and attention building relationships that work face-to-face work remotely as well.

Remotely, you have to do it a bit differently. I schedule a lot of ‘coffee calls’. This is a video call where you don't talk about work. You ask about people's hobbies, their friends, family, and pets, etc. If you get sucked back into work discussion you redirect to make the personal connection.

The other part is that you can't eliminate the value of face-to-face time. At GitLab the whole company gets together every nine months. These company all-hands meetings drive the context for the next nine months of remote work. Day-to-day can be async or video calls, but face-to-face is needed at some stage.

Keeping a pulse on other departments is tricky. At GitLab, everyone writes everything down. It's easy to poke in on other parts of the org because you just go look at their project planning and documentation - it's all accessible. If your company doesn't have the habit of documenting work then this can be near impossible to manage remotely. The benefit is that if you get into the habit of writing things down it makes even co-located work better. Instead of "let me schedule another meeting to get the latest from Ashanti," it becomes, "oh, let me look at Ashanti's project tracker - looks like she's moved into the next phase."

Making your work visible to your manager and other key stakeholders works the same way - if you write everything down and open up your project planning then everyone can see it. Manager one-on-ones go really fast because you don't need to catch them up on state, you can spend the whole time focusing on how to work smarter/better.

One problem with writing everything down is curation. When everything is a focus, then nothing is a focus. I find it helps to point stakeholders to specific places, give them summaries, and even schedule calls to call out initiatives or summarize some for them.

So in other words, write everything down so people can look at it and dig as deep as they want, but maintain good summaries and curation so there's no TL:DR (too long, didn’t read).


Q. Do you employ any visual project management tools as a PMM team that work well, even remotely?

A. Yes! We use GitLab as our project management solution. Here's an example of something I'm currently working on, and this is the next milestone.

We do as much as possible asynchronously. I use ‘comments’ on GitLab Issues predominantly, and treat chat as an async tool.  We do have weekly team meetings that are recorded and notes are taken in case anyone missed the meeting. Scheduling ad hoc calls anytime async doesn't seem to be working. I still do a lot of video calls but they tend to be the last resort rather than the first.


Q. What process(es) (e.g. meetings, regular documentation updates or memos) do you have in place to stay aligned as a team? How do you navigate any challenges around resource limitations between yourself and your fellow PMMs (e.g. creative resources, content/copywriters, digital marketers, etc.) when you can't swivel in your chair and stay informed of what your colleagues are up to or have an informed discussion around what should be a priority?

A. I will say this is way easier in a remote company than a co-located company. When everything is written down you can just look and see what other teams are up to without needing to swivel your chair. I can read faster than I can talk. I can keep up on five teams reading their GitLab Issues in the time it takes to schedule a meeting with one.

There are still challenges - as the company grows it's been more important for leadership to stay aligned. We do that through OKRs, so when different functions are aligned on what you are tackling together, then individual contributors have more autonomy to go and execute because the strategy is well defined and well documented.


Q. How do you ensure consistency in documentation approaches across people and teams? Is there any governance in place?

A. Actually, we are not very consistent across teams. Some are great at this, some are not. There is little-to-no governance in place. Part of this is cultural - we strongly believe in individual autonomy and ownership. We try to minimize approvals, governance, and oversight to optimize efficiency and execution.

I think we could do more to operationalize the practice of documentation. And I do think some governance is warranted. This is a thought-provoking question. I'll have to spend some time to think on this and make some proposals.


Q. It sounds like the primary method of info sharing is ‘pull’ rather than ‘push’ - i.e.  it’s on you to keep tabs on the things of interest to you.  Do you have a channel for pushing information that stakeholders can subscribe to? Or is that the role of strategy meetings/gatherings, and the assumption is if everyone is aligned on the strategy then everyone should be aware of what would be of interest to them?

A. This is very astute - in many ways, yes it is incumbent upon the individual to keep up with areas of interest, but this is more true for areas outside of your main work. For the stuff you work on the most you tend to get a ‘push’ notification.

There are many ‘push’ channels stakeholders may be interested in. For example, in our documented process, whenever a PM is shipping a new feature they at-mention (@) their PMM ‘stable counterpart’ on the feature messaging document for review. (We do this with GitLab Merge Requests.) A lot of teams and processes are constructed in this way, such that if something is happening and it relates to your domain or job function, then you'll get a notification about it.

In addition to async channels we still have team meetings and group syncs. I actually wish there were less of these as they don't all hold value, but some of them do for the sake of alignment.


Q. What do you find has been the most effective way to roll out new collateral/sales enablement tools/research etc. when you aren't in the room to present and get buy-in?

A. Async. We make collateral available for download at any time. Our sales team self-serves, for example, here is our resource page.

We also build things async using iteration. Instead of taking a month working on something by myself and waiting until it's super polished to share with my sales team, I share things right away. Even if it's one slide or very rough. I find this way I get input sooner. Sometimes I was headed in the wrong direction. If I had waited a month I would have wasted a month's effort. By sharing my work after one day (or one hour) I get immediate feedback and can pivot quickly to get going in the right direction.

That being said, you can't replace face-to-face time. We schedule on-site sales training especially when folks are new. We do regular "Sales Quick Starts" which are gatherings of the remote teams to on board new sales reps.

Finally, we do a weekly sales enablement call where we present and then do Q&A. We record these and put them on YouTube so that sales people can watch them even if they can't make the meeting. Here's the full playlist (we do the call every week, but sometimes we make the video private so we can talk candidly about customers and info we don't make public).


Q. Who are the people or teams you have regular check-in or status meetings with?

A. At GitLab we try to have as few status meetings as possible.

A theme emerging on this AMA is "write everything down." When everything is documented and up-to-date, you don't need as many check-ins. You can just look at the state of the project async on your own time. That being said, we still do a lot of video calls. Regularly scheduled meetings (some weekly and biweekly, many only monthly) are as follows:

  • Product marketing team meeting
  • Product team meeting
  • Product managers 1:1
  • Strategic marketing meeting (what PMM reports in to)
  • All-marketing meeting
  • 1:1s with my "stable counterparts" (if I'm doing a webinar, I might sync with the Marketing Program Manager who owns the project, or if a big piece of collateral is in development I'll schedule syncs with my Content Marketing counterpart, etc.)
  • Project kick-off/check-ins.
  • PMM <> sales enablement
  • PMM <> sales leadership.

Q. Can you speak to how your weeks and months are broken out? What is the approximate time spent in-office , face-to-face, at home, doing market research, interviewing customers/potential customers, creating documents, planning and writing, if any? There is so much a product marketer can do, what pieces do you personally focus on and what do you pass off to your team?

A. I'd say that things at GitLab have been so dynamic that I have not developed a regular cadence. I've been at the company two years and in that time we have grown from 200 employees to 1200 employees. My day-to-day work has shifted dramatically, but a few points are steady:

  • I work remote from my home office always, I don't co-work with anyone on a regular basis.
  • We meet face-to-face regularly. Every nine months the company does an all-hands, the next one is in Prague.
  • We do on-site face-to-face onboarding for new salespeople. The PMM team takes turns being on-site for these and leading sessions. I've gone to one of the last eight.
  • Our first yearly SKO was co-located.

We are currently in the process of executing GTM planning for various use cases. You can get an idea of what our Use Case GTM planning and deliverable bill of materials looks like here.

You can also see how we've broken up the work, assigned it to different teams, and the time frame we are executing against here.


Q. Were you hired as a remote PMM? Have you hired PMMs who began as remote employees? What are characteristics you highlight (in yourself) or look for (in others) that demonstrate the ability to 'get the job done' even though you're not in the office?

A. The entire company is all-remote so we were all interviewed and hired remotely.

An extremely important concept for remote is ‘manager of one’. The idea is that people should be self-motivated and self-sufficient. They shouldn't need a manager to babysit them. I'd argue that, even for co-located teams, if you need your manager to watch you to get the job done, then that is a failure mode of operating.

Managers are there to coach, inspire, unblock, and promote your work throughout the org. When I interview, I look for strong alignment with our company values. I try to ask for stories of what people have done and then I listen to see if the way they work aligns with what's needed.

For example, "Tell me your biggest win in the last 12 months?"

Then I listen to see how they measured success, or ask openly as a follow up, "how did you know you were successful?" to see if they align with our ‘Results’ value.

I also listen to understand how self-sufficient they are. Were they driving the process or relying on others? I stopped an interview in the middle once and just told the candidate, "You will not be happy at GitLab." It was clear they relied on their manager to supply directive instructions that they simply executed. They liked it that way. For some companies this works, but for remote you need a ‘manager of one’.


Q. Are there any things the company does to set up remote workers for success like coworking memberships, desk set-up, collaboration tools etc.? Are there any processes, tools, etc. you've put in place yourself that you've found to be helpful?

A. GitLab puts a lot of resources and people into making remote work successful. You'll find a ton of content and links here from ‘defining all-remote’ to ‘in-person interactions’.

A few highlights:

  • My company paid for my adjustable stand/sit desk, an ergonomic chair, and a large monitor for my home office.
  • I don't use it, but they reimburse coworking memberships.
  • A strong culture of writing everything down and a bias towards asynchronous communication.
  • Every nine months we have a company all-hands where we gather for a week face-to-face. We don't do work for this week, it's designed for relationship building.
  • Our CEO models work/life balance. He took two weeks off a week before our last funding round. I spend a lot of time with my family and take days off liberally. The rest and recuperation makes me more effective.

Q. How did you become a remote PMM? Did you apply to an already remote working job or create the opportunity during an application to a standard office-based position or create the opportunity to work remotely in a job that you already held for some time and then migrate from being office-based to remote? I'd like to become location independent - are you seeing a trend towards working remotely and have any advice to make it a reality?

A. This is heavily dependent on the company where you work. I've worked at two companies that did this well, and one where I 100% needed to be in the office. When I applied to my current company I was just, "eh, remote work is cool, I've done it before," but it wasn't what drew me to the company. Now that I've been at an all-remote company for 2+ years, I am an enormous fan and have been sold on this is the ‘right’ way to do things for a lot of companies.

Yes! The tools and technology have gotten to a point where remote work can be very seamless. We are continually hearing about more companies going remote. For example:

Companies offering great remote work experiences: Sana Benefits, Firstbase, DigitalOcean, InVision, Automattic, Graphy, Parabol, HubSpot, Hubstaff, Loom, Yac Chat, Mozilla, GitHub, Elastic, Buffer, Zapier, Stripe, Hotjar, TaxJar, GitLab, Trello, Flock, Deel.

As a PMM, look for and apply to remote companies. A huge caution for remote roles at co-located companies, those tend to be a disaster. Look for places where the norm is remote. 70+% of the team should be remote including key leaders.

As a leader, schedule a call with GitLab's CEO or Head of Remote, and watch the interviews he's done with other startup leaders listed here.


Q. What’s your take on a remote position as a first PMM role? Do you believe one can benefit more from being in office if it’s their first time as a PMM?

A. What's more important is if the team is remote. If it's your first PMM role and you are remote but everyone else is in the office you will surely fail. (At least I've never heard of anyone doing this successfully). While most folks on my team have had prior PMM experience, one of my colleagues is in his first PMM role. He is crushing it.

If you can find an all-remote company that has an existing PMM team you can learn from, then joining them as your first PMM role will be more impactful than joining a co-located team. The reason is because all-remote teams tend to document more - the more content for you to learn from. When you are in the office you are limited to learning only from the person who's right in front of you. It takes more time and effort. You learn more slowly.

That being said, the overwhelming majority of companies are co-located, so if you are looking to become a PMM then just look for a good company where you line up with their values whether it's remote or co-located (just don't go remote when everyone else is co-located!).