WP Product Talk
WP Product Talk
The Prioritization Playbook: Lessons from Multi-Product Businesses
Loading
/

Running multiple WordPress products under one roof can be both an opportunity and a challenge. In this episode of WP Product Talk, hosts Katie Keith (Barn2 Plugins) and Matt Cromwell (GiveWP/StellarWP) sit down with Ian Misner, Co-Founder and General Manager of Kestrel, to explore how product companies can juggle competing priorities without losing focus.

We’ll dive into:

✅ How to decide when to build a new product versus doubling down on an existing one
✅ The frameworks and habits that help multi-product teams stay aligned
✅ Real-world examples of cross-promotion that actually drive growth
✅ Common mistakes that fragment focus and how to avoid them

If you’re managing – or planning to manage – more than one WordPress product, this episode will give you practical insights to help you balance growth across your portfolio.

Transcript

Show/Hide Transcript
Katie Keith
00:03-00:23
Running one WordPress product is hard enough, but what happens when you've got five, ten or even more competing for your time? Today, we're unpacking how to decide where to focus, when to build something new and what it really takes to keep multiple products growing without losing momentum.

Matt Cromwell
00:25-00:47
This is WP Product Talk, a place where every week we bring you insights, product marketing. business management and growth, customer experience, product development, and more. It's your go-to podcast for WordPress product owners, by WordPress product owners. And now, enjoy the show.

Katie Keith
00:53-00:55
Hi, I'm Katie Keith from Barn2.

Matt Cromwell
00:56-00:58
And I'm Matt Cromwell from Stellar WP.

Katie Keith
00:59-01:04
And we have some exciting news at the end of today's episode.

Matt Cromwell
01:04-01:09
I thought you said we were going to do it at the beginning We're going to do it after we bring him on.

Katie Keith
01:09-01:26
Okay, but first, we've got some exciting news very soon. But first, let's get to today's topic. We have Ian Meisner with us to discuss how to successfully balance, prioritize and grow multiple WordPress products without spreading yourself or your team too thin.

Ian Misner
01:27-01:28
Ian, welcome.

Matt Cromwell
01:28-01:29
How are you doing?

Ian Misner
01:29-01:37
I'm great. Thanks for having me. Really appreciate it. And, Katie, it sounds like you're over-promising a little bit. The spreading thin part is part of it. All right.

Katie Keith
01:37-01:39
We'll see what people think.

Matt Cromwell
01:41-02:04
Nice. Yeah. And Ian's here as a guest today, but our very fun, exciting news is we have a new co-host to announce. And that co-host actually is also Ian Meisner. He's going to be joining the show, and we asked him reluctantly, and he reluctantly said yes. And so we're excited to have you, Ian. Thanks so much.

Ian Misner
02:04-02:14
Yeah, I really appreciate that as well. I mean, I've been asking tons of questions in the chat for many months at this point. So it just gives me the opportunity to ask direct. So I'm looking forward to that. From the group.

Matt Cromwell
02:14-02:25
Perfect. So that's a hint, folks. If you ever aspire to be a co-host on WP Product Talk, just troll us in the comment. And we'll just be like, fine, just get on here.

Ian Misner
02:25-02:29
There's never too many questions. That's the lesson.

Katie Keith
02:30-02:44
But weirdly, before we invited Ian to join us as co host, we had already planned today's episode with Ian as the guest. So it's a perfect test run before he starts his full hosting responsibilities.

Matt Cromwell
02:44-02:45
Yeah.

Katie Keith
02:45-03:16
So before we start, for those of you watching live on YouTube, we encourage you to leave your comments. Questions or feedback in the comment section. Do you think Ian is doing a great job, for example? And what do you want to know about managing multiple products more specifically? And we'll highlight comments and discuss them live on the show. I'm hoping people will still leave comments because Ian has been one of our most loyal commenters. So please leave your comments because Ian can't anymore.

Matt Cromwell
03:17-03:23
That's what we should have asked you to do is if you're going to co-host, you have to recruit three people to comment in your stead.

Ian Misner
03:24-03:27
I did send a few links out, so I'm hoping. Fingers crossed.

Katie Keith
03:28-03:48
Yes. And before we get into the topic, we also want to thank Amber Hind, who has been our co-host for, oh, I don't know, a year, two years, a long time. She's taking a step back, at least for the time being. So we've loved working with Amber. She's done a fantastic job. We hope to welcome her back in future.

Matt Cromwell
03:48-04:00
as well. Yeah, WP Product Talk's like the mafia, Ian. Once a co host, always a co host. So Amber can go and do her priority stuff, but we're going to get her back at some point.

Katie Keith
04:01-04:31
So let's get to the topic then. So we're talking about multiple product companies. And we got actually several good people to talk about that on today. So Ian, do you want to get started? Why does Kestrel have so many products. Maybe give us a bit of an introduction to Kestrel as well, because you're a relatively new, I think just coming up to two years company, and why you have chosen this model where you have so many products.

Ian Misner
04:32-05:40
Yeah, I mean, so I well I gotta start with a little bit of backstory to explain why. So at the very start, most of the Kestrel team are members of the former Skyburge team. So, Skyverage was one of the first third-party developers sold through the WooCommerce marketplace. For anyone who's not familiar, it's WooCommerce memberships and basically every payment gateway that isn't PayPal or Stripe. basically, right? So we spent a lot of time there and you know built up I think they have like thirty five, forty products. At that point. So, you know, we ran through that experience already. So, before starting Kestrel, you know, we had a bit of a playbook to run already. Now, as Kestrel, we started with the intent of acquiring a number of products to meet essentially a revenue goal that would allow us to sustain a team at a meaningful size so that there would be a group of people that could properly maintain a suite of products. And, you know, we were able to do that much quicker than expected. You know, we maintain now about 50 extensions, and prioritization becomes the entire job as a matter of that.

