Daniele Polencic
Daniele Polencic

Technical Topic Research for Marketers

June 2026

Technical Topic Research for Marketers

Before we commit to a technical campaign, we have to answer one question:

How do we know engineers care about this topic?

At LearnKube, campaign research starts with where engineers spend attention, what they complain about, what they try to fix, and what they share.

That research is what turns a broad category into a campaign theme.

For example, the campaign theme AI-Augmented Kubernetes Operations: From Noisy Signals to Safe Action originated from a messy question asked by an engineer:

How do I use Kubernetes and AI?

The research was the process of unpacking that question until a useful campaign theme emerged.

Start With The Question Engineers Ask

Campaign ideas start broad when the first question is broad.

The question came in this form:

How do I use Kubernetes and AI?

The first step is refining the question before turning it into a campaign theme.

In this specific case, it can mean many things:

You can ask the person who raised the question to clarify what they mean.

That helps when they already know the job they are trying to do.

But broad questions often exist because the engineer does not yet have a clean answer. They may know that Kubernetes and AI intersect, but not which part matters: workloads, GPUs, YAML, troubleshooting, agents, or remediation.

So we do not rely only on the original questioner.

We observe how engineers approach the question, what tools they try, what peers ask, and where similar conversations repeat.

We needed to determine which interpretation mattered most, which audience felt the pain, and which campaign path would be strongest.

The useful move was to keep the branches separate as intent hypotheses.

AI does not exist in a vacuum. Engineers use it to accomplish a job.

Our job is to find out which job.

The possible intents were:

Those questions created a hypothesis map and defined the research scope.

Decode The Intent Of Each Source

With the hypothesis map in hand, we searched for places where engineers were already using, evaluating, or arguing about AI with Kubernetes.

Common places include:

Different sources reveal different kinds of intent.

GitHub issues show what broke, what users expected, and which missing behavior was painful enough to report.

They also require a map of the relevant projects: you cannot search GitHub for "Kubernetes and AI" and expect the issue corpus to organize itself.

You first identify the projects where maintainers and users already work through that question.

Then you read the issues in the context of each project.

Conference talks show what the community has already packaged into a teachable story.

Going back to previous KubeCon programmes and searching for keywords exposes related topics that the community has already turned into talks.

Skepticism, framing, and market language often surface on Hacker News and r/Kubernetes, though these discussions focus beyond Kubernetes.

Vendor pages and competitors help with category language and market positioning.

Searches such as "

company" reveal more players in the space.

For the AI Kubernetes research, the strongest evidence came from places where the conversation was already unfolding.

On GitHub we searched for keywords such as "Kubernetes MCP", "Kubernetes AI", "Kubernetes LLM" and found the following projects:

RunWhen and Botkube are also companies. That led to a "

alternative" search, which highlighted more options:

Armed with some patience, we searched for "Kubernetes MCP", "Kubernetes AI", "Kubernetes LLM" as well as "k8sgpt", "holmesgpt", "botkube" and "kubectl-ai" on r/Kubernetes and Hacker News.

The first pass did not produce a conclusion yet.

It showed the shape of the conversation.

Some threads focused on AI workloads and GPUs.

Some focused on generating YAML.

Others focused on giving assistants access to kubectl, troubleshooting, logs, read-only access, MCP servers, and safe operational control.

That context moved the research from "what does this mean?" to a sharper question.

The research question became more specific:

What are engineers trying to do with these tools?

Search For Evidence In Engineer Language

The most useful evidence is the language engineers use when the tool does not solve the job.

We looked for four signals:

Here are representative examples from the research corpus:

And sometimes the evidence points away. A Reddit thread asking "why is scheduling AI workloads complicated" confirmed that GPU scheduling was real, but it formed a separate campaign branch from operations augmentation.

The full evidence table with all 12 sources is available as a CSV.

The evidence table is the research layer.

Funny enough, none of them asked for faster YAML. They all wanted to understand what their cluster was doing without drowning in output.

The pattern looked like this:

That is why the research moved away from generic "AI for Kubernetes" and toward operator augmentation.

The working campaign question became:

Where does AI help the people who operate Kubernetes systems under production pressure?

Define The Audience From The Pattern

The audience became clear after the evidence clustered around operations.

The work described focused on investigation, triage, context building, runbook reuse, and safe action.

Running AI workloads, hosting agents, and generating manifests remained adjacent branches rather than the center of this campaign.

That pulled the audience toward:

