INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.

BRAD: Welcome to Episode 70. This time Pippin and I will be answering listener questions. But first–

PIPPIN: This episode is sponsored by SearchWP, a plugin for WordPress that dramatically improves search functionality within WordPress. It allows you to create custom search forms to search within files such as PDF files or text documents. It allows you to create distinct search engines, so you could have, say, one search form that searches your products and then another search form that searches your blog posts or the other pages on your site. You can weight searches so that you can say that, like, taxonomy terms are more important than meta values or post content. It’s a really powerful search plugin from Jonathan Christopher, and it is available at SearchWP.com. If you haven’t checked it out yet, definitely go take a look.

BRAD: Awesome. Let’s get right into it. I’ll read the first question here. “How do you deal with plugin pirating? Any thoughts to share?”

PIPPIN: Well–

BRAD: Oh, boy.

PIPPIN: I think anybody who has built a commercial plugin that has received any more than maybe five customers has probably dealt or seen pirating to some degree. Now we should probably be careful on using the word “pirating” because technically sharing GPL code is not really pirating. But, overall, the general idea is you have a commercial plugin that you sell, whether it’s through your own site or CodeCanyon or any other website, and somebody either buys it or obtains a copy somehow and then resells it or redistributes it through another source without giving you compensation for it is what I think people are typically referring to when they say plugin pirating. What’s your experience been?

BRAD: We’ve only had one that I’m aware of, one instance of this. And what the person did is they took WP Migrate DB Pro.

PIPPIN: Hold on. Do you mean only one instance that you know of where your plugins where ever redistributed or only one that was problematic?

BRAD: Yeah, that’s — I don’t know of anyone else sharing our plugin. I’m sure it’s happening. I just don’t think it’s gotten enough attention that I’ve become aware of it because–I don’t know–I don’t go out there hunting for these folks, right? I don’t make it kind of my philosophy. It’s just to just kind of accept that a little bit of that is going to happen, right? It’s always happened with software, right? Anything digital is going to get passed around. So, okay, fine.

When it becomes a problem for us is when someone would take it and then they pass it off as their own work and don’t change our name, don’t change the name of the product. And so they’re essentially infringing on our trademark, and so that’s where it’s kind of a legal problem, really. But it’s still really hard to enforce, I’ve found.

And I don’t want to even say the name of this person that’s doing it or even say the name of the project that they’ve renamed it to, and the reason I don’t want to do that is because what I’ve found is that it makes it worse. It makes it worse when you bring more attention to this person because most of the time these people, that’s what they’re looking for, right? They’re looking for attention.

What I’ve learned is that every time that I try to fight it, it gets worse instead of better. So I just try to leave it alone and just hope that it kind of just dies out because the other thing is — so this person is distributing our paid product for free, so they’re not getting anything from it. So they have very little incentive to keep doing it. And it seems like the only incentive they have is to be anarchistic or contrarian. Right? That’s their motivation for doing it. Because we’re offering it as a paid subscription, they see that as wrong and so they’re doing it kind of to fly in our face, I guess.

By giving them more attention, that’s exactly what they want, right? You’re playing into their hands. So I’ve tried to just ignore it. That’s been my kind of strategy lately.

PIPPIN: I think that’s my strategy as well. I’m not convinced that actively trying to fight it, trying to get people’s hosting accounts discontinued or trying to get them to take plugins down or however they’re doing it, I’m not convinced that it’s worth it in any way. I think we have to realize that piracy or, in this case, like we said earlier, it’s not exactly piracy, but we’ll use that term for now, it happens in every industry, and it has an impact on business owners, but I think that impact is largely proportional to how you choose to fight it.

If you decide that you’re going to actively fight piracy, and you’re going to try to take down every offender, and you’re going to try to strictly protect all of your code to make sure that nobody can do it, I think you’re just wasting time. I think it is a — in my opinion it’s kind of a disservice to the people that are actually paying for your products because you’re putting time and effort into the wrong place.

Personally, my answer is I do nothing with a couple of exceptions. Every now and then if we see somebody redistributing one of our plugins while also trying to do it underneath our brand or, like, using our brand or our trademarks, then we will go after them for that. But that is only in protection of our branding, not for the actual code itself. We don’t care about the code. We care about the branding and the reputation that goes with it.