Katie Keith
05:44-05:48
So why didn't you do that with just one killer product? Why so many?

Ian Misner
05:49-06:45
Yeah, it's both though, right? So we do have the one killer product. So we've got checkout WC that sort of sits on top of all the rest. For anyone who's not familiar, Checkout WC replaces the WooCommerce checkout with a React-based checkout. It's compatible with all the extensions. Super fast, converts better. And that gives us sort of that like core product to really pay attention to, to really align with a set of customers around a specific goal. All of the other products as well, though, you know, like WooCommerce being modular is the point, right? Like, you know, the idea that you can do whatever you need to do by pulling all the parts off the shelf. People buy small features. For WooCommerce. So, you know, not everything needs to be a mega product. Sometimes the devs, the agencies, they want a feature, a simple thing, a well-maintained product. That does something that they can piece together in their own way. So we just want to support both types of users.

Matt Cromwell
06:46-06:55
Yeah. It's interesting, though, because If I remember right, WC Checkout came later in your acquisition phase, right?

Ian Misner
06:56-07:20
Yep. I mean, obviously, the bigger, more impressive things are also harder to acquire at times. So, a lot of the times, those are the folks who are doing very well. And they're very happy with what they're doing. And yeah, we've known. So Cliff, who's the founder of CheckaWC, we've known him for quite some time though. And, you know, it was sort of right place, right time with that one.

Matt Cromwell
07:20-07:55
Nice. Yeah, there's a little bit of a fun side angle to this conversation, I think, as Kestrel was Organized around acquisitions. Stellar WP also was around acquisitions. Barn too, less so, but you've also done a bit of acquisitions as well and sold a few things as well. And I think that whole conversation about how you prioritize resources is also related to like how you decide on what you want to acquire or what you want to sell. And we all have some things to say about that as well.

Ian Misner
07:57-08:39
Yes, absolutely. I mean, the reality of acquiring a lot of older, smaller plugins is that we did acquire More technical debt than products, basically. Right. So, you know, the big pile of things that needed to be fixed, what we got into it knowingly, but it also was based on the fact that we had that experience of SkyVerge to You know, with a small team, we knew how to prioritize the things with the greatest impact. And, you know, I have all these fancy methods of prioritizing that I think help. We have a pretty high confidence that we're doing a better job than the folks than other folks would be with the similar set of products.

Matt Cromwell
08:41-08:59
Or if they do you think that's I mean, I think that's a burning question a lot of our audience probably has is like these products, do you think that they are doing better under? I mean, you're biased. You have to say yes to this. But like why do you think that they are doing better with Kestrel than they were on individually?

Ian Misner
09:00-09:53
Yeah. I mean, so number one, uh, I feel very I've said this in a few places, but the, you know, with everyone talking about like AI replacing everything and, you know, the For me, the code was always a commodity, right? So the code itself isn't the product. The real product with any WordPress plugin is the experience, the support, the roadmap. the things that you do as a company that make it better tomorrow than it was yesterday, that's what people are really paying us all for, right? And so if you believe that to be true and sort of having a vision for what the product should be. And successfully delivering in a meaningful velocity against that vision is the part that actually matters. And so I will say, a question of a better job. I think if you agree with what I just said, I would say yes. There is, of course, some areas where you could debate it. But under that framing, confidently, yes.

Matt Cromwell
09:53-10:45
Sure. Interesting sidebar there. We actually had published an article on the website. We do publish blog articles every once in a while. Not very often, but every once in a while. We did a little bit of a reaction to a YouTube video from Daryl Wilson, who's a good guy and does some good content. And he was saying that AI is going to replace WordPress plugins. And we push back on that for exactly the reasons that Ian just highlighted is that there are definitely snippets that are going to replace really low hanging fruit free plugins for sure. But like, you know, all of us are in the business of providing products for WordPress, and a product is a lot more than its code. So it was a really good call out there, Ian. And if you haven't read the article, go check out their article. It's a good one.

Katie Keith
10:47-11:00
So let's get to a couple of comments first. So you mentioned that you think you're doing a better job. What are the metrics for a good or bad job done in terms of prioritization? Good question.

Ian Misner
11:01-13:55
Yeah, so I actually have a lot to say for this. Now there's at the very high level, I actually have to emphasize we have a couple of processes that matter to me more than the individual metrics of success. And the reason for that is, of course, when maintaining any suite of products, whether you have one product or 50, you will always feel like you don't have enough resources to do everything you could or should potentially do. So, there's a couple of things that before looking at like trailing measures of success that I care about even more in the day-to-day, about what the team does. Which two of which are number one, we have this sort of like broad macro allocation of resources, like this idea that In everything we do in the things we spend time on, about half the time should be spend on growing the products, making them better to attract new users. about 30% just fixing stuff, support needs, whatever, and about 20% of quality of life, dev workflows, frameworks. Are we Making it easier for us to do more in the future than what we can currently do with the set of products we have. Along with that, though, we also, for things that come through support, for that 30% of fixing stuff, We have a scoring measure that we use with our support team, which is just few scoring. It's based on rice scores, which is like an intercom thing that they shared out, but frequency, users impacted, severity, and effort. And we have this sort of like concept of SLAs around few scores, which essentially, if a user reports a bug or an issue, or Actually, the definition of what a bug is is important here. And I'm just going to gloss over that for a minute. But frequency, users impacted in severity, very easy for anyone well-versed in a product to estimate. And we have essentially one to four is a ranking for each of those things. You multiply them by each other, you get a score. If the number big, everyone drops what they're doing and panics. If number small, you throw it on the backlog. And we have other systems to capture that. More than anything, if we're adhering to that, I trust that we'll get the outcomes we want. Now, of course, we do have measures To tie that to metrics that matter. But I try not to make those the primary focus. Number one, though, is literally just the number of releases per week. is a thing we track. And ideally, quarter by quarter, that number goes up, even with the same number of engineers. Not dramatically, of course, maybe it's two point something, and then it's 2. 9, then it's 3. 0. But ideally, we're able to improve velocity over time. But then the secondary one that I care about is support requests per thousand users. which is just very bluntly, for every thousand users of a product, how many support requests per week does it generate? If that number approaches zero, it's a better product. And those two things alone, I guess the third one's revenue, of course, but I would rank them in that order.

