My Process

My content strategy process is fairly simple. First, I dig in to really understand the objective. Then, I think about possible ways to achieve it. Next, I do my homework to figure out what’s realistically possible and validate or correct my assumptions. That’s when I can start getting into the nuts and bolts of the strategy. I iterate on it until my team and stakeholders are in alignment. From there, the plan can be executed – which may also involve a high degree of testing and iteration. Finally, I evaluate the results and look for positive takeaways I can apply to my next project. 

Essentially, I start broad and work toward the specific. I’ll elaborate: 

Understanding the goal

When it comes to content strategy, the execution is never the hardest part. It’s so important to really understand the goal and ask the right questions. Who are the stakeholders? The decision-makers? What about the audience? Context matters too. What do we hope to achieve? Why do we want this specific outcome?

Don’t get me wrong, you may be able to devise a perfectly workable and successful content strategy without that big-picture view. But you’re much more likely to bump up against problems you never knew existed. And those serendipitous opportunities to make an adjustment here or there and solve a few other needs along the way? You’ll miss those completely.

Imagining what’s possible

Once I understand where the journey should end, I like to do some blue-sky thinking about all the ways we can get there. What would be the most ideal solution given known constraints? I find it’s helpful to collaborate with other teammates who can bring forward new ideas and perspectives different from my own. I truly believe a team’s diversity of thought is gold for shedding light on blind spots and bulletproofing a strategy.

Even if I factor in known constraints, it’s always the unknowns that shape the final strategy. To account for this, I like to come up good, better, and best-case scenarios to use as a guide:  

Good — A strategy based on the bare minimum needed to achieve the goal. Ability to execute hinges on few to no contingencies.

Better — A middle-ground strategy that includes a mix of “nice to have” elements alongside those that are strictly necessary. Ability to execute hinges on some contingencies.

Best — The most ideal strategy. Some elements may be especially difficult or costly to achieve or may have a number of outside dependencies. Ability to execute is highly contingent.

Research and information gathering

The best-case scenario is what informs my research and information gathering because it has the maximum of contingencies. My “good” scenario sets a bar I can’t dip below without jeopardizing the success of the project. If I uncover enough constraints to reduce the strategy to this extent, I may need to go back a step and re-think some elements, find suitable compromises, or work with stakeholders to ease or eliminate constraints.

Unless I’m very lucky, I don’t expect the best-case scenario to reflect the strategy I’ll actually execute. But it gives me room to whittle things down when I uncover new constraints. Typically, the final strategy will fall somewhere in the middle scenario. To get there, some of my explorations may include:

• Researching the audience, their needs, wants, and expectations
• Setting standards for style, accessibility, and inclusion
• Analyzing data and reports to understand performance or trends
• Consulting with product owners or subject-matter experts
• Determining available resources and competing priorities
• Evaluating functions or compatibility of technology systems at play
• Speaking with other teams to understand capacity to lend support

The list could go on, but suffice it to say, there will likely be both internal (pertaining to the organization) and external (pertaining to the end user) questions that will need to be answered. These will shape the strategy.

Detailing the strategy

Once all (or most) questions have been resolved, I can build out user personas and journey maps, decide on the tone of voice, outline necessary steps and phases, and determine the order of operations. Knowing priorities, dependencies, and constraints, I can map project phases onto a timeline and set milestones. If answers to any questions are still pending, I can begin to document ways the strategy might pivot based on the outcomes.

Feedback from end users and observation of their behaviors can help us understand where we’ve been successful and where we need to make improvements. After a launch, it’s especially important to address problems quickly. It’s also important to have a plan in place for the ongoing maintenance of a product or experience. So I like to include recommendations around these needs as part of the overall strategy as well.  

Sounding out the strategy

Once I have the first draft of a strategy, my next step is to present it to project stakeholders. I like to think of this as another bulletproofing opportunity. I look for feedback on any gaps, misses, or other considerations. I expect this to be a highly iterative and collaborative process, where I work with stakeholders to really refine the strategy. This is the time to smooth out kinks and weed out potential problems — or ensure we have suitable contingency plans in place.

The scale and scope of a project may make it necessary to iterate further on some of these steps to get to the right level of detail needed to execute successfully, especially on very large projects. But at the end of the day, planning is everything. A well-honed strategy ensures a smooth and seamless execution.

Building, testing and iterating 

Once it’s time to execute, it’s important to ensure everyone is equipped with the right tools. For content writers and editors, that means having a style guide with clear standards and text patterns. When I serve in these roles, I like to work collaboratively with designers and product owners to achieve a more harmonious marriage between microcopy and design, so tools like Figma are a must.

Mockups or wireframes are a good way to get everyone on the same page, seeing the same vision. Sometimes multiple drafts and incremental changes may be necessary to bring a project closer to the mark. When possible, I like to test different approaches to validate my work. Early insights are invaluable for testing our assumptions and can radically change the outcome of a product or experience. Plus, testing provides another opportunity to shine a light on blind spots and really see a journey from the user’s perspective.

Evaluating the outcome

The workplace is busier than ever, and it’s too easy to keep moving forward without looking back. I like taking a retrospective look at a project once it’s completed to evaluate performance and think about the takeaways. But it’s important to go a step beyond the performance metrics and think about the team and the process too.

What worked or didn’t? Did we discover repeatable processes that can be applied elsewhere? Are there opportunities for greater efficiency? Where were the snags and bottlenecks, and how can they be avoided in the future? Where did team members really shine, and how can we lean into those strengths in the future? Did everyone have all the tools and resources they needed? What can I take from this to make the next project even better?

If you challenge yourself to believe that, no matter how good something is, it can always be better, you’ll never be bored. You’ll always have a problem to solve and a motivator to drive personal and professional growth. That’s why reflecting on lessons learned is the final key to my process. Excellence is a journey, not a destination.