This also changed the campaign title.

"AI for Kubernetes" is a common term that lacks specificity around audience, situation, and trust.

"AI-Augmented Kubernetes Operations" points to the work operators already do: gathering evidence, diagnosing incidents, reusing runbooks, coordinating across teams, and deciding whether any action is safe.

Validate The Topic With First-Party LearnKube Data

Public research provides a defensible campaign hypothesis, which we then validate against LearnKube's internal audience data.

LearnKube's operating model matters here.

LearnKube operates as a set of Kubernetes media and data loops that run continuously.

Each month, we search the internet for Kubernetes content.

On an average month, we review about 2,200 links, including articles, projects, tutorials, announcements, case studies, opinions, and technical releases.

Only a small percentage passes curation, and that process gives us clear editorial signals.

We see which areas of the Kubernetes ecosystem have broad coverage, repeat too often, emerge quickly, or have thin coverage.

The curation process continues after publication.

We tag content by category and subcategory, distribute it through LearnKube channels, and then track attention through impressions, clicks, and engagement.

We track ecosystem publishing trends, editorial picks, audience click-through rates, and category longevity.

Kube Careers further validates demand through Kubernetes job descriptions tagged by infrastructure theme, skill, tool, industry, and role.

Kube Events works differently: talks, webinars, meetups, and conference sessions show which ideas are becoming teachable.

We categorize titles and abstracts, then measure which event topics attract attention.

That helps us understand which ideas are becoming teachable, discussable, and event-worthy.

KubeFM adds narrative depth.

Interviews, product announcements, engineering stories, and podcast episodes reveal which topics can sustain expert conversation and where vendors, practitioners, and open-source maintainers are converging on the same issue.

Social and newsletter channels add another layer.

They show which phrasing earns attention, which questions generate comments, which links get clicked, and which technical promises feel specific enough for engineers to act on.

We balance research and engagement data to select topics that are relevant and high priority.

We use two internal systems for this step.

First, link-reviewer-v2 shows supply. It tells us which Kubernetes articles, announcements, tutorials, repos, and discussions entered the review pipeline. It also records finalized items, rejected items, and repeat authors or sources.

Then link-manager shows audience response. Every finalized link gets a short URL, and link-manager stores visits, click metrics, platform posts, impressions, and tags.

For a campaign topic, we can search those databases by keyword, source, URL, tag, or category. For AI Kubernetes operations, that means looking for terms such as AI, LLM, SRE, MCP, observability, runbook, remediation, kubectl, k8sgpt, HolmesGPT, and related tags.

Then we score the topic across three dimensions:

This combines public research with specific signals from our audience data.

Turn The Research Into A Campaign Theme

After the research, we should be able to answer five questions:

For the AI Kubernetes campaign, the research produced this positioning:

Kubernetes teams require practical support for the actual work of operations: correlating fragmented evidence, debugging under pressure, reusing diagnostic knowledge, coordinating across teams, and acting safely inside existing security boundaries.

That became:

AI-Augmented Kubernetes Operations: From Noisy Signals to Safe Action

The evidence frames a journey engineers already know too well: too many signals, too much missing context, too many repeated investigations, and too much risk around production action.

That gives the campaign a spine:

  1. Start with the ambiguous question: What does AI with Kubernetes mean?
  2. Separate the branches: AI workloads, YAML generation, troubleshooting copilot tools, AI SRE, MCP/tool access, agent runtime, and remediation.
  3. Show why the operations branch has the strongest evidence.
  4. Explain the core pain: operators manually join fragmented evidence.
  5. Show the practical need: AI helps only when the workflow retrieves, filters, scopes, and shapes the evidence.
  6. Add the trust boundary: read-only, suggest-only, approved command, PR, approved change, or direct mutation.
  7. End with the operational model: augment the operator, preserve control, and make diagnostics repeatable.

Turn The Theme Into A Campaign Journey

The next step is to turn the theme into a journey where the engineer starts with the broad question and progresses toward a practical model.

The media plan follows that journey.

Frame the category. Start with "What does AI with Kubernetes mean?" The hypothesis map showed multiple branches: AI workloads, YAML, troubleshooting, observability, agents, and remediation. A newsletter, webinar, or ungated article gets people oriented.

Pick the strongest branch. "Which branch has real operational pull?" Issues clustered around logs, metrics, traces, context windows, read-only modes, auth, and runbooks. That becomes an evidence-led blog post or report section.