Matt Cromwell
13:55-14:00
Nice. That's interesting. The the support per thou say it again.

Ian Misner
14:01-14:02
Support per thousand users.

Matt Cromwell
14:03-14:05
How many tickets per thousand users?

Ian Misner
14:06-14:17
Yeah, exactly. And actually, this is an arbitrary aside. The word tickets is a banned word. We do call them conversations. I'm weird and nitpicky about that in particular.

Matt Cromwell
14:17-14:20
And anyone who's got to be closed at some point, right?

Ian Misner
14:20-14:28
No, no, no, they never close. You can reply in two years, we'll still answer you. All right. That's I'm sorry. That's a bit of a tangent.

Matt Cromwell
14:27-14:31
But no, we'll have another podcast. You're going to be on again. We'll talk about support.

Ian Misner
14:31-15:17
So I have strong feelings on that one in particular, and I got documents. I should probably publish something actually, but I feel very strongly about that. Yeah. No, that means that support per thousand users, though, is something that it's actually very easy to measure. It is very easy as a proxy for customer happiness. But also there is like a revenue or a cost impact, right? So if we're driving that number down, we're doing a better job as maintaining profitable products. But the way we're measuring it is: is the product easier to use? Is the customer just buying it and getting the value they desire without having to contact us? And success there is it's a shared incentive. We're all on the same page.

Matt Cromwell
15:17-15:25
Yeah, interesting. We do sales per ticket to sales ratio is what I do, weekly ticket to sales ratio.

Ian Misner
15:25-15:40
Yeah, I think that probably gets you roughly this I mean, you have that sort of fluctuation in sales is probably a little bit more dramatic than a thousand users because that gradually increases. Well, you'd hope it gradually increases, but more fluctuation in sales.

Matt Cromwell
15:40-15:51
Exactly. I always say, like, I like to be around 50% when it comes to ticket to sales, but if it jumps up into seventy or whatnot, then we probably ship the bug or something like that. Yeah.

Ian Misner
15:52-16:10
So yeah, well that is another thing is that by tracking the number week to week, you can actually definitely like if it's significantly higher. Why? If you don't know the answer, it's a problem. If you do know the answer, you can usually just move on with your life. But if you don't know, it's at least a smell, something to look for.

Matt Cromwell
16:11-17:21
It's a good one. But we're getting a little bit in the weeds on the support thing. But what I hear you saying in terms of this subject that we're talking about is that how much support a particular product in your portfolio generates Whether that's needless support that's like you should have read docs, or it's like, oh, no, these are tickets that we're going to spend hours on. that impacts how significant of attention you're going to have to give that product in one form or another. And to me, that says a couple of things. Like one, yes, You have systems that these products are inheriting when they come into your portfolio and into your business. But another one is that folks who are interested in selling their business to somebody else Probably should have an eye towards that kind of thing because the buyer is going to be interested in like how much support am I going to inherit From this product? And is my team going to be able to absorb that support? Or is part of the deal going to be that I get some support people from your business or things like that? That on the stiller side, that's the kind of thing that I'm always vetting: is like, how much is this going to impact the support team?

Ian Misner
17:21-20:01
So Yeah, well, and I will argue that that number being very bad is also a sign that it's, you know, if it's a very good product, otherwise, it's something that we can fix and be happy about, maybe. But I mean, ideally, it's just good already. So. Yeah, there's two sides to that, I'd say. Now, without jumping in too fast here, but I will say those metrics measure if we're doing enough. They don't measure if we're doing the right things, right? So, that question of prioritization is still pretty important there. And, you know, just quantity first is how I like to deal with any of these problems because. If you're doing enough work, you can modify if you're doing the right work separately. So we have the metrics to make sure we're doing enough. As far as doing the right work, though, there's a couple of things that I think are a little bit weird with the number of products we have that maybe are sort of important as context, which is like one thing that I specifically don't care too much about is the hard lines between which product is which. Ideally, as a company, if you come to us with a problem, we can give you the instructions on how to solve that problem. And whether that's one of our products or a competitor's product, that's fine, right? Like, let's just be able to answer that question. But then, when we're actually tracking what work needs to be done. We have a couple of mechanisms there to help make sure we know what people actually care about. Like our support team, for example, they track job stories For every support request. So, you know, what problem did they encounter that triggered the need to ask for help? Which that helps us understand. Separately from if it's what the product should be doing, what they actually, who cares what? I don't care if our product should have fixed it or not. I just want to know what the problem was. And then we have a data set there to help us understand. What can we do to help people? And then usually we can fit that into one of our many products, basically. But then the other thing is I have a lot of other mechanisms in place to ensure that the product decisions aren't actually centralized. Like ideally, we have a roadmap, we have a plan, we have a place we're trying to get to. But I'm not defining acceptance criteria for every set of work we do. I'm here's a set of products that we care about right now. Here's our goals. Here's the problem statements we're trying to solve. And then I hand it to our group of engineers. And they're not fully winging it. We want them to think in product terms too. But they share problems across the team. By doing that, it helps us keep the pace up as well.

