Radical Speed Month: What Shipped and What’s Next

James Kemp:
Welcome to Do the Woo, the podcast where we talk about all things WooCommerce. I’m James Kemp, the core product manager for WooCommerce.

Katie Keith:
I’m Katie Keith from Barn2. And today we’re going to be talking about Radical Speed Month, which just takes place well across automatic and also at Woo.

James Kemp:
Yeah. And it’s a bit of a different session today because it’s just us two. Right.

Katie Keith:
Well, that is because I’m afraid you were the perfect guest. So we didn’t need a guest because, you know all things that happen at Woo.

James Kemp:
Yeah, I have all the ins and outs. Before we dive in. If you have any questions and you’re watching live, feel free to ask in whatever channel you’re watching it on, we’ll try and answer them. And yeah, yeah.

Katie Keith:
And if you don’t already follow us, then please follow us or subscribe wherever you’re watching this. So you can follow us on YouTube at Do the Woo podcast on X at DotheWoo. And all the places you can follow us are on our website, dothewoo.com so make sure you do that so that you don’t miss on future episodes. Now let’s get started. So I think the first thing we should talk about is what. What was Radical Speed Month? For anybody who hasn’t heard, to me it sounds something like to do with drugs. Did you all just get a high all month?

James Kemp:
No, we didn’t. High on code, I guess, is what we did.

Katie Keith:
Okay.

James Kemp:
Yeah. It was kind of a surprise initiative. And the concept was that essentially every single person in the company, apart from some select people that were, you know, maintaining vital things that had to be maintained for the month, were asked to pair up into teams and essentially work on anything that they wanted. And really, it was a way to experiment with being able to ship fast, you know, not. Not having any blockages or processes that you normally have to go through to get code out there or to get a project out there, but also to utilize AI as like a core principle and really focus on what’s possible now with just a very small team. So we were restricted to two people. If we wanted any more than that, we kind of had to put a pitch together and explain why we needed more than two people. And we were also, for the most part, restricted to just focusing on one project. You may have seen some posts that I put out right when it started where I was focusing on two things, one of which was the Variations project, and one of them was focusing on product add ons. One of our extensions um, and I kind of over time realized that, okay, if I want, you know, one of these things to be really good, it’s going to be better to, to focus on just one thing. Um, so we had, I think, I want to say, just over 700 pairs of projects.

Katie Keith:
Specifically or automatic?

James Kemp:
No, automatic. Wide. Yeah, this was an automatic wide initiative. Woo had, let me just have a look. 174 woo projects in the four weeks. And as the name implies, it was an experiment that we were going to run for one month and it was very fun. It was great to be able to just take any idea and kind of roll with it. Um, and one of the, the main things was that you were able to ship it and then it was kind of your responsibility to make sure that what you’re shipping is good and valuable and, you know, that you’re able to sort of consider the impact that it might have as a, as a small team. Um, so we had people who maybe focused on our existing products and worked on projects related to them, but we also had people that, you know, spun up projects that were completely unrelated to anything that Automatic works on, you know, out completely outside of WordPress even. But yeah, we can dive into some of them.

Katie Keith:
Yeah, I’m more, I’m interested initially in how the decision making process works. So did it have to align with strategic priorities? Did you have complete free rein?

James Kemp:
We had complete free rein. I think the concept was that it gives you the ability to decide what you feel is important or, yeah, I think decide what you feel is important. And that could be, you know, something that would have significant business impact for whatever, you know, project you’re working on, but also could be used as like a learning tool and just a way to experiment with different ways of working that we’re not normally used to. And I think one of the big things was that not everyone is an engineer or was paired with an engineer. So people were able to use AI in ways that maybe they’re not usually doing in their normal role. And I think that made it quite interesting. I think ultimately the ideas that are maybe going to continue are the ones that would have some sort of impact on either the business or the customer, whoever the customer might be. But yeah, I think there was many different approaches to the projects that people experimented with. And some people would like, start a project and finish it in a week and then move on to another project, but it was always, you know, one project at a time. So that was interesting.

Katie Keith:
Okay, yeah, let’s have some examples then. I’m interested in kind of different examples, some that were with engineers, some that weren’t, and how that could be productive and even something a bit more radical. So let’s go through a few examples.

