How Not To Market WordPress Products (or “Why Customers Don’t Care”)

If you’re any sort of a WordPress developer, then one of the things that you’ve no doubt noticed is how we market our work.

I’d say that it can be divided into two camps:

  1. You have the developers who promote the features, design, and options that the theme or plugin offers.
  2. You have the developers who promote all of the things that have gone into the theme as to what makes it significant.

When it comes to marketing WordPress themes or plugins (or any product, for that matter), then the first group has it absolutely correct.

The second group, on the other hand, can take a few cues from the first group – namely, stop trying to market your WordPress products based on the tools and technology that were used when working on the project.

Market WordPress Products (Not What You Used)

I know – it’s fun to talk about, but it’s only fun to talk about with those who get it, and customers care no more about what has gone into your product than what material has gone into your creating the post for your mailbox.

Morla Does Not Care

But I get this (seriously, I do) because  I used to be one of those developers who would want to talk about all of the neat things that were used to make a certain feature work, or I’d want to talk about some code refactoring that decreased the filesize of the overall project by X-number of kilobytes.

And I just about walked away from my own post writing that last paragraph because when it comes to marketing a WordPress product (or any software – or hardware – product) the thing is this:

People do not care what you used to make the product. People care if it solves their problem.

That should be the end of the discussion, and I think many of us know this – even those of us who like to share that we bundle, say, our CodeKit configuration or Gruntfile with our projects intrinsically know this, but our desire to share that the tools we use overrides the need to share how we’re solving a customer’s problem.

Customers do not care about:

  • What CSS preprocessor we used,
  • What front end framework we used to manage the responsive functionality in the theme,
  • How the code has been refactored to be X% smaller and Y% faster
  • …let alone know what any of the terms mean.

In fact, I’d argue that if we simply said any of the above terms whether or not they were true, a certain type of customer would trust that it were true, purchase the product, and then say they noticed a difference being non-the-wiser. But that isn’t how we should be marketing our work. Gross.

We’re better than that.

Anyway, the same is true for us for the products we buy offline, right? For the most part, I don’t care what kind of aluminum went into parts of my treadmill, nor do I care about the details of part of the plastic and the silicon that went into making my Blu-Ray player.

The truth is that if it looks good, works well, and solves my problem, then I’m generally happy.

And I think this is true for most of us. Granted, some of us are more curious than others about what goes into creating something, and that’s fine – I really do get that – but when it comes to having a particular need and/or problem, I want it solved, and I want it solved elegantly.

The same goes for the next version of our work, too.
The same goes for the next version of our work, too.

With that said, I’d love to see a shift in how some of us market our WordPress products. The only people who are generally going to care as to what’s under the hood are fellow designers, developers, and those who ask.

The rest of the people – that is, those who are looking to have a problem solved and are looking to pay money to do so – likely care more than it looks good, functions well, and meets a need.

So start promoting your work to customers with that.

