Lena’s Blank Brief. Missing the Editor’s Slot Means Losing the Publishing Window.

A strong content brief often begins with a question your audience has already asked in public. Search queries, forum threads, GitHub issues, video comments, and app reviews reveal the words people use, but editorial judgment decides which questions deserve an answer.

At 4:40 on a rainy Thursday in Manchester, Lena was staring at a blank planning document while her co-founder packed a laptop charger for the train home. Their small developer-tools team needed Monday’s article brief before the weekend. The working title, “Why Observability Matters,” sounded respectable and said almost nothing.

One renewal conversation had already exposed a documentation gap. If the next article missed the questions prospects were actually asking, Lena could lose another week to a polished piece that attracted readers with no reason to consider the product. Their freelance editor had one open slot left. Missing it meant losing the publishing window altogether.

Then Lena found a tightly scoped question in Search Console. Someone had searched for the exact failure mode their product handled, using a phrase the team had never put on the site. A related GitHub discussion showed where developers became confused. Two YouTube comments revealed what they tried next.

The brief stopped being a guess.

Lena is an invented composite, but the bind is familiar: a deadline, a broad topic, and dozens of places where a useful question might be hiding. The answer is rarely to search everywhere. It is to search with boundaries.

Start with a defined reader and a live decision

In the previous part of this product story, the team turned broad market signals into a manageable editorial direction. That direction now becomes a filter.

Before opening Reddit or searching Stack Exchange, Lena writes one sentence at the top of the brief:

“A technical lead evaluating error monitoring needs to understand why production failures remain hard to reproduce.”

That sentence does useful work. It names the person, the decision, and the knowledge gap. A question belongs in the brief only when it helps that reader make that decision.

Without this boundary, discovery turns into collecting interesting links. A highly active discussion can still be irrelevant. A keyword with apparent demand can attract students, hobbyists, recruiters, or people looking for a different product category. Popularity tells you that attention exists. It does not tell you that the attention fits.

My bias is to reject aggressively at this stage. Ten loosely related questions create a vague article. One precise question, supported by several healthy sources, can carry an entire piece.

Build a question trail, then inspect the evidence

Lena starts with the product’s configured target market, positioning, competitors, and keywords. Marketing Agent can scan trends and news, surface evidence-linked angles, and maintain those ideas inside the product’s editorial calendar. The useful unit here is still the underlying question, with its source attached.

Her walkthrough looks like this:

1. She checks Search Console for queries that already bring impressions to relevant pages. She looks for wording that exposes confusion, comparison, urgency, or an attempted fix.

1. She searches relevant subreddits and Stack Exchange communities for the same problem. She reads the thread around each question, because the title alone often hides the real constraint.

1. She reviews product-adjacent forums and GitHub issues. A repeated technical complaint can reveal the point where a general explanation needs a concrete example.

1. She checks YouTube comments and app reviews for plainspoken language. These sources often contain phrases people would never type into a formal survey.

1. She records the source, date, question, audience fit, and the evidence it contributes. A brief should let an editor trace the idea back to where it came from.

Each source has different strengths. Search Console reflects queries connected to your existing site. Reddit and forums show argument, context, and failed attempts. GitHub can expose technical details. YouTube comments capture reactions after someone has watched an explanation. App reviews can reveal expectations and recurring friction, although they may concern competitors, old versions, or circumstances you cannot verify.

That last caveat matters. A complaint is evidence that someone expressed a problem. It does not automatically prove the cause.

Filter for relevance, source health, and answerability

By Friday morning, Lena has gathered nineteen questions. Only four survive.

She removes questions from abandoned communities where spam has replaced discussion. She drops a thread whose answers are years old and tied to an outdated product version. She rejects a popular question aimed at a different buyer. Another question stays in her notes because the team cannot answer it honestly with the evidence available.

The remaining questions pass four checks:

• The person asking resembles the intended reader in role, situation, or goal.
• The question connects to a problem the product genuinely addresses.
• The source has enough context to interpret the question without guessing.
• The team can provide a useful answer without inventing facts or forcing a sales pitch.

Source health deserves more attention than it usually gets. Check whether a community is active, moderated, and still discussing the topic seriously. Read replies for corrections and disagreement. Look for duplicate posts that may come from copied content or coordinated promotion. Compare the publication date with the current product and technical landscape.

Marketing Agent can help collect evidence-linked angles across these sources, but broad discovery cannot choose the editorial argument for you. That choice requires someone to decide what the audience needs, what the evidence supports, and what the product has earned the right to say.

Turn the surviving question into reusable drafts

Lena chooses the Search Console question as the article’s spine. The GitHub discussion supplies a technical scenario. The YouTube comments clarify the language readers use when describing the failed workaround.

Her final brief contains a direct reader question, a plain answer, the intended audience, the decision the article should support, source links, required examples, claims to avoid, and the next action a reader should understand. She adds two related questions as subheadings rather than trying to answer all four equally.

From that one evidence-backed brief, the team can produce an answer article and adapt the core idea into social drafts suited to each channel. A LinkedIn post can frame the evaluation mistake. A short Reddit draft can answer the narrow technical question in context. A video script can show the failure state using an approved product recording. Each format keeps the same argument while changing the presentation.

By Monday afternoon, Lena is reviewing a draft that opens with the exact problem prospects are trying to solve. The editor has sources to check, the developer knows which example to validate, and the social drafts have a reason to exist beyond filling the calendar.

The next part follows that brief into production: how one supported answer becomes several channel-specific pieces without flattening every platform into the same post. For now, take the next question you find and write three lines beside it: who asked, what decision they face, and what evidence would make your answer trustworthy. If those lines stay vague, keep looking.