BRAD: Right. It might be interesting for people to hear, like, what we have actually tried in the past. I’m willing to share that.

PIPPIN: I’m willing to share.

BRAD: Yeah, so I’ve contacted GitHub in the past and this was before I actually had any trademarks, any registered trademarks. Technically, if you’re selling something with a name, technically you already have a trademark. It’s just not registered yet. You have to register it with the USPTO to make it more official, and I guess it’s easier to start legal action if you actually have a registered trademark.

We have those now, but at the time I didn’t have anything. But the person who was copying our software, they were also copying all of our marketing materials off our website, and that’s copyright infringement. So I submitted a copyright infringement claim to GitHub, and they took the repository down for a short time. Then they let the guy put the stuff back up with tweaks to the marketing copy.

I still find that’s a little soft of GitHub to just give them a slap on the wrist for copyright infringement. It seems like it should be a bit more severe of a punishment than that. When the repo came back online, all of the traffic to that repo was still flowing, right? So they didn’t have to start over, right? So I feel like they could have been more harsh than they were.

Then I realized that the owner of this repo was also pushing people to a copy of our software that had our trademark in it, and so he was still using — technically distributing our software with our trademark name in it. I submitted that to GitHub, but they passed it through their legal department, and they didn’t see it as a trademark violation, which–

PIPPIN: Interesting.

BRAD: Yeah. I don’t agree, obviously, but it is what it is. And so that’s been my experience with this.

PIPPIN: We’ve done kind of in the same way you submitted to GitHub, we’ve submitted to hosting accounts, hosting companies before, so if we find a website that has taken our branding. And again we don’t care about the plugins themselves. We just care about the branding and any trademarks. Then we’ve gone to the hosting companies before and said, “Hey, this account, this URL that’s hosted on your systems are violating our trademarks and our copyrights. Please take them down. We have had some success with getting those discontinued sometimes.

The bigger one where we get really adamant about it, though, is if we discover that somebody is doing that and they’re also committing fraud at the same time. So like we have found — we’ve had customers that have come to our sites, bought all of our plugins using a stolen credit card, and then redistributed through their own site. Obviously we block that customer. But then you can report those to the hosting account. And if you have proof that it’s fraud, then that’s a lot easier to take down because it’s not just somebody trying to fork. It’s legitimate theft at that point. That will act very harshly against, so we’re pretty quick to block those. But beyond that, I’m not very interested in spending time fighting plugin redistribution.

BRAD: Yeah. We’ve got other things. I feel like–

PIPPIN: Yeah.

BRAD: –the energy you put into that kind of stuff is much better spent. If you spent the same amount of energy, like, moving your products and your company forward.

PIPPIN: Absolutely.

BRAD: Yeah.

PIPPIN: I would much rather spend one hour and earn two new customers than spend one hour and maybe take down a bad apple.

BRAD: Yeah, exactly.

PIPPIN: So, all right. We probably better move one before we go on too much of a tangent and use our whole episode.

BRAD: Yeah.

PIPPIN: Okay. Our next question is, “I’d love to hear you guys talk about marketing and sales flows. How do you promote your plugins? Where do you advertise, if you do, and what tools do you use to manage your marketing sales funnels?”

I think we’ve talked — we answered this question in some form or other on some previous episodes, so maybe we’ll keep it a little bit brief, but what do you do for your, Brad? Do you have any advertising tools that you use or specific marketing flows that you use?

BRAD: Yeah, we primarily do what you would call content marketing. So we post on our blog every week, and we try to do really high quality content for our blog, so not just fluffy articles that have very little substance, which I feel like there’s a lot of that out there these days. That’s how we try to–

PIPPIN: The ten best plugins to run your business.

BRAD: Yeah, that’s the one. We try to differentiate from that by doing, like, in-depth tutorials and, like, really substantive articles.

PIPPIN: I think that’s easily the best return we’ve ever found on any “advertising” investment.

BRAD: Right. Then, of course, we also publish this on Facebook and Twitter and Google+ just because I don’t know what Google+ does, but it’s Google, so you’ve got to play their game, man. They want you to use Google+, then we’re going to use Google+.

