Balancing Features and Focus with Your Ecommerce Products

Katie:
Hey, and welcome to Do the Woo. I’m Katie Keith, founder and CEO at Barn2 Plugins, and this is the first time I have done Woo Product Chat on Do the Woo because I was on the Biz Chat last year with Marcus Burnett. So now I’m here with co-host James Kemp from Woo. Hey, James.

James:
Hey, Katie. Yeah, I’m James Kemp, like you said, and I’m from WooCommerce. I am the Core Product Manager at WooCommerce. And yeah, this is also technically my first Woo Product Chat for Do the Woo. I’ve done a few podcasts for Do the Woo around stuff that we’re doing at WooCommerce, and they’ve now shifted over to the Inside Woo podcast. So here we really want to focus on product a lot more and just topics around working on products and things like that.

So today we have a special guest, whom I’m sure many of you in the WooCommerce community know—and even Shopify now—Bryce Adams of Metorik, and I’m pretty sure I said that right.

Bryce:
Perfect. Yeah, thank you so much for the intro, James. Yeah, you pronounced it perfectly. That’s who I am. I’ve been working with Woo, I suppose, for 10 years now, almost 10 years or something, or maybe more than that.

James:
That’s right.

Bryce:
Yeah, worked out well. That was really fun. I joined Automattic as part of that and then went out to do Metorik back in 2016—so almost 10 years ago or almost nine years ago. And I’ve been doing that since. And yeah, I really enjoy thinking about product, talking about product, so I appreciate the invite.

James:
Yeah, no worries. I think we connected pretty early on in your journey.

Bryce:
Well…

James:
Yeah, exactly. I think we were both on our own journeys then. Matt, I think, had just started Iconic at the time. I had some plugins, but I’d kind of officially rebranded as Iconic. And yeah, we got in touch, and it’s always been pretty useful talking to you.

Bryce:
Oh, no, I’ve enjoyed it. I mean, I remember talking with you about Setary back in the day—the SaaS product you were working on—and it was really fun to kind of share some of the experiences I’ve had doing a Woo SaaS with someone who was also building that. And yeah, pretty cool to see it grow over the years.

James:
Yeah, it’s not mine anymore, but I handed it over to a friend that was working on it as well. And yeah, it’s a cool product. It’s advancing since I left it. That’s good.

Katie, do you want to dive into one of our topics or set the scene for what our topic is?

Katie:
Yeah, so each time we’re going to be talking about a particular topic that is relevant to WordPress product owners. So we thought we would start with feature creep because that affects everybody. What is the scope of your products, and when is it appropriate to add a feature and grow your product? And when should you say no and stay focused?

So, Bryce, why do you think this is such a challenge that causes problems for WordPress product developers?

Bryce:
Well, I think as developers, we are very tempted by new shiny things, and that even applies to features that we won’t even use—the features we’re building for people. I think you get that dopamine rush from making something new, and sometimes that extends to why so many founders end up becoming serial founders and creating multiple companies or multiple products—because they’re addicted to that rush you get from putting something new out in the world.

Iterating is a lot, I find, more rewarding, but it’s harder, and you don’t get that instant rush. So I think that’s why we see so much feature creep, because it’s kind of like a developer scratching their own itch, and it becomes a cycle where they just keep doing it and stop actually taking care of the features that they’ve built.

James:
I think it can be a bit more than that as well. Once you’ve got some adoption and you have a customer that comes forward and says, “Oh, I wish it did this,” if the feature seems exciting to you, it’s hard to just say no—even though only one customer has asked for it.

Bryce:
Yeah, because it’s possible as well. I think the thrill of it, especially once it’s your own product…

James:
Yeah, maybe that is a good idea.

Bryce:
Why not?

Katie:
Yeah, I see that all the time. Particularly when founders are doing customer support, they’re too close to it, and so they just want to help that one customer. If you have support that creates a layer between it, that protects you from yourself.

Bryce:
That’s a pretty good lesson. Well, I think it also helps if support engineers are the ones ultimately seeing the frequency of a request. As a founder, you might just see that one request and say, “Oh, we should just do that,” but you didn’t see the three other requests that were ignored that were similar and could have also been solved with that time. So it didn’t end up being the most effective problem to solve.

