Your content strategy needs more than executive-level stakeholders

When designing a digital product, the highest level decision makers aren’t the only voices that matter. Talk to employees who will actually rely on the product day to day.
Illustration of three hands holding equal-sized parts of a pie chart

Introduction

Stakeholder buy-in is a big part of any successful content strategy. Our work isn’t just about the public-facing design of the content for people using a website or app. Working with people within an organization to optimize content processes is an essential part of what we do.

At Pixo, this typically involves a series of work sessions and activities to understand client goals, priorities, and internal functions. We talk to high-level decision-makers, of course — but from experience, we know that we also must include the people in an organization who will be working directly with the product we’re building or the customers it’s intended to reach. Why? Because these people know key details that can make or break a product.

Employees who need the tool to do their jobs have invaluable insight and deserve to be involved. 

Excluding people at lower levels of the organization can backfire after a product is launched. Consider this scenario: 

You and your client teams just launched a brand new website with custom content management system (CMS). You’re very proud. It looks great. You hand it off to the team of folks that publish and manage the web content, and they don’t seem very happy. Weeks pass, and adding content is much slower than you expected. The people using the CMS  are doing so in a way that you didn’t intend. They are using page types and components incorrectly, in an attempt to replicate the old site. How could this be? The old website and accompanying CMS was archaic, and this new one is user-friendly and modern. Improvements were made, so why don’t content authors want to use it? 

What went wrong?

In this scenario, none of the people who actually work with the CMS and publish content on the website were included in the design process. As a result, they are either having difficulty navigating a new tool that wasn’t made with them in mind, or they don’t feel empowered to get started.

Clients don’t keep other stakeholders in the dark to be malicious. They often do so to reduce the amount of internal budget spent on a website project. Sometimes clients exclude as a way of protecting their employees from information overload. Often, they just don’t realize that a variety of perspectives is necessary to good design. But, there are a couple of reasons why it is important to include these folks:

  1. Morale: When a boss or manager initiates a major overhaul that deeply impacts someone’s day-to-day work, and doesn’t include them in the process, it can impact morale. Low morale is not good for adoption of new processes or tools.
  2. Efficiency: The people writing content and managing the website are going to provide the best insight into what works and what doesn’t. Rather than guess, why not bring these experts into the project meetings? Including them from the start and keeping them involved throughout actually increases efficiency. 

How do we avoid this?

Content governance is all about establishing how the content work gets done and who does it. Make a point of talking to the people who do the work just as much as you talk to the people who  manage them. During the discovery phase of the project, content strategists must put on their journalist hats and do a little digging to get unbiased information. Instead of asking the client who they think you should talk to, do your own research and come to them with your list ready. Once you identify your stakeholders, include them early and often throughout the project. 

Employees at lower levels of the organization likely understand the customer journey better.

Content doesn’t exist in a vacuum. If your content has the potential to impact business processes or customer flow, then you better make sure to establish a shared truth about what happens during the customer journey. Here is a scenario where excluding lower-level stakeholders can lead to inaccuracies in your content: 

We are building a new website for a client, and they want a contact page. The marketing executive serving as product owner  tells us all the page needs is a general phone number for customers to call for help or questions. So, we design  that contact page and launch the website. Weeks go by, and suddenly the client is in panic mode, rushing the team to make updates to that simple contact page. Their customers are threatening to take their business elsewhere, to a place with better customer service. It turns out the phone number rings to the front desk, which is not monitored by the same person every day, nor is it staffed by people with the expertise to help confused or upset customers. So customers get passed around or put on hold, and leave voicemails that are never answered. 

What went wrong?

Not talking to customer service reps is a mistake. As a content strategist, you must establish a shared truth about the current reality of both internal and customer-facing processes. What is the service the organization offers? How is the service delivered? Note that the question is not how is it supposed to be delivered. In this scenario, assumptions were made. Sometimes we make these assumptions unconsciously, and other times we do so to jump ahead to the “important” stuff. It can feel like a waste of time to ask such basic questions. 

How do we avoid this?

In this hypothetical scenario, we had assumed that the executives and marketing team were all living in the same reality as the customer service team. Once again, we must put our journalist hat on and fact-check. If you were a journalist, and a source told you a rumor about another person, you would try to make contact with that other person to confirm the truth, right? 

When you do fact-check with the customer service team or content author or whoever in the organization does the job, remember that no question is too basic. Sometimes it is important to ask “stupid” questions, and in this case, we would have found out:

  • What types of support customers need most often
  • Who is currently providing that support, how they are providing it, and when
  • What is the most efficient way for a customer to get the support they need

With that information, we could have included step-by-step instructions for customers and a better method of making contact. At the very least, we could have included content that set expectations for how long it might take to resolve a customer service issue. 

Pixo content strategists like to talk with stakeholders at different levels in the organization, because it is not uncommon to find some discrepancies between the perspective of the customer service team and the executive team. Exposing the discrepancies is the first step to fixing them.

Make sure your clients understand why you value their employees’ perspectives.

It’s common to assume that important stakeholders for website projects are the high-level marketing or executive team members. But, as a content strategist, I’m most interested in getting to know the customer-facing stakeholders and content authors. That doesn’t mean it’s always easy to make those connections — it can be scary to tell a client you need to speak with someone other than them, or push back when they try to limit your access to multiple perspectives.

When I say you should include stakeholders early in the process, I mean very early. I find the best time to ask for this is in the sales process. Pixo makes a point of clarifying what we need from the client in our project proposals; that way, there are no surprises. The proposal is also a great place to not only ask for what you need, but to explain exactly why you need it. This is the time to draw a strong connection between the people affected by a new website  and the success of the project as a whole. Giving clients this heads-up also means they have plenty of time to coordinate schedules and plan for employee involvement. Time spent on the front end will almost always save time — and rework — at every stage of the project.