Then we also boost the Facebook article using Facebook’s ad platform, and we spend $35 to run it for a week, and that’s just to get new eyeballs on our site and stuff. Then we also have remarking running. So if you come to our site, and then you end up anywhere else on the Web, you’re going to see our banner.

PIPPIN: Every now and then I see your ad pop up. I’m always like, dang it, he’s following me!

BRAD: Yeah. Yeah, it’s kind of annoying and kind of creepy, remarketing, but it works pretty well.

PIPPIN: I believe it.

BRAD: Yeah.

PIPPIN: All right. Okay, this one is for you, Brad. “Hi. I was thinking if you guys can talk about what Redis Cache is, how to use it for WordPress, and what kind of performance improvement we can get out of it.”

BRAD: Oh, I don’t know about performance improvement.

PIPPIN: I think you’re a little bit more familiar with this than I am, so what can you tell us?

BRAD: Well, yeah. I wouldn’t say I know Redis very well because I don’t. I know of object caching, which is what we use Redis for in WordPress. I mean maybe you want to explain what — you know what object caching is, right?

PIPPIN: I do. I will say that any time I get into a caching discussion is that I typically put my foot in my mouth because I get something wrong.

BRAD: That’s okay. We’re winging it here. Yeah, so object caching is essentially let’s say you’re querying. You load a page and it’s querying for a post in the database. Well, with object caching, a persistent object cache, the next time a visitor comes to that same page and instead of querying the database, it’s going to pull that data right out of memory, which is where Redis keeps it. That was kind of a weird explanation, but hopefully that made sense. Then Redis is just a key value store, essentially, and it runs on the server, and WordPress essentially connects to the Redis server, and it can pull stuff out of it.

Prior to using Redis, I think we used something called APC, which was an extension for PHP, so you would build PHP 5.6, let’s say, with APC, and then you would use that system to manage your object cache, your persistent object cache. But with PHP 5.7, it got rid of — did I say 5.7? I meant PHP 7, it got rid of APC, and so we didn’t have an object cache any more, so now we use Redis to do our object caching. That’s why you’ve heard of Redis more recently. I think people were experimenting with Redis, like, prior to PHP 7 being released, but I think PHP 7 really pushed Redis as the persistent object cache for WordPress kind of forward. Does any of that make sense, Pippin?

PIPPIN: Yeah, I think that was nice and clear.

BRAD: Okay. Do you have any questions about it, or is it good enough?

PIPPIN: I’d be curious to know what your own performance improvement measurement was, if you were able to do it, like, with it on versus off because I think it’s important to note that any time you’re talking about caching of any kind or any kind of system that is designed to improve performance is that it can vary dramatically from system-to-system, from hosting account to hosting account, from site to site based on what else is running on the site, how you’re configured, the hardware that you’re running on, the software that you’re running on, the versions that you’re running on. Just because one person sees great results does not mean that you will as well. It’s something you have to take with a grain of salt. It’s just like why some of the caching plugins–W3 Total Cache, SuperCache, et cetera, Rocket Cache or WP Rocket–why some of those will give people awesome results and sometimes they’re horrible. Sometimes they can actually cause significant problems. Just because Brad has great results does not mean that you will.

BRAD: Yeah.

PIPPIN: Is, I think, important to realize.

BRAD: I will say, like, you should definitely have an object cache if you’re at all concerned about performance with WordPress because WordPress does do a lot of querying the database, and those are slow operations no matter what your setup is. Having object cache sitting kind of in front of that will give you a better performance. That’s it – period. Right? There is no maybe with object cache versus no object cache.

If you’re talking about cache, there’s also page cache, which is kind of like the next level where you cache the entire page request. That may or may not, depending on your application, help. Let’s say you’re running something like BuddyPress. Well, BuddyPress is a very dynamic system, right? Most of the pages you want the latest data to show up, like the new feed or whatever. Right? You don’t want to cache the whole page where the news feed is because you won’t get the latest stuff that shows up in the news feed. For that, a page cache is probably not going to help you that much, but an object cache will help you a ton in that situation.

