Skip to content
Notifications
Clear all

Unpopular opinion: brief templates should be tool-agnostic

2 Posts
2 Users
0 Reactions
0 Views
(@consultant_carl_42)
Estimable Member
Joined: 2 months ago
Posts: 127
Topic starter   [#7307]

Here's a thought that will likely get me thrown out of the next MarTech happy hour: if your content brief template has a dropdown for "Grammarly score" or a mandatory field for "Surfer SEO keyword list," you've already failed at the foundational purpose of a brief. You've built a cage for a specific vendor's hamster wheel, not a blueprint for human communication.

I've watched, with a kind of morbid fascination, as teams build exquisite, intricate templates inside their chosen tool du jour—be it Asana, ClickUp, Notion, or the latest AI-writer platform. They embed dynamic fields, connect to style guide databases, and automate distribution. It's impressive. Then, two years later, when the CMO gets a sweet deal on a different suite or the workflow tool becomes a bottleneck, the migration begins. The screaming starts. Suddenly, that beautifully engineered template is a millstone. The data is trapped in a proprietary schema, the logic is hard-coded to features that don't exist elsewhere, and the historical record of *why* decisions were made is locked in a system you're fleeing.

A brief is a strategic document. Its job is to align stakeholders on:
* **Core Objective:** What is this piece meant to *do*? (Not "generate leads," but "reduce friction for developers evaluating our API by explaining the auth flow in three concrete steps.")
* **Audience Reality:** Who are we talking to, and what do they genuinely care about *today*?
* **Message Hierarchy:** What's the one thing they must remember? What supports it?
* **Practical Constraints:** Word count, internal links, mandatory legal copy, actual due date.

Notice what's absent? Any mention of a specific software's features. When you anchor your process to the tool's capabilities, you invert the logic. You're letting the vendor's product roadmap dictate your content strategy. I've consulted on the aftermath of this more times than I care to count. The conversation is always the same: "We want to move from Platform A to Platform B, but all our templates and historical data are built around A's 'Content Score' and 'Readability Framework.' How do we translate that?" You don't. You rebuild, at great cost and frustration, because you built on sand.

Start with a flat, boring, portable document. A Markdown file, a Google Doc with standard headings, even a well-structured text file. Define the *what* and the *why* in human language. *Then*, and only then, figure out how your chosen tool of the moment can help you distribute, track, and enforce that blueprint. The tool should be an implementation detail, not the architect.

Your process should survive your software. Because I guarantee, your software will not survive your process forever.

-- Carl


Test the migration.


   
Quote
(@bearclaw)
Estimable Member
Joined: 1 week ago
Posts: 91
 

Saw the same pattern when monitoring vendors change. Teams build dashboards and alert rules so deeply tied to one platform's query language and feature quirks that the migration is a full rewrite. The playbook for what a "critical error" even means gets lost in the translation.

Your "cage for a vendor's hamster wheel" is perfect. The brief, like an alert definition, should survive the tool. If it doesn't, you documented the tool, not the intent.


Prove it.


   
ReplyQuote