James Kemp:
Yeah, I have a bunch of examples for WooCommerce. I think one of the examples that wasn’t WooCommerce related was the. And this was shown in the keynote at WordCamp. The desktop mode for WordPress is quite a radical concept for how WordPress could work. It works as a plugin on top of, you know, WordPress, and it kind of converts it to this desktop OS mode. And that’s quite impressive to ship something that works that well and is that, you know, fleshed out and that complicated in. I was gonna say four weeks, but I think it was even, you know, ready to go before that. So that’s one example of something that was still, you know, WordPress adjacent. The things that I am most aware of are the WooCommerce projects that came through. And we’ve actually been spending some time kind of grouping those projects now and figuring out what to do with them now and how we can either roll them into the product or keep experimenting with them. So some of the ones I’m going to try and see if there’s any that are a little bit different one comes to mind. And it’s like. It’s like a pinata moment where you

Katie Keith:
just crash everything with a stick, pretty much. Okay.

James Kemp:
So the concept was to bring small moments of genuine delight to WooCommerce and sort of showing up all about kind of the celebratory moments and small sprinkles and excitement throughout the WooCommerce experience. So they. They celebrated ordinary moments. And another project adjacent to that was one that was called Woo Sprinkles, which was kind of sprinkling a bit of UI design and refresh throughout the. The admin of WooCommerce, which was pretty cool. There was quite a few. There was a lot of work done on the order management page, and it was things like refining, you know, the width of the order management page, which by default is just the full width of the. Of the window, kind of moving some of the primary actions into. Into better view and then like, UI tweaks that just kind of modernize the existing experience a bit more, which was quite nice. That was one of our designers. Um, I’m not sure who she was partnered with, but that was cool. Um, you might have seen Beau, who is our artistic director for WooCommerce, shared some explorations around the navigation for WooCommerce So the left hand navigation, um, he was experimenting with what a, an E commerce focused mode would look like essentially. So you kind of click, you know, WooCommerce is the top level item and then you click into that and you get a very focused navigation that has only E commerce adjacent menu items. And it’s, it’s like a step to navigation, which is something I’ve heard quite a few people talking about. It came up at Checkout Summit. A couple of people mentioned it at WordCamp Europe as well. Not specifically Bose Exploration, but just that concept in general of essentially an E commerce mode, which I, I think could be pretty interesting. I think that is something that, you know, the merchant experience would be enhanced. I think I like the concept of them being able to choose what’s most important to them and you know, maybe different users of the website have different needs. I don’t know whether that’s a WordPress level thing or a WooCommerce something that, that we can at least do on the E commerce side. One of the projects that I shared before, so I shared this is the project that myself and Polly were working on and it was an exploration around how we could improve the variations experience. So currently the experience is a bit rough. I don’t think it’s changed much over its lifetime. In WooCommerce. It’s one of the experiences that many merchants and users complain about the most. You know, the process of dealing with large numbers of variations and even smaller numbers is still, you know, quite a complicated experience. It’s not, it’s not great. You have to configure your attributes, you know, define them as attributes used for variations and then switch over to the variations tab. You kind of have to save in between. And it’s quite a convoluted process. So myself and Polly spent a lot of time trying to figure out how we can improve that process and make it more usable for, for merchants and non technical people to set up, but also more of a flow that takes you through the process. So one of the first things we did was to move the attribute configuration into the variations tab. So this is attributes specifically used for variations. So you could say, okay, I want my product to have theme options and I want them to have color options so you can kind of add them here. And one of the things that you could do that you can’t do currently in WooCommerce is to create a new attribute and it would allow you to create a global attribute so you can create local attributes, which in my opinion is not A great type of attribute to lead with. I think typically, especially for variations, it’s a better experience to have global attributes because you can filter, you know, on the front end as a customer, you can filter and they’re also reusable across products.

Katie Keith:
Yeah, totally agree. The number of support tickets we get from people using say, our product filters or product table plugins, they don’t understand why their variations or attributes aren’t working in the filters or whatever. And it’s because they’re product specific and they don’t know there’s a difference. And it’s a big job for them to then go and recreate them all under product attributes. So that’s good. They can’t get it wrong if it’s right there.

