WordPress Product Demos

by 13 Comments

If you sell a WordPress product, then you’ve probably had a perspective customer ask if they could test it out first or if you have a demo available. Recently, we realized that our demo of Ninja Forms wasn’t working properly. Also, none of the plugins or extensions were up to date. We currently have 28 extensions plus Ninja Forms itself, so let’s just say keeping them all updated can be a difficult endeavour.

Challenges with demo sites

  • They have to be kept up to date just like any other site. Let’s tell the truth; although demo sites can be great marketing tools, they often get put at the bottom our priority list. We need something we can set and forget.
  • Users need to be able to make changes, and our demo needs to maintain consistent, testable data. We need a way to reset the database regularly to a pristine copy. This way, users can do all the testing that they want without any of their changes “sticking” to the database.
  • The demo should be running the latest stable versions of our products. We need a system that will auto update core or any plugins or themes. This can seem at odds with the teflon database, so this needs to be automatic and not a pain in the rear.
  • Sometimes the demo data has to be modified or added to. We need to be able to thaw the database, putting the site into an update mode. This way we can make content and setting changes, and then freeze the database in this new state as our new pristine copy. If this isn’t easy, it is likely to not get updated very often.
  • Users don’t need to have access to everything within the WordPress admin. To fully test our plugins, users should be able to login as both an admin and a subscriber. Of course, we don’t want these admins being able to access everything within the wp-admin. Something that we can use to limit what admins have access to is a must.

We are currently working on a plugin that will accomplish all of the above and be super easy to set-up. What are your thoughts? Anything we’re missing?

Set default layout for a Custom Post Type with Genesis

by 3 Comments

I have recently (yesterday) taken the plunge into building my websites with Genesis. I’m not exactly sure why I’ve been holding out. Most likely because I had built my own kind of framework and really like some specific things I had built into it. The problem is that I just don’t have time to work on all the other stuff that’s important for a good theme framework. So now I’m using Genesis and I couldn’t be happier. I still needed to solve a problem though so here it is.

I wanted my default layout to be CONTENT-SIDEBAR but I wanted a particular post types archives and single posts to be SIDEBAR-CONTENT. With the Genesis genesis-cpt-archives-settings custom post type support I can accomplish this for the archive pages but not for the single posts. This snippet solves that problem.

This code checks what custom post type you are viewing and applies this layout if it’s the one you’re looking for. Pretty simple.

The cost and challenges of selling WordPress products

by 26 Comments

Over the past couple years and even more recently we have seen many WordPress business re-evaluating their business models and making changes to the way they sell their products. This is inevitable as businesses grow because maintaining a growing customer base is expensive and time consuming.

We here at WP Ninjas have been thinking about this from day one and although we certainly can’t continue offering unlimited anything for the life of our business we have made it abundantly clear we don’t think the solution is a per product subscription. At least not for the products we offer currently. So in this article I would like to examine the costs of selling WordPress products and some models we’re kicking around to address them. We want to accomplish two things with whatever solution we come to.

  1. Secure a profitable and sustainable future for WP Ninjas
  2. Offer fair pricing that both values the products and services and is affordable for customers

Products not Services

WordPress plugins and themes in my opinion are products. The vast majority of customers buy them for what they do at the moment they purchase them not what they hope they might do in the future. For this reason I like the idea of selling them at a single rate based on how we evaluate their feature set. When you buy the product you’re paying for the work we’ve already invested into it and initial access to the code. That means that a product that sells for $39 is only $39. Nothing else. The product works, do what you want with it.

But what about further development and updates? Great question. Plugins and Themes need to be updated to be compatible with latest versions of WordPress and certainly some more than others.

Further Development and Updates are a Service

Every developer wants to make their products better but it takes an investment of time. And we all know the saying that time is money. Even though that’s the case I don’t know that I like the idea of charging an update fee, even at a small percentage, for every plugin we create. I’m not saying that it’s wrong to do so I just don’t want to put that kind of financial burden on our customers. For the hobbyist, the small business owner, or the developer. I want to help them keep their costs down while at the same time growing our own company as well.

Development takes time and updates take bandwidth, whether automatic or manual. So what if we had a subscription for those services? Better yet what if that subscription was based on the type of user you are and not on each and every product you use? A single site user isn’t getting as many updates as a developer might. Why not give them a break on that cost? So an annual subscription might look something like this…

  1. 1 Site = $25.00
  2. 2 – 5 Sites – $50.00
  3. Unlimited = $75.00

These subscriptions would give you updates of the current development on every product that you own. So you pay for your products individually but you pay for updates with a simple flat annual fee. And those using the most resources pay a little more to cover their higher usage.