James:
How do you handle that? I assume you have support agents that filter your requests as they come in?

Bryce:
Yeah, for sure. Our team is small—there are five of us, including me, working on the product in that way. We all have that role of support. It’s not like a specific person’s role. Some end up doing it more than others, depending on the week or if someone’s away. But ultimately, support is probably the first priority in any of our roles, and then everything else kind of feeds down through that.

I think that’s a dangerous way to do it, though. If you take Katie’s example—I mean, I’m doing support, and some days I’ll see a ticket come in and just build the feature and ship it straight away. I don’t even stop to think, “Could this have repercussions?” or “Is this the best use of my time today?” It’s probably more that than the repercussions. I think small features in themselves don’t always create bigger problems, but they do take away your time. Even if it’s just an hour or two, it’s time that perhaps wasn’t spent on the most effective thing you could have been doing.

So that’s a risk. But with five of us, I think we manage to work well together. If we see an issue, we try to have a process. For us, it’s Linear. We’ve used probably every other issue/task-tracking app before, but we’re now on Linear and really enjoying it since it’s so developer- and product-focused.

Bryce:
We’ll go in there and create an issue—any one of us—and that’s after we’ve already talked to each other in the support ticket to actually clarify: is there something here, or is this just an issue that can be solved with support? Because if we can just solve the issue by having a conversation with the customer or potentially giving them advice on how to fix something on their end—or fixing something on our end—we can save that whole development process. And that’s always an ideal outcome for me.

I think I’m trying to treat support as solving things through support, not rushing to just get the tools out and start hacking away at it to try to solve it that way.

But yeah, if it does become an issue—

James:
Sorry, I was just going to say, if it does become an issue and you do end up getting it into Linear, does it go into a triage status? So if anyone else goes in to create that issue, it’s there, or they’ll search for it and find it somewhere else?

Bryce:
Yeah, exactly. That kind of gives us an opportunity to have all the new issues surface, but then decide which ones we tackle based on frequency, ease, or what else we’ve got going on.

James:
Is that a private system, so it’s not public-facing?

Bryce:
Yeah, no, completely private. And I think—I’ve seen that open roadmap kind of approach or open ideas forums. I used one at one point, maybe six or seven years ago, where people could submit feature requests and then see them publicly. And I think there’s so much benefit to doing that, but when it comes to day-to-day bug fixing or working on some core feature, I want to do that in privacy.

Also, I feel like I don’t want my customers to be too concerned with my priorities because they only have a view into what they need, whereas we have a view into what everyone needs.

James:
That makes sense.

Katie:
Yeah, that’s true. At Barn2, we have a private feature request list, which is very large for each product, but I do use that all the time to prioritize what features to build. So I look at—not just the number of votes—but also the difficulty and the impact. We have a formula. It’s just a spreadsheet. The team hates it; they would rather use a public feature request board.

But I actually believe that feature requests are kind of commercially sensitive information because—

Bryce:
So true.

Katie:
If a competitor knows that you’ve got lots of feature requests for a particular thing, and you don’t have the capacity to build it yet, that might sit there for a while. I don’t want the competitors to know and copy that.

But James, I suspect you have a different view on this because you used to have a feature request plugin, which made it public.

James:
Yeah, I was going to say—speaking of founders building too many tools—I built a feature request plugin specifically while I was running Iconic, which was a WooCommerce plugin shop. I wanted a place to collect feature requests and somewhere to be able to guide people and say, “Go here to submit a feature request.”

And then also—this was probably before we had many support people, I think it was maybe just me and another developer—we just wanted a place to store those feature requests.

I do agree with you regarding the public aspect. If a feature sits there for ages, then it does become data for some competitor to build out that feature into their product.

Honestly, WooCommerce itself used to have an ideas board, and I would scan that to see—

Bryce:
It used to be a great place for product ideas.

Katie:
Oh, I built plugins from that. Yeah, our first plugin was from that.

Bryce:
Yeah. That was even the case back in the day before Automattic, where some of us at Woo would build plugins on the side, and we’d get ideas from there as well. If it wasn’t a priority for the company, it made sense for someone else to build it so that people could actually get it.

James:
And that disappeared—I’m not sure when—maybe a year or so ago? There is a feature request board still for WooCommerce, but it’s not as easy to find. But it does exist.