James Kemp:
Yeah. And I, I even discussed the idea of just not having local attributes at all in, in this variations experience because there’s really not much benefit. There was a few people that said, okay, we, we have essentially attributes that are unique to every product. I have no examples for that, but I guess similar to like an SKU type code that belongs to just that product.

Katie Keith:
Yeah, that does happen. But does it matter if they’re added globally?

James Kemp:
The only reason they didn’t want to do that is if they have thousands. And then it becomes quite messy to manage, you know, those attributes. But I’m not 100% sure. There was, you know, one merchant that uses them in particular that was very keen to maintain them. But the other thing I’m not sure on, and I would need to kind of find out a bit more, is whether that is, I expect that’s more of like the product level attribute and not attributes that are used for variations.

Katie Keith:
Like it could be used for variations as well if there’s one product that’s very distinct from the rest or something.

James Kemp:
Yeah, true.

Katie Keith:
But then if you think about an attribute is just a taxonomy and there’s Nowhere else in WordPress where you can add taxonomy terms that are only available to one, let’s say post like tags or whatever. So you might add tags that only apply to one post and that’s not seen as a problem, is it, in WordPress?

James Kemp:
Yeah, that’s true. And I think it’s a bit more like a meta field. Right. Where you’re giving it a label and a value, but the value happens to be, you know, separated by pipes, which is also not very user friendly.

Katie Keith:
True.

James Kemp:
Which actually, you know, even if this isn’t a global attribute, at least we solve that issue as well. So you’ve got this kind of, you know, Pill type value field, which makes it a bit easier to deal with.

Katie Keith:
Yeah.

James Kemp:
So some improvements there. We kept the Attributes tab, like I say, for products level attributes that aren’t used for variations, there’s still some discussion as to whether we should show these variation attributes in the Attributes tab as well.

Katie Keith:
Yeah, people might expect that.

James Kemp:
Yeah. Especially, you know, if they have experience with it. So you would add the attributes and then you get this kind of summary of the attributes that have been added. So you can see that within the Variations tab. And then you can either generate variations or add variations manually. So the experience of generating variations in WooCommerce currently is it generates every single possible combination of attributes, and it does it in batches of 50. So you have to click continuously to generate until it’s created all of the variations for you. And that experience is not clear. Like, I don’t. I don’t think there’s anything that tells you have to do that. You just kind of have to figure it out for yourself.

Katie Keith:
I think it just pops up on the screen once it gets to 50 or something.

James Kemp:
Yeah, it says at the beginning, I think it’s limited to 50, but it doesn’t say, you know, run it again to generate the next 50.

Katie Keith:
Oh, that is confusing then.

James Kemp:
Yeah, yeah. So obviously we wanted to improve that experience, and one of the ways we were thinking about to do that is to allow the person setting it up to choose which attributes to use to actually create the variations. So in this example, if they select both theme and color, it’s going to create 15 separate variations. If they take away color, it will create five variations. So five of the five themes available in any color, the combination of using attributes to create variations becomes quite exponential because for every one you add, it’s a multiplier against everything else.

Katie Keith:
Yes, it’s always been like that. Yeah.

James Kemp:
So for this example, if every combination is selected, it’s going to create 1,200 variations, but as soon as you remove one, it drops it dramatically. And that makes the process of creating variations much better for the merchant because, okay, maybe, you know, size doesn’t affect the stock count or the image or the price, and they can kind of tweak this to get closer to the number of variations that they actually need without having to either create each one manually. Because creating, you know, 75 variations manually is going to take a lot of time. But creating 1,200 variations to get down to 75 is also going to take a lot of time. So by having this ability to choose which attributes actually Generate the variations makes that process much nicer for the merchant.

Katie Keith:
Okay, so if you did that and got it down to 75, how would they choose a size?

