Designing WooCommerce Products Users Love

James:
Hi everyone. Welcome to another product chat with me and Katie, and our guest today is Jewel. We’re going to talk about user experience today and how we’re designing products that users love and taking a user experience-first approach. Katie, do you want to introduce yourself?

Katie:
Yep. So I’m Katie Keith, founder and CEO at Barn2 Plugins, and we sell a range of plugins for WordPress and mostly WooCommerce.

James:
Awesome. I didn’t introduce myself, but I am James Kemp. I am the core product manager at WooCommerce. And Jewel, do you want to introduce yourself?

Jewel:
Yeah, hi everyone. I run a company, WP Manage Ninja. We basically build business plugins for small businesses, and currently, we are powering over a million websites.

James:
That is an incredible statistic.

Katie:
That is incredible.

James:
Yeah, I’ve followed your work for a while. I think you’ve probably seen a few comments from me, but one of the things that stands out with primarily the Fluent range of products, which are the ones that I’ve used, is the design—just the UI and UX components of the design. It’s just very impressive. One of the best sets of designed products in the WordPress space, I would say. Thank you.

Katie:
Yeah. So before we get into how you achieve that, should we talk a bit about why it matters? So Jewel, why is that such a priority for you in your products?

Jewel:
So I think we did not actually take it as a priority or something. It actually comes naturally. One important thing is that we are heavy users of our own products. We use every product heavily. For some products, maybe we are the most advanced users. Take FluentCRM, for example—we use it every day. We run every email campaign with it. We manage our customers and everything. So when I use the product, I see, okay, this is taking too much time, it’s complicated, I can’t understand it, or my marketing team can’t understand it. They give feedback, and then we improve that experience. I think that helped us a lot. There are other factors we will discuss in the show, but that’s kind of the main vision—our product UX is great.

James:
That’s very cool. So you’re dogfooding, I guess—that’s the term, right? You’re using your own products and solving your own needs. I think something that would be useful to understand is—your overall company is WP Manage Ninja, right? That’s the company that makes products?

Jewel:
Yeah.

James:
What’s your role in that, and what are your most popular one or two products?

Jewel:
I’m the founder and CEO. My daily job—I love coding. I am a programmer. Over the last couple of years, my team has gotten really big. Now it’s around 100 to 120 people.

James:
Wow, wow.

Jewel:
But I love programming, so in the last couple of years, I built teams who can manage everyone—like team leads, departments, and everything. I have a CMO who manages our whole marketing team, a support head who manages our support department, and also a CTO—very experienced—and a VP of Engineering who actually handles day-to-day management. So mostly, when I get time, I try to code, I try to review commits, and everything. But most of the time, what I do is talk with our customers. Sometimes I hop into the customer ticketing system and see what users are doing. I get notifications from our customer support system, and I also check social media to see what people are saying about our product—whether it’s positive or negative feedback. I try to understand their pain points. My role isn’t necessarily about being the product owner, but more about how I can improve things, how I can save time. That’s kind of my day-to-day job.

Katie:
I really like that. First of all, you are your own users, so you see the pain points—that’s the best way to do it. But in addition to that, you’re getting feedback directly from your customers. It’s hard, isn’t it? You started off, I expect, on your own as the founder, then you grow, you hire people, and that naturally takes you away from the customer to some extent. So I really like that you try to stay hands-on with the customer because, of course, a lot of CEOs with growing teams wouldn’t do that. I know I have the same issue—I don’t do support on a daily basis like I used to, but I do enjoy it when I do sometimes. Also, I do a monthly live stream, which is a good way to hear from customers and what they want. And James, I think at Woo, you all do a week of support a year or something, don’t you?

James:
Yeah, we have what they call a support rotation. Typically, you block out a week, and you only work in support. That would be in Zendesk, which is what we use. You can focus on a specific area, which is quite nice. I did mine in December because I joined in December over a year ago. It lines up nicely—I can wind down a little bit with a week of support. But I’m also quite heavily active in GitHub discussions and on X, seeing what people are talking about regarding eCommerce and just generally asking questions and getting feedback.

