Increase Blog Brief Output for ClickUp

With demands increasing to 200 blogs per month, the SEO team for ClickUp (a small, 3 member team) is strapped for resources to build comprehensive briefs for the writing team, which consists of in-house writers and agencies. Each brief, when at its best, takes up to 45 minutes of human labor, adding up to at least 150 hours/month, but is itself just a vehicle for information and knowledge transfer.

Goals

We aim to automate the blog brief process while retaining essential SEO research to maintain quality. The goals are: to decrease time to production, free up bandwidth for team members for higher leverage SEO tasks, improve quality of SEO inputs in the blog brief.

Business Case

Content requirements are growing, and the SEO demands are higher than ever Great organic SEO has led to 150% growth in user acquisition growth year over year The brief is an important document that provides direction for topics writers should include, but is never an actual content product released publicly

Qualitative Evidence

SEO manager: “This would be a game changer and help us break down the bottlenecks that are the brief demands.”

SEO specialist: “My work has been slowly filling up with more and more briefs, it’s becoming a blur.”

Current products in the market that help with brief building include SurferSEO and Frase. However, these solutions are all “one-size-fits-all” solutions and do not include company-specific knowledge, such as internal links and company products. Furthermore, they require a subscription of $50-100 per month.

Key Product Unlocks

Important benchmarks for the product will look as follows:

Access and retain comprehensive research in topic analysis

Current state: Reading through top search results and analyzing research requires 40% of the brief building process. It requires the user to click on each result, scan the top headings for common keywords, and synthesize a cohesive hypothesis on important sections to include. Sometimes, the user can take a more analytical approach through the SurferSEO tool which will aggregate these semantic connections and provide best recommendations.

A process which automates this should have the following functionalities:

parse multiple sources of research
pare down important and essential similarities
return cohesive, actionable information

This will replace the need for such a manual process and save a large majority of the brief building time, as well as uplevel the “information gain” score.

Return brief outline according to ClickUp’s standards and best practices

Current state: After synthesizing the information, the user would put together an outline of headings, descriptions, audience and tone, which requires decision-making at each level. However a lot of these decisions are based on research parsed in the first step and the user is just essentially “copy-and-pasting”. This step takes approximately 25% of the overall brief building.

A process that automates this should be able to:

Follow the same structural guidelines consistently
Include all the relevant information
Return highly relevant internal links

Current state: The user usually spends 15% of the blog brief building process finding relevant internal links that would make sense to include in the article. The general process for doing so would be to use the operator “site:clickup.com [target keyword]” and grab the first 5 results. This is not only inefficient (and highly automatable) but also haphazard – Google, while great at serving up publicly relevant content, may not have access to the entire site’s database.

This method does not consider recently published posts or other articles which have a bit more tangential relevance. Furthermore, there are usually needs to include landing pages and templates and so the user would need to run this query multiple times.

A process that automates this should be able to:

parse through a list of relevant URLs
reference a list of URLs that is automatically updated
return a custom number of relevant links

Mockup

A sample mockup of a proposed blog brief agent should look as follows:

Blog Workflow

Risks

There are two concerns for risk. First, the solution could make the job longer to build an at-par brief. Second, implementing this solution would lead to downstream effects of poorer SEO results due to lower quality briefing instructions. To mitigate these risks, this solution will take a more comprehensive approach to brief building to reduce the need to switch between multiple apps. To avoid poor SEO results, we should ensure the SEO team has screened the first batch of outputs to ensure quality. We should also collect data through multiple points of the research process, such as top SERP results for multiple variations and information gain strategies such as parsing indexed PDFs.

Measurements of Success

Hypothesis: We can increase output of blogs by 2x while decreasing time investment North Star Metric: 75% time savings on blog briefs, as measured by number of completed tasks per week.

Reason: This is primarily an efficiency product, aimed to increase quality of output and decrease time to market. If the team is able to scale to more than 200 briefs, the SEO flywheel can be scaled even further with more writers and teams.

Guardrails:

NPS of writers (qualitative) - is the brief easier to digest? Does it provide a better user experience? Is it comprehensive? Are there any made-up facts or repeated headings?
SEO results (rankings & traffic) - do we see a drop in time-to-rank or overall lower ranking averages with new pieces?

Next Steps

Discuss with the relevant stakeholders: SEO team, writers, and engineers SEO - what are the major “SEO quality” elements that must be included for this to be more useful than manual? Writers - what are key pieces of information you’d wish you had when writing? Engineers - is this mockup possible and what are other ways of approach?

This was my first PRD I wrote, after coming across Akash Gupta’s Becoming a PM with No Experience where he advised us to start writing PRDs, writing them for our own products we made.

I’ll admit that this PRD was after the fact that I built the tool, but it was still fun nonetheless. As I wrote this, it made me realize some massive oversights I had made, which, had I considered them, would have made the product significantly better. Alas…

If you have any comments or suggestions to improve this PRD, please email me.