James Kemp:
So it’s exactly the same as the way WooCommerce works today. Currently, if you, you could create one variation and it could be, you know, any theme, any color, any size, any material. There’s, there’s one product that it narrows down to on the front end, but you, you’ve only got one variation to deal with. So it works in exactly the same way. And the, the whole data structure behind all of this is exactly the same as what it is today. The only difference is the ui. So once you’ve generated variations, you get this experience of Data Views. This is Data Views and Data Forms, which is the experience that we’ve talked a lot about in regards to the product editor. So Data Views is a nice table where now we can actually filter and search the variations so we can see all yellow ones. We can add filters for things like the attributes. Obviously pattern is one that we chose. Any, let’s see, color, we can say show all the blue ones. So the merchant can kind of group the variations like this and then they would be able to select all of them and bulk edit, you know, very specific selections of variations. So the, the bulk edit experience is also new in this and it, it’s reflecting a similar experience that another team was working on for the product list. So you know, the list of all your products once you click, I think it’s WooCommerce products. Right. So this experience is very, very similar to that and it adds a bit of consistency in the UI and the expectations and it’s pretty cool. You can do some nice stuff with, you know, price changes across the selected products. I don’t know if you can see, you probably can’t. So you can set new amounts, you can increase all prices by a specific amount. You can decrease, you can increase by percentage and decrease by percentage. So you can make all of these, you know, batch changes to variations in, in one go, which makes for a much nicer editing experience.

Katie Keith:
So what are we talking about then? Is this happening? Is it live? Is it in Q&A? Is it a proposal?

James Kemp:
So that particular work and also some other work is actually in. Will be in 10.9 behind a feature flag. Variations work is very much not ready that the code exists in core. The beginnings of the code exists in core. For that work specifically, the goal would be we want to have this kind of final vision of the future product editor. You know, we had the product editor experience that we shipped a few years ago. You may have seen that that’s now being. It was deprecated in 2024, but we’re now actually removing the code from the code base. As an aside, one of the reasons for that is because we found that when we were working with these AI agents on the code base, they were looking at that code as an example of, okay, this is how code should be done in WooCommerce and it definitely isn’t how code should be done. That’s the reason we stopped that project was because it diverted away from data forms and data views, which is the, the WordPress experience of those, you know, similar, you know, view table views and form fields. So, yeah, it was confusing AI agents, they were trying to use code from that quite a lot, which isn’t what we wanted. We want to understand what the future version of the product editor looks like. And we, the way I would like to do it is to have that future vision. Okay, this is, you know, what we’re aiming for, and then ship the smaller components of that over time. So we’re not saying, you know, we’re not spending a year redoing the whole editor, shipping it, and then creating a ton of headaches for people who extend it or integrate with it. But we would like to do it a bit more iteratively. So, okay, you know, in this release we’re updating the variations experience and that gives plugins time to extend it and work with it and, you know, gather feedback on that as well. So that would be the goal so one of the things we need to do now is to make sure that that project aligns with what the future version of the Editor looks like. And actually, one of the problems with Radical Speed Month is that the teams that were working on these different projects weren’t necessarily aligned with the. With each other, I guess, because we were very, you know, siloed in the work we were doing. So we found ourselves actually collaborating a lot with Veronica and Luigi, who were working on the product list experience, to make sure that we’re not duplicating work across those two screens, because they have very similar aspects. So I think that’s one area where the concept of working in teams of two without blockers, without these kind of input from anyone else, maybe won’t work unless we have some sort of final or expected vision. Like these are. This is the goal, these are the kind of components that you can use, which, you know, come from the shared design system. So there’s some challenges there that we. We need to figure out and align on before we can actually ship this thing. Because what. What I wouldn’t want to do for variation specifically is have a sort of middle state where we’ve got the. The classic experience, a new experience that is much better, but then is, you know, replaced by whatever the future experience is. We want to make sure that whatever we ship now is the same as what the future experience would be.

Katie Keith:
Yeah, and that makes sense about it fitting into a wider project context, because there’s been talk for many years about the entire edit product screen with the whole block editor thing and all of that and how that all fits together. So that does make sense. It’s not doing something now that’s just going to change later. But we’ve got feedback from Dave Lutz who says, love the new Variation ui.

James Kemp:
Yeah. One of the things we did, which was quite nice, was to. We met with quite a few people. It was, you know, Polly and I and whoever we were meeting with, and we just kind of let them explore this demo, which was a really nice way to figure out what worked and what they expected to happen as they were using it. And I think one of the things that multiple people got from the experience of RSM, to be a bit more public with the work that they’re working on, you know, ask for feedback, use prototypes to actually get feedback coming in before we’ve got, you know, too deep into the actual coding of it. So that was really cool.