Jewel:
Yeah, we are actually kind of inspired by Automattic in our onboarding process when we hire someone. They must work with our support team for two weeks—that’s part of the onboarding process so they can understand our products and how we build them. Another important thing is that most of our product managers come from the support team. They dictate which features we will develop in the next sprint, and they play a vital role in our quarterly product development meetings. That’s how we work here.

Each of our products is like its own startup. For example, Fluent Forms—that’s our biggest product, and we have a whole team dedicated to it. They don’t work on any other product. We have a support team, a marketing team, and a dev team. Those three departments form a small, focused team, and they manage everything. I have very little input—I just do a quarterly or monthly meeting with the team to check in. If I have an idea, I pass it to them, and they decide how to prioritize it.

We manage a lot of products—around eight or nine now. Back in 2019 or 2020, when we had a smaller team of 30-35 people, we tried having developers work across multiple products. The problem was that when a developer was working on one product, they would forget about the others, and the same happened with marketing. So we shifted to a dedicated team approach.

Now, when we build a new product, we form a team. First, we hire or reshuffle developers to build the product. Then we onboard marketing, and finally, once we launch, we onboard the support team. Each product operates like a startup. The advantage is that each team is deeply focused on its product without being distracted by others.

James:
Yeah, it’s funny you mentioned 38 people being a small team.

Katie:
Yeah, I smiled at that bit.

James:
My previous company worked in a similar way, but we were truly a small team—just four developers. Each of us was assigned a set of plugins. Automattic is similar—it’s the umbrella company, but each product has its own team. There’s some cross-collaboration, but primarily, those teams focus on specific products. One thing I noticed you didn’t mention is designers.

Jewel:
We’ve had a dedicated UX team for the last year and a half. Before that, we only had a UI designer. Initially, the developers handled UX, and the UI designer refined things. Then we realized we needed a proper UX team. Now, we have five people solely focused on UX for our plugins. Meanwhile, our UI team works only with our marketing team. That separation has really improved our latest products.

James:
That makes sense. I think one of the key things about Fluent products specifically is that you stray a little bit from default WordPress in terms of the admin experience, and with Fluent Community, in terms of the front-end experience as well, right? With Fluent Community, I assume that product was designed once you had this design team in place.

Jewel:
Yeah.

James:
Because that’s your newest product, right?

Jewel:
Yeah, it’s our newest product, exactly. So that’s why it’s more refined.

James:
Yeah. Well, I think there’s more design work involved in that product because the front-end is its own entire experience. When you came to approaching that product idea—

Jewel:
Okay, so actually, we built that product around two years ago. It’s another story, actually—it also involves Automattic. I think Automattic has a product that is one of their best, like P2, I think. You guys use that?

James:
P2? Yeah.

Jewel:
Yeah, exactly. So I was following P2 from the very beginning, I think back in 2018, 2019, or 2020—something like that. I really liked the idea. Everyone on the team is posting updates in one place. I was waiting for Automattic to make it open source so I could install it and integrate it with our other systems. We also have our own project management board, so we wanted to tie everything together. Our HR portal is also integrated into our own internal portal, so everything is web-based.

I was waiting for P2, but then Automattic started offering it as a SaaS service instead of making it open source. So I thought, okay, I need something simple—just like a Facebook group—but for my internal teams. Each team would have a space to post updates, and I could see everything based on roles.

So, we built that two years ago and used it internally. Then, last year, we decided to launch it as a product. That launch was a bit different—we wanted to do a beta testing phase with our existing customers. This is also a core part of how we build products—I believe we build products for our customers, not just for ourselves. That’s why we onboard them when we have an MVP.

We installed the software, created a space, and invited 20 to 30 people to try it and give feedback. The first thing they asked was, “What is this? I want to use this!” After five or six months, we had onboarded 500 people in that portal. We launched the product, and it was great.