Matt Cromwell
20:01-20:02
Yep, nice.

Katie Keith
20:03-20:17
So you just said, here's a group of products that we care about right now. How are you making that decision on which group of products? Do you, for example, always focus on the one that gets the best sales? Or is it more nuanced than that?

Ian Misner
20:18-22:48
Yeah, definitely more nuance. Now, obviously, the stuff with the most sales tends to bubble up to the top of the list. So I'm not going to pretend otherwise, right? Like, check out WC gets more updates than anything else we have, right? That's just going to. Probably continue to be true indefinitely. That being said, by focusing on the problem, the set of problems, And that macro allocation I talked about, you end up with a few things that help you bubble up other things and to make sure you're always Fix it. People are paying us for even the smaller stuff. They deserve fixes and updates and improvements as well, basically. So the growth projects tend to focus on revenue-driving work or new features or whatever. And often, though, we'll figure out what the need is before deciding where it belongs. So we're not thinking about improving a specific product. We're trying to identify a problem statement that we can resolve and then putting it in the most relevant product once we once we know what it is we're doing. So that's one thing that separates that from revenue in some cases. The other one though is just the fixing stuff portion. Often if we're fixing a couple of bugs, we just go and add something also while we're there. So we have in shortcut JIRA but cooler. We have a big huge backlog of all the wonderful things we may one day do. We log our feature requests. All of the fun stuff that everyone else is already doing, I'm sure. But when you're there to fix something, add something to, you know, find something cool. And this is sort of part of it where. Just enabling the engineers to get excited and do the thing they want to care about next is intentional. I will add one other thing that maybe is important context is we brought up that we built up the suite as a bunch of Acquisitions. Whenever possible, we brought on the team from those acquisitions as well. So Cliff is still the lead engineer on Checkout WC. He's been working on it for seven or eight years. So we put a bug in front of him. He ends up in an area of the product. He just goes and does the stuff he wishes he had done before, also. Right. Similarly, with like rental products or product badges, you know, David from that team, he's working on that still. And in, you know. Basically, every acquisition we've done, barring, there's one or two exceptions, but almost all of them, we have at least some of the people that have always worked on it here.

Matt Cromwell
22:48-23:08
Yeah, that's the way Stellar has done it as well. And honestly, it's as one of the acquired products that came into Stellar. it was the reason why we decided to go with Liquid Web and not other folks who were trying to acquisition us. in different ways.

Ian Misner
23:08-23:30
So yeah, I I I do like I went through an acquisition myself. So me and the Skyverage team, we joined GoDaddy back in twenty twenty. And I do feel very strongly that like the founders matter in those sorts of situations. Like they They know something about the product that you can't know. At least it takes years to know, at least, right?

Katie Keith
23:32-23:52
Yeah. So let's get to some comments. A quick one first, which is that Shortcut needs to add Jira but cooler to their marketing copy now, if that works. And then Rob says, Ian, how long did you allow for the ROI on dealing with all the tech debt? And did you meet those goals?

Ian Misner
23:53-25:31
Yeah, I'll let you know first of all. So, you know, we're only about two years in. And so as far as ROI is concerned, you know, we're doing great, but obviously, arguably, we'll find out. But also, that does vary heavily by product. And that's this is one of those questions that's not as neat as I like. The spreadsheet isn't quite as pretty as it maybe should be here. Because, again, like the way that I'm prioritizing things across the suite of products. We have 10 or 12 products that definitely get the majority of our attention because we've gotten excited about the problem space, or we get the feedback loops from users that these are the things they care about. You know, so we're just spending a lot more time there and seeing a much rapider, a much more rapid ROI as a result. Attention begets sales. It's pretty straightforward. As far as straight up technical debt, though, just as a quick thing, we have a concept of a framework. We have a plug-in framework. We did this back at Skyverge. We're doing it again here at Kestrel. The framework is a bunch of unified things that we do across all of our products to make them easier to maintain. And again, in that sort of macro allocation I shared. 20% of our engineering time is meant to make their lives easier. So when it comes down to bringing more things into our frameworks and making them easier to fix bugs in the future, easier For third-party developers to look at our code and understand what they're seeing. That's something that is sort of a never-ending process in the way we do things. I don't have a target date, but you know, next year it'll be better than last year. And I can say that with confidence.

Matt Cromwell
25:32-25:39
20%, that's quite a lot. That's like a day a week. Like every Friday is like, yay, we get to do what we want day.

Ian Misner
25:39-26:02
These things are not things we truly measure. It's 50, 30, 20 is like a vibe, sort of like, you know, does it feel like you're. Matching the spirit of this is the point there. But also, the 20%, I will also say, like often that does come out as bug fixes and all those releasable things as well. So there's fuzzy lines there. It's a framework, a concept, not a target.

Matt Cromwell
26:02-26:05
Yeah, yeah. I like it.