Katie Keith:
Yeah, well, people have always liked that about your work because you often share things on X for consultation prior to anything actually being done. And people do like feeding back on that and feeling listened to.

James Kemp:
Yeah, exactly. I think there’s A tendency in software, maybe that’s going away a bit now, you know, to work on something and then talk about it when it’s done. And at that point it’s maybe a bit late. Um, especially with software that’s quite open, like, you know, the core of WooCommerce, the, the input of the people that build on top of it and you know, actually contribute to it is very valuable. Um, you know, we have this, we have access to hundreds and thousands of people that work with WooCommerce every day and it makes sense to, to get their feedback and their experience and also their experience of how their merchants and their clients actually work with the thing. So it’s a really nice way to stay grounded.

Katie Keith:
Yeah, that’s really helpful and valuable and not always easy to get. Unless you’ve got such a big user base as WooCommerce.

James Kemp:
Yeah, it’s really hard to get hold of merchants specifically. So having this like connection with agencies who have merchant clients, because unless they’re like mildly technical merchants, I found don’t really hang out online. Anywhere you can’t find them all in

Katie Keith:
one place is a challenge. I went to a talk at WordCamp Europe on Friday about market research and the importance of validating products ideas and feature ideas. And I came away thinking that’s going to be as much work as actually developing the thing and seeing if people like it. Because once people start using it and they feed back and you learn and new ideas come to you based on that. So I get the concept, but it’s not always easy to find people. So it’s good that we do have some opportunities to do that.

James Kemp:
Yeah, I mean, we have access to, you know, a number of merchants, but I think we don’t directly hear from them as, you know, someone working with them to actually configure their store and hear their pain points. So I think it’s good for the agencies and developers to connect us with the merchant because they have like, they can kind of translate their problems, the merchant’s problems, which is quite nice.

Katie Keith:
Yeah. And collate them based on multiple merchants that they work with.

James Kemp:
Yeah.

Katie Keith:
Okay. So I understand the variations thing is quite complex and will be done as more of a long term thing. I read a tweet by Brian Coords the other day saying that as a developer advocate, he’s preparing the release post for an upcoming release and he said there’s more in it than he’s ever had before to announce. So what is actually coming soon as a result of all this?

James Kemp:
Yeah, there’s A few things. I’m actually going to pull up Brian’s tweet because it’s probably the best.

Katie Keith:
I don’t remember if he actually said what was in it, just that there was a lot he might.

James Kemp:
I think he did. I think he listed it. He tweets a lot. Here we go. Uh, so, yeah, I, I would say most of the stuff that is coming is behind a feature flag.

Katie Keith:
What does that mean?

James Kemp:
Uh, it means if you go to WooCommerce settings, advanced features, it’s something that you can turn on or off.

Katie Keith:
I like the AI stuff.

James Kemp:
Yes. So by default it’s not on and if you want to try it out and experiment with it, you have to go turn it on. It is also possible to have feature flags that aren’t that don’t have a checkbox, like a toggle in that area and you would turn them on programmatically with like a filter essentially. Believe most of the things that he’s listed are coming as feature flag features, which gives us the ability to have people test it and see, you know, what the experience is like and find bugs. And one of the things we want to do is actually have like a life cycle of feature flags. So how it moves from an experimental feature into, you know, a beta release or like a slow rollout of some kind until it’s eventually rolled out to everyone. Sometimes we would roll it out to new stores only, like HPOS. So HPOS is actually still behind a feature flag as well. High performance order storage so that new stores get it and old stores or existing stores are able to turn it on if they want to. So there’s, there’s numerous ways to kind of deal with feature flags. I had a conversation at WordCamp actually. There was this concept of remote feature flags. So the ability for whoever, you know, implemented the feature flag to turn it on remotely to all stores. So similar to like a SaaS product, you could enable a feature without them having to update the plugin.

Katie Keith:
Wouldn’t people hate that because they want control over self hosted software and need as well?

