WordPress plugin documentation as a way of getting new customers [Episode 6]

Recap of Episode 6 of WordPress Plugin Startup Show: 21 July 2020

* SpeedGuard is a WordPress plugin to keep an eye on your site speed, in background.

* AB Split Test is a WordPress plugin to improve your website conversions automatically.

In this episode, we continue talking about WordPress plugin documentation, (the beginning is in episodes #4 and #5).

Ideally documentation should serve all steps of the marketing funnel and be a part of a bigger content plan.

How plugin documentation can help you to get NEW customers:

Firstly, it can be a point of getting to know about your plugin

By using your product people hope to resolve some problem they have.

That’s obvious and we all know that.

But somehow we tend to forget about this when pitching our product. We talk too much about what it does and talk too little about the actual problem it solves. I believe we should talk more about the problem!

If you haven’t yet, take 13 minutes to watch this video where Chris Lema.

But be cautious! After you watch it you might want to change your landing pages, ads and all other marketing messages you currently have.

Examples how companies address the problem their customers have:

• Screaming Frog answers the question: If it’s duplicated content on my website that keeps it from getting more traffic from Google? It’s one of their posts

• Yoast answers the question: What do I do if my site has wrong meta-desction displayed in Google? It’s one of their docs

• Ahrefs answers the question: How do I drive more leads to my website through content? It’s one of their courses

They are not talking about their product. Instead they talk a lot about the problem the person have and how to resolve it, possibly with their software.

How to find the problem:

1. Define the point in the customer journey where your plugin solves a problem
2. Look for the previous step — the problem itself
3. What kind of information they need on this step? What questions they might have?

* If you already have use scenarios for different customer segments — do it for each.

Toolset has built their entire documentation answering this previous-step-question.

The step where plugin solves the problem – how to create custom post types, taxonomies etc

The previous step question is: How to build a membership site?

Also, good documentation lets people spend time with you and your product!

If we already are using a plugin (especially premium one, especially if it cost a lot, especially if out site’s functionality heavily depends on it) we are very likely to use plugins documentation and try to find answers there if it’s not particularly good. Just because we are forced to.

But imagine someone who is not your customer yet spends time on your website reading about your product and the ways of using it, just because the information is useful, interesting, and highly appealing to them. Isn’t that what we all are aiming for?

I can hardly imagine myself re-reading someone’s landing page, but I found myself quite a few times browsing through documentation of some plugin that I don’t use because it was exciting reading!

But of course, you can’t make this exciting if your documentation is just about “click button x, click button y”.

Good documentation is a compelling reason to buy your plugin

5 compelling reasons actually:

1. It shows how much you care (good vs poor documentation vs none)
2. It shows about whom you care.
   You know that feeling when you read or watch and it’s immediately “Oh yeah! That’s me!”
   Design with your target audience in mind: API/hooks/filters developers vs numbers/results etc vs layouts/beautiful pictures
3. It shows someone already trusted you their money — especially for NEW plugins (and money means not only payment for license!)
4. It decreases worries about: what I would be doing in case something goes wrong with this complicated product (all new stuff seems complicated at first, think about your feelings when Facebook or Twitter change interface!)
   *Troubleshooting section makes perfect sense for the plugins like WP Rocket — complicated systems, that need to be compatible with many others!
5. Good documentation looks like a promise of good support (“Looks like these guys know their stuff!”, “Looks like they have everything in order/under the control here”

Random tips on writing documentation:

What distinguishes good documentation from bad?

When you use some software for a long time, at some point you stop noticing how inconvenient docs are. Even if they are really tricky to go through, you just get used to it.

While working on these episodes I went through so many documentation websites recently. Most of them are plugins/software I never used myself.

Good documentation is one that you want to keep reading even though you’re not using a product, because it answers a bigger question.

Should documentation look or read like marketing copy?

Definitely not. But also it shouldn’t be code-only.

Often tech documentation is written in a super-minimalistic way like a set of commands or a list of actions etc. It’s a very usual thing I see in chats: “I gave up on plugin x, it’s too complicated”. Which means it just does a poor work of explaining things in human language.

About updating documentation:

LearnDash updates their documentation before releasing the new version — I think that’s coo!

Another good practice: Yith displays the version + last updated date for each plugin and theme they have (and they have lots of them!).

About contributing to documentation:

For some plugins, it makes a lot of sense to make a support forum a part of their documentation like ACF does.

Who should write it?

Should be prepared by a tech team, perhaps. And then repurposed-rewritten by a marketing team. Cheers me an Nathan as we are all-in-one! 🙂

Haven’t heard success stories of entirely outsourcing this process.

SEO through documentation

Should be planned and written with SEO in mind.

If you already have some number of docs — why not updating it for SEO also?

Design and tools

I like this layouts: GeneratePress, EDD, Timber, Gravity Forms, and ACF, of course 🙂

There is in-depth research by a friend of mine, Vova Feldman from Freemius, about plugins and SaaS options to consider for your knowledge base.

Turn compatibility/partnership use cases into docs

Branch has a guide for quite a few hosting companies they are compatible with about how to use Branch for automatic deployments on that specific hosting.

Michael Killen teaches how to build marketing funnels. Here is his course landing page on how to do this specifically with tools that you already use: “How to build a marketing automation funnel with Beaver Builder and ActiveCampaign“.

Doing the work once — and get paid for it multiple times

This is my favorite way of doing things 🙂 So I asked myself:

What kind of content for my plugin, SpeedGuard, can serve as:

1. Pillar content
2. Onboarding
3. SEO
4. Might be applied to PRO version as well
5. And as documentation too!
6. Free course also 

I’m gonna make documentation like that. And Nathan is going to do the same for AB Split Test.

* SpeedGuard is a WordPress plugin to keep an eye on your site speed, in background.

* AB Split Test is a WordPress plugin to improve your website conversions automatically.

Our homework this time is to write at least 3 pieces of documentation that could be multipurposed like that.

Next week we’ll be talking about … We haven’t decided yet! Next episode is on 4th of August!