Product Content Ops have a powerful role to play in team health in a way that supports but does not duplicate the manager’s role. In most orgs, a manager’s role is very clearly defined, and its focus is typically on people management and higher-level content strategy.
Tools & systems
- Evaluating different tools used to produce, manage, distribute, & maintain content, which can include:
- Working with different teams to manage internal and external-facing content.
- Identifying tools that can fill gaps or ease pain points in existing or ideal processes.
- Holding meetings with providers to understand new/alternative tools and how they can best fit the org processes.
- Reaching out to other members of the community to understand how other teams have handled similar challenges.
- Keeping their finger on the pulse of industry trends.
- Exploration of new delivery mediums to keep the business at the head of their game.
- Establishing and tracking team initiatives (for example, holding content audits).
- Identifying, suggesting, and shaping team-wide projects that further team goals.
- Making sure projects progress as expected.
- Establishing and updating a content design system and other style, voice & tone guidelines, and making sure these are adopted and consistently.
- Overseeing content management hygiene.
To optimize success, the above 3 tenants of the Product Content Ops role ideally facilitates the work of others, acts in a dialog, and is available as a consultant, not as one-way enforcer.
Sounds like more than one person’s job? Quite possibly! But at the same time, not everything included in the above list needs to be solely managed by Product Content Ops. In some orgs, it may make more sense for the manager or principal product writers to take on some of these tasks. Which tasks depends on the size of the business, the team, and the biggest challenges the content team is facing.
Product Content Ops always has a place
When is the right time to establish a Product Content Ops role? That’s a great question, but it doesn’t have a one-size-fits all answer.
Small and medium businesses may not have the need or resources to have a separate role that does Product Content Ops, but that doesn’t mean that no Product Content Ops tasks should be done. Even as a single product writer in a company, Ops tasks should be identified and carried out as much as they can and according to the most pressing needs. This may look like more data analysis and establishing guidelines than education and onboarding. I would advocate that the product writer needs to make sure that a certain percentage of their time is reserved for such tasks, which means the next hire should come sooner rather than later, and the manager of the first product writer must be aware that this is an important part of the product writer’s time. At this stage, the single product writer should not be completely focussed on purely writing.
As the next product writers are hired, including a dedicated product content team manager, time should still be reserved for Product Content Ops in each headcount’s role, even if the distribution of those tasks is not allocated per person.
As a larger team is established to keep up with business needs, it makes sense to begin to consider shifting Product Content Ops off the collective and into a dedicated role. Whether this shift comes to a team of 5 or 10 product writers is going to depend on business growth, product size, team maturity, and smaller but not less important factors such as how the current infrastructure supports what’s required of the team. There may be a catalyst that means having a defined role comes earlier rather than later, such as the need to replace a tool, establish processes, or when it’s clear there are many stakeholders to collaborate with (too many for a team to keep up with).
Starting a dedicated Product Content Ops practice
It’s not that hard to get a Product Content Ops practice started. Rachel McConnell, the world’s leading authority on Product Content Ops, generously shares her wisdom both in her book Leading Content Design and in choice talks she’s given on the subject. I strongly recommend this book, catching a talk, or even joining her community Lead with Tempo to immerse yourself in the ins and outs of Product Content Ops. Let’s go over the key starting points suggested by Rachel here.
STEP 1: LISTEN
The first step is to take stock of what’s happening on the ground. This will initially take the form of a lot of interviews with “All The People,” starting with product writers and moving out progressively from everyone they work with to everyone within the org who either consumes or leverages their content. The goal of this listening step is to drill down to uncover the problems that exist, and assess their severity.
The second part of this step will be to observe what is happening in real-time. This might look like the Product Content Ops attending meetings to observe processes as they happen live, taking time-tracking surveys to understand how much time is spent on different tasks, or holding post-mortems to look critically at what is and what is not working.
By the end of this step, you should have the answers to the following questions:
What should product writers be doing vs. what are they actually doing?
What are the desired outcomes of their work vs. what is the actual outcome?
What’s being said?
STEP 2: MAP
In the second step, the Product Content Ops should assess and map the tools and processes that are currently in place in the organization. This step should surface data that’s less biased than people’s opinions, and more rooted in the nuts and bolts of the mechanism serving the system. Look out for gaps in addition to what exists. Together with data collected in the first step, the biggest pain points and challenges should be emerging quite clearly.
By the end of this step, you should have the answers to the following questions:
What are the biggest pain points?
What categories do the issues fall into?
What’s already being done about them?
STEP 3: SOLVE
In the third step, it’s time to brainstorm solutions to all the identified problems. Since product content is mostly a Product discipline, I’d recommend using Product methodologies such as problem framing and ideation through design thinking. This just seems like the natural choice to me, but it’s certainly not the only way. As well as identifying the “what” of the solution, give some thought to “how” you can establish alternatives, and what that will look like and how long that will take for each solution.
At this point, it’s probably also prudent to link the problems and solutions to your org goals. Prioritization, which we’ll get to in the next step, will be affected by your business focus, so it’s good to be able to tie the benefits associated with the problems you’re solving to those goals.
STEP 4: PRIORITIZE
Once you’ve identified solutions, the fourth step is to prioritize how and when you are going to tackle the issues. An easy way is to use the high/low effort/impact quadrant, but again, this is not the only way. At the end of this step, you should be able to have a roadmap of what you’ll be tackling immediately, and what you’ll start in the short term, and what can wait one or two quarters, or not be tackled at all this year.
AFTER: ONGOING IMPROVEMENT
Once you’re up and running, the Product Content Ops should keep the discipline in check by continuing to monitor the success of implemented changes, and keeping checks on both the level of severity of problems that were identified but not prioritized, and staying alert for any new problems that arise. The Intent Cycle maps the process of establishing the Product Content Ops practice to the ongoing cycle of establishing that allows for constant improvement as time goes on.