James Kemp:
I think it depends what it is. It’s a good way to be able to experiment with sort of like a B testing, I guess. And you see tools like Shopify doing that quite a lot. I would say it would probably have to be something that they opt in to allow, you know, bleeding edge features that are enabled when we know that it’s stable. So I don’t think you would see us enabling experimental features, but it might be, you know, okay, this feature has passed A number of beta, you know, programs and is now ready to be rolled out. And maybe we’ve rolled it out to a specific segment more easily. But yeah, we don’t do that at the moment. At the moment it’s, it’s a feature flag and it is enabled if you enable it or if we’ve validated that. Okay. That that feature is ready to go, which is similar to cost of goods. And then we would just turn it on for everyone or whatever bracket of people that are most suited to it. So Brian’s post lists color swatches. So color Swatches are in 10.9 behind a feature flag and they belong to attributes and that is in the filters and also in the, in the product options block. So that’s pretty cool. I think it’s color and image swatches, a few sort of email notifications like abandoned car back in stock and review request emails. So the review request email is an email that can be turned on to send, you know, after seven days of someone purchasing something to request a review for that product.

Katie Keith:
Now you say it, it seems incredible. It’s not always been there because so many e commerce stores have that, don’t they?

James Kemp:
Yeah, I think it’s. It makes sense. Like in the lineup of emails we have some form of review functionality in WooCommerce. So why not, you know, try and encourage this, you know, aspect of social proof and just general feedback. Because reviews show up in, in Google as well, right?

Katie Keith:
Yeah. And actually it makes sense to make reviews better in Woo core because Shopify doesn’t even have reviews in Core. So that is a clear way that Woo is better than Shopify.

James Kemp:
Yeah, there’s going to be some work that we do on reviews at some point because they’re very much like glorified comments at the moment. It’s. It’s a comment field with stars that you can choose. So yeah, we’re definitely going to dig into that and see if we can improve that baseline. There’s the easy mobile app login and granular push notifications. Transactional email logging. This one’s quite cool. Variation image galleries and videos in product galleries. So that was one of our extensions in the marketplace that, you know, worked on. The more in core stuff was kind of flagged as something that, that should probably be in Core. So the ability to have more than one image assigned to a variation.

Katie Keith:
Didn’t even know that was a official extension. I only knew about Iconic’s plugin.

James Kemp:
Yeah, it’s. It was actually an extension when I was running Iconic. It. It Existed.

Katie Keith:
Um, you obviously marketed yours better.

James Kemp:
I did a very good job of marketing mine. I mean mine. My plugin was built in 2011 and was, was the most popular iconic plugin. So I think it kind of signifies that this maybe should have been available. Like eventually that plugin became more than just additional images.

Katie Keith:
But yeah, it had video and stuff in the gallery.

James Kemp:
Yeah, we had video and like gallery layouts and things like that. But yeah, like having more than one image on a variation just kind of makes sense. There’s the concept of wish lists and save for later that one of the teams was working on. This is the Woo Sprinkles where you’ve got major admin UI cleanup and a new settings ui, the modernized product catalog which is the work I was talking about with the product list and a bit of bulk editing in there as well. There’s a dual API and a dual rest API and GraphQL API which is something I need to dig in a bit more about. But it seems like a cool project. Better MCP and abilities for WooCommerce block based email editing improvements and performance improvements, including with checkout draft orders. I would probably say that all of that work was RSM work. Radical Speed month. Okay, so that’s a pretty cool batch of work to come out of, you know, one month that we maybe wouldn’t have seen, you know, without that.

Katie Keith:
Yeah, those are real features that will make a noticeable difference to WooCommerce stores. They’re not just tiny little tweaks, they’re proper features.

James Kemp:
Yeah, exactly. And like I said, it was 174 projects. So that’s, you know, some of the features that we worked on. Now that we’re kind of going back to normal, whatever normal looks like now, I expect there’ll be some shift in how we work on, you know, a more permanent basis to be a bit more agile, to be able to, you know, work together in smaller teams, I would hope slightly larger teams, you know, three to four people and actually ship things. But there’s going to be some work to assign the projects that were being worked on to the relevant product managers of the particular product areas and kind of prioritize and make sure that they don’t just end up disappearing. Because I think there’s some very cool stuff that was worked on. There was a few AI things which were worked on as well, kind of like in app chat experiences which were pretty cool. I’d love to see a bit more of them happening. But yeah, there’s tons of good stuff that was worked On I’m excited to kind of figure out which of those things can actually go into core. And I think like I said, one of the things we need to do is make sure there’s cohesion between those projects that we’re not duplicating efforts and you know, repeating or creating like different experiences in terms of UI and ux. But I guess that’s where the blockers start to come in and, you know, divert away from the expectation of Radical Speed month.