Bryce:
Well, and on that note, we have the same thing in our app. If you’re logged in and you’re in the app, we have a roadmap section, which we’re not directing a lot of attention to, but we hope that if people are wondering what the big things are that we’re going to work on, they can see it there.

Because a lot of times, it’s not out of a place of “I need this,” but rather “this would be cool.” And you do want to support that desire in customers. That feature might come one day, if it’s something you might do.

It’s good to help them with their planning because they might not need it immediately, but they might want it in six months or a year, and it’s nice to know it’s coming.

James:
Yeah, we’ve been discussing something similar at WooCommerce because we don’t really have a public roadmap of things that we’re working on or things that are coming up. It’s one of my goals this year to get something like that available.

But I don’t think it will be a typical roadmap with dates of when things are coming—maybe it will be—but more of an open vision of “these are the things we’re working on this year,” without the pressure and disappointment of deadlines that probably won’t get hit.

Bryce:
But that’s also useful—not just to users, but also to the developers that build on Woo. They can start to get an idea of, “Okay, Woo’s going to work on this feature. I might give that a pass,” or “They’re going to build this—this could be a product I could build that would enhance that feature.”

And then that roadmap starts to even really benefit customers later when they’re using extensions built for products that Woo is working on.

James:
For sure.

Katie:
That’s true. At Barn2, we have a private feature request list, but I do use that all the time to prioritize what features to build. I look at—it’s not just the number of votes, but also the difficulty and the impact.

We have a formula, and it’s just a spreadsheet. The team hates it. They would rather use a public feature request board. But I actually believe that feature requests are kind of commercially sensitive information.

Bryce:
So true.

Katie:
If a competitor knows that you’ve got lots of feature requests for a particular thing, and you don’t have the capacity to build it yet, that might sit there for a while. I don’t want the competitors to know and copy that.

James:
Yeah, I was going to say, speaking of founders building too many tools, I built a feature request plugin specifically while I was running Iconic, which was a WooCommerce plugin shop. I wanted a place to collect feature requests and somewhere to be able to guide people and say, “Go here to submit a feature request.”

And then also—this was probably before we had many support people, I think it was maybe just me and another developer—we just wanted a place to store those feature requests.

I do agree with you regarding the public aspect. If a feature sits there for ages, then it does become data for some competitor to build out that feature into their product.

Honestly, WooCommerce itself used to have an ideas board, and I would scan that to see—

Bryce:
It used to be a great place for product ideas.

Katie:
Oh, I built plugins from that. Yeah, our first plugin was from that.

Bryce:
Yeah. That was even the case back in the day before Automattic, where some of us at Woo would build plugins on the side, and we’d get ideas from there as well. If it wasn’t a priority for the company, it made sense for someone else to build it so that people could actually get it.

James:
And that disappeared—I’m not sure when—maybe a year or so ago? There is a feature request board still for WooCommerce, but it’s not as easy to find. But it does exist.

Bryce:
Well, and on that note, we have the same thing in our app. If you’re logged in and you’re in the app, we have a roadmap section, which we’re not directing a lot of attention to, but we hope that if people are wondering what the big things are that we’re going to work on, they can see it there.

Because a lot of times, it’s not out of a place of “I need this,” but rather “this would be cool.” And you do want to support that desire in customers. That feature might come one day, if it’s something you might do.

It’s good to help them with their planning because they might not need it immediately, but they might want it in six months or a year, and it’s nice to know it’s coming.

James:
Yeah, we’ve been discussing something similar at WooCommerce because we don’t really have a public roadmap of things that we’re working on or things that are coming up. It’s one of my goals this year to get something like that available.

But I don’t think it will be a typical roadmap with dates of when things are coming—maybe it will be—but more of an open vision of “these are the things we’re working on this year,” without the pressure and disappointment of deadlines that probably won’t get hit.

Bryce:
But that’s also useful—not just to users, but also to the developers that build on Woo. They can start to get an idea of, “Okay, Woo’s going to work on this feature. I might give that a pass,” or “They’re going to build this—this could be a product I could build that would enhance that feature.”

And then that roadmap starts to even really benefit customers later when they’re using extensions built for products that Woo is working on.

James:
For sure.