There’s also–

PIPPIN: E-commerce is another great example where page caching can be problematic.

BRAD: Oh, yeah. Yeah. On our site for e-commerce, we don’t have a shopping cart icon or anything in the top part because we page cache everything.

PIPPIN: Right.

BRAD: But we could get around that by doing ajax, by doing an ajax call to show the cart count. But we just haven’t bothered because we have one. We have two products, so how big is your cart going to be?

PIPPIN: Right. You don’t really need a shopping cart. You need a checkout page that happens to allow people to complete the payment, but you’re not adding and removing items from your shopping cart.

BRAD: Exactly. I will refer our listeners to an article on our blog that will give them a really good overview of where you’re going to be able to get lots of performance. Ashley wrote a great article titled A CDN Isn’t a Silver Bullet for Performance because we get a lot of people coming to us to buy WP Offload S3 thinking that it’s going to just magically make their site faster. But if you’re on, like, you know, cheap Web hosting that’s shared with way too many people, you know, if your server is slow, that’s not — you know, that’s where you need to focus your energy on first before you start looking at a CDN.

Anyway, Ashley really lays out where you should start before you get to a CDN for your optimization. And so he goes through all the different levels of caching and all that stuff. We’ll link that up.

PIPPIN: We’ll get that linked up in the show notes.

BRAD: Yeah, for sure.

PIPPIN: All right. What’s next, Brad?

BRAD: Ah, yes. What do we have here? “What would be the recommended roadmap for a PHP developer to become a WordPress plugin developer? What are the steps?” This is a good one.

PIPPIN: This is actually, I think, a fantastic question, and I don’t know if I’m going to have a decent answer for it, for one because my experience is going to vary wildly from the person asking this question, and that’s because I learned PHP through WordPress, which means that I knew WordPress before I learned PHP.

BRAD: [Gasp!]

PIPPIN: For better or for worse. There’s going to be a lot of people that will — well, okay. We’ll leave that for another discussion.

I think there’s a couple of things that you do need to look at first. I mean the very first step is you need to look at a plugin API, the plugin API being the action and filter hook system that WordPress has because that’s how everything is going to run, how every plugin is — every plugin is going to use that plugin’s API to function. There are some things you can do without using the plugin’s API, but it’s almost zero, so that’s the first thing.

If you’re listening and this is for you, Google search “WordPress plugins API,” and that’ll get you started. You have to know how to hook in. You need to know how to add in filters. And you need to know how to add in actions during the WordPress load process. I think the step that comes second is to learn the load process, to learn when certain actions happen, where certain filters fire, et cetera, so that you can tie in at the proper place.

BRAD: How would you suggest people do that exactly?

PIPPIN: To learn the load process?

BRAD: Yeah.

PIPPIN: There is a wonderful diagram. I want to say that Rarst put it together – goes by Rarst online. It’s basically a tree diagram or a flow diagram that shows here’s where it starts, and then here’s each of the actions that happen. Here’s the file it comes from. Here’s basically the step, and let’s you get a pretty good view of when things happen. It also has notes in there of, like, okay, at this point is when it’s safe to run plugin. At this point is when the theme is loaded. Here’s where you can interact with the request from the browser. Here’s where you can do this and do that, et cetera. I’ll try and link it up in the show notes. I’ll find a link to it after this and put it in there.

BRAD: Cool.

PIPPIN: It’s very valuable.

BRAD: Yeah. I don’t think I’ve seen that. I don’t think I’ve seen that.

PIPPIN: Oh, it’s excellent. I still reference it pretty frequently.

BRAD: Nice. I think what I would do — I think what I have done is I’ve gone — I started at index.php, and then I go from there. I just follow the code until, you know, until I’m satisfied, I guess, to see where I am.

PIPPIN: Yeah, I think that’s a great way to do it. I wrote a tutorial series for plugin development 101, and I think one of the ones, one of the parts to that series was about looking into the code of core. There is a lot of code in core. There’s a lot of different files. There’s a lot of different logic that happens, and it’s–I don’t know–10, it’s now, what, 12, 14 years old, something like that. You can see every quality of code there. There’s bad code. There’s good code. There’s spaghetti code. There’s pretty code. There’s a mix of everything. By digging into it and reading through it, like you said, starting at index.php, you can get a better understanding of what’s happening, when things are happening, and that should give you a good start.