Katie Keith:
Yeah, so you mentioned about hoping it would become a more usual way of working. So, so what made speed possible that isn’t normally there? Like what was actually different so that so much could be get done, be achieved in such a short time?

James Kemp:
I think a few things. There were still some blockers and I’ll get to that. There was the concept of like anyone can do the work where normally we have our, you know, specific roles and we, we go through the process and the work goes down to an engineer or a designer and they implement the thing. So I think the allowance for anyone to be able to actually produce code or, you know, UI or UX, whether that was the actual code that’s, you know, added to the product or more of a prototype that can be, you know, adapted and turned into a actual thing. I think one of the blockers that we still had was once the work became a pr, like specifically for WooCommerce, we, we were allowed to just merge that stuff. You know, you should be responsible for whatever you’re merging. But a lot of it we felt needed still some like engineer input and human input. Like we don’t want to just rely on AI to produce code and hope that it, you know, works the same way that we would expect.

Katie Keith:
Let’s hope so. In a product as important as Wu,

James Kemp:
I think so I think there’s going to be an influx of, you know, AI based code. There already is an influx of AI codes that comes in, you know, from internal teams from contributors. And one of the challenges that we need to figure out is how, how do we review that with human capacity reliably. I think there needs to be some level of AI review that we can actually trust because at the moment it’s, there’s some like, logic to it in terms of our, or some context to it in terms of our code base. But there’s still like a level of distrust, I think between just allowing the AI to say, okay, yeah, I approve this change, let’s merge it. Pretty much everything that’s been reviewed has had an engineer review. It and, you know, flag things that the AI has missed, like, you know, backwards compatibility or extensibility or, you know, if, if the, if a designer wasn’t part of the project. Like, this design component is different to, you know, how we’re doing it over here. And there’s a lot of that context that not everyone has. So I think the smaller teams that we create, assuming it goes that way, I think they need to include, they need to cover the skill set of product design and engineering, whatever, you know, whether one person can cover multiple parts of that triad or whether there’s like an individual person for each of those areas. But I think like those core things need to be covered and that allows us to produce quality work and work that aligns with everything else as well as, like, the way we’re moving is very much more towards design system type work. So we’re reusing components rather than designing UIs per project. And I think that’s going to enable us to be more confident in the code that the AI is producing alongside, you know, whoever’s using that as their tool. And I think there’s, there’s some level of AI review that needs to happen to get it to a point where we can, you know, 80 to 90% trust it. And then the human has, they’re not as much of a blocker because they have, they trust, you know, the review that’s been done already and they’re just kind of signing it off and topping it up to the 100%. So I don’t know what that looks like at the moment.

Katie Keith:
Yeah, at Baan 2 we have a. Well, we only have one QA person, but his whole job is to do QA and he sets up automated tests. But a lot of it is manual checking and we haven’t seen a way to get rid of that. So do you have QAs at woo or does it always go to a fully qualified developer?

James Kemp:
I would say it probably goes mostly to the engineer for. Or like an engineer that is responsible for whatever area the code is, you know, based on. So we might have specific engineers that are experts in the checkout and cartoon. We might have engineers that are experts in the REST API or the store API. Yes, someone from one of those teams would be the person it goes to kind of quality check that code. I feel like their time is better spent actually, you know, creating the thing rather than reviewing them.

Katie Keith:
Well, this is why we created a dedicated role. Obviously it’s cost saving as well, because a QA person is a lower band than a senior developer. So it works really. And actually they’re better at the job in my experience. Feel free to shoot me online for this or whatever. Most developers are not good at testing, whereas a dedicated QA can often be much more methodical, knows exactly what tools to use to record and replicate and explain the issues, and generally does a better job of testing.

