---
title: "What I learned in using AI for planning and prioritization: Content strategy might be safe from automation"
date: 2023-10-06
description: "Planning and prioritization tasks Inputs to consider when doing doc planning Correctly identifying priorities Cycling in important-but-not-pressing tasks <a href="
canonical_url: https://idratherbewriting.com/blog/content-strategy-safe-from-automation
---
# What I learned in using AI for planning and prioritization: Content strategy might be safe from automation
The short answer is basically no, AI tools aren’t that helpful with this task. This is actually a good result, as it points to an area that tech writers can focus on without the fear of it being automated by AI.

Note: Due to the limited availability of tools for this task, I wasn’t able to do the full testing I wanted to perform. As a result, this post is more theoretical than experiential.

## Inputs to consider when doing doc planning

When doing planning and prioritization, you have multiple inputs to consider:

 - **Objectives at different levels:** These objectives include company-wide objectives, department-wide objectives, group-wide objectives, team-wide objectives, and even personal objectives. Known by many different names, these objectives are often called “OKRs,” for objectives and key results. Theoretically, the OKRs should stack, with each level supporting the objectives above it, eventually rolling up to the company-wide objectives. This stacking provides coherence across the organization. However, in reality, the objectives rarely stack.

 - **Analytics**: Analytics can identify the most popular content, content with potential usability problems, content with findability problems, least-visited content, and more. These analytics can inform priorities in some way. At the very least, a list of your top ten most popular pages should likely receive more attention than pages no one visits (unless the one visitor is a multi-million dollar partner).

 - **Release calendar:** The release calendar identifies upcoming product releases (that require supporting documentation) for all the teams you support. Gathering release information is key to planning, especially because it identifies some of the lengthier documentation efforts that might take several weeks to complete. Minor doc tasks don’t usually appear on the release calendar, but those major product releases that often require weeks of documentation work do.

 - **Backlog of bugs:** Almost every tech writing team I’ve worked on has 100+ bugs in the backlog, with different creation dates, severity, priority, and difficulty for each bug. The list of bugs is usually a miscellaneous list in random order. Some bugs were filed by tech writers, others by engineering teams. Some bugs might be old and no longer relevant, while others are still relevant but old and people seem to be getting by just fine as is.

## Correctly identifying priorities

Beyond these inputs, you have to navigate misplaced priorities due to extra-vocal requesters. Just because a team makes a doc request and is vocal about fixing the doc issue, it doesn’t always mean you should prioritize it. There might be more pressing issues impacting users that are outside the requesting team’s priorities.

For example, suppose Issue A is resulting in many frustrations and failures for users, but the Alpha team isn’t responsible for Issue A. Instead, team Alpha has a huge upcoming release for a feature that, in all reality, isn’t even something users want. Team Alpha is riding you to create documentation for their upcoming SuperDuper Widget, and they’re invested in having you dedicate endless hours to creating the perfect docs. All the while, Issue A continues to discourage users and lose business revenue; users don’t have a clear way to relay the problems with Issue A to you.

It takes a lot of acumen and willpower to backburner Team Alpha’s request and focus on Issue A. Now multiply this kind of prioritization across 5 different teams, and you’ve got a real challenge. Suppose Team Alpha happens to be co-located with you, or is familiar with how to file docs, or even just has doc champions. That doesn’t mean Team Alpha’s projects are more important than Team Omega’s projects, or Team Zeta’s, or Team Beta’s, and so on. In short, you need an objective way of determining priority apart from the person who happens to be shouting the loudest.

## Cycling in important-but-not-pressing tasks

There are also doc tasks that are important but which don’t map to any OKRs, aren’t things people are asking you about, and aren’t even user-facing bugs. These bugs could be scripts to automate doc generation and publishing, internal docs that define processes to follow, bug templates that require requesters to add necessary details when filling bugs, and so on. You have to cycle this work into the other doc work.

From all of these inputs, you have to decide what to work on. Ideally, you do this planning during sprint planning periods, which scrum-following teams tend to do every 2-3 weeks. However, in my experience, work rhythms are usually too dynamic to do this in a neat fashion. Incoming requests frequently disrupt and shift sprint plans. Additionally, it’s rare that I dedicate an entire day to auditing, labeling, and prioritizing bugs in a way that would facilitate proper planning. Even gathering analytics data, reviewing goals, and updating the release calendar are time-consuming tasks in themselves.

Here’s what usually happens: Every few days, I take out a clean sheet of paper and write down all the pressing tasks I have for the day or week. I draw a vertical line down the page and put all the work tasks under a title called work, and on the other side title it home and put all my personal tasks. About every 2 to 3 days, I repeat this process with a new piece of paper. It feels ridiculous and embarrassing to explain that this is my organization process, but it’s what I’ve been doing for 15 years.

Can we use AI to help with the planning and prioritization of doc work? Let’s see.

## The experiment

Here’s my initial experiment to use AI for planning and prioritization.

### Step 1: Make sure information is up to date

To experiment, I first needed to make sure all the information was populated online somewhere. If the task was in my head only, there’s no way AI could help with planning and prioritization. To make sure all information was noted, I did the following:

 - **Make sure bugs exist for the work.** I looked through my email to make sure all doc requests were represented by bugs in the ticketing system. A lot of times, conversations start here but haven’t materialized into bugs yet.

 - **Audit all the bugs in the backlog to make sure they are current.** For each bug, I tagged them with the product name and the priority. I also made sure the titles reflected the work.

 - **Make sure my team goals are up to date.** I made sure our team goals were current. We make quarterly goals during a planning process, but they aren’t set in stone. They can also go out of date, get postponed, or be tasks that are already completed. If the tasks were completed, I marked them as completed so the AI tool didn’t factor them into the plans.

 - **Create a release calendar.** Although many teams have release calendars to track product releases, sadly I wasn’t this organized and didn’t have one. To put together this release calendar, I would need to navigate our launch system for product launches; the problem is that not all teams use this system, so it’s not reliable to track all feature releases.

 - **Export the latest analytics.** I should have exported our analytics, but I didn’t do this because I haven’t been monitoring my doc analytics lately.

## Step 2: Create a list of planning and prioritization rules

In this step, I created a list of planning and prioritization rules for the AI to follow. How can the AI decide what’s a priority unless I’ve defined what a priority is? Here are my rules for priority:

 - Prioritize bugs that are marked as P0 or P1 over P2, P3, and P4 bugs.

 - If the task is large (meaning it will take more than 3-4 hours to complete), suggest breaking it down into subtasks.

 - Keep time-sensitive tasks with due dates in mind. They might need to be prioritized more than tasks with no due dates.

 - Group similar tasks to take advantage of similar momentum and context.

 - Prioritize bugs that are related to goals (OKRs).

 - Don’t prioritize bugs that are blocked due to incomplete prerequisite tasks.