Katie:
So, James, I think this is an interesting topic for WooCommerce at the moment because your actual role right now is largely to increase the scope of the core product, isn’t it? With the “More in Core” initiative and everything?

So how are you navigating those decisions, given that you’re meant to be enlarging it, but obviously don’t want to go crazy with it?

James:
Yeah, it’s a tricky one, and obviously everyone has opinions on what should and shouldn’t be in core.

I think our goal is that core—this is core WooCommerce, not core WordPress—should serve the majority of users and specifically the target users that we are focusing on. And I think that’s the driving factor of what we choose to roll into core.

So, if anyone’s not aware, what we’re looking at is a lot of our premium plugins that currently, if you want back-in-stock notifications, for example, you have to pay for an extension to get that, or shipment tracking and things like that, which are fairly minimal but essential features.

And those are the kinds of features that we’re looking to roll into core—just to have that base offering and then allow people to extend on top of that.

Bryce:
Yeah, well, I think—

James:
Go on.

Bryce:
Just using brands as an example, where you’re bringing that into core as a plugin.

We found—being a SaaS—that with the WooCommerce stores we were working with, 40–50% (I don’t remember the exact number, but a large majority) were using the brands plugin on their site.

We noticed that because people were asking for brand-related features or reporting, and this is going back several years now, but we confirmed it with the data—the majority of customers did use the brands plugin and had that data.

So it made sense for us to build a feature on top of that, and that’s been really useful to stores. But we wouldn’t have done it if it was only used by 5 or 10% of stores.

But the advantage when you bring that into core is that maybe that number becomes 70 or 80% or more, and other products can extend it and help benefit the core user as well.

James:
Yeah, and I think that’s one of the key things to consider. It kind of goes back to your weight of goods scenario.

WooCommerce can serve so many different types of businesses that we don’t want to merge very specific, niche features into core.

So yeah, the process is actually similar to what you were saying, Katie, with a formula-based spreadsheet as a guiding factor.

I’m looking at the usage data of each of our owned plugins in the marketplace and also adding to that list features that we don’t have plugins for—like sequential order IDs and MPN numbers. Recently we did GTIN numbers as part of the product data.

So things like that also go into this spreadsheet that I’m looking at, along with usage data for our target customer, but also across the board—versus how many stores there are and how many stores are actually using these plugins.

Of course, we take revenue into consideration for some of those plugins. Competitor analysis is part of that equation.

If every competitor has it in their core offering and we don’t, then I think that’s a good signal that we probably should.

And then on top of that, we consider some manual data points—how complex is the support for this product? What kind of impact will this have on merchants? How happy will they be if we implement this feature?

All that kind of stuff eventually gives me a priority score to use as a basis. I think there’ll be some cases where there’s maybe a plugin that’s got high priority, but it just wouldn’t make sense in core.

And I think there’s a bit of a gut check at that point. But yeah, that’s an example.

Bryce:
Yeah, like subscriptions or something along those lines?

James:
Yeah, subscriptions, product add-ons is in the list. Bundling—bundles—I think could be a core thing, but I’m not convinced about it.

Bryce:
Yeah, it’s interesting. Where do you draw the line? It’s so different.

James:
I mean, bundles—we already kind of have them.

Bryce:
Yeah, and I think maybe it’s a light version of those features where someone can get value out of it. But if you want to take it to the extra level with customizing it and having mix-and-match pricing and custom options, that’s where I think you have to think: is this core, or is this a plugin?

And to everyone’s benefit—because if it’s part of the core product and it’s free, it’s going to get limited attention. You can’t have a developer working on it full-time if it doesn’t make any money.

James:
Yeah, exactly.

Bryce:
On that specific feature, it’s not going to be viable.

James:
Yeah, I think the tricky thing at this point is navigating the third-party extensions that maybe already offer these features.

And I think, like you said, anything we put in will probably be a light version. It won’t be advanced, niche functionality, but it will be the basics that will serve 80% of the target customer.

And then the goal, in my mind, is that—coming from being a third-party developer, I know it’s not as easy as it sounds—but that those developers would then base their plugins on top of the core functionality.

But we’re also implementing ways to turn off certain features. So, for example, brands—you can turn that off.

But I think there’s kind of a dilemma around that. Do we want it to be able to be turned off, or should we be more opinionated and say, “This is the way you have to do it”?