14 Replies to “How Not To Market WordPress Products (or “Why Customers Don’t Care”)”

  1. Unless your customers are developers in which case they do care. In fact, I would say that with the reputation ThemeForest gained early on for being hit or miss with how themes were coded anyone who knows even a little bit about code will want the information available.

    For example, say I am very comfortable with Bootstrap and go looking for a theme. If I search for themes that are built with it I would miss Mayer (assuming it was available for purchase where I could modify or build off of it).

    I can use sass and want to keep using it so I’ll look for a theme which used it as well. Repeat the same pattern for any other tools/libraries.

    Marketing on WordPress.com I can understand it but almost anywhere I think you miss out on a sale if you don’t include more technical information.

    1. I think you actually bring up a good point — the only thing I’d change is that perhaps there should be a “technical information” page, sheet, or area lower down in the marketing material unless you’re specifically targeting developers.

  2. If you are selling a solution to developers then I think some technical information about the product is necessary but if your target market is the public at large then it makes sense to market the product from the angle of ‘solving the pain’ rather than emphasising the ‘bling’ of the product. This idea also works with non-web related applications e.g. desktop applications. Most of the time clients will not be as technically savvy as the developer and an IT related jargon will go over their head. They are more interested in the answer to the question of ‘what can your product do for me?’.

    1. I agree with your point on if you’re selling to developers. I mean, it’s certainly all about knowing your target market, for sure.

      I just think that developers, generally speaking, have a hard time not showing off whatever technologies they’ve used when it really makes no difference to those who don’t even know what they were to begin with :).

      They are more interested in the answer to the question of ‘what can your product do for me?’.

      Bingo.

  3. It’s always a good idea to market things using the same language your clients use.

    That being said, if your clients are developers looking to create complex custom fields and custom post types and custom taxonomies and custom queries using WP_Query in order to modify the query_vars so they could query multiple custom post types with different custom fields depending on what taxonomy they are in… you better start using that stuff in your marketing :))

  4. I agree with the points made here to a certain extent. I have found over time that most non-technical people don’t really care how something was done. They care more that it is done, looks the way they want it to look, or does what they want it to do. The details are mostly boring to them, and they could usually care less about them.
    On the other hand, I have also run into some people who are new to WordPress and just need some support from someone who knows what they are doing and can guide them in the right direction. Those people, while not “developers”, want to learn how their site works and are very much interested in the technical details.
    With that said, I think the article is spot on for the majority of people who are willing to pay for their problems to be solved.

    1. They care more that it is done, looks the way they want it to look, or does what they want it to do. The details are mostly boring to them, and they could usually care less about them.

      This can also breed poor development practices, at least in my experience, because programmers can (and will) take advantage of this and ship poor quality code with the customer being nonethewiser.

      Human nature, I guess, but it’s lame that it happens, nonetheless.

      Those people, while not “developers”, want to learn how their site works and are very much interested in the technical details.

      Exactly! There are people who can grok many of the ideas and it’s great to be able to guide them in the proper direction.

      1. This can also breed poor development practices, at least in my experience, because programmers can (and will) take advantage of this and ship poor quality code with the customer being nonethewiser.

        I think any developer who does this is not only doing their clients a disservice, but they also are shooting themselves in the foot. Eventually the issue that they worked on, or “fixed” will pop up again due to their poor quality code, and the client will grow upset that it wasn’t handled correctly in the first place. Again, their client being the person that only cares that it works (as opposed to how it works).
        For example. I’m no mechanic, and I have no desire to learn anything more about taking care of my car than how to put gas in it. If I take my car in to a mechanic so they can fix a “thunk thunk” sound, and a week later it starts up again because of their poor quality work, I’ll probably never go to that mechanic again.
        Developers may cut corners thinking that their clients will have no idea, but I’d guess that in the long run this only serves the interest of ethical developers who will ultimately scoop up those clients.
        Now, if you’re talking about poor quality code as in it isn’t commented well, or something like that, then I would also argue that this is a disservice to the developer who may need to revisit their work down the road. They would arguably waste more time trying to figure out what the heck they had done than if they had done a good job commenting their code in the first place.

        1. I agree with everything you’ve said. The only thing I’d add to is this:

          and the client will grow upset that it wasn’t handled correctly in the first place

          There are times in which clients expect one thing to happen, but developers deliver something different, but this is more of a lack of communication, understanding, and proper testing, so I digress for now :).

  5. So true, Tom. This is true of a lot of tech businesses. They’re too caught up in the PROCESS and don’t focus on the RESULT that their customers are looking for. They expect the customer to bridge the gap and just see it, when in actual fact the customer has a million competing thoughts and desires, so we need to make it instantly clear what our products actually PROVIDE.

    1. The easiest way I’ve found to handle this is to try to get in the mindset of the customer if they are looking at what I (or someone else) is working on.

      We’re all customers to someone else, you know? So it’s not that hard to do. I think we just have an innate difficulty in remembering to do so when we’re on the other side of the provider/customer relationship.

  6. This is an interesting point not least because I see this happening from both ends in that I have developers and occasionally other colleagues who claim wordpress is not technically capable enough (hah, I laugh at their outdated views) and we have clients who most certainly for the most part don’t give a stuff how it was written provided it is achieves their needs in a robust and secure manner. Overall it is benefits that sell not features and for the most part developers would be a lot better off if they realised this….

    1. (hah, I laugh at their outdated views)

      #LOL

      Overall it is benefits that sell not features and for the most part developers would be a lot better off if they realised this….

      Well put. I like that.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.