BRAD: Right. On that note about the differing code quality, one thing that I found helpful when I’m going through the code is if you look at, like, the headers, the header comments of certain methods and functions, there’ll be an @since version number, which I believe that means when that function or method was added to core. So that gives you kind of a better idea of, like, what does modern code look like versus, like, something that’s more kind of older.

PIPPIN: Yeah. Core has also been getting really good about putting in in-line documentation to say when something changed as well. So there might be a since tag in there to say, like, since 3.0 this now behaves this way.

BRAD: Oh, okay. Does since always mean when it was first introduced, or is it–?

PIPPIN: I always thought it did, but it turns out it doesn’t.

BRAD: Uh-oh.

PIPPIN: In terms of–I don’t know what you call it–the PHP documentation syntax, you can use multiple since tags. So you can have your since and say this was introduced in version 1.0, and then since 3.0 this now behaves this way. You can have as many as you want, and you can also use them in line. It doesn’t have to just be in a function definition. You can use them inside of functions as well, and it’s still considered proper syntax.

BRAD: Huh. Interesting.

PIPPIN: Yeah, I did not know that until like, I think–I don’t know–two weeks ago when I asked Drew Jaynes about it.

BRAD: The oracle.

PIPPIN: He’s the code documentation guru. Yeah.

BRAD: Yeah. Is he the one that added all the doc blocks for the filters? Is that him?

PIPPIN: He’s done a huge number of them. It wasn’t just him. It was a coordinated effort with a team, but I believe he led that project.

BRAD: Yeah, yeah. I remember that he was just killing it for that project.

PIPPIN: Our in line code documentation at Affiliate WP has quadrupled since he started working on it.

BRAD: I bet. Nice.

PIPPIN: Great.

BRAD: Cool.

PIPPIN: All right. Anything else before we move on?

BRAD: No. Let’s go.

PIPPIN: Okay. The next one — well, actually, Brad, why don’t you read this–

BRAD: Sure.

PIPPIN: –because this is about EDD?

BRAD: Oh, okay. Yeah. You’re going to take this one. Okay. This is, quote, “I use EDD and the software licensing extension to sell WordPress plugins. Plugins hosted on the WordPress.org plugins directory are recognized by their slug. If a premium plugin I am selling using EDD has the same slug as a plugin on the WordPress.org plugins directory and an update is available for my version of the plugin, will be overridden by one on WordPress.org.” This is kind of written crazily, but, “Is it possible to, let’s say, hijack the plugin update process so that my version is the one that is updated?”

PIPPIN: Basically this is a known problem with plugin updaters for, like, updating from a source outside of WordPress.org. The plugin update API in WordPress core is designed to interact with WordPress.org, period, and is not designed to interact with any other remote location. That means that every single plugin installed on your website is going to have — WordPress is going to look to WordPress.org and say, “Does this plugin have an update on WordPress.org?”

Let’s use your plugin as an example. Let’s say WP Migrate DB Pro. If someone was to fork your plugin and put it on .org and was able to get the slug of WP Migrate DB Pro on WordPress.org, any time they push an update and if their version number is higher than the one from your website, WordPress will show the .org version instead of your version because .org takes precedence, basically. Typically that’s how it typically works.

To answer the question directly related to EDD software licensing, we did actually add a parameter to our updater class that allows you to overwrite or ignore .org. We wrote a blog post on our development website about how to use this, and I will link it up into the show notes. The short answer is yes, you can get rid of this problem and you can fix it.

BRAD: Your plugin, so EDD will essentially just override whatever is on .org. It’ll just ignore it.

PIPPIN: Right. Yep. If your plugin on your website is version 2, but on WordPress.org there’s a matching plugin found that is version 3, it will just ignore the version 3 and will show the version from your website.

BRAD: Right. This is the code that a developer would include in their plugin, right? This is part of that code.

PIPPIN: Yes, it is.

BRAD: Yeah.

PIPPIN: Yep.