James Kemp:
That’s interesting. Yeah, I think one of the things that we do and that the AIs tend to pick up on is that most of the work that gets built comes with some sort of test as well. So the PR usually includes, you know, some, some code based test. But it’s definitely, I think there’s two aspects to reviews that slow things down. AI is great at creating PRs that have thousands of changes and for a human to review that takes a lot of time. Like they have to really think through every change that they’re seeing. And I think that’s the kind of thing that an AI could review and we could have some level of trust in. And we do have AIs that review that stuff already. But there’s still, I feel there’s still like a level of distrust. Like I wouldn’t just blindly say, okay, yeah, that’s perfect because we have a responsibility to everyone using WooCommerce, you know, and people are running their livelihoods on this platform. So we can’t, I believe, just ship code that we haven’t looked at.

Katie Keith:
Yeah, I think the distrust is entirely appropriate. AI is an additional tool for more robust testing.

James Kemp:
Yeah. So I think we’ll see some tooling that is AI based that helps us to improve that process or, you know, reduce the time that that process takes. And then the other side to it is like the actual manual testing that some of the work that comes through requires. And that’s kind of hard to again trust an AI to do. You know, you have tools like Ghost Inspector that, that do it and you can review that, which worked pretty well. Or play right now is the choice of AI tools or Claude Chrome. I guess we did a few experiments of whenever a PR is created, if the AI sees that this has a visual change or like a UI change, it would automate in a sandbox. Testing that and screenshotting it. One of our engineers, Svetan, created a tool that took a screenshot and then highlighted the specific thing in the screenshot, which was pretty cool because it, I guess if you trust that screenshot, I feel like a screenshot is more trustworthy than it just saying, yeah, it works

Katie Keith:
fine as long as a Human looks at it.

James Kemp:
Yeah, exactly. Even then though, I still feel like you would want to manually test it. Um, so maybe it’s just a case of getting those environments and like the, the configuration needed to test it more automated. So, yeah, those are, those are some of the challenges, I think, with, with the current way of working.

Katie Keith:
Yeah. Well, it sounds like a huge amount was achieved. It’s. It’ll be good to see those bits go live soon and other bits maybe more into the future now. I think we’ve covered it pretty comprehensively. Is there anything else you’d like to say about Reticle Speed month before we finish?

James Kemp:
Just that I think it was a great experience. I really like that we. It was like a month long hackathon essentially. It gave everyone an opportunity to use AI and explore AI and you know, the concept of a smaller team and partnering with someone, it gave everyone the opportunity to do that and express their ideas and, you know, get their ideas out there that maybe they don’t normally feel comfortable doing. And I think doing that is going to act as like a bit of a reset and a refresh in how we work. And I think that’s important right now. You know, the tooling that we use is changing on a weekly basis and I think it’s. It’s definitely a good experiment to have run and I’m kind of looking forward to seeing what the outcome is, the kind of long term outcome, and also whether it’s an experiment that we run again. I think all of the feedback I saw online because I feel like the people doing the projects in their pairs were very much doing it more in public. There was a lot of work that was shared, a lot of excitement around the work that was being shared. And I think if we can figure out how to do that reliably and cohesively, like that’s going to be very beneficial for a product like WooCommerce.

Katie Keith:
Yeah, well, as you well know, I get frustrated by large organizations moving slowly, which is normally the case. So I really like this concept of a large organization operating as a small one and taking some of the principles from the smaller ones, like the small teams thing you’ve mentioned and so on. So that could really help things to get done.

James Kemp:
Yeah, I think so. I agree.

Katie Keith:
Okay, so what have we got on the next episode?

James Kemp:
So in the next episode we’re joined by Tamara Neeson, who is the chief marketing officer of WooCommerce and we’re going to talk about how we can all work together to promote and grow WooCommerce more effectively. I believe that’s scheduled for 22 June at 4pm UK time.

Katie Keith:
I’m looking forward to that one because I’ve recently I did my checkout summit talk and then I published a blog post about how I think we should be promoting woo. So I’m looking forward to talking about that.

James Kemp:
Me too.

Katie Keith:
So if you don’t already follow us, then subscribe, follow etc YouTube with Do the Woo Podcast X we’re do the Woo and you can find all the places to follow us and previous episodes on do the Woo. Com. Thanks for watching. Bye.

James Kemp:
Thank you.