Marketers grapple with finding topics for their thought leadership content, especially once they get the first couple (the easy ones such as Best Practices ) under their belts.
I thought I’d share my approach.
My clients come to me with a subject for thought leadership content: HTML5 security, big data search architecture, CRM, restaurant inventory management—or whatever it might be.
It’s my job to find the topic.
I have a guiding principle I follow.
The easiest way to lead someone’s thinking is to take it where it’s already going.
I group target audiences together in terms of roles and responsibilities. Different groups need different thought leadership messages. The CIOs and CFOs who own the green lights need some. The department mangers that make the choice need some. The people in the trenches that influence and obstruct need some. Each of those groups are thinking about very different things. The CIO is only peripherally concerned with the development environment. The network engineer isn’t any the more interested in corporate exit strategies.
So before I try to lead my target’s thinking, I want to find out what’s on their minds.
I look, of course, at the similar content my client’s competitors publish. It’s a kind of Pareto principle: 80% of what I see discusses 20% of the possible topics. Often, my clients have already published a couple of these basic pieces, and need something with more depth and focus.
My most treasured source of information (maybe it’s because it’s so rarely available) is the sales force. They talk to my targets. They answer their questions. They profile them internally and think about the best ways to argue the case.
They follow my principle all the time.
But as I say they’re not often available to me.
Each target group—developers, managers, executives—has its own community: populated with magazines and published experts and so on. That’s a real mine of information. Just to make the point, as I’m writing this, I picked the developer community, pulled up a list of online magazines targeted to it, opened good old Dr. Dobbs and this is the first headline I saw:
Engineering Managers Should Code 30% of Their Time
A skim of the article led me to a concept that was new to me: “technical debt.” I found a healthy discussion about it.
That one-minute excursion gave me insight into what the development community is thinking about.
It takes longer in real life. I’d read the articles and the blogs and so forth, and that insight would deepen. I’d look through the other magazines as well in the same way, trying to find concepts that many of them were discussing. But if that were the only data point, I could still refashion “Best Practices for Writing Great Code” into “Don’t Mortgage Your Software’s Future: Understand How to Eradicate Technical Debt.”
More and more, I join LinkedIn groups to learn what those communities are talking about—and the discussions point to a lot of information resources. (Full disclosure: LinkedIn is a client).
The overall research might take an hour or two before workable topics emerge–no need to dig deeper than success.
And in the end, it’s an easy, reliable methodology for finding relevant topics that touch the right buttons in the marketplace.