Katie Keith
26:06-31:33
So it's interesting to hear that you acquired the people with most of the products. In a way, that probably makes it easier to manage multiple products because you are increasing your capacity at the same time as you do those acquisitions. which we don't do at Barn too because all but one of our nineteen Premium WordPress plugins are in house built. We only ever acquired one product, which was fairly small, WooCommerce product tabs. So it's a bit different. We've kind of never really found that killer product that would dominate our entire business. Maybe that's a kind of negative reason to have multiple products, but the way we've naturally grown is how let's grow more now by going into a new market or new sub tangent of our existing market. with a new product instead of we have a killer product that we're going to put all our resources in. And that seems to work pretty well. In some ways, I'd love to have a massive product that's as big as I don't know, Lifter LMS or something like that, where you could run a whole one successful company with the one product, albeit maybe with add ons. But essentially, that's an ecosystem. We don't have that at Barn Tu. But I'm going to show you how it works for us. So I'm going to put a chart on of our revenue percentages. So This is our total revenue on the screen broken down by plugin. And we have nineteen premium plugins. We've also got a Shopify app, but that's only made one hundred ninety dollars. So we can Forget about that for now. So, with our WordPress plugins, our top plug-in actually only makes 26% of our revenue. when you think about like the size of Barn two, it's you can see in this chart how important it is that we're a multiple product company. But at the same time, the eighty twenty rule does apply. So twenty two percent of our sales is made up of twelve of our plugins. That's very AT twenty rule actually, if you work out where we should be spending our time. So it's really important to prioritize and put your resources into the not necessarily one plug in, but the few plugins that are doing the best. And that this chart where you can see that the bottom twelve are truncated like that into twenty two percent, it would have been worse except that we sold our five lowest selling plugins. to the lovely Ian and Kestrel, who for some reason wanted our smallest plugins, and that fit into their business plan of acquiring multiple products to very quickly get to a certain revenue level. So I found that really interesting. I didn't like try to con them or anything. I said, these are our lowest selling plugins. They are not worth our time. That's why we want them to be acquired. And Kestrel, it did fit into their plans at the time. So I think that's really interesting that even though we've got this breakdown of nineteen products, there was a limit for us where it wasn't worth maintaining some of them. So we've now got an equilibrium where every plugin is making, I think, at least $1,000 a month or something like that. So none of them are super tiny, and some of them are doing a lot more, of course. So I use that knowledge to prioritize. And when we're looking at things like feature requests, we're thinking about whether how what the impact on revenue is. And that makes a big difference. If a plugin is selling more, then its top feature request is likely to have a bigger effect on revenue. But you can't completely neglect your smaller ones because customers need to see that stuff is happening. People look at change logs before they make a purchase. People also use the number of new features added in a year to decide whether to renew often. So if they've been receiving emails about new features, that's going to improve your retention on that product. So you can't just put everything into your bigger products. You need to get the right kind of balance between them. But another thing I love about having multiple products is the cross promotion opportunity. So about, I think, fifteen of our nineteen plugins are for WooCommerce. So that means that we can cross promote them really well, just like Kestrel can with their WooCommerce extensions. And so we have, for example, an all access pass where you can buy all of our plugins, which only actually makes up six percent of our revenue. You think it might be more, but it's not. But it's we also sell all of our plugins as a kind of an option with a two plugin bundle. So we've chosen the most closely related plugin. And it's right there on the sales page. Don't just buy this, buy these two and see how they work together. So that's a way that we have increased our average order value. So there's lots of business benefits, I think, to having multiple products. And also, I would say spreading the risk. I kind of would love to have a killer product, but that would also terrify me because if you have a massive new competitor, that's going to have a lot more impact on you. than if you have nineteen products, where if we have a new competitor, it's really not going to have much impact.

Matt Cromwell
31:34-32:12
That's a really significant topic in this whole conversation, in my mind. I love the idea of diversifying risk in terms of your product offerings overall. Honestly, our intent when we were building out Impress. org was to have a more diversified approach, but our but give started j to just become so incredibly dominant in our portfolio that we couldn't d prioritize the other products at all anymore. And it wasn't our intent, but it is exactly what happened though.

Ian Misner
32:14-32:50
Yeah, I mean, honestly, our distribution of revenue isn't too different from Katie's. I think that our long tail probably goes a little longer. As you noted, we picked up some smaller stuff with intention. But I think that there is something to be said for we are extending WooCommerce with all of our extensions. And ultimately, there's like the so the platform goes, so do the products associated with it. And so as long as we're empowering users to do the things they need to do with WooCommerce, we view what we're doing as successful regardless. Yeah, absolutely.

Matt Cromwell
32:50-32:56
But Katie, did you explain that, was it like 20% other? Is that like some like shady side business you're doing?

Katie Keith
32:57-33:02
Or what is That's just our small plugins. That's plugins eight to nineteen.

Matt Cromwell
33:03-33:10
I see, got it. It just said other and I was like, that's interesting. That seems like a conversation we should be having.

Katie Keith
33:15-33:15
Nice.

Ian Misner
33:15-34:16
Yeah, as far as the 80-20 rule, like our top, I think it's 12 plugins are legitimately like 80% of our revenue. And it's 12 out of 50. It's pretty close to 80-20. And theoretically, we could just go just do those things. But I think realistically, support for some of the smaller stuff helps us drive sales for the things that are bigger. And even more meaningful, right? And we don't do quite as many cool cross sell things as what Katie sorted out yet, at least, right? But support is a very strong sales channel for us. Not because we're act like we don't I actually have a rule in support where you always give the free solution next to the paid offer. It's like a, you know, here's the snippet you would use, or if you want to go try to figure it out yourself, here's what you would start with. But then we always associate that with, or just buy this thing, right? And that sort of. But we wouldn't sell as many of our bigger plugins if we didn't have some. You know, you could argue there's maybe some of the lowest end aren't doing the work there, but it's still worth it in the end.