BRAD: All right. Cool. A little fun question for you from a listener. “Does Pippin ever take off his hat?”

PIPPIN: No.

BRAD: I think — yeah, he sleeps with it, showers with it.

PIPPIN: Pretty much. Pretty much.

BRAD: Yeah.

PIPPIN: Nah, I have a very close, personal relationship with my hat. I like it a lot.

BRAD: Yeah. Cool.

PIPPIN: All right. Next is — and this is our last question for the day. “What does your project management look like, such as what tools do you use? Do you validate features with users? How do you decide on features, et cetera?”

What do you do, Brad?

BRAD: Wow. Okay. So we use Trello for kind of the high level, bird’s eye view of what people are working on. As an example, like one of the cards would be WP Migrate DB Pro 1.7. That release and then whoever, the members of the team that are working on that are assigned to that card, so it gives a nice view of what everybody is working on in the company at any given time.

Then to get more granular, you would go to GitHub to the issues for WP Migrate DB Pro and take a look at what the issues are for the milestone 1.7. We keep most of our project management stuff in GitHub, kind of the details.

Then we use Slack for, like, the rest of the communication. We use a little bit of Google Docs for meeting notes and that kind of stuff, and that’s about it. I can’t really think of any other tools that we use for project management. What about you?

PIPPIN: We pretty much share the same suite of tools. We have numerous Trello boards that we use for kind of our internal discussions, planning, project management, et cetera. Like for example we have one for EDD. We have one for Affiliate WP. We have one for RCP. We have one that is kind of company-wide. We have a marketing board that is company-wide. We have an extensions board for managing all of our plugins for Easy Digital Downloads. We use a Trello board for Apply Filters.

We have a bunch of different Trello boards that we use kind of for that internal communication that needs to be persistent. For example, stuff that should not be in a chat conversation that will be quickly lost goes into Trello. If we have an ongoing project that might take us a week, a month, a year to complete, we’re going to put it in Trello and slowly work on it.

Then we use GitHub for all of our development tracking: bugs, features, enhancements, et cetera. Slack is our team communication tool, and we use it every single day. We break our Slack channel, or we break it up into multiple channels. For example we have a support channel for each product. We have an EDD support, RCP support, AffWP support. We have a docs channel for each one. We have a general channel for each one so that we can break each one of those general subject areas into its own channel so that we can have multiple concurrent conversations. Then we also have a general, which is just like a water cooler.

We have other ones for things like health and wellness. We have one that we call each one teach one, so if you want to ask somebody, hey, could you teach me this kind of thing, whether it’s a PHP question, a Git question, a personal life question, anything. We also maintain a couple other things like we have a security channel, for example, that if we need to discuss a security problem, we have those.

Those are really our three big ones. Oh, I guess Help Scout for support, but I guess the question was really about project management, so it’s GitHub, Slack, and Trello are the three. Then every now and then we’ll also use Google Docs for if we need to write things up or if we want to get some spreadsheets together of various things.

BRAD: Yeah. Have you guys tried the GitHub, the new GitHub features that are similar to Trello?

PIPPIN: We played with them a little bit. I’m not in love with them yet. I think they’re really cool. Right now they don’t provide enough of what we would need to replace Trello, and it doesn’t make a whole lot of sense for us to use both.

BRAD: Yep. That’s exactly what we determined as well in our assessment.

PIPPIN: I think it would work really great if you have, say, an open source plugin that has outside contributors or any open source project that has outside contributors and you don’t want to set up, like, a dedicated project management for all the contributors. If you don’t want to set a Trello board or a Slack channel or anything like that, you could use the new projects features in GitHub to help manage that. That would definitely be a worthwhile tool.

The other one that I forgot to mention is Zapier. We use Zapier a lot.

BRAD: Oh, yeah? What for?

PIPPIN: We do a few things. Number one, we have kind of a pick me up thing that runs any time we get a large sale, so like anything over $400. It sends a ping to our Slack room as a “Hooray!” kind of thing.

BRAD: Nice.

PIPPIN: It’s just a little fun pick me up.

BRAD: “Check that it’s fraud!”

