Researching Subjects for Content Strategy

Here’s your handy guide to the more popular objections you may encounter:

We already know what our customers want.

Despite hiring you to deliver valuable content, stakeholders still insist they know best. Fine, start there. Get a list of requests and treat them as assumptions. Assumptions are there to be challenged or confirmed. Domain research confirms whether experts and users agree with your stakeholders about what’s important.

Say, “All your suggestions are interesting. We don’t have budget to do everything. Let me talk to the customers to make sure we’re not spending money on the wrong stuff.”

We don’t want to bother anyone.

This happens a lot, especially if you’re an agency engaging with a client company. The implicit translation is “we don’t want you bothering anyone.” It’s as though the company is afraid of looking vulnerable in front of its own customers. Here are a couple of lines to try:

“This app we’re making needs to pay for itself by reducing calls to the support center. Let’s find out what kind of support customers need most. Then I can provide the right content to meet your goals.”

“To make you a great website, I need to understand your business. We can decide on what that looks like later. For now, let’s talk to some people from around the business to figure out how everything works.”

It will take too long.

As opposed to what? Diving straight in without a clue? Maybe your stakeholder got burned by a six-month research project that led to nothing but a report. That report currently resides unread at the bottom of everyone’s drawer. But you’re asking for only a few weeks (maybe even a few days) to lay the groundwork for the whole project. Tell them this:

“It’s great that you’re eager to get started. I want to make sure we lay the right foundations before we start building. Let me put time in your diary for us to chat. In the meantime, I’ll reach out to other folks around the business. I want to get a real understanding of what happens here.”

It will hold up engineering.

We truly, madly, deeply love engineers. They’re the people who make the rubber meet the road. But sometimes they’re treated like a marching army who must never stop for anything or anyone. (If only the rest of us commanded that much respect.) If you’re treating your most expensive people with such care, you should want to point them at the right problem. Give this line a whirl:

“I want to get engineering involved! This kind of planning could use their expertise in how to structure information. What I’m calling ‘research’ is really how we get them what they need to build the data model.”

By the way, that’s completely true. Figuring out the subject domain informs the model you’ll design to support content in your database or CMS. In fact, engineers have been some of our most supportive allies in this process. More on that in Chapter 5.

We’re doing Agile development.

The Agile manifesto for software development favors “responding to change over following a plan.” For some teams, that can mean that anything that smells like planning gets dismissed out of hand. But even the smartest Agile teams don’t dive into development without a clue about what they’re trying to achieve. Instead, they develop a working hypothesis. You’re proposing just enough research to get them started.

“I believe that using structured content will make the product more useful and usable. If we build for the right mental model, we’re investing effort in a scalable content framework. That’s much more efficient than making one-off, throwaway microsites.”

Agile teams may start by building something smaller, sooner. Starting with a small, structured content prototype, they’ll follow the same process of research and discovery and funnel everything they learn into a new and improved prototype.

It will be too expensive.

Not nearly as expensive as leaping into interface design and engineering without a plan. Since good preparation is the basis of any project, we’re not sure that even the stakeholders who make this argument believe it. Still, prepare to defend your ground:

“As you know, cost and complexity increase the further you get into a ­project. I’m trying to contain costs by preventing any rework due to assumptions that turn out to be incorrect. This is perhaps the cheapest way of preventing expense later.”