Matt Cromwell
34:16-34:17
Yep.

Katie Keith
34:17-36:24
Yeah. So we've got a few more comments in from Francisco following what I said. Barn2 has enough resources. Profit that could be used to explore new verticals or type of SaaS products. Yes. So our main project in the last year has been expanding into Shopify. to further diversify and safeguard the business by being across multiple platforms. And we have done that with our existing resources. I didn't actually realize you could use WordPress developers for Shopify, but you can use very similar technologies like React. So two of our developers are mostly working on Shopify now. And I thought we'd have to hire new people and we didn't. So that's nice. But we are still adding features to our biggest plugins in particular. And with the remaining developers, we haven't gone all in on Shopify. but it is nice to be able to do that and go into new things as well as looking after your existing products. So we got a question from Rob for each of us. So do you factor in how often you release updates to your plugins? Because each update should require testing. before the end user upgrades, and that costs them money. Okay, I'll go first on that. So we don't we do updates when we need to do updates really, and we have a minimum time scale where no plugin should go longer than X months without an update. And we do have proper QA. We have a full time QA in house and lots of automated testing. So we just do what we need to. And sometimes we have to prioritize the QA and say, look, we need to get this out. Can you do that before that or something. But I don't think you can particularly delay updates in that sense if you need them. And if you want a new feature and you've got the capacity to build it you need to test it and release it. So I suppose I don't allow the testing to lead the development time scales. What about you, Matt?

Matt Cromwell
36:25-38:33
Yes, we don't have like strict rules on it. We do operate in terms of two week sprints, and every sprint has code that gets committed to the products in one form or another. Every single release is a mix of fixes, tweaks, and usually at least one or two features as well. But that just kind of happens a l bit more organically. Not every single sprint results in a push to like a release To the user. But within two or three sprints maximum, we'll have at least one push to the user and a release. It's not a hard and fast rule, and each of the teams operates just a little bit differently, but they all are on these two-week sprints. I do sympathize. Rob's follow up here is like part of the context for his question is he's saying, for example, I've gone away from plugins that release little patches all the time because it was taking up too much time. In my staging environment, testing. I'll honestly say I do know that there are some there so especially when it comes to the free plugins with the WordPress. org plugins. Whenever you push out a new release, you definitely see a bump. And it's not just people updating. There's just a natural kind of bump in which Maybe you're higher in the search rankings or something, but you start getting a bit more users. And there are folks who do kind of be like, Let's just push out a release because we want to get a few more users right now. That does happen, honestly. But if they're doing it, like you're saying, all the time, they're just kind of like little tiny patches that don't matter at all, that aren't even user facing improvements, like I would be skeptical of that kind of thing. But I mean, looking at the change log of any reputable plugin, you should see like really good. clear, obvious, value based improvements in every single release in one form or another. That's my take.

Ian Misner
38:36-39:54
Yeah, for me, so we do have a couple of different things. One is if it's a larger, like a product release, like a growth-focused release, a meaningful feature update. Whoever wrote the initial pitch reviews it, tests it, tries it. And we ask the support team to review it and test it and try it as well. That's usually going to be like the major releases, though, right? So that's only happening. You know, once a month, ideally, you know, maybe a little bit more often. But all the little bug fixes, though, we just, it's simple, second set of eyes, whoever does the code review tries it. And that is the extent of what we do for little bug fixes. Now across fifty products, though, we don't encounter that problem that I think Rob is alluding to, where there's so many updates. that that becomes the issue. If anything, we're trying to keep up. We're trying to make sure we're putting enough out there that everybody's getting the value they deserve. And I will just add, WooCommerce has recently added in their marketplace where we do a lot of our sales a minimum of every six months for updates. So even the very smallest product will get two updates a year, no matter what. And honestly, for us, that will increase the number of updates to a couple of products. Not many, but it impacts us a not-in-zero amount, right? And honestly, I think that sort of thing is a great little rule for them to have added.

Matt Cromwell
39:56-40:30
I mean, there is also the WordPress. org. If you aren't updated within the last three WordPress releases, there's a banner notice that goes up on there that's user facing. And you'll be negatively impacted on search results, things like that. If you don't update your compatibility or if you don't update your PHP compatibility even, that can be have a negative impact depending on the host that you're on. So there's several things like that that sometimes require basic updates.

Ian Misner
40:30-40:52
I will add on Checkout WC though, which probably does get the most of our updates. Our changelog page on the website is actually one of the most trafficked pages we have. People are checking, reviewing to see if it's worth updating or not. Obviously, we always encourage you to, but there is probably updates at least every week on that product. So I understand if people are reviewing to make sure it's worth their time.

Katie Keith
40:56-41:57
And we've got a comment from Nick, who says, yes, the balance between diversifying risk and creating prioritization problems is maybe the key dynamic here. Yeah, always difficult. Another comment is, have platform changes or directional changes in the WordPress and Woo ecosystems over the past few years affected your pro approach to prioritization? at all, yes. There is a reason that late last year we decided to diversify into Shopify. We haven't been seeing the growth that we previously saw in WordPress since about mid last year. And that's why we've decided to that one way to safeguard the business as well as having so many products, which you already have, is also to have products on other platforms. So we're that's why we started to spread our resources a bit. Have either of the two of you done anything like that?

