Adventures in Content Marketing

Series: product dev September 26, 2016

I came across the Priceonomics Content Marketing Handbook – a jumbo-sized blog post (that could easily be a book) that outlined a strategy for creating interesting content. The key idea is to tell a story using data that only you have (or are willing to research). By using your proprietary data, you can write posts that no one else can, which is critical in standing out in the crowded internet.

I did a brainstorming session to try out this method for generating content ideas. In this case, I wanted to think about blog topics for SEP’s company blog. SEP is similar to other software development firms but there are some unique aspects that could turn into potentially great content:

  • We gave people unlimited PTO at our service company and we didn’t go out of business
  • How much does it actually cost to build a software project?
  • How many lines of code does a software company write in a year?
  • How and why of becoming an employee-owned software company (ESOP)
  • I started a consulting company, how do I “exit”?
  • Success of projects with and without discovery
  • What kind of insurance does a software consultancy need?
  • How do enterprise companies hire a software company?
  • What does a software company need to do to get ISO certified? Why should they?
  • How do you lay out an office for a software company?
  • Investing in professional development / how to run a professional development program
  • Running technical book clubs at work
  • The first five decisions your dev team needs to answer before starting a project
  • So you want to hire some interns, how exactly does that work? Career fairs, legal stuff, prep, on-boarding
  • How to reject a candidate when hiring / how to stop an interview
  • Basic financial literacy for everyone at a consulting company (capacity, effective rate, opportunities, bank account)
  • How much reserve cash should you have for a software consulting company?
  • I’m sponsoring a conference and have a booth, what am I supposed to do now?
  • Sharing weekly staffing meeting notes with the whole company
  • Tracking company project experience: why, how, and the troubles

And I thought of a few ideas that were heavier on the story and research aspects:

  • The history of sticky notes and why software companies use so many
  • The same principles that Chipotle uses to make a burrito is used to deliver software
  • Why government software is so expensive (example: TSA screening app)

Are all of these ideas winners? No. But I think there are some ideas that are more interesting and would attract more readers than yet-another article on the benefits of TDD or how to get started with NodeJS. My biggest take-away was that we don’t recognize the value of the specific, “insider” knowledge that every business has.

What proprietary information do I have?

Armed with this new approach, I turned my attention toward the product I am running: MoraleApp. In the past, our blog has featured analysis and commentary about office happiness studies, articles on conflict in the workplace, and so on. It was fine, but it was something that anyone else interested in employee engagement could do.

We were not making use of our treasure-trove of data.

We had daily mood data for hundreds of teams, some of which had been tracking for years. This is our unique advantage that we could use to tell a compelling story. People have strong opinions about the impact of certain practices on team morale, but often have no data to support their claims. But we have this data!

Here are a few of the ideas I came up with:

  • The impact of crunch time on team morale
  • Do retrospectives make the team feel better or worse?
  • Do teams hate scrum planning meetings?
  • How does the size of a team effect morale? Adding/removing people?
  • What if we applied lean process techniques to managing team happiness?
  • Is there a measurable improvement in morale following a team celebration?

Doing the work

Another crucial point from the Priceonomics playbook was that quality content takes time and effort. Researching, outlining, writing, editing, and producing charts and graphics can easily take 40 hours of work when you first start. Churning out a post in an hour seems good, but if the quality isn’t up to par, it is unlikely that your content will be spread.

The act of writing is important, but it’s not the end of the work. In some ways, it is just the beginning. Until you build up a large readership, you have to be more intentional about promoting and sharing your content.

The playbook is emphatic that you need to come up with a list of 50 people to personally contat about your post if you want it to get traction. This part was particularly scary to me – cold-emailing people about something I wrote made me feel a bit uncomfortable.

But because I had put in the time, I felt better about sharing my work with others; I wasn’t just blasting them a link to some garbage. It was a struggle to identify the right people and it took the better part of a day to email, ping, and submit the article to my list of 50 contacts.

I was pleasantly surprised to get replies from some of the “big names” that I reached out to. It was reassuring that no one seemed annoyed that I had shared my post with them.

Results

So after all the hemming and hawing, I published my first post following these guidelines: How much does ‘crunch time’ hurt team morale?

It received 1,013 views in the first week it was live and referred two people to sign up for paid plans. Not a great success in terms of views, but we converted two customers (a win) and we have a piece of content that is evergreen and uses proprietary data that only we have access to.

One thing I’d like to improve is telling a better story around the data. I think my first attempt was a bit too dry and leaned heavily on the data and analysis, instead of trying to create a more compelling narrative.

Like every marketing channel, there is no silver bullet. But so far, this has been the most successful mechanism for my product. It was hard work – I always find writing prose to be more draining than writing code – but I was happy with the result.


built with , Jekyll, and GitHub Pages — read the fine print