I feel like this could be a win win for everyone. Customers keep their annual costs to minimum by not paying a per product renewal fee while at the same time investing in the future development of Ninja Forms and the extensions they use.

If you are with me so far you might be wondering about support. I like this one most of all.

Support should be for Everyone but not Necessarily Free

The thing that hurts WordPress business more than anything is the increasing support requests they get because of a growing user-base. It’s definitely a challenge but I don’t think it needs to be as daunting as we make it out to be.

This is absolutely one of those areas where I think people should pay for what they use. Not everyone needs a lot of support and some don’t need any at all. To factor that in across the board so some people are paying for something they never use while others are using way more than their fair share is another one of those things I just think we can do better. I want to do away with support subscriptions altogether.

The challenge here is that everyone needs a place to ask questions from time to time so you need to have a way that can happen in an orderly fashion. And they shouldn’t have to have a support subscription to do it. So we need a system where all questions and support requests can be submitted and filtered. I’m leaning towards a pay-per-ticket model. Thomas Griffin the developer of Soliloquy once used a model similar to this where you buy tokens for priority support. This got me thinking and I want to take it a little further.

The support process would work like this…

  1. User submits a ticket
  2. After Initial review we determine is this request…
    1. A bug – Then we support for free
    2. A chance to improve documentation – then we do and point them to it
    3. Custom help or completely unique case? If so we move on to step three
  3. We quote the support request within the support thread based on the estimated time to assist them
  4. If the user agrees they can pay within their next response seamlessly
  5. We resolve the request

I love this idea because it gives everyone the freedom to make any request they want while allowing us the flexibility to determine if it’s something we just need to fix or something that requires additional cost. Paying-per-ticket can expedite an issue or secure more custom assistance. My favorite part is that people who don’t need it aren’t footing the bill for the people that do.

This may not work for everyone

Not every company can do it this way. I’m not even convinced that it’s the right way for us but I definitely like the idea better than others I’ve seen thus far. Of course this isn’t something we’re implementing tomorrow. This is meant to be a public discussion of a possible option.

We’ve laid out our idea and now we have some questions for you.

  • Past & Potential Customers – What do you think of this model? Is it fair and/or affordable? Do you like it or hate it and why?
  • WordPress Businesses – Do you think this would be sustainable if WP Ninjas was your business? Do you see any pitfalls? Would you improve on this in any way? Do you like it or hate it and why?
  • Everyone – Any “gotchas” you think we’re missing or things that we haven’t properly addressed?

Please join the discussion. We would really like to know everyone’s opinion.

Why we all suck at pricing?

by 8 Comments

The current hot topics in the WordPress community are pricing models and sustainability. It seems like every site or blog related to WordPress, plugin and theme developers, and everyone in-between are discussing the feasibility of various pricing models. The general consensus seems to be that if support and updates aren’t paid for by subscription, it won’t be long before you can’t keep up and your business crumbles around you. The war cry appears to be something akin to, “offering unlimited anything isn’t sustainable.” If only it were that simple.

There are far too many factors to consider when pricing a product to assume that any model is absolutely right or wrong. Here are a number of things to consider:

  1. How much support will your product actually require?
  2. Are you relatively known or absolutely new to a market?
  3. How saturated is your market? How much competition is there?
  4. Are you the best, or at least could you be?
  5. How frequently will you be updating your product?
  6. What are the short term and long term goals for your business and/or product?

All of these are things that Kevin and I had to think through, and continue to wrestle with, as we manage Ninja Forms. Soon, we’ll be doing a series of videos where we talk through these issues.

Businesses require different things at different times

No business stays the same forever; just like any living creature, it must change and adapt as it grows. All of the preceding questions must be asked at each stage, and the answers, and strategies that go along with them, may change many times. The Ninja Forms of two years ago is dramatically different from the Ninja Forms of today. I’m not just talking about the plugin, although that is definitely true, but also about it’s methodology. If we hadn’t adapted our processes and model from two years ago, there is no way Ninja Forms would be what it is today. It probably wouldn’t exist at all. Heck, it’s still growing and changing. The things we did at the beginning allow us to be doing what we are now.

Yesterday we changed our pricing model slightly. It wasn’t a drastic change, but it was necessary to continue growing and adapting our business. I can promise you this, it is not the last time we will change. It would be naive of us to think that we won’t need to continue to adjust as we grow.

There is more than one way to price a product

You don’t have to be married to your pricing structure for the life of your product – it isn’t to death do you part, although many business have died because they refused to part with their pricing structure. Sometimes the best thing you can do is divorce your current pricing model and take up with a newer, sexier one.

