[Music] [Shaun McCran] Today we have a session about Visual Comfort and their progressive journey across storefronts.
The key thing for this is it's a great story and we're really keen on you participating in how this journey has happened for the company. Visual Comfort has obviously Kevin here on stage with us who's going take you through that story, but they also have a whole team of people. Does the team want to wave? Anyone? Whoo-hoo. We're here, right? So there will be time for questions and answers in this session. We'll do that at the end because we want to keep the integrity of the story together. And also the team are here, right? They're here for the next couple of days. I heard they were staying all weekend, having a bit of a festival. I don't know if that's true. So reach out to them. Talk to them about the story. The reason they're here is because they want to share this story with you, bring it to life. And if you're in a similar position trying to do the same thing, they are a great example of how they have lived that process. With that, I'm going to keep it quiet. I'm going to hand over to Kevin, and he's going to take you through himself, his role, and who Visual Comfort are, and how this all came to be. [Kevin Visco] All right, great. So welcome. Glad you're here. Hopefully you get something valuable out of this session because this is a tough one to have. At the end of the day, I'm between you and drinks, food, everything at the reception. But my background is in product management. So I want to just set that context. As a product manager, I'm going to give you the high level journey that we were on with Edge.
That said, I have my technical engineer here with me. So if we do have more technical questions that you want to get into, we can certainly do that at the end. But again, my background's in product management. And what I'm going to share with you today is our journey, our journey to Edge Delivery and the agile process that we followed to get there. So I'm really going to start out first, give you some background on what Visual Comfort is and the problems and goals that we had. We'll then talk about that process that we had to get to that journey, those outcomes that we were hoping to achieve and the problems we were hoping to solve. And then also share with you some key learnings. And that really is what I think is really great about sessions like this, is if you decide to undertake something similar, that hopefully you get a few tips, tricks, lessons learned out of it that you can then take back. And in some cases, not repeat some of the mistakes that we made or reapply some of the successes we had. So that's what we're going to do today. And so that's my goal. So again, if you can come out of here with a few lessons learned, then I've succeeded. So who is Visual Comfort? So Visual Comfort is a market leader and premier resource for decorative lighting, architectural lighting, ceiling fans from some of the most influential designers in the world. Good example of one of our very popular chandeliers here. We were established in '87, headquartered in Houston, Texas, and we have offices and showrooms throughout the country as well as some ecommerce business in the UK and Europe as well. That's important because that sets the stage for some of the three characteristics of us that's very important in our journey here is, again, we have ecommerce presence, but we also have showrooms. In fact, there's a showroom here in Las Vegas. I don't know how far it is, not too far, but just down the road here in Vegas. So three things that I really want you to understand about our company, and that really leads into some of the challenges we're having. First is we do have B2B and B2C. We have customers that are spanning retail, trade, and wholesale. And B2B is foundational for us. Our wholesale trade is a big part of our business. So if think about that from a lighting perspective, it makes a lot of sense, right? Those are like designers that are helping customers implement lighting in their homes or builders or contractors in that case. So again, spanning that aspect of all of our customers and foundational, but at the same time, wanting to grow in B2C. Omnichannel, as I mentioned, capability is very important to us because we do have showrooms, we do have ecommerce. We want to be able to link those together and be successful in both of them and make them work to their strengths. And then design is at the heart of what we're about. As I mentioned, we have a lot of designers like Ralph Lauren and all that that design our products. So we want that design context, if you will, emotion to be throughout everything we do, including our website. So that's important. So that's what we are as a company. And let's talk a little bit about the beginning of where we were in 2024 in this year long journey. And I think what's interesting about this journey is I actually joined Visual Comfort a year ago. So I was right here at the beginning of the journey and got to see it through to where we are today, and almost a year ago to date, in fact. So where were we at? We had three things that we were having issues with. The first being performance. So we had a lot of performance issues with our website. And no matter what we could do, throwing resources at it, making some improvements to Adobe Commerce, we couldn't speed it up. The speed of delivery was also slow. We were finding it challenging to author in Adobe Commerce and make changes and deploy those quickly and easily.
It was also tough to innovate. We were struggling to innovate due to the front end complexity. We had some high level customization. And what I think was even more challenging is because of Adobe Commerce, the PHP, we needed those specialized resources to help us knowing PHP and Adobe Commerce. Finding those resources were difficult to do, expensive as well. And then dependency. The business, because of that complexity and all of that skill set that was needed, the business was reliant on IT developers to operate the platform, even for small changes. And then those small changes would build up, and we'd have this huge backlog of things that would have to happen. And then on the other side, it was impacting our development capacity for bigger things because we were doing a lot of smaller changes. So those were some of the challenges we had. In addition, we had some pretty ambitious goals. I would call them digital product goals or business goals that we were trying to achieve.
First and foremost, as I mentioned to you, that business to business is very foundational to us. We wanted to grow it, nurture it, and drive those opportunities, such as improving the account experience, the self-service experience. We also want, interestingly enough, because a lot of times the trade customers are familiar with us as a brand, their customers, even though they're implementing the lighting in their homes, may not actually be familiar with us. So we wanted to be able to use business to business to also increase brand awareness, customer experience to drive trial and conversion for all our customers.
At the same time, these two go together, we wanted to also grow in business to consumer, right? So we wanted to grow beyond what my previous manager referred to as accidental buyers who aren't aware of the brand. They find the brand out for some reason. We wanted to bring more of those into our website, into our stores, and improve that B2C experience while, again, at the same time, nurturing that B2B business.
And then we wanted to implement more agility. An agile business, not just from an agile technical standpoint, but strengthening those omnichannel opportunities as they come up between our retail and give more control to the business. Allow them to create, manage, deliver the content they want when they want it, not always having to come to IT to make changes, especially small changes. So three things that we were having some challenges with, especially around performance, the complexity, and trying to grow that and nurture that business to business, grow in B2C, and also create more agility. So that's where we were.
And along comes two perfect storms.
They're about to collide right around this time last year.
The first and the foremost is the fact that our Adobe folks, great partnership that we have with them, come in to us and give us a demo on this new capability called Edge Delivery Services. And we were blown away about what it could do. And I say we blown away. It was mostly the folks that were there before I really got there and knew what was going on with it. Like my previous manager, and Jennifer is here, saw what it could do.
But there was also a little bit of concern there on this just seems too good to be true.
There's got to be some magic behind this. We don't really know how do we implement this. Also, we're not, at that time, we're not ready to just do another wholesale migration of our website. We'd already been through a previous upgrade to Magento 2, to Adobe Comm. So there was a little bit of risk aversion there, right? So keep that in mind. We see this great capability where we can create proof of concepts of websites, web pages, spin them up, do that very quickly with Edge Delivery. But a little bit of the mystery there behind the scenes of how to do that, as well as wanting to do wholesale migration and the nervousness of that. At the same time, IT was really on this strategy of implementing product management within the organization. Product management approach, where we're driven more by impact, more by iterative approach where we take things piece by piece. And those two things came together with the idea of how we would approach our migration to Edge Delivery. A product management approach to migration where we could iterate, learn, adapt, start out small, so a product led and agile approach that would progressively migrate our storefront to Edge Delivery Services. And what do we mean by that? Well, we're going to work iteratively from ideation to release, generate value, learn as we go, lower the risk, realize value earlier, be agile, adapt as needed. And we did adapt. There are actually a few pages that we migrated to Edge Delivery Service that were never part of the original plan, these two sticking out here. And actually, I'll share those with you a little bit later around our quotes pages and our showroom pages.
So the original plan is, okay, let's do a little bit, a little bit. Let's first start with the US. We'll lead with the US. We'll do our US, which is our main site. And then we'll eventually fast follow to UK and EU.
And we'll start first with our homepage, then we'll go to our PLPs, our product listing pages. We'll go to our product detail pages, cart and checkout, and move in that iterative approach.
And how are we going to do that in that iterative approach? What did that product management look like? So some of you who have done agile or product management may be familiar with an agile approach or scrum framework. But again, at its essence, it's having small teams focused on a very specific mission that are going to work iteratively towards a product goal. So a product goal example may be to deliver that homepage experience with Edge Delivery Services. And then every two weeks, we tend to run what's called two week sprints, set up sprint goals to build and build to that release and eventually release that capability. Guided overall, again, by that product goal, incremental progress, right? And we had multiple pods or multiple teams that were all sprinting with different missions. So we dedicated-- Actually, there were two teams working together. There was an Adobe VIP team and an internal team. And those two teams would work together hand in hand on sprint, as well as some other teams or other pods working on other missions because we didn't stop the other needs of the business, right? There's other things that had to happen that needed to go on, improvements to the site or operations or DevOps. So we'd have other pods running at different-- And maybe they'd be out of sync, but they would still run two week sprints.
Had a product manager responsible for the Edge Delivery, making sure, again, that those sprint goals were being met and everything was being achieved, running through the acceptance criteria, as well as a technical lead that was managing the technical aspect of it. I did mention that we started out, we had this Adobe VIP team, and we had this internal team. One of the key lessons is that we found out, we set them up as separate teams. And the problem with that, it was very difficult to coordinate those. So as you know, scrum principle, you want to have one team that's self-sufficient. We've since approved that communication and coordination between the teams, but that's how we started. It made sense at the time. And again, we learned as we went that we wanted more integration and communication between those teams. The other thing we did was we had dedicated Edge or Edge Delivery teams focused on that and then we had separate what we called Adobe Commerce or A Comm teams. We quickly realized, as we began to migrate and move forward, and we had more and more of our site on Edge, and as you'll see later, I will share one technical thing which is an architectural diagram. There's tight integration between Edge Delivery and Adobe Commerce. So that was a little bit of a mistake saying, well, we have just Edge teams and we have A Comm teams. We really just needed teams, ecommerce teams, that had the capabilities for both Edge Delivery Services and Adobe Commerce on the same team. Some cases, that could just be two developers, one that was more of an Edge developer, one that was more of an Adobe Commerce developer. Ideally, both developers that could do both. So we started out with those separate teams that worked initially, again, when we only had a homepage. But eventually, that became a little bit difficult for us to manage. And we eventually now have teams that are both Edge. We don't call them-- There's still some legacy out there where someone will say, "Well, that's the Edge team." We don't have, and my team knows that, I'll say that. We do not have Edge teams or Adobe Commerce teams. We have ecommerce teams that have both capability for Edge and Adobe Commerce. So that was like the method of how we got there.
So let's go ahead and start this journey. Let's start the journey, go through some of the capabilities.
As we mentioned, we had some performance issues. As I said, it was very, very noticeable even to our board. So we're a privately funded equity fund company right now. So we have a board that meets from time to time. And one of the things they kept bringing up over and over again was, I guess they were running Google Lighthouse scores on our website, and they're saying things like, "Hey, your homepage is so slow. What are you guys doing about it? What are going to do about it?" But for this is actual scores at the time, that was the performance of our homepage.
Not very good, right? But I mentioned to you about that demo that we had, and that led to that light bulb moment that I mentioned was, hey, we can start to address our goals, especially like our performance goals with this capability, and of course, using the product management approach that we were going to take. So we're going to start the journey with the homepage. Again, product management approach. We'll start out small, get a quick win. MVP concept, if you're familiar with that, minimum viable product, let's just get the homepage out there. We'll start with that. We'll see how it goes.
Well, two weeks to implement. These are the scores afterwards. Massive performance improvement, quicker edits for the business, easier personalization and content.
This, right off the bat, okay, this is a journey we want to take. This is a path we want to go down. This is definitely going to be an improvement for us. We'll still continue this more incremental approach. Homepage is successful. Let's move on to the next one, product listing page. So for the homepage, we're going to move on now to the next part of our journey. Again, progressive migration here. Just do this in pieces. I should point out at that time, the only thing that was Edge was the homepage for the US. We'll come back and we'll eventually get the homepage for the UK and EU. In fact, that's on Edge today. But right now, it's just the US. Let's do the PLPs. Again, these are actual scores at the time, performance scores of 26. Our categories are still managed in Adobe Commerce. You'll see that architecture later. We still have a lot in Adobe Commerce. We're still very reliant on that integration component. So we have our products and categories managed there, and then they'll be listed in the storefront via Edge Delivery. So our product listing page...
Well, pattern begins to emerge.
Performance up to 91. This is actually the graphic at the time. You'll see there's reference quotes to as high as 99. Significant performance improvement.
Performance is going up. Our Lighthouse scores are going up, which is hopefully in turn driving that traffic to our site. But we're also seeing other benefits. More flexible, easier content management, simplified DevOps, more reliable code, and improved QA automation. It just made it easier for us to automate, and we were actually on a journey to do more QA automation as well as get more coverage of our testing and tie that automatically to our deployment.
But as I mentioned, we were agile.
Along late summer, we've got a success going on our homepage. We got our PLPs. If you recall, the plan was, okay, we're going to go to our PDPs next. Well, there's two things happening at that time. We see the value from the PLPs, and then we have this big implementation in the company to migrate to Dynamics 365 project. And we're going to migrate our quotes to Edge Delivery. We're going to have to make changes to our quotes page anyways. So we figure, well, if we're going to have to do that for Dynamics 365, let's go ahead and do it in Edge.
And another thing that we could also experiment and learn as we go here is what if the Edge Delivery page could bypass almost Adobe Commerce and get a lot of its information from an API? That's where almost that quote information's coming from, so what if we can just do that as well in this new page? And so we developed this new Edge Delivery quotes page.
So now we're being a little agile here. We're pivoting a little bit from plan, but we've got this new Edge Delivery quotes page, better experience, fewer errors, improved showroom application integration, remember that omnichannel capability that we're trying to get to, as well as what was really critical about this is because it's now on that simpler development platform of Edge, it's foundational to a bigger strategy we had known as Unified Cart, which was to set up this concept of having an ability to unify the cart between our ecommerce site as well as our showrooms. And this gave us capability to grow with. Remember one of the problems I'd mentioned to you before about innovation? Now we have a capability to innovate on this, and we have. We've been adding more capabilities to this. We actually have several features right now in progress to add more and more capabilities to our quotes capability. This gave us an innovative platform.
We decided to be agile again. One of the PMs that's actually here in the room today decided, hey, we're going to do this other new capability where we're going to basically take our showroom page, and we're going to put that to Edge as well, because it naturally fits with how we want to manage showrooms, which is just a list of information for each particular showroom. And wow, wouldn't it be wonderful if we could manage that in our document capability of Edge, which was Excel spreadsheets? So here's what this is. This is actually a copy of the actual Excel that's on the website with all the showroom information in it. So if you have a particular showroom, address, that capability, another Excel sheet that then shows what elements of that data should be displayed on the showroom page. And voila, a showroom page through Edge Delivery. So if you need to make changes, capabilities, improvements to it, you just go into update these Excel sheets, preview it, publish it, and you now have updates to the showroom pages.
So we're starting to, again, see this benefit beyond just performance with just how simple it was to manage this capability.
At the same time, we're doing Edge Delivery, I do want to make a point here that we're looking at improving our storefront capability across the board and another related capability for Edge Delivery that we're doing, and we're hoping to go live with any night now, any day now, is further improving and simplify our content management with images and other media managed from Adobe Experience Manager assets. So putting all our images, all those wonderful, beautiful product images that you see on our website in AEM, being able to auto scale those...
Feed them through the URLs to those images through our product information management solution and be able to display them on our commerce as well as in our showroom application. So this actually is also part of our journey of improving that whole storefront experience, the Edge Delivery, along with our AEM capabilities.
So I promised you I would get a little technical here...
But I do want to show the architecture because it does bring out a few learnings that I want to bring up.
This was our architecture before Edge Delivery. Pretty straightforward. Wanted to keep this fairly simple in the sense it just shows you the fact that we had basically our Commerce Cloud with Adobe Commerce, some Fastly (CDN) caching capability, some API connections connecting to Commerce Cloud, and then we use Bloomreach for our search capabilities. So this was our architecture at the time before we started down Edge Delivery.
This is what it looks like today. Okay, so...
That may seem like it added some complexity. Yes, it did. It did in the sense that what's really important is you do have to understand that there is this integration that you now need to think about between Edge Delivery and Adobe Commerce and how you're going to make sure that they work properly together. It also brings to life the fact you're going to need to make sure that you have people on your team that can understand these capabilities because they are integrated, right? That's why I mentioned to you before about these pods or these teams, right? Some of them, we don't have an Edge team. We don't have a commerce team. We have teams that have both capabilities in them.
Also, the way we were actually publishing the document, the content management, we're using SharePoint.
And SharePoint folders, we have the content in there, in different folders for the different countries. And we are using Word documents, Excel documents primarily in there. This also highlights, though, when you're thinking about this architecture, think very carefully about this SharePoint setup or how you're setting up those documents and the access to those documents. We started out with just one folder called website...
And it was all the content, right? And so you can imagine that that's your production content. It's our staging content. It's all the content. So there could be instances there where somebody could publish a page. Maybe someone made a change in, preview it, but then along came someone made another change. So understanding that is very important. And when you start to build and think about your Edge Delivery DevOps process, understanding how you're going to set that up. Today, we now have three folders. We have the website folder, website stage folder, website dev folder. And we're going to be able to move things from different ones and make sure that we're not publishing things to our production environment.
So that's the structure that we had. Again, very important to know it does add some more additional complexity that you need to plan for. Make sure you have the skills in place to manage that, and then also make sure you're understanding how you're going to manage that SharePoint or that content.
So what does it mean to develop a storefront on Edge Delivery Services? So I do want to share a few highlights here before we dive into the actual learnings, right? So there's three key things that really you get when you start thinking about developing your storefront in Edge. First and foremost, you are developing in a new way, right? You've got documents and files in the content store. It reminds me a lot of, anybody familiar with citizen development or citizen automation or thing? So yeah, you got to keep that in mind. You have this content. It can be managed by your business. Addresses exactly what we were trying to address. But that also means, again, you now have this group of folks that are managing that content, and you need to make sure, again, you set up those environments in the right way. Easier resourcing.
Remember one of the issues we talked about before, finding those skill resources that we needed to have, right? So we have Edge powered by HTML, JavaScript, CSS. We can find those skills. It was more accessible, increased our flexibility to develop solutions. And then as I mentioned, one of the benefits we didn't realize at time that came along as we were going through this iterative process and learning, Edge is built right into the development process so we can open pull requests, get auto Lighthouse scores, kick off our automation testing. All of that can be built in pretty seamlessly. So we were increasing and improving our QA test automation. At the same time, we were also increasing our test coverage, our automated test coverage, which was helping us from a productivity standpoint. So I'm going to divide the learnings into two groups. And I didn't realize this at the time I did it, but I've got, this one's like more on the positive side. The next one's maybe more on the learning side. But I've got product learnings, what we learned from the product. And then I'll share with you what we learned from the migration. Again, gets to why I'm hoping you can learn some of the things that you can take away when you undertake this migration yourself. First and foremost, Edge Delivery, it's simple. The code is HTML, JavaScript, learning curve is easy. And I mean that from the Edge Delivery perspective, not the full end to end piece, right? That's the piece that I mentioned that you also have to take into account. Connects easily to Adobe Commerce, built from the ground up as an Adobe solution, works seamlessly together. Content changes are easy to manage. Easy to edit Word documents, Excel workbooks, manage that content. You preview it. You publish it.
It's pretty incredible, right? It really does give you a very, very easy way to manage your content. It does simplify DevOps, right? So for upgrades, patches, again, for the Edge component of it, it also sets us up better for CI/CD, right? Because you can make changes and push them and publish them pretty quickly with all that automated testing. Initially in our journey, we were actually pushing out releases and changes to Edge Delivery every day. We'd make a change, we'd push it out. Make a change, we pushed it out. Now we learned a little bit later on as we became more and more mixed between Edge Delivery and Adobe Commerce that, again, there were some dependencies between those. So we pulled back a little bit on that. But as we get into more and more of the site being on Edge, we may get back to a more of a CI/CD approach, especially for our Edge Delivery content. And again, the automated testing, changing how we performed it, improving the deployments, the coverage. You can spin up websites. You can quickly test them. I mean, it was amazing there in what it did for our QA and test capabilities.
Okay, so migration learnings. First of all, we had a strategy of what we called lift and shift, right? The idea was we're going to take the content that we have on our websites, and we're just going to lift it over, move it over from Adobe Commerce to Edge Delivery Service. And that is so much almost like a falsehood that we believe. We're just doing lift and shift. Jennifer knows that, right? Lift and shift. It's just, it's all lift and shift. No, it's not all lift and shift, right? Yes, from a content perspective, but you got to be prepared for what will change. Your DevOps process to change, the architecture that will change, and start building in mechanisms to handle that. The operations may change, which is another thing we discovered when we got to the PDPs. How those are managed will actually change how the operations goes. So it's not all lift and shift. Yes, the pages themselves, they are, but you have to understand that in the bigger context of your migration strategy. Easy to manage still in an iterative approach, but you just need to think through that.
Business partnership is critical...
Not just for your website requirements, right? Thinking about, okay, how are going to design the page? How are going to place it? But also understanding the operational and process changes and the impact of that, right? For folks that are going to go into the catalog and maintaining the data, then how does that catalog then get reflected in Edge? When does it get pushed? How long does that push take? What's the SLA for that? What's the expected change? When will they see it on the website? How does it work in Edge? If there's an issue with it, how do I troubleshoot it, right? If I'm not seeing that product, is it on the Adobe Commerce side? Is it on the Edge Delivery side? All of that has to be thought about, and you need a strong business partnership to make sure that's being covered. The environment setup. Making sure you have that partnership on that environment setup for managing and governing that content, okay? The other thing to think through is what I call progressive DevOps. I talked about progressive migration, but also realize that progressive DevOps capabilities we just talked about. As you move more and more to your content to Edge, you still have to manage your development in Adobe Commerce. So how do we manage that? Combining those releases. So what we would do is initially, as I said, we were doing separate teams and separate releases, we realized that created some mistakes where an Edge change went out that turned out it was actually dependent also on a small change in Adobe Commerce. So the way we do it now is we have basically two RCs, two release candidates, an Edge candidate and an Adobe Commerce candidate. They're both pushed up to our stage environment at the same time on the same day. We run a full end to end regression suite covering both Edge and Adobe Commerce, make sure that's all covered. And then that release goes out that night, again, Edge and Adobe Commerce. So right now, we just keep them all in sync and coordinate that. But make sure you do that. The other thing to think about too, especially as you get into things like the product development pages, is also consider the use of dark mode, where you can release things. So we were doing pages incrementally, but I think we could have leveraged dark mode more where we move things out into the production environment and can do some of the testing that we weren't able to test in our stage environments and see the impact of that, right, because of all that caching and all that goes on with the Edge, also think about doing more of that. And the other thing is making sure you have the right skill set.
Just because it's JavaScript CSS, you still need to make sure you have the Adobe Commerce expertise that you need while also upskilling them to Edge Delivery, right? Because there is that coordination, that linkage between those. So understanding both is very, very helpful. And ensure there's end to end understanding of Commerce and Edge. And all your pods, as I mentioned before, or that's what we call our teams, pods...
Need to be capable in both. Because a lot of times we'll get a change, we'll have a change come through, and it'll be like change a particular feature on the site. And keep in mind, the UK and EU, even if we have a PLP page that's on Edge, the PLP page like today, right now, is on Adobe Commerce in the UK. And if that's a global change, then there's two things that have to happen, right? You have to change that on the Edge page, and you have to change that on the Adobe Commerce page. Not difficult to manage. We typically use one ticket, if you will, one user story, with just two sets of acceptance criteria for it, and make sure that, again, the development for both of those occurs at the same time. And again, it goes into that progressive DevOps process where that Edge and that Adobe Commerce change goes out at the same time. So we're already in that habit. Not a problem to do that. So just keep in mind you have that capability across your teams.
So when you put this slide in here, I thought it was funny. This is the day we were alive with Edge, we hit 99. And then what popped into my head is it goes to 11.
So anybody a fan of Spinal Tap? All right, we have a few. So I'll give you the story here because I think it is amusing. It does highlight the performance improvement we saw here. So the whole scenario there is it's a mockumentary about a rock band, an aging rock band. And there's a guitarist that takes the director in his room, shows him all his guitars and all his amplifiers. And he's showing off his amplifiers, showing how his amplifiers are special and powerful because they go to 11.
And so he says when he's up there playing on his guitar and he's rocking out and everything like that, if it was just a normal amp, if it was just a normal guitarist, I could only go to 10. But because of these special amplifiers, I can go to 11.
The director looks at him though and says, "Well, what if you just change a label of yours from 0 to 10? Wouldn't that be okay?" And the guitarist pauses, takes a moment, looks at the amplifiers and says, "Yep, but these go to 11." So we hit 11. We got scores upwards of 99. We definitely saw huge performance improvements with Edge Delivery. It goes to 11.
We were unable, and this is like a miss on our part, we didn't really measure the value impact of it. We did see across 2024, our orders revenue, a lot of increase there, but we can't attribute that clearly just to Edge. There may have been some improvement to that, but we also had some great marketing last year. We had some great effort by the marketing team. So it's hard to do that. But what we do know is performance is up.
And I just love this chart because this one, you can actually see, if I were to remove everything from this page other than the x-axis, which shows the dates...
If you can read the x-axis, hopefully someone can, but when did we go live with the homepage? May 2024.
And it's pretty clear, 64% improvement. Performance was up on our homepage. Performance was up on our PLP. We saw that across the board. Content management was easier. DevOps and code management was simpler. QA automation improved. This we know. This we saw.
So we're going to continue our Edge Delivery migration.
We had some challenges with our product development pages. We're regrouping on that. We'll be hopefully in the next month or so, we'll go live with our PDPs, and we'll continue on that journey. So what's next for us then? Well, we're going to continue to deliver impact and measurable value, start measuring the value, what we're seeing with this, of Adobe Commerce and Edge Delivery Services. So we are going to do some stabilization, upgrading, which we've done as we've gone. Quotes is a good example. We've improved the quotes pages. There were a few little things we wanted to go. We, again, follow a product management approach. So when we release things, we release MVPs or Minimum Viable Products. Get them, release them, learn about them, adapt them. So we're still improving things that even the things we have released. We're going to expand. We're going to move the product listing pages for the US to the UK and Europe. That'll go live any week now.
We're going to implement the product detail pages, the shopping cart, and the checkout page. This is an example of a mock, not example, it is the mockup.
It is the latest mockup.
It was a mockup of the checkout page. The nice thing about this is this is actually a slight change in our checkout too. It's a single page checkout. We had two-tab checkout before. So improving that, hopefully to drive up more conversion with that. And that will be done, again, in Edge Delivery.
We're going to continue to enhance new and improved content. We got new professional pages, new headers, new things that we're going to do with our content pages, and continue to enhance it and continue to improve it.
So that's what's next for us. We're continuing on this journey, continuing to see that success that we've seen, and continue to deliver value. So three key takeaways. And hopefully you've got these already, and I'm just reiterating them. And if you didn't, then it's my fault for hopefully not making sure I covered these well enough. First and foremost, the progressive migration, or as I like to just say, be agile, right? Take it little by little, piece by piece, progressively migrate parts of your storefront to Edge Delivery. Just keep in mind, again, that linkage that you have with Adobe Commerce as you do that, not impossible to do. You can do it. And it can just move parts of your site to EDS.
Prepare for the transformation. Again, plan for that new approach to content development, DevOps, testing. It is transformative. And I'm intentional in using that word because with transformation comes a lot of change, right? You need to think through some of that, how that change is going to impact your business, how it's going to impact your business partners and the operations, how it's going to impact the way you do business and DevOps, how your teams are going to be structured. We've hired-- How many Edge developers have we hired? Like four or five, six, and we've had to go out and hire JavaScript and Edge development capability, right? So these are the things that you got to plan for. And that relates to upscaling those teams, making sure your teams, not just know Edge Delivery technologies, but that you have this end to end capability of upscaling, training, and documentation. One of our most powerful technical leaders right now, he comes from a deep background in Adobe Commerce and he's learning Edge. But because of that Adobe Commerce understanding, he's picking up Edge pretty quick, and he can understand that end to end integration very, very well. And that is very, very powerful. So keep these three things in mind as key takeaways. Progressively migrate, prepare for your transformation, and upscale your teams. And hopefully you can have as successful a journey as we had with Edge Delivery and see the performance that we saw so you can take your website to what? - [Man] Eleven. - Eleven. All right, don't forget to give feedback here. I'll leave that. Do want me to put it on like the slide where we take Q&A here or-- It's in the app. Okay. Yeah, do you want to go back to that one? Yeah. So thank you, Kevin, for that walkthrough on where you found success, where you hit some roadblocks, how you changed the organization to show what you were going to do across that process. As is usual with most of these types of projects, it's really a combination of technology and people and process. And I think you brought that to life extremely well. Don't just implement a new piece of technology and expect it to work because you have to adapt to it. And I think the processes you went through there were exemplary in how that works. What Kevin and the team described is that progressive migration through the storefront homepage, through the PLPs and PDPs and all the way through the cart and checkout.
We have many other examples of people doing it entirely randomly. So you can approach this in any way you want. Some customers have a conversation with other Kevins and they go, "My PDP is terrible." So you can focus on that one bit. The idea is that this is de risking what you're doing with your storefront. I'm in the Commerce team and we appreciate more than anything that changing a storefront is risky, right? It's high risk. It's your shop window into the world. In this case, you have 50 other actual shop windows, but it's your experience for that digital platform. So this whole approach has really been built fundamentally into the core of the product so that it's de risking it, so that it's bite sized pieces that you're comfortable with and you can release when and how you're ready. There is no big bang approach to this unless you're doing a net new instance and then that's a different story. So it's really about how you're comfortable and how you're realizing value in a way you want to that results for value for your business. What Kevin described is great in a way that they had a homepage problem, so they focused there first, drove value, resolved that issue, and then looked at the next opportunity. It's exactly what we put it together for. So, Kevin, thank you very much for taking us through a story. It's amazing.
Excellent. We're all good.
[Music]