Explain the pain. "Why do incidents still require so much human correlation?" k8sgpt#1367, kubectl-ai#266, and kubernetes-mcp-server#876 show that raw cluster state is not enough. An ebook chapter or technical webinar makes the case.

Teach useful context. "What evidence should AI see before it answers?" kubernetes-mcp-server#876 and HolmesGPT#1946 show why status-only views, server-side filtering, and visible truncation matter. A deep-dive article or demo post works here.

Preserve operational memory. "How can teams preserve diagnostic paths?" RunWhen, HolmesGPT, k8sgpt analyzers, and internal ops-log patterns point to reusable diagnostic workflows. A KubeFM interview or case study fits.

Define safe action. "What can AI change safely in production?" kubectl-ai#289, runwhen-local#702, Botkube RBAC patterns, and MCP resource controls show read-only and scoped access as prerequisites. A webinar, checklist, or buyer guide.

Connect to the sponsor. "Where does the sponsor fit?" The sponsor should own a specific part of the journey: evidence, workflow, safety, or remediation. A landing page, workshop, demo, or nurture sequence.

For this campaign, the asset choices follow the technical journey. A category-framing webinar explains the map. An evidence-led ebook chapter explains fragmented context. A KubeFM conversation covers MCP/tool access. A workshop or checklist covers read-only and approved-action workflows.

One Research Theme Can Produce Multiple Campaigns

Strong research can produce more than one campaign.

Research builds a map of credible campaign opportunities.

"AI + Kubernetes" can become many campaigns:

Each campaign would have a different audience slice, sponsor fit, asset mix, and proof strategy.

The Recipe: Validate A Technical Campaign Topic

Use this process before deciding on a campaign title, building a webinar, or writing a content brief.

Identify The Messy Question

Start with the question engineers are already asking.

Imprecise questions expose market ambiguity, making them useful starting points.

For example, "How do I use Kubernetes and AI?" can mean:

Avoid forcing the question into one meaning too early by listing the plausible interpretations first.

Keep The Audience As A Hypothesis

At this stage, do not lock the audience.

Use possible meanings to guide research instead of declaring answers prematurely.

Each branch can point to a different group of engineers, but that is still a hypothesis.

Replace "Which persona should we target?" with a research question:

Which branch has enough evidence to become a campaign?

Decode Source Intent

List the places where engineers leave evidence for each branch of the hypothesis, then decide what each source type tells you.

For Kubernetes topics, start with:

Treat them differently.

Classify GitHub issues by intent, project context, expected behavior, workaround, and repeated request.

Use community questions to understand pain before it becomes polished language.

Use conference talks to see what practitioners have already packaged into a teachable story.

Use vendor pages for category language and positioning, then pair them with practitioner evidence.

Extract Evidence In Engineer Language

Read the sources with four questions in mind:

For AI Kubernetes operations, the answers looked like this:

Problem:

Operational evidence spans too many systems.

Goal:

Engineers want faster triage, reusable diagnostics, and fewer escalations.

Constraint:

Production access must remain controlled, auditable, scoped, and human-approved.

Assumption:

Engineers do not trust AI advice without real context and safety rules.

That combination is much stronger than a generic topic like "AI for Kubernetes."

Check The Pattern Across Sources

Do not stop at one issue, one post, or one conversation.

Search for patterns across multiple independent places.

Ask:

Repeating patterns show a topic strong enough to support a campaign.

If the evidence is thin, keep researching or narrow the audience.

Infer The Audience From The Evidence

Only after the pattern repeats should you define the audience.

The audience should come from the work that keeps appearing in the evidence.

For AI Kubernetes operations, the repeated work was operational: gathering context, investigating incidents, connecting evidence, preserving diagnostic paths, and deciding which actions are safe.

That pulled the audience toward:

If the audience is not specific at this point, the campaign drifts into generic messaging.

Validate With Audience Data

Use first-party data wherever possible.

At LearnKube, this includes:

Write The Theme After The Evidence Is Clear

Once the evidence is clear, compress it into a theme that names:

For example:

AI-Augmented Kubernetes Operations: From Noisy Signals to Safe Action

That theme works because it is specific enough for engineers and broad enough to support multiple assets.

Turn The Theme Into A Learning Path

Once the theme is clear, break it into teachable parts by asking:

Then assign media to the path.

The asset mix can include:

Iterate The Process

Trace successful responses back to their source categories to refine the next brief.