.png)
The FODcast
In the FODcast (The Future of #DigitalCommerce) we explore the real career stories of the people who have made it to the very top of the sector and those who are working at the cutting edge of innovation and change right now. Listeners to the podcast gain insight into the journeys industry leaders have taken to be where they are today, the challenges they are facing now and their aims for the future.
The FODcast
RE-RUN: Are You Ready for Composable? Hard Lessons from the Frontlines
For our latest dig into the FODcast archives whilst we gear up for Season 7, we’re revisiting some of our most popular episodes and a topic of conversation that is still as relevant now as it was back in November 2023 when it was recorded.
This re-run episode features a candid conversation with David Hardiman, former Head of Software Development at Wiggle, about his experience leading a major retailer through a two-and-a-half-year transformation from a 20-year-old legacy system to a modern composable architecture.
This episode sheds light on the complexities of composable commerce that often go unspoken. David pulls back the curtain on what happens when the nine-month transformation you were promised stretches into years of challenges, unexpected hurdles, and hard-earned lessons.
He discusses managing 150 different integration points, selecting the right components and partners, and the crucial importance of understanding the problems you're trying to solve before committing to a composable approach.
Since this episode aired, the landscape of digital transformation has continued to evolve. David's insights remain incredibly relevant, especially as the future of eCommerce is increasingly shaped by AI and large language models.
If you’re navigating digital transformation, rethinking your tech stack, or simply looking for expert perspectives on the realities of composable commerce, this episode is a must-listen.
Simply Commerce is the leading supplier of talent into digital commerce across technology, digital marketing, product, sales, and leadership.
Find our more about our approach and our services within digital commerce recruitment here: https://simply-commerce.co.uk/
Hello and welcome to the final episode of Series 4 of the FOD the future of all things digital commerce. Today we bring a bumper episode to the series before kicking Series 5 off very, very soon. Today's guest is David Hardiman, former Head of Software Development at Wiggle. Welcome, david, thanks for having me. David brings a fresh perspective when it comes to moving towards composable architecture and, given the show's aim is to help educate those considering the move, this is a conversation I couldn't wait to have. So, david, over to you for a quick introduction, yeah so I'm Dave Heidemann.
Speaker 2:I was head of software development for Wiggle Chain Reaction. I left at the end of April, having spent most of the previous three years leading the technical implementation of Wiggle's move to composable commerce. Prior to that, I'd spent three years with Kingfisher in a contract role and prior to that lots of mobile development, so been around a bit.
Speaker 1:Been around the block a bit, it's fair to say. But just to be clear. So you joined Wiggle approximately three years ago now.
Speaker 2:Yeah, it was June, july, something like that 2020 I joined.
Speaker 1:Okay, perfect. And at the point in which you joined, how far along their Composable journey were they?
Speaker 2:Not very far at all. So when I joined, wiggle had just made the decision to sort of end of life their legacy tech stack. It served them well over 20 years, but it was in a position where we couldn't really iterate on it. It was difficult to maintain, and so on. So we were at that point considering the various options between something perhaps monolithic, salesforce, whatever, or the composable group.
Speaker 1:OK, ok, so you joined that at a fairly exciting time. Then, it's fair to say, get the involvement in deciding what and how Wiggle takes the next step to hopefully future-proof its business. Indeed, yeah, nice, okay. So I guess that leads on pretty nicely then to the first question, which what is the biggest challenge that you faced during your time at Wiggle?
Speaker 2:wiggle, yeah, so. So before I answer that, um, I just want to sort of set some, some context because it might help to to frame some of the stuff that I might say in the future that I I think there's there's kind of two definitions of composable commerce, and the first one is the, the kind of the architectural view of, of composition, and, from an architecture perspective, composition is almost always a good goal for any software system being able to scale it, being able to change it, being able to add to it in future. That composition is always helpful. But the second one, I think, is the marketing term that's used by the various SaaS providers and the delivery partners in the space, people like Mac Alliance and so on, where they're going to come along and sell to you this concept of composable commerce and so on. So neither of those things are in any way negative, but I just think, in terms of the marketing perspective, I think it's always important that people you know take what they're shown with a pinch of salt and remember that they're they're being pitched a sale all the time. So, um, back to your question what? What are the? What are the challenges we faced? I think?
Speaker 2:I think we faced three challenges in our in our program, and I think all of them ended up contributing to the fact that the transformation we went through was a lot more difficult than we thought it should be at the start. The first challenge was sales pitch from the commercial players in the world of composable commerce. Don't really take into account the complexity of your business and the legacy stuff that you've got. I mean, they can't. They're pitching to you from their perspective. They don't necessarily know what you you've got, so you might see a proof of concept or a demo appear real quickly and that's really alluring, um, especially, you know, in my case I was already quite sold on the composable architecture perspective. I thought it was the right route, um, but if someone's selling you a vision of your transformation taking nine months, I reckon that that that's probably quite unlikely if you're going for like a full scale transformation.
Speaker 2:The second challenge we faced was finding the right experts to lead us through the transformation. You know there's loads of SIs and delivery partners who can come in and help you, but you need to find the right one for you and they need to prove that they've got experience with the components you've selected. Or maybe you need to find one who can guide you through selecting those components, and I think that's quite important. I think one commerce engine is probably very much the same as any other commerce engine, so selecting based on commercials and license costs and so on is probably the way to go, and finding the right partner to help you pick the right one is probably going to be valuable to you in that project.
Speaker 2:We had a few missteps with partners who struggled with complexities of our world, complexities of what we'd chosen, um, so it took us a while to find the right person. Um, that that's probably less of a concern for a big company where you've got loads of architects and all that kind of stuff internally, but, um, but for us it was important. And the last one is that integrating that composable system is a really huge task and you shouldn't underestimate it. I think we did underestimate that. I think we were quite naive at the start of the program about how simple that integration piece was going to be. By the end of it we had 150 odd integration points between, you know, commerce, commerce and order management and ERP and all of that kind of stuff. So, regardless of what technology you're going to be building that in, you've got a lot of work.
Speaker 1:It's a lot of work, right.
Speaker 2:Yeah, you're going to be designing integrations, mapping messages documentation it's really intensive. Mapping messages documentation it's really intensive. And with this composable commerce idea from the vendors, very few of them are going to talk to each other directly out of the box. So there's lots of places where you are going to save yourself development time, but you might just be moving that development time somewhere else. So you know, if you were doing something in salesforce or or a monolithic system, you might be sacrificing flexibility and future scalability, but you might gain massively on the development time and the future maintenance costs. So those kind of things I think are really important for anybody thinking of going down this route to make sure that they're they're really switched on about that, otherwise it's going to take them longer than they might think okay, I think it's fair to say there's quite a lot of talk in the market already about transformations taking longer than expected.
Speaker 1:Whether that's just a misunderstanding from the customer, whether it's a slight, oh mis-selling from the vendors, possibly a combination of both, I'd imagine. Um, but uh, I guess we've all been in the scenario right where you have a demo and it looks amazing, and it looks great. I mean, we've had it here and on a substantially smaller scale to what you would have experienced at wiggle. But the demo looks perfect. And then you actually look to get it set up into your environment and it's like, well, hang on a minute, it doesn't do that. And it doesn't do that.
Speaker 2:And it's like, okay, it looked like it did when we did the demo and then you go back and forth getting the amendments but there's also the kind of in a lot of cases you'll have a, an it team or a development team being tasked with building something new, and until we've signed off the project we're not going to go and talk to everyone else within the business and actually undercover all the little complexities and so on that the business is doing, and that will again lead to additional time taken and all that kind of stuff. So you know, it's just not. It's never easy. It doesn't matter how simple you think it might be, by the time you actually sort of get to it and you uncover all of these little bits and pieces, it's always more complex than you think it will be yeah, I, I would probably agree.
Speaker 1:Um, just quickly going back to the first comment you made around um, if they tell you it's going to take around nine months, you think it's quite unlikely and possibly substantially more than that. How? How long was the process with wiggle from kind of signing off on deciding you're going to move towards Composable and then getting it to a state in which you were happy?
Speaker 2:I mean including the the sort of missteps that we had. I guess we we probably started in some vein around December 2020, um, and we finished it my last week at Wiggle, so the end of April this year, so two and a half years, and that was an MVP. It wasn't everything we dreamed it would be and, as I say, we had some missteps along the way. You can do it quicker, and I know folks at other companies who have delivered parts of composable commerce systems a lot quicker, but they were probably doing it step by step, whereas we went for a big bang approach to just get rid of all of the legacy stuff that we had to. We had so many complexities that doing that strangulation strategy wasn't possible for us strategy wasn't possible for us.
Speaker 1:Okay, yeah, I guess that. Uh, yeah, I think many that I've spoken to over the course of this series they've they've recommended breaking it down slowly and doing it bit by bit so you can start to see the roi quicker. But I guess every business is in a slightly different situation when it decides to make the move and in your case, like you said, your tech was 20 years old and you had to make the change, and that probably forced your decision making in some cases as well. Yeah, so cool. Okay, well, I obviously appreciate some of the uh, the insights you shared there. You've obviously gone through this um change over approximately two and a half year period. You've clearly learned a lot from that process, so I guess it moves nicely on to the next question, which would be um, if you had to pick three tips that you would suggest to anyone that's contemplating making the move to composable architecture, what would they be?
Speaker 2:So I think the first one is you need absolute clarity on what problem you're trying to solve. At Wiggle, whilst we did know what we were trying to solve we were trying to solve the fact that we had a system we could no longer maintain and replace. It meant that we probably weren't really analyzing what good looked like and what we were really trying to achieve. We just were kind of replacing like with like, and I think that's I think that's a case in a lot of sort of examples and people that I've spoken to, where they just they just feel like technology needs to come and solve their problems but they might not have analyzed them properly. So you know the technology on its own it can't improve your product discovery journey if your product data isn't up to scratch, for example. So you might spend a lot of money on a new mdm system or pim ai driven search, all of these kind of things that look great, but if you're not also budgeting to improve your product data now and in the future, there's only so much you can do with the technology that you put in place. You know in that example of the product discovery journey that that data is probably more important in the technology, but quite a long way, because you've got really high quality product data. You can use any old search engine to make it discoverable and at that point, the humans doing the work to make sure the data is up to scratch it actually ends up being more important than the technology. So you'll watch a sharp sales pitch from a search provider that shows AI returning amazing results based on vague queries or natural language search terms. But you've got to remember that those demos are deliberately generic and they may well not apply to your product set. Once you get it in second tip. You know, once you know what problems you're looking to fix, you need to prioritize them and work through them methodically. So you should be looking to strangle your system and I I think if, if you're in a position, like we were, where that strangulation is really difficult, I think you kind of need to wonder whether you should be looking at composable architecture straight out the gate. You know, if we'd gone with something monolithic, that might have just given us something really basic to get out the door really quickly and then we might have been able to look at strangling that monolith. So you know, it might have cost us more in terms of license costs and it will add a different complexity, but I think it would have. Possibly I don't know it might have made our overall process a little bit quicker.
Speaker 2:I'm not sure, but I think if you're not able to do it step by step, you know, if you can't replace your commerce engine with commerce tools, for example, and then move on to something else, there's an element of additional complexity and, as I've previously alluded to, the last tip is don't underestimate how complex this is. You know you are going to see lots of demos that say this is going to be simple and quick and we'll have you up and running in composable commerce in no time at all. Um, but it is complex. So find a partner with a coder accelerator who can you know, who can get you set up with something really basic infrastructure and a rough site as quickly as possible and then customize from there. Um, but. But even then there's lots of work to do, because what they've got is you know it's generic, they're taking that to their customers and using it. You're going to have lots of work to do as you add in the bits and pieces that you want to use um and that you know.
Speaker 2:That's again why, again, why I suggested finding a partner first. There's several on the market who have these accelerators and when we found one that had an accelerator, it gave us a big bump. It moved us along a lot more quickly. Their preferences are probably similar to what you're already looking at, but where they might differ, they'll have done it for a reason and it's probably good enough. You've got to remember that. The nature of composable means any choice you make today isn't binding. You can replace it later. So get your system live, work with what you know, work with what got you live quickly and then look around on the market Is there a better search engine, or do I want to add something over here, or whatever. That's the whole point in Composable is. It means you can swap stuff out as you come across it.
Speaker 1:Awesome. Maybe that can get overlooked sometimes as well, because I feel, like you said, the idea is you can change the product as and when you need to. You don't need to do everything from day one. Like you said, maybe, change, have you, have your, your commerce, whether that's commerce tools, for example, possibly even a monolith like salesforce, and then you might go and make it headless. You might then change the cms or the pin you don't need, you don't need to do everything in a 12-month period. But yeah, so the point you mentioned there about the third, about the, the, your tech partners and your integrators, um, and do you choose the partner first or do you choose the software first? And I think you you mentioned, possibly pick the partner first and then you can pick the software, following some of their previous successful case studies, yeah, because you know they know how the software works in your. Is that for you? Is that quite a big, a big factor?
Speaker 2:well. So, as an example, we we had a bit of a misstep with with one of the components that we chose. So we we chose it because it was functionally at the time superior. And then our project wasn't going particularly smoothly, so we changed our delivery partner and our delivery partner said to us you know, if you swap out that component for this component, we're probably going to be able to save you two to three months on what? What we reckon. The estimate is um.
Speaker 2:So now we've got some license costs spent. You know, you could be there in the sunk cost fallacy and say, look, we spent money on the license costs, so we're going to stick with it. Thankfully we didn't. We we moved on to the other thing. But actually these things move so quickly that actually by the time we'd made the decision to switch the thing um, the thing that we switched to now, actually by the time we'd made the decision to switch the thing um, the thing that we switched to now actually had the functionality things that made us choose the other thing in the first place. You know that, okay, they're all competing against each other and if you know, if you've got a piece of functionality missing in in this thing they will be trying to catch up to, to these definitely yeah because otherwise they're not going to get any business.
Speaker 2:So if somebody's advising you to go with something because they'll get it out the door quicker, you might as well do that, because even if it's missing a piece of functionality, first of all that company's going to be trying to pick that functionality up because they have to. It's competition. They'll lose you if you don't, and if they don't, you can move to it in two years, um one, you know. Once your license original license agreement runs out, you can move to that thing that you liked in the first place. But you've got your project live, yeah that's it.
Speaker 1:You prioritize and focus on what's likely to get you live quickest and easiest, yeah, and where they're going to be more complex, integrations, getting two softwares to actually speak to each other.
Speaker 1:That makes sense as well, and I guess that goes going back to the question. It shows the invaluable insights of the right systems integrator, of the right systems integrator, because they will be able to tell you what they said around this piece of software being able to save you maybe two or three months from a time perspective, which is interesting, I guess. Yeah, I mean, there's probably pros and cons to both, but, like you said, reality is, when you look at the different softwares, a lot of them are actually very similar in terms of what they offer, and it's probably a fair point in saying that if one can't do what the other can, it's going to be working really hard behind the scenes to be able to have that functionality in the shortest time frame possible. Yeah, um, so, um, yeah, interesting one.
Speaker 2:One other thing I guess you need to remember is that all of these systems are quite complex. You know, if you need to set commerce tools up to work how you want it to do, it's it's not a zero cost thing. So having somebody that's used it is really important. If you choose something they haven't used before, your delivery partner might have a ramp up time or you've got to bring people in house to to get up to speed with it, and so on, whereas if you've got a delivery partner who already knows how to do it, that's going to save you a lot of time.
Speaker 1:Yeah, I would agree, and I also think that's something that's really important when companies make the move towards composable architecture, is they use a delivery partner that actually has delivered composable transformations as well. We're starting to see a lot of work go to some of the larger consultancies and the quality is not quite there from what we're hearing. Now I don't know the ins and outs of anything, but from what I hear in the market anyway, if you look at some of the smaller boutique systems integrators that focus entirely within composable transformations, they're normally the transformations you hear going better than the ones that are delivered by your larger consultancies.
Speaker 2:Yeah, and I think nobody should overestimate how complicated software development is in terms of writing code. Writing code is rarely the most difficult thing, and lots of my, my previous uh developers will probably hate me for saying that, but writing code shouldn't be difficult. The difficult bit is in the system design and the architecture and so on. So if you're, you know, if you're going with one of these smaller boutique companies, as you say, who have, you know, a lot of experience in architecting these systems, you could even go with a hybrid model where you're getting bums on seats, developers from you know from another supplier, but you've got one trusted person leading you with the design and the architecture of the system. I think if you've got, if you've got the, the experience in the architecture, you can get developers from anywhere. Developers take a, take a user story and they code it up and hopefully they do a good job, but if the design is wrong in the first place, then you're, you're in a you know you're, you're in a hole from the start.
Speaker 1:Yeah, I would certainly agree around the design. Wonder if we'll get any backlash from developers after seeing this. But there we go um cool, okay, so um, moving on to the next question then, um, we have, in your opinion, if slash any, um, what type of customer should avoid moving, uh, towards composable architecture? Right, so I I think there's a maybe three types in my head.
Speaker 2:Um of all, if you don't plan to have a technical team in your company long term, whether that's via permanent hires or by a trusted outsourcing partner, don't touch composable.
Speaker 2:You're going to have custom code, and when you've got custom code, you've got bugs, you've got security issues, you've got dependencies that are getting deprecated and need updating. So you're always going to need to have people on hand to do some work in this. Even if you never plan to do any more functional development, you need to be prepared to maintain this system. So maybe your initial delivery partner is the right one to be with long term. Maybe they're not, but you need a long term maintenance strategy and if you don't have that, don't touch Composeable. The other type of customer I think should avoid it is one who doesn't have any particularly big functional ambitions. If you just want search and browse and checkout and then you're sending an order to a warehouse to be fulfilled, salesforce Shopify whatever they can. If they can cover your functional ambitions today, go with them.
Speaker 2:There's an acronym in the development world Yagni. Why a GNI which stands for you ain't gonna need it, and it applies here. Don't get carried away with future ambitions. If you can see something off the shelf that covers your current ambitions, ultimately, don't build something that you don't need now. Wait until you need it to build it, and so you know really, look at your ambitions and look at what sort of retail organization you are and then really consider those monolithic platforms because they may well be good enough and if they're good enough, that will save you a lot of complexity.
Speaker 2:Um, the last type of company I would suggest probably misses it is somebody starting up, somebody new to the market. Get something that does everything you need simply with a you know, a small team that can maintain it and then start moving to composable, as you do outgrow this system. You know you can. You can always expand on something, but it's much. You know you can always make something more complex as you need it, but it's difficult to rein that complexity back in if you start complex and then realise you wish you started you didn't need to.
Speaker 1:yeah, yeah, okay. The second point you made I found quite interesting, because I guess that whilst you're saying if you don't need it now, you're probably better off to wait until you do need it, I guess there will be many out there that would say, well, why not future-proof your business and invest in this now?
Speaker 2:So I guess I guess I guess my point there is that there's nothing wrong with future-proofing If you know exactly what your ambitions are. But if you're not clear on what your ambitions are, do you genuinely think that your ambitions might outgrow what they are today? If you don't have a real clear plan of what you're going to be moving to in the future, then probably sticking with something that is an out-of-the-box commerce solution is not a daft thing to do. You know I said previously you need to be really clear on what kind of problems you're trying to solve, and this is kind of what I mean is that you know, if you don't have a really clear roadmap and you don't have a real keen core understanding of what it is you're trying to solve with composable commerce, you probably don't need composable commerce. What you need is a rock solid commerce platform that your customers are going to be able to get onto your site, find what they're looking for, check out and have it delivered.
Speaker 2:That's most of what most commerce sites are. Hopefully they'll grow beyond that to be something more interesting in the future. But if that's what you're looking for, how much of that do you really need to build yourself? I think a lot of the time you may not. If you're a huge retailer, absolutely you want to own a lot of that technology and you want to be in complete control of it because you're huge and you've got so many different customers that you need to cater for and so on. But if you're, if you're relatively small in scale, you probably don't need that complexity and you may never need that complexity yeah, I think that's fair to say.
Speaker 1:I think sometimes you can create more work than needed. In fact, a couple of our previous guests have also said similar when one of them had actually gone on the journey and they decided that actually they don't need everything that they have. They're paying huge licensing costs for things like Adobe Experience Manager and they can actually get pretty much all the functionality they need from Shopify Plus. So they're on a journey back towards Shopify Plus because it's going to save them an awful lot per month and they can still do what they need to do and there's one or two things that they can't do. But they've decided that actually that's not fundamental to the business and they're better off going back to there and starting again.
Speaker 1:So I think it goes back to the key. I mean, the key theme I think in this conversation is you don't let the technology decide what you you want to do. You understand your problems first, get clarity on where the problems are, how you're going to solve them, and then you pick the tech to say, okay, this is the right tech for us and, let's be honest, you could even go and, as we said, go for like a sales force and if you want to get a particular loyalty piece and pick the right loyalty and then integrate that into your sales wider Salesforce or SAP or whatever. Yeah, exactly, cool, okay, so moving on. The next question is in your opinion, what is the biggest upside of moving fully composable?
Speaker 2:Yeah, I'm not going to spend a huge amount of time here, because I suspect that your, your previous guests have probably sold this already.
Speaker 2:But ultimately, if you don't fall into the categories that I've just said, I think the flexibility you gain from composable um, a composable architecture, is hugely valuable.
Speaker 2:You're going to be able to add new components as you need them, swap stuff as you find something better, cheaper, whatever and it also allows you to focus on building the pieces of the system that are most important to you, whether that's the front end, because your customer journey is really important to you, or you've got a really complex distribution model, so you want to build your own order management system.
Speaker 2:Whatever it is, it gives you that complete control to decide where you're investing your time and focus and then buy other bits and pieces off the shelf. So for any reasonable size mature commerce organization with a good development team, composable is almost certainly the right choice. Whether or not that is, you go on the Mac Alliance website and you cherry pick all of the bits and pieces that you think are right for you, or whether you're building it yourself, that composable architecture is almost certainly correct for you, but you've got to make sure that you're approaching it with your eyes wide open. As to as to the fact that it's not easy, so, yeah, you know, I think that I think in general, the advantages are obvious.
Speaker 1:What's less obvious is the disadvantages okay, and the challenges actually that it takes to to get the business in a, in a position where it's operating functionally on with a fully composable architecture and and that's it, and then that's the whole reason behind this, this, this show as well, because it's it's all well and great marketing a product and saying this is the best thing since life spread and, let's be honest, the mac alliance are very good at marketing, um, but actually what? Uh? What people need to understand is the blood, sweat and tears that can go into a transformation and and actually some of the smaller things. Like you mentioned at the start, the 150 integrations that you had to put together alongside another member of the team I can't remember who you said and that's that's the stuff that doesn't get spoken about as much, and I think a lot of people see it still as the the lego bricks and you just put them together and it's like wow, if only it was that easy, right?
Speaker 2:I mean yeah, and you know there are places where it is Lego bricks and you can connect stuff directly, you know, but that depends on the component that you choose and whether they happen to have felt there is commercial value in them in integrating something directly with another component that you use, and so on. So there's loads of good software available in the Mac Alliance and probably from people who aren't in the Mac Alliance and so on. So there's loads of good software available in the mac alliance and probably from people who aren't in the mac alliance, and so on. Um, it, it's a, you know, it is a really kind of useful organization that they, all of these people, have come together and they're they're, you know, selling this vision. But you just need to be, be careful and make sure that it is right for you and that you can afford to implement the the complexity that's going to come with it okay, something I've found pretty interesting.
Speaker 1:Um, recently I was at the ecom expo at the excel. I believe it was a few weeks ago and I think the day before or maybe even the day of the show, commerce Tools announced its connector I can't remember what it's called, but it comes with pre-built connectors to other independent software vendors that are Mac Alliance members. Now I think there was only four or five for now, but I understand it's on their roadmap to increase that dramatically. Do you see that as a bit of a game changer when it comes to the different vendors actually having pre-built connectors to talk to each other? Do you see that as saving like the, the end customer and the, the integrators quite a lot of time when it comes to integrating into the architecture?
Speaker 2:uh, difficult for me to say without having seen it. You know I haven't spent the last six months looking at um stuff like that in particular. But it could do. But it's going to depend on on what those components are that they're integrating to and and how customizable those integrations become, because, you know, can you always guarantee that one customer's message from system a to system b looks like all the other customers? I don't know the answer to that um, but probably say not.
Speaker 1:But yeah, I don't know the answer either it's.
Speaker 2:It's definitely a step in the right direction and the closer that the the vendors in the mac alliance can get to just being able to talk to each other out of the box um, the the more, the more close they're going to be able to get to actually delivering the vision that they sell um. But you know, a lot of these components still need significant configuration to do what your business needs them to and when. When you configure it in a certain way, does that, does that affect the out-of-the-box integrations or not? I don't know the answer to that. Yeah, but yeah, if they're, if they're making those, those inroads into those um, into those integrations. Yes, of course it trims down that catalog of integrations that you need to build, but there's always going to be systems that aren't included in that catalog, I think there would need to be.
Speaker 1:By the very nature of it being bespoke and composable to your business, there's always going to be that work required. But yeah, I guess, if you can take that from 150 to 70, for example there's half the workload you would hope it improves the time and everything else that comes with it. So I think it's. I think it's interesting. I mean it's brand new. I've not seen or heard of it actually in play so far, so I guess that'll be quite interesting seeing that pan out over the next sort of 12 to 18 months. Um, and yeah, take it from there. I guess, like we said earlier, these companies are always looking at ways in which they can improve their product offerings, whether it be individually or collectively. So that's cool. And then last question then is how do you see the next two years looking?
Speaker 2:Yeah, so I spent a bit of time thinking about this and I'm not an expert and I'm not an economist, so I think that a lot depends on whether the economy picks up and so on. I think you're going to continue to see the folks in the Mac Alliance pushing Composable as the one true way. You're going to see lots more competitors, I think, join the market. I'm sure we'll see a ton of sales pitches about AI and how it's going to revolutionize commerce sales pitches about AI and how it's going to revolutionize commerce. If we don't see lots of large language models making functional ripples in the commerce space, I'd be quite surprised. I mentioned earlier about product data, for example, and could you use an LLM to improve how searchable your product data is? Lm to improve how searchable your product data is, use that to attribute it better and link to other products, and so on. I suspect we'll start seeing stuff like that. We'll probably see more improvements in customer segmentation, hopefully in a way that respects customer privacy, but unfortunately probably not. But if the economy doesn't pick up, we're going to actually see quite a lot of stagnation, I think, in this space and we're going to see retailers decide to keep cash in the bank rather than spend on it because you know their sites probably work quite well already.
Speaker 2:Um, I, I, I would be surprised if, in the next couple of years, we see anything major that truly changes what an e-commerce site or app is, and you know again what I'm saying.
Speaker 2:What I'd hope is that more retailers are going to understand that the technology alone won't solve their problems. It might solve some of their problems and it might improve user journeys and so on, but to be truly successful in being different to their competitors, it takes more than technology. It takes improvements to people and processes and data quality and so on. So, companies, if they commit to the maintenance of those complex systems and improving all of the the dependencies for those systems, then you might see some real, real improvements to you know what an e-commerce site looks like. But if you don't, um you, we probably won't see any major differences. So ultimately, my main message is that if you don't get your foundations right, you're going to continue to struggle, even if you change your technology, and I think hopefully over the next couple of years, people are really going to start understanding that it's the foundations of the business that are more key than whatever technology is ultimately serving pages to customers.
Speaker 1:Yeah, I feel like we've probably already seen a couple of really good examples of that as well. Look at the turnaround for M&S, for example, over the last couple of years. Your car should have served back five years ago. They were a business that was in turmoil and they were in serious trouble. They've obviously appointed the right people. They've stripped it back to looking at, okay, what are our problems? And also what, where do we want the business to go like, what do we want to do? And they've, they've, they've stripped it back. They've understood exactly what problems are wanting to do and then they've then used technology off the back of that to then execute that vision and they're now thriving. Basically, they're doing really well. I think, profits are back on the up and they're obviously in the press regularly for good performances. I think we've seen fairly similar with Matalan as well.
Speaker 2:You can solve a problem in multiple different ways, but if you don't understand it, you won't solve it at all.
Speaker 1:I think it's on that note. It's a good way to wrap up the session. So, yeah, look, thanks again for your time, david. Really appreciate your time as well as your willingness to talk through sort of the genuine experiences that you face at Wiggle. I am super confident that there's going to be people listening today that have found this very insightful.
Speaker 1:Um, yes, it can be a really good move, moving, composable, but you understand what you're getting yourself in for and, on the same note, it might also not be the right move for you, but that's ultimately why we set this podcast series up is to talk through the nitty-gritty of all of it, to give everyone the real insights as to what you can expect. Um, for me, I think the underlying message and we spoke about this a few times today is uh, understand your problems first and then pick your technology, not the other way around. Yeah, so, uh, thanks for tuning in. Uh, if you're still listening, please do like and subscribe. Um, please share. Uh, it really really does help. Um, spread the word and I look forward to seeing all of you very, very soon for series five. Thanks again.