At this point, I’m going to say something that’s probably not going to win me any points with other WordPress business: I hate the idea that charging for an annual or monthly update and support subscription is the best way to sell your product. There, I said it, and I feel better. Notice I said the best way; it is certainly one way, but I’m definitely not convinced it’s the best way.

Arguments for Subscriptions

There are plenty of reasons that a subscription model makes sense. In order to continue losing points with WordPress businesses, here are a few of these reasons along with some rebuttals:

I have to maintain the code and keep it up-to-date with API’s. etc.

Let’s be honest, this would have to be done anyway if you wanted to keep selling to new customers. If something changes that requires you to update the code, you either have to update it or stop selling altogether. I personally don’t want to charge customers for something  I would have to do regardless. I don’t have to update this plugin because the user has it; they haven’t caused me any more work. It’s not a new feature; it’s due diligence. If an API changes, or a new WordPress version is released, and it breaks my plugin, fixing it is not “working for free.” I’m working so that I can continue to sell it. The choice between customer and business isn’t binary – it has to be about the customer and the business, not one or the other. It’s about how to do do well for myself while also doing good for my customers.

I can’t justify continued development of a product I only get paid once for. 

If you aren’t attracting new buyers, then perhaps your product isn’t sustainable. I don’t want to develop a product that isn’t attracting new users, regardless of the model. If your sales volume is so low that you can’t afford to support what you’re selling based upon new sales, perhaps it’s a hobby and not a business. I don’t remember the latest numbers of new WordPress websites being created every day, but I do know that if you get a small fraction of them, you will have no problem making enough sales to justify further development.

It’s not sustainable to support a product unless you have an annual subscription.

Chris Lema made this point in his post about pricing by the same name. In it, he gives an example of raising a product’s price by $1…

Now, let’s change the price to $11. And sell only 9,000. Our total revenue is $99,000. For a second it looks like this is worse. But wait. Our cost to support it goes down, doesn’t it. Because we have had less customers.

I’m pretty sure this isn’t what he means, but it almost sounds like his answer to climbing support costs is to make more money from less customers. This feels wrong to me on so many levels. Increasing customers doesn’t have to mean overwhelming support requests. We don’t have all the answers, this is something that we’re working on right now, but my experience tells me that there are better ways of handling support.

Ultimately, I’m not interested in finding out how much my customers will pay for my products, but actually lowering expenses. Providing better documentation and developing better user interfaces and  more stable products can help dramatically lower support costs. I’m not saying supporting a product isn’t expensive and tricky; I’m just saying I’m not sure fewer customers is a great solution.

What are some other options

  • Create a system in which customers pay for what they use. Charge for support to cover your time. Charge for different volumes of automatic updates to cover bandwidth costs.
  • Release your plugins like Microsoft does their operating system: charge for the current version and support it with patches when needed. When you release a new version, charge a discounted upgrade. I know this sounds similar to a subscription, but it’s too much to unpack in this list. We’ll revisit this one in another post.
  • Don’t treat all products the same: some simply don’t get updated frequently. Charge accordingly.

I’m sure there are a lot more, but for me it’s about doing what’s best for me and all my customers. The problem is, I think, too many people are worried to make mistakes they don’t try anything new.

So why do we really suck at pricing?

Because we think of it as a fixed decision, without room for experimentation.

We’re so afraid that if we don’t get it right the first time, we’re just doomed to go out of business. After all, everyone is telling you it’s not sustainable. Why does it have to be sustainable in the beginning? There are phases in a business’ life where doing things that don’t scale and aren’t sustainable is not the only option, it’s the best option. You can change as your business grows; you can learn to adapt with the market.

Yesterday, WooThemes announced that they are changing their pricing structure. It’s caused a lot of conversations, both positive and negative. Is it the right model for them? I can’t answer that – I’m not in their shoes or facing their numbers. Do I agree with their choice not to honor previous unlimited licenses? Not especially, but again, it’s not my business. What I think I can safely say is that if they had started with this model, they would not be where they are today. If these were their prices when their products were fewer and less mature, I don’t think they would be nearly as big as they are now. I absolutely support them making the change. They work hard and create great products that are worth every penny. They didn’t start where they are now though; they grew and developed over time. They are adapting.

Do you want to have a sustainable business. Don’t worry about getting everything right. Just adapt.

Agree or disagree? I would love to hear your comments.

New Video Series: Meet the WP Ninjas!

by 3 Comments

Kevin and I have decided to start doing some video talks about various subjects like running a WordPress business, Ninja Forms, and WordPress in general. We hope to accomplish a few things with these videos.