Bryce:
Well, it’s WordPress, so you’ll never have the final say. There’s always a way.

Katie:
And you’ve got backward compatibility problems.

If WooCommerce were just being launched now, then fine—put brands in. If you don’t use that taxonomy, that’s up to you. But people might have to disable it if there’s a conflict with the slug, for example, and things like that.

James:
Yeah, exactly.

Bryce:
Which has been coming up.

Katie:
I’ve seen that in the last day or so.

Bryce:
But I think ultimately, that’s on the developers that are building products around it. They need to try to embrace it and not fight it.

And I’m thinking—with our integration with brands in the past, it worked with the brands plugin, the official one. Then there were some other third parties making popular brands plugins, so we made sure ours worked with those.

Then brands were brought into core, so we added support for that. Then someone said, “Well, I just want to send an attribute called ‘brand’ on the product.” So we added support for that.

As a developer extending these products, you shouldn’t be too opinionated on what the right way to do something is. I think you have to adapt, because that’s how you help your customers at the end of the day.

James:
And I think that’s the risk of building on top of a platform like WordPress. There’s always going to be a risk that whatever you build could be put into core in some way.

But yeah, I think there’s probably some messaging around this—specifically, talking about this brands issue, where there have been some slug conflicts.

I think maybe we should be encouraging third-party developers a bit more to use the test releases and check that everything works, and come to us with issues before it’s fully rolled out.

We could probably be a bit more proactive about that. I think we do release announcements when those updates go out, but I’m not sure that we directly email marketplace vendors, for example. Maybe we could.

Bryce:
It’s like you almost need someone to play devil’s advocate and just sit there and think, “What could go wrong with this? What part of this could backfire?”

James:
And I mean, that did happen. So brands, specifically, was tested against all of the most popular brands plugins.

But there’s always going to be things that you miss when it’s rolled out at the scale that it’s rolled out.

Bryce:
And ultimately, some blame has to be placed on both the developer and Woo in that situation, because the developer could have tested it.

And we will try to test things when we see the announcements on the Woo blog, but we’ll also sometimes miss something.

And if the announcement was there and we missed it, I can be bothered by it, but I can also look at how to not let that happen again.

And it’s very clear: read the announcement, test it, implement it. Otherwise, you’ve got to deal with the consequences of that.

Katie:
And that’s a pretty obvious one, isn’t it? They are literally building the same thing into core. That’s not something someone who owns a brands plugin is likely to miss.

And there was notice of it in advance, wasn’t there?

James:
Yeah. Yeah. But I mean, I think there are definitely issues that crop up once something like that is rolled out at scale.

So it did have a phased rollout, actually. Brands, I think, were rolled out to 10% of users first, then 50%, and then 100%.

Bryce:
That’s awesome. And that’s an improvement in itself—doing it in those incremental ways and trying to catch things.

Even if it doesn’t work, at least you’re going about a better process to do it.

James:
Yeah, for sure.

So yeah, my method is experimental at the moment. But yeah—

And I guess part of that method as well will be when I and the team have an idea of, “Okay, these are the features that we want to roll in,” I would likely take that to some sort of public platform to get feedback on it before we do anything.

And yeah, I think that’s important.

Like I said, I think there’s always going to be a split of opinions, and I think you have to figure out how to take those opinions on board and validate the correct ones, which is tricky to navigate.

Bryce:
Well, the ones that also fit with your goals as an organization over the next few years.

James:
Yes.

Bryce:
Yeah, often a feature helps one person in one moment, but you, as the builder of that feature, have to live with the consequences of that decision forever.

And I’ve got features that I find I added six years ago for one customer, and they’ve long gone. They canceled three years ago, and that feature isn’t being used by anyone.

And you wonder—it’s like you gave birth to something that you have to keep taking care of, and they’ve just abandoned it. They’ve stopped paying. It’s your responsibility now.

James:
Agreed. Well, yeah, it’s been awesome having you on, Bryce.

Bryce:
Thanks for having me.

James:
Hopefully, you can join us for another one at some point in the future.

Bryce:
Yeah, I would love to.

James:
Yeah, that’d be awesome. Cool. Well, thanks, everyone. See you next time.

Katie:
Bye.

Bryce:
Thank you.