Radical Speed Month What Shipped and What’s Next

Radical Speed Month: What Shipped and What’s Next ![rw-book-cover](https://img.youtube.com/vi/YR1aWwygrxk/maxresdefault.jpg) 🔗 **Source:** [Radical Speed Month: What Shipped and What’s Next](https://www.youtube.com/watch?v=YR1aWwygrxk) > [!note]+ Document Notes > tags: [woocommerce, radical-speed-month, product-development] > author: [MISSING] > source: Do the Woo > reference: https://www.youtube.com/watch?v=YR1aWwygrxk > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Radical Speed Month: What Shipped and What's Next >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - **What happened**: Automattic ran "Radical Speed Month," a company-wide month-long experiment where 700+ pairs worked on any project they wanted, using AI as a core principle and focusing on rapid shipping without traditional blockers. - **Why it matters**: Generated 174 WooCommerce projects in 4 weeks, with many features now shipping in WooCommerce 10.9 behind feature flags, demonstrating how large organizations can operate like small, agile teams. - **Key stakeholders**: Automattic employees, WooCommerce merchants, plugin developers, and the broader WordPress ecosystem. - **Risks and tradeoffs**: Lack of coordination between teams created potential duplication and alignment issues; AI-generated code still requires human review for quality and security. - **Bottom line**: Successful experiment in rapid development that may reshape how Automattic approaches product development long-term, with significant features like variation improvements, color swatches, and email notifications now entering production. ## 📖 Main Content Radical Speed Month was Automattic's company-wide experiment in rapid product development, running for four weeks with over 700 project pairs across the organization. The concept removed traditional development blockers and emphasized small teams (restricted to 2 people), AI utilization, and fast shipping. ### Core Principles The initiative operated on complete creative freedom - teams could work on anything they wanted, whether related to existing Automattic products or entirely new concepts. The only constraints were team size (2 people maximum, with exceptions requiring justification) and focus (one project at a time per team). ### WooCommerce Results WooCommerce generated 174 projects during the month, with several major features now entering production in version 10.9 behind feature flags: **Immediate shipping features**: - Color and image swatches for product attributes - Email notifications (abandoned cart, back in stock, review requests) - Variation image galleries and video support - Wishlist and save-for-later functionality - Major admin UI cleanup ("Woo Sprinkles") - Modernized product catalog with bulk editing - Dual REST API and GraphQL API support - Performance improvements including checkout draft orders **Long-term development projects**: - Complete variations experience overhaul (demonstrated in the podcast) - E-commerce focused navigation mode - Block-based email editing improvements ### Variations Experience Redesign James Kemp and Polly's variations project represents the most comprehensive example of RSM output. The redesign addresses long-standing merchant pain points: **Current problems**: Convoluted process requiring attribute configuration, tab switching, mandatory saves, and batch generation of variations in groups of 50. **New approach**: - Unified interface combining attribute creation and variation management - Global attribute creation by default (solving filtering issues) - Selective variation generation (choose which attributes create combinations) - Data views integration with filtering, searching, and bulk editing - Advanced pricing controls (increase/decrease by amount or percentage) The system maintains WooCommerce's existing data structure while dramatically improving the user interface. ### AI Integration and Code Quality Teams heavily utilized AI for code generation, but human review remained essential. The experiment revealed both opportunities and challenges: **Opportunities**: Non-engineers could produce functional code; rapid prototyping became accessible to all team members. **Challenges**: AI agents sometimes referenced deprecated code as examples; large AI-generated PRs require significant human review time; trust levels for AI code review remain low for production systems. ## 🗒️ Notes #### ⏱️ [00:03:12](https://www.youtube.com/watch?v=YR1aWwygrxk?t=192) RSM Overview - Company-wide initiative, 700+ pairs across Automattic - 174 WooCommerce-specific projects in 4 weeks - Complete creative freedom with 2-person team limit - AI utilization as core principle - Focus on shipping without traditional blockers #### ⏱️ [00:15:30](https://www.youtube.com/watch?v=YR1aWwygrxk?t=930) Variations Project Deep Dive - Current experience: convoluted, requires tab switching, batch generation in 50s - New approach: unified interface, selective variation generation - Data views integration for filtering and bulk editing - Maintains existing data structure, improves UI dramatically - Addresses exponential combination problem (1,200 potential variations → 75 needed) #### ⏱️ [00:35:45](https://www.youtube.com/watch?v=YR1aWwygrxk?t=2145) Feature Flag Strategy - Most new features shipping behind feature flags in 10.9 - Allows experimentation and gradual rollout - Lifecycle from experimental → beta → full release - New stores vs. existing stores deployment strategies - Remote feature flag concept discussed but not implemented #### ⏱️ [00:42:20](https://www.youtube.com/watch?v=YR1aWwygrxk?t=2540) Shipping Features List - Color/image swatches, email notifications, variation galleries - Admin UI cleanup, modernized product catalog - Wishlist functionality, performance improvements - Dual API support, block-based email editing #### ⏱️ [00:48:15](https://www.youtube.com/watch?v=YR1aWwygrxk?t=2895) AI and Code Review Challenges - AI generates large PRs requiring extensive human review - Deprecated code confused AI agents about best practices - Trust levels for AI code review remain low - Need for AI-assisted review tools to reduce human bottlenecks - Screenshot-based testing automation experiments #### ⏱️ [00:52:30](https://www.youtube.com/watch?v=YR1aWwygrxk?t=3150) Future Working Methods - Hope for permanent shift to smaller, more agile teams - 3-4 person teams covering product/design/engineering triad - Design system approach for component reuse - Need for project coordination to avoid duplication - Balance between speed and quality/security requirements ## 📚 References - [WooCommerce 10.9 Release](https://woocommerce.com) - [Data Views and Data Forms](https://wordpress.org) - WordPress admin interface components - [Do the Woo Podcast](https://dothewoo.com) - [Brian Cords' Twitter/X](https://x.com) - Developer Advocate release announcements ## 🗣️ Paraphrase Automattic conducted an ambitious month-long experiment called Radical Speed Month, where the entire company was organized into pairs working on any project they chose, with the goal of shipping fast using AI tools and minimal bureaucratic oversight. This resulted in over 700 projects company-wide, with WooCommerce alone producing 174 projects. Many significant features are now shipping in WooCommerce 10.9, including long-requested capabilities like color swatches, improved email notifications, and enhanced variation management. The experiment demonstrated how large organizations can achieve startup-like agility while revealing the ongoing challenges of integrating AI-generated code into production systems. ## 📰 Newsletter 🚀 **Radical Speed at Scale: WooCommerce's Month-Long Innovation Sprint** Automattic just proved that big companies can move fast! Their "Radical Speed Month" experiment paired up 700+ people across the company to work on anything they wanted for 4 weeks straight. The result? 174 WooCommerce projects and a treasure trove of new features hitting 10.9. **What's shipping now**: Color swatches (finally!), smart email notifications, variation image galleries, and a completely redesigned variations experience that'll make your product setup actually enjoyable. Plus wishlist functionality and major admin UI improvements. **The secret sauce**: Small teams (2 people max), AI as a core tool, and permission to ship without the usual corporate gatekeeping. It's like giving your dev team startup superpowers while keeping enterprise stability. **For agencies**: These aren't just nice-to-haves—they're client problem-solvers. No more explaining why WooCommerce doesn't have review request emails or why variation setup is so clunky. The features launching behind feature flags means you can test early and stay ahead of client needs. **Links**: [Watch the full breakdown](https://www.youtube.com/watch?v=YR1aWwygrxk) • [Follow Do the Woo](https://dothewoo.com) for more insider insights ## ✅ Action Items #### WordPress - **Core**: Monitor feature flag lifecycle patterns from WooCommerce for potential WordPress core adoption - **Community**: Document RSM methodology as case study for other open source projects - **Documentation**: Create guidance on AI-assisted development workflows and code review processes #### DevRel - **Developer advocacy**: Create content around new WooCommerce features launching in 10.9 - **Education**: Develop tutorials for variation management improvements and feature flag usage - **Community engagement**: Gather feedback from agencies and developers on RSM-generated features #### Community - **Maintainers**: Study small team methodologies for faster feature development - **Contributors**: Explore AI-assisted contribution workflows while maintaining quality standards - **Ecosystem**: Prepare plugin compatibility for upcoming WooCommerce feature releases ## 🧪 Hypotheses - Small, autonomous teams (2-3 people) can deliver features faster than traditional larger teams with more oversight - AI-assisted development can maintain quality standards when combined with appropriate human review processes - Feature flags enable faster innovation cycles while reducing risk for production environments - Public prototyping and early feedback loops improve final product quality more than internal-only development - Month-long sprint formats generate more diverse innovation than quarterly planning cycles - Removing traditional corporate blockers increases both development speed and team satisfaction ### 📊 Methodology **RSM Impact Study**: Compare feature delivery velocity, quality metrics, and merchant satisfaction for RSM-generated features vs. traditional development pipeline over 6-month period. Track adoption rates of feature-flagged capabilities. **AI Code Quality Analysis**: Measure bug rates, security vulnerabilities, and maintainability scores for AI-assisted vs. human-only code contributions. Establish review time benchmarks. **Small Team Effectiveness**: A/B test 2-person vs. 4-6 person teams on comparable feature development, measuring time-to-ship, iteration cycles, and stakeholder satisfaction. ### ❓ Questions - How can large organizations maintain architectural coherence while enabling autonomous small teams? - What level of AI code review can be trusted for production e-commerce systems handling financial transactions? - How do you balance rapid feature development with backward compatibility and plugin ecosystem stability? - What metrics best predict which experimental features should progress to full release? - How can remote feature flags be implemented without compromising self-hosted software principles? ### 🔮 Future Research - **Organizational dynamics**: Study how RSM-style experiments affect long-term team structure and corporate culture - **AI development workflows**: Research optimal human-AI collaboration patterns for different types of software projects - **Feature lifecycle management**: Develop frameworks for graduating experimental features through beta to production - **Quality assurance automation**: Investigate AI-assisted testing methodologies that can match human QA effectiveness ### 💡 Implications **For practice**: Demonstrates viability of hybrid development models combining human creativity with AI acceleration. Suggests traditional corporate development processes may be unnecessarily slow. **For policy**: Raises questions about code review standards, liability, and quality assurance in AI-assisted development environments. **For education**: Indicates need for training developers in AI collaboration workflows and small-team product development methodologies. **For funding models**: Shows potential for reduced development costs through AI assistance and streamlined processes, possibly affecting development budgets and resource allocation. ### 🧠 Learning Styles Assessment **Reading level estimate**: Flesch-Kincaid Grade 12.3 - Technical discussion with domain-specific terminology but conversational tone makes it accessible. #### 👀 Visual learners **Present**: Screenshots of variation interface redesign, feature comparison tables **Improve**: Process flow diagrams showing before/after development workflows, organizational chart showing team structure changes, timeline visualization of 4-week sprint progression #### 🔊 Aural learners **Present**: 60-minute podcast format with detailed discussion **Improve**: Segment-specific audio summaries, timestamped navigation for key topics #### 🗣️ Verbal learners **Present**: Conversational explanations, analogies (e.g., "month-long hackathon"), clear definitions **Improve**: Glossary of technical terms, more business analogies for corporate concepts #### 🧩 Kinesthetic learners **Present**: Prototype demonstrations, hands-on feature exploration **Improve**: Step-by-step setup guides for feature flags, interactive demos of new variations interface #### 🧠 Logical learners **Present**: Clear problem-solution structure, numbered feature lists, cause-effect relationships **Improve**: Decision trees for feature flag progression, ROI analysis frameworks, process flowcharts #### 🧑‍🤝‍🧑 Social learners **Present**: Two-host discussion format, community feedback integration **Improve**: Discussion prompts for teams considering similar experiments, community case study collection #### 🧘‍♀️ Solitary learners **Present**: Detailed written analysis, individual reflection points **Improve**: Self-assessment worksheets for team structure optimization, personal action planning templates #### 🌿 Naturalistic learners **Present**: Ecosystem thinking about WordPress/WooCommerce community **Improve**: Environmental impact considerations of development methodologies, sustainability aspects of rapid development cycles ### 📊 Accessibility Assessment #### Screen reader semantics **Present**: Clear heading structure, descriptive link text for references **Improve**: More detailed alt text for interface screenshots, audio descriptions for video demonstrations #### Keyboard navigation **Present**: Standard web accessibility for text-based content **Improve**: Ensure all embedded videos have keyboard controls, tabindex optimization for long-form content #### Contrast and readability **Present**: Standard text contrast ratios **Improve**: High-contrast mode support for technical diagrams, larger text options for code examples #### Text resizing and reflow **Present**: Responsive text layout **Improve**: Ensure embedded content scales appropriately, test at 200% zoom with technical screenshots #### Media and captions **Present**: Video content with transcript **Improve**: Captions for video segments, downloadable transcript with timestamps #### Standards reference Maps to WCAG 2.2 AA Level A and AA criteria for informational content. ### 🌍 DEIB Assessment #### Cultural breadth **Present**: Global perspective on open source development **Improve**: Examples from diverse geographic regions, consideration of different regulatory environments #### Inclusive language **Present**: Gender-neutral team references, accessible technical explanations **Improve**: Define corporate jargon more clearly, avoid assumptions about organizational familiarity #### Neurodiversity support **Present**: Clear section breaks, consistent formatting **Improve**: More frequent subheadings, bullet point summaries for key concepts #### Representation **Present**: Mixed gender representation in podcast hosts **Improve**: Broader range of perspectives on development methodologies, international case studies #### Psychological safety **Present**: Respectful discussion of challenges and failures **Improve**: Content warnings for high-pressure work environments, balanced view of AI impact on employment ### ✅ Logical Validity #### Strong reasoning **Causal reasoning** (timestamp 15:30): Identifies specific pain points in current variations experience and demonstrates how new interface addresses each issue systematically. **Inductive reasoning** (timestamp 48:15): Draws broader conclusions about AI development challenges from specific examples of code review bottlenecks and deprecated code confusion. **Analogical reasoning** (throughout): Effectively compares RSM to hackathons and startup methodologies to help audience understand the concept. #### Fallacies **Post hoc reasoning** (timestamp 52:30): Assumes RSM success directly causes need for permanent organizational changes without considering other factors that might influence development speed. **Survivorship bias** (throughout): Focuses primarily on successful RSM projects without detailed discussion of failed experiments or abandoned initiatives. #### Tone of voice **Professional but conversational**: Uses technical terminology appropriately while maintaining accessibility. Shows appropriate caution about AI integration and quality concerns. Demonstrates enthusiasm for innovation while acknowledging implementation challenges. ### 🛡️ DARVO Analysis No DARVO patterns detected. The discussion maintains focus on technical and organizational improvements without defensiveness or blame-shifting. Challenges are acknowledged directly (AI review limitations, coordination difficulties) without minimization or redirection. ## 🎯 Conclusion Radical Speed Month represents a significant experiment in organizational agility for large technology companies. By temporarily removing traditional development processes and embracing small teams with AI assistance, Automattic generated substantial feature development in a compressed timeframe. The WooCommerce results demonstrate the viability of this approach, with numerous production-ready features now entering the platform. The key insight is that speed and quality aren't necessarily inversely related when proper safeguards (feature flags, human review, public feedback) are maintained. For the WordPress ecosystem, this suggests opportunities for more responsive development cycles while preserving the stability and reliability that merchants depend on. The challenge moving forward will be systematizing these rapid development approaches while maintaining the coordination and architectural coherence that large-scale software projects require. ## 🔄 Refactor Appendix — Radical Speed Month: What Shipped and What's Next ### 📚 Literature Atoms #### RSM demonstrates small teams ship faster than traditional development processes > [!quote] ID:rw_podcast_001 > "We had complete free reign... essentially every single person in the company apart from some select people were asked to pair up into teams and essentially work on anything that they wanted." **Context & use**: - Timestamp: 00:03:12 - Core methodology explanation - Why this matters: Challenges conventional wisdom about corporate development requiring extensive oversight and process layers **Tags**: #xref #articleseed **Highlight**: [view highlight](https://www.youtube.com/watch?v=YR1aWwygrxk?t=192)  #### AI code generation requires human review for production e-commerce systems > [!quote] ID:rw_podcast_002 > "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.' Because we have a responsibility to everyone using Woo Commerce." **Context & use**: - Timestamp: 48:15 - Code quality discussion - Why this matters: Defines boundaries for AI integration in mission-critical software development **Tags**: #xref #articleseed **Highlight**: [view highlight](https://www.youtube.com/watch?v=YR1aWwygrxk?t=2895)  #### Feature flags enable rapid innovation while reducing production risk > [!quote] ID:rw_podcast_003 > "Most of the stuff that is coming is behind a feature flag... 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." **Context & use**: - Timestamp: 35:45 - Feature deployment strategy - Why this matters: Provides framework for balancing innovation speed with stability requirements **Tags**: #xref **Highlight**: [view highlight](https://www.youtube.com/watch?v=YR1aWwygrxk?t=2145)  ### 🧠 Permanent Candidates #### Large organizations can achieve startup-like development velocity through structural constraints **Claim**: Imposing specific constraints (2-person teams, single project focus, AI-first development) enables large corporations to replicate the agility and innovation speed typically associated with startups. **Evidence pointer**: [[#RSM demonstrates small teams ship faster than traditional development processes]] **Scope & conditions**: - Holds when: Clear constraints are defined and enforced; leadership provides complete creative freedom within those constraints; existing processes are temporarily suspended - Breaks when: Projects require coordination across multiple teams; architectural coherence becomes critical; security/compliance requirements demand extensive review **Links**: - [[Startup development methodologies]] — because contrasts on organizational scale - [[Corporate innovation processes]] — because extends beyond traditional R&D - [[Agile development frameworks]] — because applies-in enterprise contexts  ### ✏️ Fleeting Queue - Investigate remote feature flag implementation for self-hosted software - balance between control and innovation - Research optimal team size for different types of development projects - 2 vs 3-4 people trade-offs - Explore AI-assisted code review tools that can achieve human-level quality assessment ### → Things 3 - [ ] Set up WooCommerce 10.9 test environment to evaluate new feature flags #things - [ ] Research feature flag lifecycle management for WordPress plugins #things --- ## Full Transcript [00:32] Hello, welcome to Do the Woo, the [00:35] podcast where we talk about all things [00:37] Woo Commerce. I'm James Kemp, the core [00:40] product manager for Woo Commerce. [00:42] >> And I'm Katy Keith from Barn 2. And [00:45] today we're going to be talking about [00:47] radical speed month, which just take [00:49] took place well across automatic and [00:52] also at Woo. [00:55] >> Yeah. And it's a bit of a different [00:57] session today because it's just us two, [00:59] right? [01:00] >> Well, that is because I'm afraid you [01:02] were the perfect guest. So, we didn't [01:04] need a guest because you know all things [01:06] that happen at Woo. Yeah, I have all the [01:08] the ins and outs. Um, before we dive in, [01:11] if you have any questions and you're [01:13] watching live, uh, feel free to ask in [01:16] whatever channel you're watching it on, [01:18] um, we'll try and answer them. And, uh, [01:21] yeah. [01:22] >> Yeah. And if you don't already follow [01:24] us, then please follow us or subscribe [01:27] wherever you're watching this. So you [01:30] can follow us on YouTube at dotheoo [01:32] podcast on xd dothewoo and all the [01:35] places you can follow us are on our [01:38] website dothewoo.com. So make sure you [01:40] do that uh so that you don't miss on [01:42] future episodes. [01:44] Now let's get started. So I think the [01:47] first thing we should talk about is what [01:49] was radical speed month for anybody who [01:52] hasn't heard. To me it sounds something [01:54] like to do with drugs. Did you all just [01:56] get high all month? [01:59] No, we didn't. Um, high on code, I [02:02] guess, is is what we did. [02:04] >> Okay. [02:04] >> Um, yeah, it was [02:08] kind of a surprise initiative. Um, and [02:11] the concept was that [02:14] essentially every single person in the [02:16] company apart from some select people [02:18] that were, you know, maintaining uh [02:21] vital things that had to be uh [02:23] maintained for the month. um were asked [02:27] to pair up into teams and essentially [02:31] work on anything that they wanted. Um [02:36] and really it was a way to experiment [02:38] with being able to ship fast, you know, [02:42] not not having any uh blockages or [02:45] processes that you normally have to go [02:47] through to to get code out there or to [02:49] get a project out there. um but also to [02:52] utilize AI as like a core principle and [02:56] really focus on what's possible now with [03:00] just a very small team. So we were [03:03] restricted to two people. Um if we [03:07] wanted any more than that, we kind of [03:09] had to put a pitch together and and [03:11] explain why we needed more than two [03:13] people. Uh and we were also for the most [03:16] part restricted to just focusing on one [03:19] project. Um, you may have seen some [03:22] posts that I put out uh right when it [03:24] started where I was focusing on two [03:26] things. Um, one of which was the uh [03:30] variations project and one of them was [03:33] focusing on product add-ons, one of our [03:35] extensions. [03:36] Um, [03:38] and I kind of over time realized that [03:41] okay, if I want, you know, one of these [03:43] things to be really good, it's going to [03:46] be better to to focus on just one thing. [03:49] Um, so we had I think [03:53] I want to say just over 700 [03:56] pairs of projects that were [03:58] >> Woo specifically or automatic [04:00] >> no automatic wide. Yeah, this was an [04:02] automatic wide initiative. [04:04] >> Um, Woo had let me just have a look [04:09] uh 174 [04:11] WO projects uh in in the four weeks. Uh [04:14] and as as the name implies, it was uh an [04:18] experiment that we were going to run for [04:20] one month. Um and it was very fun. It [04:23] was it was great to be able to just, you [04:27] know, take any idea and kind of roll [04:29] with it. Um, and one of the the main [04:33] things was that [04:35] you were able to ship it and then it was [04:38] kind of your responsibility to make sure [04:40] that what you're shipping is uh good and [04:44] valuable um and you know that you're [04:47] able to sort of consider the impact that [04:50] it might have as a as a small team. Um, [04:52] so we had people who maybe focused on [04:55] our existing products and worked on uh [04:59] projects related to them, but we also [05:01] had people that, you know, spun up [05:03] projects that were completely unrelated [05:05] uh to anything that automatic works on. [05:09] Um, you know, out completely outside of [05:12] WordPress even. Um, [05:16] but yeah, we can dive into some of them [05:19] shortly. Yeah, I'm more I'm interested [05:21] initially in how the decision making [05:24] process worked. So, did it have to align [05:26] with strategic priorities? Did you have [05:29] complete free reign? [05:32] >> We had complete free reign. Um, [05:36] I think the concept was that it gives [05:39] you the ability to [05:42] decide what you feel is important or [05:46] um, yeah, I think decide what you feel [05:48] is important and that could be, [05:51] you know, something that would have [05:53] significant business impact for [05:55] whatever, you know, project you're [05:56] working on. um but also could be used as [05:59] like a a learning tool and just a way to [06:02] experiment with different ways of [06:04] working that we're we're not normally um [06:07] you know used to. And I I think one of [06:11] the big things was that not everyone is [06:13] an engineer or was paired with an [06:15] engineer. So people were able to use AI [06:19] in ways that maybe they're not usually [06:23] doing in their normal role. Um, and I [06:26] think that made it quite interesting. I [06:28] think ultimately [06:32] the ideas that are maybe going to [06:34] continue are the ones that would have [06:35] some sort of impact on uh either the [06:38] business or the customer uh whoever the [06:41] customer might be. Um, but yeah, I I [06:45] think there was many different [06:46] approaches to the projects that people [06:49] experimented with. Uh, and some people [06:51] would like start a project and finish it [06:53] in a week and then move on to another [06:55] project, but it was always, you know, [06:57] one project at a time. Um, so that was [07:00] interesting. [07:02] >> Okay. And let's have some examples then. [07:04] I'm interested in kind of different [07:06] examples. Some that were with engineers, [07:10] some that weren't, and how that could be [07:12] productive and even something a bit more [07:15] radical. So, let's go through a few [07:16] examples. [07:19] Yeah, I have a bunch of examples for Woo [07:21] Commerce. Um, I think one of the [07:25] examples that wasn't Woo Commerce [07:26] related was the uh and this was shown uh [07:30] in the keynote at Word Camp. Um, the [07:34] desktop mode for for WordPress is quite [07:37] a radical concept for how WordPress [07:39] could work. Um, it works as a plug-in on [07:42] top of, you know, WordPress and it kind [07:44] of converts it to this desktop OS mode. [07:48] Um, [07:50] and that's quite impressive to ship [07:52] something that works that well and is [07:55] that, you know, fleshed out and that [07:57] complicated in [07:59] I was going to say four weeks, but I [08:01] think it it was even, you know, ready to [08:02] go before that. So that's um one example [08:07] of something that was still you know [08:09] WordPress adjacent. Um the things that I [08:13] am most aware of are the WooCommerce [08:16] projects that that came through. Um, and [08:20] we we've actually been spending some [08:22] time kind of grouping those projects now [08:24] and figuring out what what to do with [08:27] them now and and how we can, you know, [08:30] either roll them into the the product or [08:32] keep experimenting with them. Um, so [08:36] some of the ones [08:38] I'm going to try and see if there's any [08:39] that are a little bit different. [08:42] One one comes to mind and it's like um [08:46] fly uh [08:49] It's like a pinata moment. [08:52] I'm just going to see if I can find it. [08:54] >> Everything with a stick [08:56] >> pretty much. [08:57] >> Okay. [08:58] >> Uh, no, I think it's going to do that at [09:00] some point, but [09:02] >> let's see if I can find it. Yeah, here [09:04] we go. [09:07] So, [09:10] got a fly flying around me. Um, so the [09:13] concept was to bring uh small moments of [09:16] genuine delight to Woo Commerce. Um, and [09:21] sort of showing up at celebratory [09:24] moments for the merchant. [09:27] So, you might consider like, okay, [09:28] they've made uh 100 sales now. Um, I'm [09:33] going to see if I can share this [09:36] somehow. [09:38] Uh, let's see. [09:41] I haven't done a [09:45] I haven't done sharing on this live [09:47] stream yet. So, this may or may not [09:50] work. [09:52] >> Uh let's see. [09:57] Is this going to work? [10:01] Share. [10:06] Nope. [10:09] This fire is annoying. Uh, [10:18] just trying to isolate it, but it's not [10:20] really working out for me. [10:28] Is it a link you could give me because [10:30] I'm logged in as the host? [10:33] >> No, I can I can load it. It's just on a [10:36] It's a video. I only wanted to show the [10:38] video. Uh, [10:42] yeah. Okay. Maybe I can't share this [10:44] particular screen. Um, [10:49] maybe if I do full screen. Oh, that [10:51] might work. Let's try this. [10:57] Okay, I'm sharing that. I think you have [10:58] to add it. [10:59] >> Yeah, done that. [11:01] >> Nice. So, this is a little demo of the [11:05] pinata moment. [11:08] >> Yeah. [11:12] >> And this one's quite a quite a random [11:15] but, you know, celebratory moment for [11:17] the merchant that [11:19] someone worked on, but it's quite um [11:25] quite nice. Quite fun. [11:26] >> Yeah, it's cute. Um so their project was [11:29] all about um [11:32] you know [11:37] uh all about kind of the celebratory [11:39] moments and and small uh sprinkles and [11:44] excitement throughout the Woo Commerce [11:46] experience. Um so they [11:50] they uh celebrated ordinary moments and [11:53] another project adjacent to that was one [11:55] that was called Woo Sprinkles. [11:58] um which was kind of sprinkling a bit of [12:01] uh UI design and refresh throughout the [12:03] the admin of WooCommerce uh which was [12:07] pretty cool. [12:11] There was quite a few there there was a [12:13] lot of work done on the order management [12:15] page. [12:16] Um [12:18] and it was things like [12:21] refining you know the width of the order [12:23] management page which by default is just [12:26] the full width of the uh of the window. [12:30] Um [12:31] kind of moving some of the primary [12:33] actions into into better view. Um, and [12:37] then like UI tweaks that just kind of [12:40] modernized the existing experience a bit [12:43] more. Um, which was quite nice. That was [12:46] one of our designers. Um, [12:50] and I'm not sure who she was partnered [12:52] with, [12:54] but that was cool. Um you might have [12:57] seen [12:59] Bo who is our artistic director for [13:03] WooCommerce uh shared some explorations [13:06] around the navigation for WooCommerce. [13:09] So the lefth hand navigation [13:12] um he was experimenting with what a [13:16] an e-commerce focused mode would look [13:18] like essentially. So you kind of click [13:21] uh you know Woo Commerce is the top [13:22] level item and then you click into that [13:25] and you get a very focused navigation [13:27] that has um only e-commerce adjacent [13:30] menu items and it's it's like a stepped [13:33] navigation. [13:34] >> Mhm. [13:35] >> Uh which is something I've heard quite a [13:37] few people talking about. Um it came up [13:40] at checkout summit. Uh a couple of [13:42] people mentioned it at Word Camp Europe [13:44] as well. not specifically Bose's [13:46] exploration but just that concept in [13:48] general of um essentially an e-commerce [13:51] mode which I I think could be pretty [13:54] interesting. I think that that is [13:56] something that you know the merchant [13:59] experience would be [14:02] enhanced I think [14:04] um I like the concept of them being able [14:07] to choose what's most important to them [14:10] and you know maybe different users of [14:13] the website have different needs. Um, I [14:16] don't know whether that's a WordPress [14:18] level thing or a WooCommerce something [14:21] that that we can at least do on the [14:24] e-commerce side. [14:28] Um, [14:29] one of the projects that I shared before [14:34] was I'm going to try and share it again. [14:39] I might have to zoom in a bit. [14:44] There we go. All [14:47] right. [14:49] Share. [14:53] So I shared this is the project that [14:55] myself and Polly were working on. Um and [14:57] it was an exploration around how we [14:59] could improve the variations experience. [15:03] Um [15:04] so currently the experience is a bit [15:07] rough. Um [15:10] I I don't think it's changed much uh [15:12] over its lifetime in Woo Commerce, but [15:16] there's [15:18] it's one of the experiences that many [15:21] uh merchants and users complain about [15:24] the most. You know, the process of [15:26] dealing with [15:29] large numbers of variations and even [15:31] smaller numbers is is still, you know, [15:34] quite a complicated experience. It's not [15:36] it's not great. you have to configure [15:39] attributes um you know define them as [15:42] attributes used for variations and then [15:44] switch over to the variations tab. You [15:46] you kind of have to save in between um [15:49] and it's quite a a convoluted process. [15:52] So [15:53] myself and Polly spent a lot of time [15:56] trying to figure out how we can improve [15:58] that process and make it more usable for [16:02] for merchants and nontechnical people to [16:05] set up um but also more of a flow that [16:10] that takes you through the process. So [16:13] one of the first things we did was to [16:14] move the attribute uh configuration into [16:19] the variations tab. So this is [16:22] attributes specifically used for [16:24] variations. [16:26] Um so you could say okay I want I want [16:28] my product to have theme options [16:32] and I want them to have color options. [16:36] So you can kind of add them here. Uh and [16:39] one of the things that you could do that [16:40] you can't do currently in Woo Commerce [16:42] is to create a new attribute. [16:45] Uh and it would allow you to create a [16:48] global attribute. So you can create [16:51] local attributes [16:53] um which in my opinion is not a great [16:57] type of attribute to lead with. I think [17:00] typically especially for variations [17:03] you [17:04] it it's a better experience to have uh [17:07] global attributes because you can filter [17:10] um you know on on the front end as a [17:13] customer you can filter uh and they're [17:15] also reusable across products. Yeah, [17:18] totally agree. The number of support [17:20] tickets we get from people using say our [17:23] product filters or product table [17:24] plugins, they don't understand why their [17:27] variations or attributes aren't working [17:30] in the filters or whatever and it's [17:31] because they're product specific and [17:33] they don't know there's a difference and [17:34] it's a big job for them to then go and [17:36] recreate them all under product [17:38] attributes. So that's good. They can't [17:40] get it wrong if it's right there. [17:43] >> Yeah. And I I even discussed the idea of [17:46] just not having local attributes at all [17:49] in in this variations experience. [17:52] Um [17:54] because there there's really not much [17:56] benefit there. There was a few people [17:57] that said, okay, we we have [18:01] essentially attributes that are unique [18:02] to every product. [18:04] Um I have no examples for that, but I [18:07] guess similar to like an SKU type code [18:10] that belongs to just that product. Yeah, [18:12] that does happen. But does it matter if [18:14] they're added globally? [18:18] >> The only reason they didn't want to do [18:20] that is if they have thousands and then [18:22] it becomes quite messy to to manage, you [18:25] know, those attributes, [18:28] but I'm not 100% sure. Um, there was, [18:32] you know, one merchant that uses them in [18:34] particular that was very keen to [18:36] maintain them. But the other thing I'm [18:38] not sure on and I would need to kind of [18:41] find out a bit more is whether that is I [18:45] expect that's more of like the product [18:46] level attribute and not attributes that [18:49] are used for variations like I [18:52] >> it could be used for variations as well [18:54] if there's one product that's very [18:55] distinct from the rest or something. [18:58] >> Yeah, true. But then if you think about [19:00] so a ver an attribute is just a taxonomy [19:03] and there's no where else in WordPress [19:06] where you can add taxonomy terms that [19:08] are only available to one let's say post [19:11] uh like tags or whatever. So you might [19:14] add tags that only apply to one post and [19:17] that's not seen as a problem is it in [19:19] WordPress. [19:20] >> Yeah that's true. And I think it it's a [19:24] bit more like a meta field, right? Where [19:26] you're giving it a label and a value, [19:29] but the value happens to be uh you know, [19:32] separated by pipes, which is also not [19:35] very user friendly. [19:37] >> True. [19:37] >> Um [19:39] which actually, you know, even if this [19:41] isn't a global attribute, at least we [19:44] solve that issue as well. So you've got [19:45] this kind of [19:47] >> um [19:50] you know pill type value field which [19:52] makes it a bit easier to to deal with. [19:54] >> Yeah. [19:56] >> Um so some improvements there. We we [19:58] kept the attributes tab uh like I say [20:00] for products level attributes that [20:02] aren't used for variations. Um there's [20:05] still some discussion as to whether we [20:07] should show these variation attributes [20:09] in the attributes tab as well. [20:12] >> Yeah, people might expect that. Yeah, [20:14] especially you know if they have [20:16] experience with it. [20:18] So you would add the attributes and then [20:21] you get this kind of summary of the [20:23] attributes that have been added. So you [20:24] can see that uh within the variations [20:27] tab [20:29] um and then you can either generate [20:30] variations or add variations manually. [20:34] So the experience of generating [20:36] variations in WooCommerce currently [20:39] is it generates every single possible [20:42] combination of attributes and it does it [20:46] in batches of 50. So you have to click [20:49] uh continuously to generate until it's [20:52] created all of the variations for you. [20:55] >> Yeah. [20:55] >> Uh and that experience is not clear like [20:59] I don't I don't think there's anything [21:00] that tells you you have to do that. You [21:03] just kind of have to figure it out for [21:04] yourself. [21:05] >> I think it just pops up on the screen [21:06] once it gets to 50 or something. [21:09] >> Yeah, it says at the beginning, I think [21:12] it's limited to 50, but it doesn't say, [21:15] you know, run it again to generate the [21:16] next 50. [21:17] >> Oh, that is confusing then. Yeah. [21:19] >> Yeah. Um, so obviously we wanted to [21:23] improve that experience. [21:25] And one of the ways we were thinking [21:27] about to do that is to allow the uh [21:31] person setting it up to choose which [21:33] attributes to use to actually create the [21:36] variations. Um so in this example, if [21:41] they select both theme and color, it's [21:43] going to create 15 separate variations. [21:45] If they take away color, it will create [21:48] five variations. So five of the five [21:50] themes available in any color. [21:54] Um, and you can imagine [21:57] this is a prototype, so this may not [21:59] work. But as you start adding more like [22:02] this, [22:04] just going to add not that one [22:08] pattern. [22:12] So if we add a load, [22:15] I'm not going to create any new. [22:19] Yeah, I didn't think it would. [22:22] have to refresh [22:30] the combination of [22:33] using attributes to create variations [22:36] becomes quite exponential because for [22:38] every one you add [22:41] it's a multiplier against everything [22:43] else. [22:44] >> Yes, it's always been like that. Yeah. [22:47] So, for this example, [22:49] if every combination is selected, it's [22:52] going to create 1,200 variations. But as [22:55] soon as you remove one, it drops it [22:57] dramatically. [22:59] And that makes the process of creating [23:01] variations much better for the merchant [23:04] because, okay, maybe, you know, size [23:08] doesn't affect the uh stock count or the [23:11] image or the price. Um, and they can [23:15] kind of tweak this to get closer to the [23:18] the number of variations that they [23:20] actually need without having to either [23:22] create each one manually because [23:24] creating, you know, 75 variations [23:26] manually is going to take a lot of time. [23:29] But creating 1,200 variations to get [23:32] down to 75 is also going to take a lot [23:34] of time. So by having this ability to [23:38] choose which attributes actually [23:40] generate the variations makes that [23:42] process much nicer for the merchant. [23:45] >> Okay. So if you did that and got it down [23:47] to 75, how would they choose a size? [23:51] >> So it's exactly the same as the way Woo [23:54] Commerce works today. [23:56] Um [23:58] where if we look down here so [24:00] >> Oh, it's effectively blank. I see. [24:02] >> It's it's blank. Yeah. Yeah. So [24:05] currently if you you could create one [24:07] variation and it could be you know any [24:10] theme, any color, any size, any [24:12] material. There's there's one product [24:13] that it narrows down to on the front [24:16] end. Um [24:19] but you you've only got one variation to [24:21] deal with. [24:22] So it works in exactly the same way and [24:25] the the whole data structure behind all [24:27] of this is exactly the same as what it [24:29] is today. The only difference is the UI. [24:33] >> Yeah. [24:35] So once you've generated the variations, [24:37] you get this experience of um data [24:40] views. This is data views and data forms [24:42] which is uh the experience that we've [24:44] talked a lot about in regards to the [24:46] product editor. [24:48] Um so data views is a nice table where [24:51] now we can actually filter and search [24:53] the variations. Um so we can see all [24:56] yellow ones. [24:58] Uh we can add filters for things like [25:01] the attributes. Uh obviously pattern is [25:05] one that we chose any let's see color we [25:09] can say show all the blue ones. So the [25:12] merchant can kind of group um their [25:15] variations like this and then they would [25:19] be able to select all of them and [25:21] bulkedit you know very specific [25:23] selections of variations. [25:26] Um [25:28] so the the bulk edit experience is also [25:32] new in this and it it's reflecting a [25:35] similar experience that uh another team [25:38] was working on for the product list. Um [25:42] so you know the list of all your [25:44] products uh once you click uh I think [25:47] it's Woo Commerce products right? [25:50] Um, [25:52] so this experience is very very similar [25:54] to that and it adds a bit of consistency [25:56] uh in the UI and the expectations. [25:59] Um, and it's pretty cool. You can do [26:01] some nice stuff with, you know, price [26:04] changes across the the selected [26:06] products. Uh, I don't know if you can [26:08] see, you probably can't. Um, [26:10] >> you can't see the open dropown just so [26:13] you can set new amounts. You can [26:14] increase all prices by a specific [26:16] amount. [26:18] You can decrease, you can increase by [26:21] percentage, and decrease by percentage. [26:24] Um, so you can make all of these, you [26:25] know, batch changes to variations in in [26:28] one go, which makes for a much nicer [26:32] editing experience. [26:37] Um, [26:38] >> so what are we talking about then? Is [26:40] this happening? Is it live? Is it in QA? [26:43] Is it a proposal? [26:45] So that particular work and also some [26:48] other work is actually in uh will be in [26:53] 10.9 behind a feature flag. Um [26:57] the variations work is very much not [27:00] ready but the code exists in in core. [27:05] The beginnings of the code exists in [27:07] core. [27:09] Um for that work specifically the goal [27:12] would be [27:15] we we want to have this kind of final [27:17] vision of the future product editor. Um [27:21] you know we had the the product editor [27:23] experience that we shipped a few years [27:25] ago. Uh you may have seen that that's [27:28] now being uh it was deprecated in 2024 [27:31] but we're now actually removing the code [27:32] from the codebase. Um, [27:36] and as an aside, one of the reasons for [27:39] that is because [27:41] we found that when we were working with [27:42] these AI agents on the codebase, they [27:45] were looking at that code as an example [27:47] of, okay, this is how, you know, code [27:49] should be done in Woo Commerce. Um, and [27:52] it definitely isn't how code should be [27:54] done. You know that's the reason we we [27:56] stopped that project was because uh it [27:59] diverted away from like data forms and [28:01] data views which is the the WordPress [28:04] experience [28:05] uh of of those you know similar [28:09] um you know views table views and and [28:12] form fields. [28:14] Um so yeah it was confusing AI agents. [28:17] They were they were trying to use code [28:19] from that quite a lot. Uh which which [28:22] isn't what we wanted. Um, [28:26] so yeah, we [28:28] we want to understand what the future [28:31] version of the product editor looks like [28:33] and we [28:35] the way I would like to do it is to [28:38] have that future vision. Okay, this this [28:40] is, you know, what we're aiming for and [28:42] then ship the smaller components of that [28:46] over time. So, we're not saying, you [28:49] know, we're not spending a year uh [28:51] redoing the whole editor, shipping it, [28:54] and then creating a ton of headaches for [28:56] people uh who extend it or integrate [28:59] with it. But we [29:02] would like to do it a bit more [29:03] iteratively. So, okay, you know, in this [29:06] release, we're updating the variations [29:08] experience. Um, and that gives uh [29:12] plugins time to extend it and and work [29:14] with it. um and you know gather feedback [29:18] on that as well. Um so that would be the [29:21] goal. So one of the things we need to do [29:24] now is to make sure that that project [29:27] aligns with what the future version of [29:30] the editor looks like. Um, and actually [29:33] one of the problems with Radical Speed [29:35] Month is that [29:37] the the teams that were working on these [29:40] different projects weren't necessarily [29:41] aligned with the uh with each other, I [29:45] guess, because we were very, you know, [29:47] siloed in in the work we were doing. Um, [29:51] so we found ourselves actually [29:53] collaborating a lot with uh Veronica and [29:56] Luigi who were working on the product [29:58] list experience. [30:00] um to make sure that we're not [30:02] duplicating [30:04] uh work across those two screens because [30:06] they were they have very similar [30:07] aspects. [30:09] Um so I think that's one area where [30:13] the concept of working in teams of two [30:17] without [30:19] you know blockers without these kind of [30:21] um input from anyone else maybe won't [30:24] work unless we have some sort of final [30:27] uh or expected vision like these are [30:31] this is the goal these are the kind of [30:32] components that you can use um which you [30:36] know come from the shared design system. [30:38] So there's some challenges there that we [30:40] we need to figure out and align on [30:43] before we can actually ship this thing. [30:46] Um because what what I wouldn't want to [30:49] do for variation specifically is have a [30:53] sort of middle state where we've got the [30:55] the classic experience [30:57] uh a new experience that is much better [31:00] but then is you know replaced by [31:02] whatever the future experience is. We [31:05] want to make sure that whatever we ship [31:07] now is the same as what the future [31:09] experience would be. [31:12] >> Yeah. And that makes sense about it [31:13] fitting into a wider uh project context [31:16] because there's been talk for many years [31:18] about the entire edit product screen [31:20] with the whole block editor thing and [31:22] all of that and how that all fits [31:24] together. So that does make sense. It's [31:26] not doing something now that's just [31:27] going to change later. But we've got [31:30] feedback from Dave Loots who says, "Love [31:32] the new variation UI." So people are [31:35] liking it and hope to see it live. [31:38] >> Yeah. One of the things we did um which [31:40] was quite nice was to [31:43] we met with quite a few people uh was [31:46] you know Polly and I and whoever we were [31:48] meeting with. Uh and we just kind of let [31:51] them explore this demo. Um which was a a [31:56] really nice way to figure out what [31:58] worked and and what they expected uh to [32:01] happen as they were using it. [32:03] Um, and I think one of the things that [32:08] multiple people got from the experience [32:10] of RSM was to be a bit more public with [32:14] the work that they're working on. Uh, [32:17] you know, ask for feedback, use [32:19] prototypes to actually get feedback [32:21] coming in before we've got, you know, [32:23] too deep into the the actual coding of [32:25] it. Um, so that was really cool. [32:28] >> Yeah. Well, people have always liked [32:29] that about your work because you often [32:31] share things on X for consultation um [32:34] prior to anything actually being done [32:35] and people do like feeding back on that [32:37] and feeling listen to. [32:40] >> Yeah, exactly. I think there's a there's [32:41] a tendency [32:43] in software maybe that's going away a [32:46] bit now um [32:49] you know to work on something and then [32:50] talk about it when it's done. And at [32:52] that point it's it's maybe a bit late. [32:55] um especially with software that's quite [32:58] open like you know the core of Woo [32:59] Commerce where [33:02] the the input of the people that build [33:04] on top of it and you know actually [33:07] contribute to it is very valuable um you [33:11] know we have this we have access to [33:14] hundreds and thousands of people that [33:16] work with Woo Commerce every day and it [33:18] makes sense to to get their feedback and [33:21] their experience and also their [33:23] experience [33:24] of how their merchants and their clients [33:27] actually work with the thing. Um, so [33:30] it's it's a really nice way to stay [33:32] grounded. [33:34] >> Yeah, that's really helpful and valuable [33:36] and not always easy to get unless you've [33:38] got such a big user base as Woo [33:40] Commerce. [33:42] >> Yeah, it's really hard to get hold of [33:44] merchants specifically. say having this [33:47] like connection with agencies [33:50] um who have merchant clients because [33:54] unless they're like mildly technical [33:56] merchants I found don't really hang out [33:59] online anywhere [34:02] um you can't find them all in one place [34:05] >> there is a challenge I went to a talk at [34:07] Word Camp Europe on Friday about uh [34:10] market research and the importance of [34:12] validating product ideas and feature [34:14] ideas and I came away thinking that's [34:17] going to be as much work as actually [34:18] developing the thing and seeing if [34:20] people like it because once people start [34:22] using it then they feed back and you [34:24] learn and new ideas come to you based on [34:27] that. So I get the concept but it's not [34:30] always easy to find people. So it's good [34:33] that we do have some opportunities to do [34:35] that. [34:36] >> Yeah. Yeah, I mean we have access to, [34:38] you know, a number of merchants. Um, but [34:42] I think we don't directly hear from them [34:46] as, you know, someone uh working with [34:49] them to actually configure their store [34:52] and and hear their pain points. So I [34:55] think it's it's good for the agencies [34:58] and developers to connect us with the [35:01] merchant because they have like they can [35:03] kind of translate their problems um the [35:06] merchants problems which is quite nice. [35:07] >> Yeah. And collect them based on multiple [35:09] merchants that they work with. [35:11] >> Yeah. [35:12] Yeah. Exactly. [35:15] >> Okay. So I understand the variations [35:17] thing is quite complex and will be done [35:19] as more of a long-term thing. I read a [35:21] tweet by Brian Cords the other day [35:23] saying that as a developer advocate he's [35:26] preparing the release post for an [35:28] upcoming release and he said there's [35:30] more in it than he's ever had before to [35:33] announce. So what is actually coming [35:36] soon as a result of all this? [35:39] >> Yeah, there's there's a few things. Um [35:42] I'm actually going to pull up Brian's [35:43] tweet because it's probably the best. [35:46] >> I don't remember actually said what was [35:47] in it just there was a lot. But he might [35:49] >> I think he did. I think he listed it. [35:52] Um, let's see. [35:56] He tweets a lot. Here we go. Uh, so [35:59] yeah, I I would say most of the stuff [36:01] that is coming is behind a feature flag. [36:06] Um, [36:07] >> what does that mean? [36:08] >> Uh, it means if you go to Woo Commerce [36:12] settings, advanced features, it's [36:15] something that you can turn on or off. [36:17] >> Oh, like the AI stuff. [36:19] >> Yes. So, by default, it's not on. And if [36:22] you want to try it out and experiment [36:23] with it, you have to go turn it on. Uh, [36:28] it is also possible to have feature [36:29] flags that aren't that don't have a [36:31] checkbox, like a toggle in that area. [36:34] Um, and you would turn them on [36:36] programmatically with like a a filter [36:38] essentially. [36:40] Um so I believe most of the things that [36:43] he's listed are coming as feature flag [36:47] um features which gives us the ability [36:51] to [36:53] uh have people test it and and see you [36:55] know what the experience is like and [36:57] find bugs. [36:59] Um [37:00] and one of the things [37:02] we want to do is actually have like a [37:05] life cycle of of feature flags. So, how [37:08] how it moves from uh a an experimental [37:12] feature into, you know, a beta release [37:15] or or like a slow roll out of some kind [37:18] uh until it's eventually rolled out to [37:20] everyone. Um [37:23] sometimes we would roll it out to new [37:25] stores only like uh H+. [37:28] So, H+ is actually still behind a [37:32] feature flag as well. Um high [37:34] performance order storage. [37:37] so that new stores get it and old stores [37:41] or existing stores are are able to turn [37:43] it on if they want to. Um so there's [37:46] there's numerous ways to kind of deal [37:48] with feature flags. Uh I had a [37:50] conversation at Word Camp actually. Um [37:53] there was this concept of remote feature [37:55] flags. So the ability for [37:59] whoever you know implemented the feature [38:01] flag to turn it on remotely to to all [38:05] stores. So, similar to like a SAS [38:07] product where [38:10] you could enable a feature without them [38:12] having to update the plug-in. [38:15] >> Wouldn't people hate that because they [38:17] want control over self-hosted software [38:20] >> potentially as well? [38:22] >> I think it depends what it is. Um, [38:25] that it's a good way to be able to [38:28] experiment with [38:30] uh [38:33] sort of like AB testing, I guess. And [38:35] you see tools like Shopify doing that [38:37] quite a lot. Um [38:40] I would say it would probably have to be [38:43] something that they opt into to allow um [38:46] you know bleeding edge features that are [38:50] enabled when we know that it's stable. [38:53] So I don't think you would see us [38:54] enabling experimental features but it [38:57] might be um you know okay this feature [39:00] has passed a number of uh beta you know [39:06] programs um and is now ready to be [39:09] rolled out and maybe we roll it out to [39:12] uh a specific segment more easily. [39:15] Um I thought that was interesting that I [39:17] can't remember who it was that I was [39:18] talking to about. I need to uh to write [39:21] up my notes from word camp. [39:24] Um but yeah, we don't do that at the [39:26] moment. At the moment, it's it's a [39:29] feature flag uh and it is enabled if you [39:32] enable it. Uh or if we've validated [39:36] that, okay, that that feature is ready [39:38] to go, which is uh similar to cost of [39:40] goods. Um and then we would just turn it [39:43] on for everyone or whatever bracket of [39:46] people that are most suited to it. Um, [39:49] so Brian's post lists color swatches. [39:53] So color swatches are [39:57] in 10.9 behind a future flag and they [40:00] belong to attributes. [40:02] Um, and that is in the filters and also [40:06] in the in the product options block. Um, [40:10] so that's pretty cool. I think it's [40:11] color and image swatches. [40:14] um a few sort of email notifications [40:18] like abandoned car back in stock uh and [40:21] review request emails. Uh so the review [40:24] request email is an email that can be [40:28] turned on to send you know after seven [40:30] days of someone purchasing something to [40:32] request a review for that product. [40:35] >> Yeah. Now you say it seems incredible [40:36] it's not always been there because so [40:39] many e-commerce stores have that, don't [40:40] they? [40:42] Yeah, I think it's it makes sense like [40:44] in the lineup of of emails, we have some [40:48] form of review functionality in [40:50] WooCommerce. So, why not, you know, try [40:51] and encourage this, you know, aspect of [40:54] social proof um and just general general [40:58] feedback because reviews show up in in [41:00] Google as well, right? [41:02] >> Yeah. And actually, it makes sense to [41:04] make reviews better in Woo Core because [41:06] Shopify doesn't even have reviews in [41:08] core. So that is a clear way that Woo is [41:10] better than Shopify. [41:12] >> Yeah, there's going to be some work that [41:13] we do on reviews at some point because [41:17] they're very much like glorified [41:18] comments at the moment. [41:20] >> It's it's a comment field with um stars [41:24] that you can choose. Um so yeah, we're [41:27] definitely going to dig into that and [41:29] see if we can improve that baseline. [41:32] Um, there's the easy mobile app login [41:36] and granular push notifications, [41:39] transactional email logging. [41:41] Uh, this one's quite cool. Variation [41:43] image galleries and videos in product [41:46] galleries. So, that was one of our [41:48] extensions in the marketplace that when [41:51] we, you know, worked on the more and [41:53] core stuff was kind of flagged as [41:56] something that that should probably be [41:57] in core. So, the ability to have more [42:00] than one image assigned to a variation. [42:03] >> I didn't even know that was a official [42:05] extension. I only knew about Iconics [42:07] plugin. [42:08] >> Yeah, it's it was actually an extension [42:12] um when I was running Iconic. It it [42:14] existed. Um [42:16] >> you obviously marketed yours better. [42:18] >> I did a very good job of marketing mine. [42:20] I mean, mine my plug-in was built in [42:22] 2011 [42:24] and was was the most popular iconic [42:26] plugin. So I think it kind of signifies [42:29] that this maybe should have been [42:32] available like [42:34] >> uh eventually that plug-in became more [42:36] than just additional images but [42:38] >> yeah it had video and stuff in the [42:40] gallery. [42:40] >> Yeah, we had video and like gallery [42:42] layouts and things like that. Um [42:46] but yeah like having more than one image [42:48] on a variation just kind of makes sense. [42:52] Uh there's the concept of wish lists and [42:54] save for later that uh one of the teams [42:57] was working on. Um this is the the Woo [43:00] sprinkles where you've got major admin [43:03] uh UI cleanup and a new settings UI. [43:07] Um the modernized product catalog which [43:09] is the work I was talking about with the [43:11] product list and and a bit of uh bulk [43:14] editing in there as well. [43:16] There's a dual API and uh a dual REST [43:20] API and GraphQL API, which is something [43:24] I need to dig in a bit more about, but [43:27] it seems like a cool project. Um, [43:31] better MCP and abilities [43:34] uh for Woo Commerce, block- based email [43:37] editing improvements, and performance [43:39] improvements, including with uh checkout [43:43] draft orders. Um, so I would say that [43:48] I would probably say that all of that [43:50] work was RSM work. Uh, RSM radical speed [43:55] month. [43:56] >> Okay. [43:56] >> Um, [43:58] so that's a pretty cool batch of work to [44:02] to come out of, you know, one month [44:04] >> um that we maybe wouldn't have seen, you [44:08] know, without that. Yeah, those are real [44:11] features that will make a noticeable [44:13] difference to Woo Commerce stores. [44:15] They're not just tiny little tweaks. [44:17] They're proper features. [44:19] >> Yeah, exactly. And like I say, there was [44:22] 174 projects. So that's, you know, some [44:24] of the features that that were worked [44:25] on. Uh, and I think now that we're kind [44:30] of going back to normal, um, whatever [44:32] normal looks like now, I expect there'll [44:34] be some some shift in in how we work on, [44:38] you know, a more permanent basis, [44:40] uh, to to be a bit more agile, to be [44:43] able to [44:45] um, you know, work together in smaller [44:47] teams. I would hope slightly larger [44:50] teams, you know, three to four people [44:53] um and actually ship things, but there's [44:57] going to be some work to [45:00] uh assign the projects that were being [45:03] worked on to the relevant product [45:06] managers of the particular product areas [45:09] um and kind of prioritize and and make [45:11] sure that they don't just end up [45:13] disappearing because I think there's [45:15] some some very cool stuff that was [45:17] worked on. There was a few uh AI things [45:20] which all worked on as well. Um kind of [45:23] like inapp chat experiences [45:27] uh which were pretty cool. Um I'd love [45:29] to see a bit more of them happening. [45:34] >> Um but yeah, there's there's tons of [45:35] good stuff that was worked on. I'm [45:37] excited to kind of [45:39] uh you know figure out which of those [45:42] things can actually go into core. And [45:45] I I think like I said, one of the things [45:46] we need to do is make sure there's like [45:49] cohesion between those projects that [45:51] we're not duplicating efforts and um you [45:56] know, repeating or creating like [45:58] different experiences um in terms of UI [46:01] and and UX. [46:04] Um, but I guess that's where the the [46:06] blockers start to come in and and you [46:08] know divert away from the [46:11] uh expectation of radical speed month. [46:15] >> Yeah. So you mentioned about hoping it [46:18] would become a more usual way of [46:20] working. So what made speed possible [46:23] that isn't normally there? Like what was [46:26] actually different so that so much could [46:27] be get done be achieved in such a short [46:30] time? [46:32] I think a few things. [46:36] There were still some blockers um and [46:38] I'll get to that [46:41] there. There was the concept of like [46:43] anyone can do the work where normally [46:48] we have our you know specific roles and [46:50] we we go through the process and the [46:52] work goes down to an engineer or a [46:55] designer um and they implement the [46:57] thing. [46:59] Um, so I I think the allowance for [47:03] anyone to be able to [47:06] actually produce code or you know UI or [47:09] UX [47:11] um whether that was the actual code [47:13] that's you know added to the product or [47:17] more of a prototype that can be uh you [47:20] know adapted and and turned into a [47:23] actual thing. [47:25] Um, [47:27] I think one of the blockers that we [47:29] still had was [47:31] once the work became a PR, like [47:33] specifically for WooCommerce, [47:36] um, [47:39] we we were allowed to just merge that [47:42] stuff and [47:45] you know, you should be responsible for [47:46] whatever you're merging. Uh but a lot of [47:50] it we felt needed still some like uh [47:54] engineer input and human input like we [47:57] don't want to just rely on AI to produce [48:00] code and hope that it you know works the [48:03] same way that we would expect. [48:05] >> Let's hope so in a product as important [48:07] as Woo. [48:08] >> I think so. Um [48:11] I I think there's going to be an influx [48:13] of you know AI based code. there already [48:16] is uh an influx of AI code that comes [48:20] in, you know, from internal teams, from [48:22] contributors. [48:24] Um, and one of the challenges that we [48:26] need to figure out is how [48:29] how do we review that [48:32] with human capacity [48:35] reliably? I think there needs to be [48:38] some level of AI review that we can [48:40] actually trust. [48:42] Um, because at the moment it's [48:46] there's some like logic to it in terms [48:47] of our or some context to it in terms of [48:50] our codebase. [48:51] Um, but there's still like a level of [48:54] distrust I think between [48:57] just allowing the AI to say, "Okay, [48:59] yeah, I approve this change. Let's merge [49:01] it." Um, we [49:04] >> pretty much everything that's been [49:05] reviewed has had an engineer uh review [49:08] it and you know flag things that the AI [49:11] AI has missed like um, you know, [49:14] backwards compatibility or extensibility [49:18] or you know if if the if a designer [49:21] wasn't part of the project like this [49:23] design component is different to, you [49:26] know, how we're doing it over here. And [49:28] there's a lot of that context that um [49:32] not everyone has. So I think [49:36] the smaller teams that we create uh [49:40] assuming it goes that way. I think they [49:43] need to include [49:46] they need to cover the skill set of [49:48] product design and engineering whatever [49:51] you know whether one person can cover [49:53] multiple uh parts of that triad or uh [49:57] whether there's like an individual [49:59] person for each of those areas but I [50:01] think like those core things need to be [50:03] covered um and that allows us to produce [50:08] quality work and work that aligns with [50:10] everything else um as well as like the [50:16] the way we're moving is very much more [50:17] towards design system type work. Um, so [50:22] we're we're reusing components rather [50:25] than designing UIs uh per project [50:30] and I think that's going to enable us to [50:32] be more confident in the code that the [50:34] AI is producing uh alongside you know [50:37] whoever's using that as their tool. Um, [50:41] and I think there's there's some level [50:43] of AI review that [50:46] needs to happen [50:48] uh to get it to a point where we can, [50:51] you know, 80 to 90% trust it. And then [50:54] the human has [50:57] uh they're not they're not as much of a [50:58] blocker because they have um they trust, [51:02] you know, the the review that's been [51:04] done already. uh and they're just kind [51:06] of signing it off and and topping it up [51:09] to the 100%. [51:11] Um so I don't know what that looks like [51:12] at the moment. [51:14] >> Yeah, at Barn 2 we have a well we only [51:17] have one QA person but his whole job is [51:20] to do QA and he sets up automated tests [51:23] but a lot of it is manual checking and [51:26] we haven't seen a way to get rid of [51:27] that. So, do you have QAS at Woo or does [51:31] it always go to a fully qualified um [51:34] developer? [51:36] >> Uh, I would say it probably goes mostly [51:38] to the engineer for or like an engineer [51:42] that is uh responsible for whatever area [51:45] the the code is, you know, based on. So, [51:50] we might have specific engineers that [51:52] are experts in the checkout and cart. uh [51:54] we might have engineers that are experts [51:56] in uh the rest API or the store uh API [52:01] and [52:03] yes someone from one of those teams [52:04] would be the person that goes to to kind [52:06] of quality check that code. [52:10] Um [52:12] but yeah, I [52:14] I feel like [52:17] their time is better spent actually, you [52:20] know, creating the thing rather than [52:23] reviewing. [52:24] >> Well, this is why we created a dedicated [52:26] role. Obviously, it's costsaving as well [52:29] because a QA person is a lower band than [52:32] a senior developer. So it works really [52:35] and and actually they're better at the [52:37] job. Um did most in my experience feel [52:41] free to shoot me online for this or [52:43] whatever. Um most developers are not [52:45] good at testing whereas a dedicated QA [52:48] has is can often be much more methodical [52:51] knows exactly what tools to use to [52:54] record and replicate and explain the [52:56] issues and generally does a better job [52:57] of testing. [52:59] >> That's interesting. Yeah. I think one of [53:00] the things that we do uh and that the [53:04] AIS tend to pick up on is that most of [53:06] the work that gets built comes with some [53:09] sort of test as well. So the PR usually [53:12] includes um you know some some codebased [53:16] test. Uh but it's definitely I think [53:20] there's two aspects to reviews that slow [53:23] things down. Uh AI is great at creating [53:26] PRs that have thousands of changes and [53:31] for a human to review that [53:34] takes a lot of time. Like they have to [53:36] really think through every change that [53:38] they're seeing. Um [53:41] and I I think that's the kind of thing [53:43] that the that an AI could review and we [53:47] could have some level of trust in. And [53:49] we do have AIs that review that stuff [53:51] already. Um, but there's still I I feel [53:55] there's still like a level of distrust. [53:56] Like I wouldn't just blindly say, "Okay, [53:59] yeah, that's perfect." Because we have a [54:01] responsibility to everyone using Woo [54:03] Commerce. Um, you know, and people are [54:06] are running their livelihoods on on this [54:09] platform. So, we can't, I believe, just [54:12] ship code that we haven't looked at. [54:15] >> Yeah, I think the distrust is entirely [54:17] appropriate. AI is an additional tool [54:19] for more robust testing. [54:21] >> Yeah. So I think we'll see some tooling [54:24] that is AI based that helps us to [54:27] improve that process uh or or you know [54:30] reduce the time that that process takes. [54:33] Um and then the other side to it is like [54:35] the actual manual testing that some of [54:38] the work that comes through uh requires [54:42] and that's kind of hard to again trust [54:44] an AI to do. Um, you know, you have [54:48] tools like ghost inspector that that do [54:51] it and you can review that. Um, which [54:53] work pretty well. Uh, or playright now [54:56] is is the the choice of AI tools. Uh, or [55:00] or clauding Chrome, I guess. Um we we [55:04] did a few experiments of [55:07] uh whenever a PR is created if if the AI [55:10] sees that this has a visual change or [55:12] like a UI change it would automate in a [55:16] sandbox um testing that and [55:18] screenshotting it. uh one of our [55:21] engineers, Zvatan, um [55:24] created a tool that took a screenshot [55:28] and then highlighted the specific thing [55:30] in the screenshot. Uh which was pretty [55:32] cool cuz it [55:33] >> it really like [55:36] I guess if you trust that screenshot, I [55:38] feel like a screenshot is more [55:39] trustworthy than it just saying, "Yeah, [55:42] it works fine." Um [55:45] >> as long as human looks at it. [55:47] >> Yeah, exactly. Even then though, I still [55:49] feel like you would want to manually [55:51] test it. [55:52] >> Um, so maybe it's just a case of getting [55:54] those environments and like the the [55:56] configuration needed to test it more [55:59] automated. [56:01] Um, so yeah, those are those are some of [56:04] the challenges I think with [56:07] >> with the current way of working. [56:10] >> Yeah. Well, it sounds like a huge amount [56:12] was achieved. Um, it's it'll be good to [56:14] see those bits go live soon and other [56:16] bits maybe more into the future. Now, I [56:19] think we've covered it pretty [56:20] comprehensively. Is there anything else [56:22] you'd like to say about Radical Speed [56:23] month before we finish? [56:26] >> Uh, just that I think it was a great [56:28] experience. Um, I really like that we it [56:33] was like a month-long hackathon [56:34] essentially. Um, it gave everyone an [56:37] opportunity to use AI and explore AI. [56:42] Uh, and you know, the concept of a [56:44] smaller team and partnering with someone [56:48] um, it gave everyone the opportunity to [56:50] do that and and express their ideas and, [56:53] you know, get their ideas out there um, [56:56] that maybe they don't normally feel [56:58] comfortable doing. Um, and I think doing [57:02] that is going to act as like a bit of a [57:04] a reset and a refresh in how we work. [57:08] And I think that's important right now. [57:10] Um, you know, the the tooling that we [57:12] use is changing on a weekly basis. [57:15] Um, and I think it's it's definitely a [57:19] good experiment to have run. Uh, and I'm [57:22] kind of looking forward to seeing what, [57:24] you know, the outcome is, the the kind [57:26] of long-term outcome. [57:28] Um, and also whether it's an experiment [57:31] that we run again. I think like all of [57:33] the feedback I saw online because I feel [57:36] like the people doing the projects [57:39] uh in their pairs were very much like [57:41] doing it more in public. Um, there was a [57:45] lot of work that was shared. Uh, a lot [57:47] of excitement around the work that was [57:49] being shared. And I think if we can [57:51] figure out how to do that [57:54] uh reliably and cohesively, like that's [57:57] going to be very beneficial for a [58:00] product like WooCommerce. [58:03] >> Yeah. Well, as you well know, I get [58:05] frustrated by large organizations moving [58:08] slowly, which is normally the case. So I [58:10] really like this concept of a large [58:12] organization operating as a small one [58:15] and taking some of the principles from [58:17] the smaller ones like the small teams [58:19] thing you've mentioned and so on. So [58:21] that could really help things to get [58:23] done. [58:24] >> Yeah, I think so. I agree. [58:28] >> Okay. So what have we got on the next [58:30] episode? [58:32] So, in the next episode, we're joined by [58:34] Tamara Nissan, who is the chief [58:37] marketing officer uh of Woo Commerce, [58:39] and we're going to talk about how we can [58:41] all work together to promote and grow [58:43] Woo Commerce more effectively. [58:45] >> I believe that's scheduled for the 22nd [58:48] of June at 400 p.m. UK time. [58:51] >> Yeah, I'm looking forward to that one [58:53] because I've recently I did my checkout [58:55] summit talk and then I published a blog [58:57] post about how I think we should be [58:59] promoting Woo. So, I'm looking forward [59:01] to talking about that. [59:03] >> Me, too. [59:04] >> So, um, if you don't already follow us, [59:07] then subscribe, follow, etc. YouTube, [59:10] we're do the woo podcast x We're do the [59:14] woo and you can find all the places to [59:16] follow us and previous episodes on [59:18] dothew.com.  ## Highlights - We had complete free reign... essentially every single person in the company apart from some select people were asked to pair up into teams and essentially work on anything that they wanted. - Note: 📚 RSM demonstrates small teams ship faster than traditional development processes · - Timestamp: 00:03:12 - Core methodology explanation - Why this matters: Challenges conventional wisdom about corporate development requiring extensive oversight and process layers · #atom/literature/h1 - 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.' Because we have a responsibility to everyone using Woo Commerce. - Note: 📚 AI code generation requires human review for production e-commerce systems · - Timestamp: 48:15 - Code quality discussion - Why this matters: Defines boundaries for AI integration in mission-critical software development · #atom/literature/h2 - Most of the stuff that is coming is behind a feature flag... 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. - Note: 📚 Feature flags enable rapid innovation while reducing production risk · - Timestamp: 35:45 - Feature deployment strategy - Why this matters: Provides framework for balancing innovation speed with stability requirements · #atom/literature/h3 - Large organizations can achieve startup-like development velocity through structural constraints - Note: Holds when: Clear constraints are defined and enforced; leadership provides complete creative freedom within those constraints; existing processes are temporarily suspended · - [[Startup development methodologies]] — because contrasts on organizational scale · #atom/zettel/z1