Make our business more personal

It’s easy to use or buy a product and forget that there are real people behind it or submit a support ticket and not realize there is someone who really wants to help you but also has life events they deal with as well. The idea it to be real names and faces behind the name WP Ninjas and hopefully breakdown the barrier between business and customer.

Share our perspective

Of course that’s a part of being more personal but it’s also a way to connect our users, customers, and followers with the way we think about a topic. You may not agree with our opinions but at least you’ll know why we hold them.

Share our success and failures

We are young business and we are making many decisions and struggling with many challenges for the first time. Hashing these things out on video gives us a chance to share has and hasn’t worked for us and perhaps might give you some ideas on how to best launch and maintain your next project.

We’ve decided that our first series of videos would be on the topic of developing a growing product since that is our current challenge as we are building the Ninja Forms brand and community.

We had to start somewhere

Here is our first video simply introducing ourselves and little extra. It’s rough to say the least but I promise the quality will get better the more we make and the more comfortable we get. Enjoy and please leave some comments or feedback below.

Create your own conditional tag

by 1 Comment

Have you ever wanted to do something based on a specific set of conditions. Sure you have and you’ve probably used  the WordPress Conditional Tags at least once or twice. Conditional Tags are extremely useful functions that check a set of conditions for you.

They work like this…

The is_single function returns true if what you are interacting with is a single post. It reads nicely. If is single then so something. But is_single, while useful, isn’t always the thing you want to check. Sometimes what you are checking for is much more complicated.

Here is an example of something we use on this site. We use Easy Digital Downloads to sell our products. All of these products, at least at the moment, are extensions of Ninja Forms. I wanted a way to conditionally target all downloads that had the category of “extension”. This way I could include or exclude certain functionality from just these types of products. I can check this condition like this…

This first checks if what I an interacting with is a download and then loops through the terms to see if one of them is “extension”. If it is then it will run some code. If not it does nothing. Here’s the problem though, I have to run through this same bit of code every single time I want to check this condition. Worse yet, if I want to expand or change my condition I have to go back and edit every place I’ve used this code. What a pain in the neck.

This is where creating your own conditional tag comes in to save the day. All we really have to do is wrap the code above into a function and add a few lines of code.

See what we’ve added. A variable set to false at the beginning, change the variable to true if the condition is met, and return that variable at the end. Now we can use this function anytime we want to check this condition.

See how much simpler that is? The best part is if you want to tweak the condition at some point down the road you only have to change one function and not a dozen places where you’ve copied that same code.

Of course this is a very specific example that we are currently using but you can apply this to almost anything you might want to check regularly and save your project possible hundreds of lines of code.

What conditional tags do you find useful or wish were available?

Improving support with less not more

by Leave a Comment

Don’t be alarmed. I don’t mean less support.

I mean less support channels. I know this may seem counter intuitive, but having more ways for people to request support doesn’t mean better quality support. In fact, it means the opposite. It means less time helping users and more time tracking down and keeping up with all the places a request might have come from. It means more time scouring multiple forums and searching emails hoping we didn’t miss something. And here’s a hint, we always miss something.

I mean how couldn’t we with 7 WordPress support forums. Or the possible 12 on this site if you split up basic and priority forums. What about all the other products we plan to release? Inevitably there are those people who ignore our pleas to use our forums. All the possible places for people to seek assistance can at times render us completely inefficient at providing it.

That’s why we are saying goodbye to forums for the foreseeable future. Instead, we have built our own ticket-based system and have attached it to our Members Area. We will still continue to offer both Basic (FREE) and Priority (PAID) support through this system. The benefit is that, because we built it, we have the flexibility to enhance it in anyway that will help us help you better. This system will provide us with better notifications and give us the ability to get all the important info we need to provide the best support possible.

If you need support for any products that we’ve created head on over to our members support page and we’ll be looking for your next ticket.

Scheduled Slides for Soliloquy

by 1 Comment

It should be no secret that we love the Soliloquy WordPress Slider plugin and we think you should too.

Recently while working on a project we had a need to set Soliloquy slides to only appear during specific date ranges. The use case might be you have a special running on your site that starts on the coming Friday and expires on Monday and you want to post a banner for that. Sure you could just add it on Friday and remove it on Monday but our client is busy and just wanted to set it and forget it. So we extended Soliloquy to do just that.

I can see how this could be a common need so we decided to release for the benefit of everyone.

Introducing Scheduled Slides for Soliloquy!

We hope you enjoy it but be sure to get your copy of Soliloquy first. Otherwise you installed this plugin for nothing. :)