That first version was about 90% of what Trello is. But after launching it, our customers started saying, “We need this!” They had similar use cases—they had coaching businesses and needed spaces for their students. There were alternatives like Circle or Skool, but those were SaaS services and really expensive for many small businesses. That’s when I thought, okay, maybe we can build this as a product.

At that time, our UX wasn’t great, and we didn’t have a dedicated team for it. Everything was just based on what my team needed. But then, our UX team worked on every screen and possible feature for six or seven months before we released the product last November.

James:
That’s interesting.

Jewel:
Yeah, and now over 2,000 businesses are using it. It was our most successful launch ever.

James:
That’s incredible for you. I think it’s quite interesting that a lot of your products were originally built for your own use and then refined based on customer feedback.

Jewel:
Exactly. We also have a support ticketing system product. One thing I really love is open source—I love self-hosting. For the last 15 years, I’ve only worked on open-source software. WordPress and all these open-source tools have allowed me to build a business, and I’m really grateful for that. That’s why I try to use open-source tools for my business as much as possible.

I’m not saying SaaS is bad, but that’s my personal choice. That’s why we built our own support ticketing system for our internal use. To be honest, it’s not the most practical thing for every business, but we loved it. We used it for about a year, and then we made it a product. Now, 10,000 businesses use it, and it has become a profitable product.

FluentCRM, our second fastest-growing product, has a similar story. We initially used MailChimp, but back then, we were still using EDD (Easy Digital Downloads). Synchronizing data between platforms was really hard for us.

We use a lot of data in our decision-making. Every time we run a campaign or release a new product, we use data to maximize our results. We want to know:

• Which customers use a specific product but not another?
• Which customers are happy or not happy?

If we have all our customer data in one place—support tickets, CRM, and sales—we can generate reports, write SQL queries, or build a UI to analyze the data. That’s why we initially built FluentCRM as an MVP—to send campaign emails. When we release an update, we notify customers and also upsell another product.

For example, when we released Fluent Community, we ran a campaign targeting FluentCRM users who hadn’t purchased Fluent Community yet. The conversion was great. So, every time we release a new update, we also generate new sales.

Katie:
Yeah, that’s good. When you have multiple products, you can cross-promote. We do something similar—three days after purchase, we send an email offering 50% off their next plugin. It converts well, and we suggest plugins that are complementary to what they purchased. There’s a lot of logic there, and I know how hard it can be to get the right data. We use EDD as well, and sometimes we don’t have the data we need, so we have to build custom solutions.

It’s also interesting that your UX team thinks from scratch—what’s the best possible interface for the customer? We take a different approach. We always start with WordPress and WooCommerce because those are familiar. Even if they don’t have the best UI, we follow them because our products are built for that ecosystem.

We don’t impose our own branding on our products—we try to match WordPress and WooCommerce. If a UI pattern exists in WordPress, we use it. If it doesn’t, we design something intuitive that still feels like WordPress. So, it’s a different approach—do you go for familiarity or the best possible experience?

Jewel:
Yeah, one reason we could take our approach is that our products are like applications within WordPress. Our plugins—Forms, CRM, Support, Community—are full applications. We get the whole UI frame to work with. But for you, Katie, your products live inside WooCommerce, so you have to match WooCommerce’s UI.

For us, we had more freedom. Our focus wasn’t on WordPress UI guidelines—we looked at how big SaaS companies design their products. We built our own design guidelines—color schemes, styles—so our products have a consistent look. It’s not the standard WordPress way, but it has worked for us.

James:
Yeah, that’s an interesting approach. It definitely makes your products stand out. Even though they run in WordPress, they feel distinct. That’s a nice way to put it—your products provide solutions that are separate but built into WordPress.

I think we’ve covered a lot of ground, and we’re coming up on time. Was there anything you wanted to add before we wrap up?

Jewel:
I think we’ve covered many things.

James:
Yeah, it’s been a great discussion. We’ve crossed paths before, but we’ve never really spent much time talking. It’s been great to connect with you. Hopefully, we can have you on again to discuss another topic. Until then, we’ll see you next time.

Katie:
Yeah, and thank you so much for coming on.