Ian Misner
41:59-42:48
I mean, I'm still working on A great answer for this. I will say, never give up, never surrender is one angle to take here. You know, we have a number of products, and there is a global traffic to Klein that I'm seeing, and you know, less revenue on a lot of the smaller products. Our biggest things are still growing, though, you know, and I see it almost as a bit of a consolidation rather than an actual shrinking of things. Yeah. When it comes down to it, figuring out how to cater to the people who are continuing to care the most about WooCommerce is, I think, the right answer. And to me, at least, that tends to mean like the agencies and small devs that are you know building on it. And maybe a little bit of that gray market stuff that I don't like to embrace too openly. There's a lot of it, right? So it's there.

Matt Cromwell
42:49-43:53
Yeah. We haven't changed all that much, honestly, in light of all the change and whatnot. We also are seeing. We're pretty bullish about WordPress as a whole. We continue to see good gains across our stellar products. We're hovering around ten percent year over year growth right now for our whole product line. And that makes us happy. So we haven't changed all that much. I hear a lot of folks with a lot of doom and gloom types of things, which I think are understandable for sure. And I in many ways, over the last year, I've shared some big concerns about where things might be heading. But what I'm seeing in the data in terms of what's happening in our website analytics, in our customer base. Is that folks still really want to build with WordPress, and they're still building some really incredible websites out there. So as long as folks are doing that, we're going to keep doing what we do.

Katie Keith
43:55-44:09
So our co host, Zack, has a question following up on something Ian said, less revenue on a lot of our smaller products. How do you determine when to put a prop plugin into maintenance mode and only release security patches?

Matt Cromwell
44:10-44:21
That's actually. going to be my show and tell. My answer to that question is basically how I was going to talk about our stellar products. Ian, if you want to jump in quick, then that's cool.

Ian Misner
44:22-45:31
Yes, I'll give a short answer, leading to yours then. So essentially, I don't believe in maintenance mode is going to be my top level hot take here. If you're selling the product, the commitment to maintenance and support is definitely part of it. But also, when we do support, we're going to treat every request in the same way we treat every other request. We use support to prioritize a lot of the development we do. And again, you will see some products bubble to the top, some kind of sink to the bottom. But if a compelling enough feature request comes out, or something one of the devs just gets excited about and builds in half a day, we're still going to do it. As a quick example of that, we have a product that we don't do a lot of work on where we got three support requests asking for a tip feature in like three weeks And one of the devs just built a prototype of that in like an hour. Like it was that simple, that easy. And so it's 90% done. So it's half done. We got to go spend a day to make it worth actually releasing. But like we're going to do that if customers are asking us to do things, if we're getting feature requests. Maintenance mode is a bad concept as far as I'm concerned.

Matt Cromwell
45:31-45:32
For sure.

Ian Misner
45:32-45:34
Yeah. Go for it on your end, though, Matt.

Matt Cromwell
45:34-47:16
Yeah, I will say we definitely have to balance our resources really, really carefully. at Stellar. And I mean, one of the journeys that we have had as Stellar WP is that, yes, we all came in as independent businesses with independent teams, all focused on their individual brands. And as we have grown and matured over the last like five years, we have more consolidated to be one stellar WP team that manages all these products. There's still several folks, especially support folks, who are brand specific, but a lot of folks, especially across all of leadership, they're multi-brand leadership and things like that. That. And so, because of that, we have to figure out a really good way to prioritize where we put our efforts smartly and well. I'm going to drop a link here in the YouTube comment from the Product Talk account. That's a a matrix or a prioritization matrix, some people call the BCG matrix, that we have talked about quite a bit because our products are also all very mature. 10 years old, you know, iThemes Solid WP is 15 years old. So they've been around a long time. They have a lot of renewal revenue that's really significant and important. And we can't just simply say, oh, yeah, this thing is on maintenance mode. That's not a thing that we can do in any way, just like Ian was saying.

Ian Misner
47:17-47:19
We have a lot of smaller products as well.

Matt Cromwell
47:19-47:20
Sorry, go ahead.

Ian Misner
47:20-47:45
I just want to throw in, if I was ever going to do something that what people mean when they mean maintenance mode, there's two ways I would handle it. One, I would take the features, I would fold them into a related product. So it's easier to maintain and easier to justify, which we have done in the past. Or I would just throw it on. org and continue to do security releases that way. If we're not going to treat it like a product that you should pay for,

Matt Cromwell
47:44-51:22
Yeah, we're just gonna make it a product you don't have to pay for. Yeah, yeah, for sure. Um, we we definitely have uh A lot of smaller products that we spend less time on, and we put less energy in them. And this matrix is kind of one of the things that we talk through. In order to prioritize those things. And you'll see there, well, let's see if I can share screen super quick without breaking everything down. Is that working? Nice. So growth share matrix, you basically are going to break up your products into somewhere on this matrix chart here, where you look at How much market share does that product have? How much growth potential does that product have? So if I take a product like Cadence WP, for example. it is on a very high growth trajectory. So it's very high up on this growth area. And in terms of the market share, it's a little bit towards the middle, like if you compare it to things like Like Divi or Elementra that have so much of the WordPress market share, it's kind of crazy. But it's definitely not in the question mark area. So it's still, I would say, right into the high area. So cadence for us is definitely a star. Absolutely. And that means that we definitely want to add more resources and more time and more marketing into Cadence as much as we can. Honestly, in some ways, GiveWP is a bit of a cash cow because its growth potential has really waned over the years, but it has a very, very high market share still. So it's definitely bringing us in money all the time, regularly, both in terms of renewals and new sales and revenue share as well. But its growth potential is not gigantic. It's not going to go taking off like cadence is right now anymore. So those types of things really change the way that we think about each of our products. Like give, we're definitely going to continue to build on it and improve it all the time. But we're probably not going to do any major, gigantic, huge renovations of it in order for it to jump into this new vertical or whatnot. We're not going to necessarily, you know, we have done this already. We rebuilt the whole entire form experience. Completely. We have a whole new way that we're managing our donors and our donations in the database So that we can enable more tags and different meta fields for all those things. We've done all that work in a lot of different ways. And now we just want to double down on what's there and continue to serve that customer base in a really Super strong way. But there's some ways in which give could become a star again, honestly. But And I'm not saying 100% that we're always thinking cash cow. There's certain things that happen that change it in different ways. There's always stuff that happens in the market that you have to take serious or That you should react to quickly in different ways. So there's for us, that type of matrix is just helpful to be able to say, like, okay, these resources need to be focused over here. because of its potential. And this one needs to have different folks working on it to keep stability and whatnot. So it's been useful for us. It's been helpful for sure.