PIPPIN: Yeah, right. Aw, sad day. We also have a — this is a specific use case that we have not taken full advantage of yet, but something that we were starting to look into was doing better with sending out swag to high value customers. We set up a workflow in Zapier that if a customer ever crushes a threshold, add them to a Trello list with their value and their email address, their name, et cetera as a, “Hey, we should send this person a thank you,” with something that we connected with Zapier. It basically reads data from EDD any time a customer is updated. Then if it passes a set of conditions, basically a lifetime value, it then sends a card to Trello and then automatically assigns it to a team member. We haven’t finished doing it yet, but it’s in progress.

We also use it for automatically subscribing or unsubscribing customers to a specific list in MailChimp based on their license key. If a license key expires, they get added to a dedicated list that says, “Hey, this is an expired customer,” so that we can then set them into workflows of follow up in a month or so to offer them a discount if they want to come back and renew or send them a question of, “Hey, is there a reason you didn’t renew? Can you provide any feedback to help us improve it?” things like that.

Then we use a similar workflow with Zapier that any time a license key is renewed or reactivated, go and look and see if that customer was on that list and remove them to make sure that they don’t get an improper email. We do quite a bit of that. Zapier automation is awesome.

BRAD: Yeah. There’s another part to the question I don’t think we answered. “Do you validate features with users? How do you decide on features?”

PIPPIN: Do you want to answer that first?

BRAD: No. You go ahead.

PIPPIN: Okay. I toyed around with various ways to do this a lot. I think there are a lot of common ways to do it. One is to do it purely based on customer feedback, so if a customer, like in a support ticket, or in a presale or in a feature request ticket or something like that says, “Hey, I would love to have this,” or, “I think it should behave this way,” make a note of that. Whether you note it down in GitHub or your own internal board on Trello or a Google Doc or however you choose to do it, take a note of it.

Another way you can do it is you could say, “Here is a public roadmap that anybody can vote on. Here’s all of the features that we have listed as possible candidates.” Allow people to add their own features as well. I’ve seen that work well. And maybe then some were a mix of the two.

We do some of both of those. We don’t have anywhere for people to vote on features. There’s a few reasons behind it, but we decided not to. We do have almost all of our GitHub repos are public, and we have most of our planned features logged there. We have quite a few feature requests logged there as well, so anybody who wanted to could come in and leave their comment or their feedback on it.

The main thing that we do, though, is in customer support. If we get a request for something, we log it. Then when we get another request for that, we log that back on where we logged it originally to say, “Hey, here’s another request for it. Here’s another request for it. Here’s another request for it.” And we try and keep a connection between the customers that requested a feature and the development of that feature so that when it’s done, we can go back and follow up with them all.

BRAD: How do you manage all that? Is there a system that you use for that, like some kind of software?

PIPPIN: For that it’s mostly in GitHub.

BRAD: It’s mostly in GitHub, so you’re just adding comments to an issue every time.

PIPPIN: Yeah, so the first time we get a feature request, we’ll log it as an “add support for this” or “add this feature” or however you want to describe it. Then we might say, “Originally requested here.” Then the next time it comes in, we just drop a note that says, “Here’s another customer that requested it. Here’s another one.”

BRAD: With a link to the Help Scout?

PIPPIN: Yeah.

BRAD: Yeah. It’s exactly what we do. But we’ve found that that kind of sucked because, at any given time, you couldn’t say, “Okay. What’s the top five issues?”

PIPPIN: Yeah. You can’t sort it by votes.

BRAD: Exactly, and so it was good for a while to do it that way when we were smaller and you could kind of just — you kind of just had a sense for, like, what the things that kept coming in were.

PIPPIN: Right. Right. If you see the same request over and over again, you just remember it.

BRAD: Yeah. But now we’ve got eight people doing support, right? So not any one person doesn’t have that sense any more. So we’ve got to frickin’ log and count things, so we set up a spreadsheet with things, with the issues on each row is an issue or a feature request or whatever that comes into support. Then the first column is votes. That determines how it’s sorted, so the whole spreadsheet is sorted by the vote count. We have it somehow — we found a little macro that sorts the whole spreadsheet as you update the votes.

PIPPIN: So you don’t ever log a request on your GitHub–