Katie Keith
51:23-51:37
Yes. So two quick comments before we move on to best advice. Patrick says, love that maintenance mode is a bad concept. And he also says Cadence is an absolute star, no question.

Matt Cromwell
51:37-51:41
Thanks, Patrick. Didn't even pay you for that one. That's great.

Katie Keith
51:41-52:04
And we've got a question from Rob, which we're not going to answer because how do you prioritize who to build for, end users or agencies, developers? That was last week's show. So you need to go on last week's show where Zack and I interviewed Robert Abella from Mellopress, and we had a whole hour talking about that. So that is a very timely question.

Ian Misner
52:04-52:11
I just want to give a five-second answer to that. I said, it's the same thing if you're making it easier for the agencies to deliver to end users.

Katie Keith
52:11-52:17
Same thing. Yeah, we kind of came to that. Yeah. Hey, we want him to listen to last week.

Ian Misner
52:17-52:17
All right.

Katie Keith
52:19-53:00
So we always wrap up every show with a quick roundtable question. What is your best advice for anyone struggling to manage multiple products or build a multi-product business? So I'll go first. I think that my best advice would be to have it's fine to it's great to have multiple products, but try to keep them related so that you can take every opportunity to cross-promote them. and get maximum value from each customer because they're using multiple products. And that makes it a much better use of your resources and also achieves better economies of scale with development and things. What about you, Ian?

Ian Misner
53:01-53:24
I mean, my main piece of advice is just to listen to the merchants, right? Every single WooCommerce customer, every customer that I deal with, they want one of two things. They want to spend less time or they want to make more money. Regardless of where the product is or what lines you draw between products, every improvement and every fix should help serve those goals. And they'll be happy to talk to you and work with you regardless of how you package it up.

Matt Cromwell
53:25-54:30
Love it. I would say similar to the way Katie is saying, like keep them somewhat similar, I would say try to make sure to Keep them associated with each other as much as possible. The way Kestrel does, for example, you know, if you're getting a Kestrel product, you know if you're getting a Barn II product. We had Stellar, honestly, we were not promoting Stellar for a long time, but we are changing that and we're trying to make it more obvious that GiveWP is a Stellar WP product and TEC is a Stellar WP product because We believe in the long term that that reputation will impact all of those products positively. So that you know every single time when you get a Stellar WPP product, you know what kind of support you're going to get. you know what kind of development practices they have. I do think that type of reputation comes from a good, strong I don't love calling it an umbrella brand, but an associative brand in one form or another. I think that's really beneficial to your business strategy.

Ian Misner
54:31-54:40
Yeah, when choosing a WordPress solution, it's who's building it should be. You know, your number one question, right? Everything else is secondary. So, yeah.

Katie Keith
54:41-54:47
Yeah. Well, that's a wrap. Ian, thank you so much. Where can people find you online?

Ian Misner
54:47-54:59
I'm on Twitter but X Way Too Much, just Ian Meisner there, and then kestrelwp. com. You can find all the stuff we do there. Message me in either place. I will answer.

Matt Cromwell
55:02-55:05
Great. I don't have the show notes in front of me.

Katie Keith
55:07-55:09
You repeat the news. That's next.

Matt Cromwell
55:10-55:11
Repeat the news?

Katie Keith
55:11-55:13
Oh, yes, about Ian.

Matt Cromwell
55:13-55:20
Thanks so much for being a co-host, Ian. We're excited to have you on. Actually, is next week your first co-host episode next week or the week?

Katie Keith
55:20-55:23
No, I think it's two weeks that we've got Ian on the host.

Ian Misner
55:23-55:26
Yeah, I'm at WordCamp Canada next week, is why.

Matt Cromwell
55:26-55:37
Oh, yeah, yeah. So, watch out for Ian's next episode where he's co-hosting. We're going to put him under the gun and see how he does. And next week, we're doing something special. What are we doing, Katie?

Katie Keith
55:37-55:47
Yes, we've got Aaron Edwards from DocSpot. We're talking about AI support, which is changing all the time, and this is definitely a good time to discuss that.

Matt Cromwell
55:47-56:24
Yeah, I'm excited about that topic for sure. I've done a lot with Aaron and with DocSpot at Stellar WP. So that'll be a good episode. Thanks, everybody. Thanks to PostStatus, as always, for being our green room, for organizing and whatnot. And please like, subscribe, do all the things to help the show. Subscribe especially. We're trying to get to a thousand subscribers if possible. Because you know that that's where like that's the magic YouTube number. So you have to have a thousand subscribers. Help us out. Tell your friends. Tell your family. Get your dog to subscribe, things like that. It would be super Helpful, and we'll see you all next week. Thanks so much.

Katie Keith
56:24-56:25
Bye.

Related Episodes