BRAD: We do. We do both.

PIPPIN: –until you decide to actually do it.

BRAD: No, we do both. We log it on GitHub so that we have a record of who is requesting these things, right? So we still need to know, like, what are the Help Scout issues for those, for this feature, who is actually requesting these things. We log it in GitHub, and we add a count to the spreadsheet. So it’s not a very — it’s kind of nuisance of a system, but we couldn’t — like I went out looking for software that could manage this and I couldn’t find anything.

PIPPIN: Yeah, I’ve never really found a good one that isn’t a public roadmap.

BRAD: Exactly.

PIPPIN: I think public roadmaps are really easy to do because, for example, you could do a public Trello board that has the vote feature.

BRAD: Yeah.

PIPPIN: What I would really like is a roadmap tool that has a vote feature. I would love this to be in GitHub. I want GitHub to add a vote feature.

BRAD: Yeah.

PIPPIN: It would make me so happy.

BRAD: In GitHub or in Help Scout. Help Scout would be a good place for it too.

PIPPIN: Yes. But the other thing that I want is I don’t want just a unique vote system. I want a count system where an admin can set a count any number of times they want. So every time that we get a request in, I can up the count, up the count, up the count, because most voting systems are based on unique, so it’s unique votes. But let’s say if you are doing it as a private system, you’re not having 100 people come in and vote. You as an admin are coming in and say we’ve had 100 people ask for this, so you are logging that count.

If anybody has a great tool recommendation, please share because I think, yeah, Brad, you and I have definitely both run across this and not found a great tool for it.

BRAD: One of my team, I think it was Gilbert pointed me to this Baremetrics system that I really like it. I really like it. It’s a scoring system, so there’s demand, so you can rate the demand high, medium, low. You could rate the impact that this feature will have as high, medium, low.

The effort required to build it as high, low, you know, like how much effort is it going to take to build this. If it’s really low then the score would be higher, right, because it’s easier to knock it off. You can do it really quickly, then why not do it? If it’s got low effort, high impact, and high demand, that’s a winner, right? So that would have a high–

PIPPIN: Oh, yeah, this is cool.

BRAD: –a high score, right? This scoring system, I think, is genius. I think we’re going to integrate it and maybe alter it slightly because I would really like to include our vote count as one of the metrics because that’s missing here. The demand is one of the metrics that Baremetrics is using, but it’s subjective, right? I chose high demand or medium demand or low demand. If we could use the actual vote count that we have already in our spreadsheet as the demand, I think this would be awesome for us. That’s on my to-do list is to integrate….

PIPPIN: We’ll put a link to that. It was a blog post on Baremetrics that showed this. I’ll put it in the show notes. It looks like a pretty sweet system.

BRAD: Yeah. Yeah, so all it is is a Google spreadsheet that they’re just offering up. You just make a copy of it and use it.

PIPPIN: Very nice. I think it’s addressing that question that I think every developer and every team faces of what to build next.

BRAD: What to build next. It’s so easy when you’re first starting out because, like–

PIPPIN: I know, right?

BRAD: But then as the project gets more mature and the team gets bigger, it does get much more difficult to tell what you build next, you know.

PIPPIN: Yeah, figuring out like what has priority versus what doesn’t. I mean you could have 1,000 requests for something, but that doesn’t mean it has priority.

BRAD: Yep. Exactly. I think the advice that I heard early on from people was just don’t worry about early on because you’ll have that sense for what’s important. This scoring system, if you’re just staring out and you have a product that’s really new, don’t do the scoring system. I think that’s probably premature. I mean you can if you want, obviously. But I think it’s probably not worth it in the beginning. Just go with kind of your gut and what people are telling you.

PIPPIN: I would agree with that 110%.

BRAD: Yeah.

PIPPIN: Well, shall we wrap up here?

BRAD: Yes. Let’s do it.

PIPPIN: All right. Thanks for chiming in again, everybody. Once again, this episode was sponsored by SearchWP. You can find them at SearchWP.com. Jonathan is nice and easy to reach out to if you have any questions, and he’s very friendly, so don’t be afraid to.

BRAD: Right. Talk to you next time.

PIPPIN: Cheers.