Justin:

Digital Commerce is a field of contradictions. Today we talk about Unifying and Customizing Multinational Brands, dealing with dumb systems in smart architectures, we also talk about Plumbing, Big Feelings when things go Bump in the Net, and how knowing how to spin a yarn makes for better products. Let’s unravel this, shall we?

Welcome to Commerce Chats from High Velocity. I'm joined today with Jamus Driscoll, the CEO of Elastic Path. Welcome, Jamus. How are you doing today?

Jamus:

I'm doing great, Justin. Thanks. A lot for having me on.

Justin:

Excellent. Well, could you tell me just briefly a little bit about Elastic Path and what you guys do? I'm sure you're used to doing that.

Jamus:

Yeah, I am a little bit, um, very excited to do it. So Elastic Path is an e commerce company. Um, we are a part of the movement of 100% composable, meaning API first modular architecture. And we power the commerce for some of the world's biggest online shops, including T-Mobile and Comcast and Intuit, Tesla, Pella, windows, Konica Minolta, and a number of others. A little over, you know, 200 plus customers in the business. Our proposition is really around allowing customers to deliver commerce the way they want, not necessarily the way a platform would dictate and back that up completely. With an ethos around customer success and outcomes, we often refer to ourselves as a customer success company that happens to have the world's best products.

Working with Multinational Digital Commerce Brands

Justin:

Pokemon International, Konica Minolta. I'm particularly interested because those are Japanese based companies. I mean, you have a very strong identity and culture. Uh, and then when it gets into E-com, it takes a little bit of nuance. Can you talk to me a little bit about, like, what it's like dealing with internationally based companies, maybe ones that use like different topographies, like, different language support,

Jamus:

I'd be happy to. I mean, say it goes to our overall ethos and what we do with a lot of companies and most of our, our customers. So those companies typically, you know, often have a unique way of delivering commerce to their to their consumer. I mean, Pokemon for certainly for certain is a highly experiential company where it's a combination of both, um, raving fans who are closely attuned to particular drops or things they may do with their characters, um, and products. Konica. Konica minolta as well as do a lot of our other other customers. And so we work with them to make sure that the teams are equipped to drive the right experience for them in the right markets. And every market behaves a little bit differently. Every team wants to operate a little bit differently, understanding the nuances of the consumer and what the buyers are. So what we offer to them is the means of controlling that experience and delivering the kind of commerce that makes sense for each market and each consumer experience that they want to offer, all the while without sort of coming in and legislating exactly how it should work. So within, as you mentioned, particularly large international companies where there's lots of different ways cultural and consumer experience, ways of going to market, we give those teams the means to design the experiences that are right for them.

Justin:

Yeah, I find that that's interesting because you have brands that have a certain feel or persona, like in the States, and maybe the States is their biggest consumer but in their home, on their home ground, it's a very different I mean, the branding might be the same, but it's a different brand experience depending on where you are.

Jamus:

Yeah. For certain. I mean, this was something that, you know, I learned over, I don't know, 20 plus years of digital is that there are competing forces, particularly in large multinational companies, um, that represent a technology and business challenge for them. On the one hand, the company believes there's efficiency to be gained by having centralized technology and making sure that things are done a certain way, because otherwise it can become a free for all. And that's not really desirable. It's not driving the expense leverage and productivity usage that, that, that they would want. Yet each local market is unique. Each local market has a brand proposition to deliver a way that consumers want to engage cultural variances, differences, merchandising differences. And so one of the big challenges historically has been how do you maintain centralized technology while at the same time giving the right freedom to the P&L groups that are running separate markets so that they can optimize the opportunity? And that's historically represented, if you will, a challenge with the cookie cutter based approach to commerce, which is, as Henry Ford would say, any color you like as long as it's black. Well, black doesn't work in every market. And so you have to find the right balance between, um, control and autonomy. And, um, you know, that's something that we think about a lot here.

Justin:

If you're in 45 different countries, uh, the chances of you having one CMS and one payment gateway are pretty slim. I mean, you want to have one, right? You want to have one and do that. Does composable make it easier for that or do you still try to keep it? I mean, as much as I don't know, I mean, because from your perspective, I guess you're you're selling, but then you're also like you say, be the customer, right?

Jamus:

Totally. Uh, totally. Well, I mean, composable for what composable does has a lot of advantages. And I'm sort of caveating on this because, yes, the composability of an architecture meaning highly modular API first, allowing interoperability of components gives a freedom to various groups if they want to change components, you know, and if you will tailor the architecture, all the while getting reusability globally at the component level. So there's a lot that, you know, composability does to help that. It also provides to the market the freedom that, hey, if there's a unique piece of dev that a local market wants to do, a unique feature, a function, that market can do that without blowing up the entire architecture, right? And that's always been the hard part. How do I use the monolith? So there's a lot that that does in composability to make that achievable. And there's also the benefit of centralized IT components that are built in regions can be used globally. So there's a lot that goes on where the team can sort of collaborate around an architecture more so than you could around a monolith, where every market has to send its requirements to the centralized office or then prioritizes and decides and, you know, that stifles innovation and freedom. So that's the architectural benefits of composability. That said, each of the components also has to be has to deliver capabilities that help solve that. So particularly acute is the catalog. Um, so on the one hand the corporation wants to make sure that, you know, you've got the standardized catalog to sell for your market and region, yet you got to have full control over exactly how the assortment presents, how things are priced, what gets presented when, and then those are regional merchandising and catalog controls that, you know, you have to have the right composable piece in order to do that. It's less so than just saying it's composable, and therefore, because it's composable, it'll solve everything.

Gleaming the Cube Tweaking the Monolith

Justin:

You mentioned tweaking the monolith. It sounds like a 1990s skateboarding film. Yeah. Uh, but okay, so let's say I'm coming to you, Jamus and I am limping along. I'm on an end of life platform. Uh, there's no support for it. It's a big monolith. Uh, what am I doing? Am I am I replatforming I mean, like, now we're talking about, like, modules and stuff like that. You mentioned, un- platform. Right. What is that process? What am I doing? How can you help

Jamus:

Right. Well, to, you know, go back to what you're saying. I mean, that's certainly something that we, you know, every customer we speak with is in that spot where I have something that's running right, so life won't stop if I don't change things. Occasionally it is burning platform issues, but by and large, customers have something that's been working. Um, and often these companies have gone through 2 or 3 whole wholesale architectural changes in their history. And, you know, that cycle, um, you know, being an industry of 20 years now, you've seen that cycle a few different times. It starts with the promise of the new the new platform all the hopes and dreams go into it. There's a large expense. There's a year of development, a year of implementation. There's joy on the first, you know, 90 days to six months where everyone's really, really excited. And then the requirements come and then we figure out how do we adjust and change that lives alone for a while. And then the replatforming cycle starts again. And that's been something we've been doing for, you know, 20 plus years as an industry and justifiably, there's a fair amount of fatigue with that right now. Um, because what you're saying and if I'm doing an ROI analysis as customer, I can clearly quantify the risk of getting it wrong. It's harder to quantify the gain of getting it right. And because, you know, you know, boy, if I mess with the money button, I know what things look like. But if I get it really, really right, am I going to generate a return that far outstrips that risk, I don't know. And then that's again, to put yourself in the shoes of the customer. That's something that we hear a lot. So one of the things that we've certainly focused on is a much more risk adjusted way for customers to evolve their current architectures, and it often starts with, hey, I'm on platform X, I'm frustrated. I know at some point I might want to get off time for development, time for upgrades. Performance isn't exactly what I want yet, but now I got to go jump into a whole new vendor and a whole new relationship with someone I don't know. Geez, that feels risky. Um, so coming back to our ethos as a company, we typically start with a customer and say, well, what do you want to solve? Never mind platform this or platform that. What do you want to solve for? What is it the value that you want to get? Where do you want to take this? Why do you want to take this a certain place and then ask the question, are you open to incremental steps? I mean, we've got this mentality that a replatform has to be all or nothing, and I would say is largely a vendor driven agenda, less so than a customer driven one. Customers want to solve their problems. Um, and if you solve enough problems successively over time, great. Right. Then you're getting return from each incremental initiative. So we have talked to customers about how is the best way to solve the problem

And sometimes that doesn't require a replatform it requires incremental steps. But customers want to know does do those incremental steps add up to something over time that gets me to a better future? Yes. Can I get off the train at any point in time? That makes sense. Yes. So that's the way if we were approaching things where something was so important as commerce, we'd say, how do we eat the elephant, a little bit at a time, knowing that we're on our way. So when we approach customers, that's often how we want to drive the conversation. If there's something they need to do right now, great. We can help you with that. If there's something that you say, listen, let's just do it a piece at a time and see how it goes and make sure we're getting good value. Great. Let's do that too. As we all know, digital for all we've been doing is still a journey. And so that journey is going to is going to continue.

How to deal with “Dumb” systems in Smart Architectures (or Renovate your Bathroom)

Justin:

Let's say I have an AS400 somewhere, right? I've got some big iron in the back that I've never seen, but it's something that it runs all the things, like all the money things you talk about, like money buttons, sales, audit, financials, all of that. It is dumb as a stump. But we get key like catalog data from that. But it's making all of my other systems stupid because of that data structure. Is that is that inescapable. How do you handle that if you're I mean, sometimes you're just like, we just gotta get up. We gotta get live transactable, but you end up with a smart platform, but it can't do anything. How do you how do you handle that from from a consultative perspective?

Jamus:

I mean, it's an excellent, excellent question. Certainly. You know, we see this a lot. I mean, I think a lot of this is sort of plumbing in my house. Um, yeah. Right. If I'm going to upgrade a bathroom Well, I want to talk about the vanities. I want to talk about the new shower. I want to talk about those things. Um, and I want the plumbing to work, and I want to reuse the plumbing. I don't want to in order to get the new vanity. I don't want to tear out the plumbing all through my house just so I can get a vanity, right? And I want to be bored with it. So I think one of the most important things that an architecture can do is to respect and understand that, and to understand that there are certain things that you want to do, the minimum amount of plumbing disruption, and you think about layers, if you will, in what you want to touch and don't touch. There are core systems that have run that are bulletproof, that continue to go, that don't need to be disrupted. The AS400 for example, um, and the question is, how do we leave them where they are reliably get the data from them and bring them into a system that allows us to then do the things for the business that we want to go do without having to necessarily tear out, you know, the AS400. And so we think about that a lot, which is let's bring the data forward into an environment that the merchandisers and marketers can work with. Let's make sure that we're respectful and understanding of what the back, you know, infrastructure has to look like and remain and then allow the business to progress from there. Um so a lot of it is just understanding where and how and what needs to be disrupted with the goal of disrupting, frankly, as little as possible.

A Neck to Wring: Service Accountability and Composable

Justin:

I've been I was with system integrators for like 15 years. Uh, and I've seen a lot of this kind of progression. I saw the emergence of headless, which sounds like badass, but is sometime I mean, it's metal, but I it's not necessarily intuitive. And we mentioned like composable pre composable. Now people are talking about single contract as the holy grail for this. Is that the vendor holy grail is that the customer holy Grail is that like just negotiation fatigue? What is what is that or do you buy that?

Jamus:

Um, well, it's an excellent question. And I sort of go to what the what's the root of that? Um, and I certainly believe that anything a vendor does should be driven by what makes the customer's life better. Um, I mean, that's what vendors are here to do. Provide the technology and enablement services and consultation to help customers achieve their outcomes. So I think a lot of the conversation around getting all of it onto a single, a single contract, um, you know, is a bit of a pendulum swing. And one of the things that sort of come up about the world of composable is, okay, great. I can choose any component I want. Okay. Now I have 18 contracts in my commerce architecture. Now I, as a customer have to think about negotiating that piece. I got to think about how does it all integrate. I got to think about what happens in terms of uptime, availability, support, what happens if something goes bump in my architecture and 18 providers are saying it's not us, right? So there is a pendulum swing where there are to acknowledge it. There are real benefits of a monolith. We don't want to toss the baby in the bathwater. And the benefit of a relationship is digital can be complicated. Um, and what the monolith provided is all the pieces stitched in a certain way, delivered underneath a single relationship with a vendor. And you knew exactly who to call if something went wrong. Um, and you knew exactly that, all these pieces, you didn't have to get the headache of figuring out how to stitch it all together. And that came with the downside of, again, you can have any color you like as long as it's black, because that's the proposition. It's all there. It's all stitched. It's stitched this way. You have a single a single contract. As long as you're willing to you know, conform your business to exactly how this technology works. Well, that's proven to be an unpalatable trade off. Hence the rise of composability of look, I want freedom right to drive. But that came with additional complexity. So the concept of having a single, you know, contract, we also look at it as a single support relationship, a single player to talk to when something you know, when you want to have one party to go to. So the single contract is a manifest, a manifestation of that. But it's not about the it shouldn't be about the vendor agenda of selling more technology. It should be about simplifying the relationship. I mean, we would say to the customer acknowledging the things that are great about a monolith and acknowledging the things that are great about composable. Wouldn't you want the best of both worlds? You know, all the good stuff and none of the bad. And the answer to that is yes. And so you're seeing a lot more of a push toward getting to the fact, getting to a point where customers can have, if you will, sort of the things they loved about the monolith with all the benefits of composability, contracting with one of them.

Big Feelings When Things go Bump - The Reality of Support in Multivendor Architectures

Justin:

I've definitely been on ones where we had a caching issue and you should see the blame just scoot around all these different vendors, you know, As we were trying to figure out why a page was taking six seconds to load, uh, and yeah, being able to call somebody and say what? You know, what, just went bump.

Jamus:

And that's, I mean, that's a real that's a real thing. And, you know, let's put ourselves let's exercise empathy and understand what the customer is feeling at that moment. Right. Revenue is in processing. The commerce engine is faltering. Those are periods of, you know, um, there are very acute moments and

Justin:

Big feelings.

Jamus:

Yeah. Big feelings And in that moment, you want to be with someone who's like, look, I've got you soup to nuts, right? And yes, we may have made selections, but there are components that I don't ultimately control as a vendor. But I'm here with you in the saddle trying to solve it. And so like, for instance, for Elastic Path, we recognize this early if someone has a relationship with us we have first line support agreements over the entire solution. Um, because call us and we're going to help you triage this, and we're going to help you understand where things are going. Bump, what's working, what's not working, what's firing, what's not firing. And we're going to fix it with you. And I think if you say it's not my problem because my product, my APIs are up, well, that's not really demonstrating customer empathy and understanding and fulfilling our obligations of service.

Unicorn Coding Ninjas and Integration Platform as a Service

Justin:

So when we talk about composable headless, like you mentioned, you have different relationships and you have the way that you have them talk to each other. And sometimes you're supposed to be using services and in a loosely coupled way. But then, you know, maybe you did this like five years ago and, you know, maybe some things in JavaScript, JavaScript have changed or Next.js then or whatever. And then all of a sudden you've got all of these services all entwined together, and you have to have like ninja unicorn code wizards to manage it. Is it possible?

Yeah.

Justin:

Is there a way we could not do that? Do you know

Jamus:

Yeah. I mean, I think there is. I mean, everyone's code base is a little bit different. So I sort of have to parse that.

Justin:

And, and I just want to say I love Unicorn Code Ninjas. I mean, they're they're totally my favorite. But not everybody has access to a cadre of code ninjas. So but yeah, I mean, for people who just need to maintain it.

Jamus:

Well, we we feel this has been something that we've done in our product product strategy. And a directionally addresses the question that you have is, do we feel like to make composable really work? There's been an underlying piece of thinking that we felt has been absent. And again, this comes from if you walk in a customer's shoes, you think this way that we felt one of the important pieces underpinning it all is the concept of a commerce ipaas, or integration platform as a service. And think about that as the back, the back plane in which all the components plug and interoperate. Um, and it also provides the opportunity to pull all the pieces together to create your own pieces, and then, most importantly, to have full visibility over the entire architecture and how it's all working. Um, where in the absence of something like that, then it's really point to point integrations, and everyone's got to figure out how to connect your product to that product to the front end, and that won't change the front end. I got to isolate the codes there and oh, wait, I want to change this component. I got to rewrite all the integrations. Um, and all the while I'm at a customer and uniquely in a position of I'm the only one that knows how it all works, right? That doesn't feel like a great spot to be in. Um, and so the concept of having a backup plan, which we built is, as you want to change components, you have isolation of concerns that allows those components to be changed, all the while maintaining visibility, performance monitoring. Um, and we feel like that's been a missing piece again, sort of going to the monolith, stitched all that together in a way that eliminated the need for something like this. When you separate the components, well, it becomes more important. Um, as Beethoven said, music is the silence between the notes. It's the same with composability. It's how the products and their components interoperate in a way that maintains elasticity and optionality is a very, very important part of architectural considerations.

Justin:

That's something that I've noticed that it's almost like, uh, an evolution. It's like you, you kind of come into a new form, this new structure, but now we're having to, like, evolve gills or lungs or something because the environment itself is, has changed. Uh, and that's, that's one of those things where it's like you talk about like, uh, a unified support ability, uh, you know, the, the isolation of concerns like, these are things that you don't talk about whenever you're in the honeymoon period, like with a platform. You know, I was in a I was in a BA perspective. So a lot of this was trying to elicit that and trying to get some of that stuff out of the client's brain because they were like, this isn't documented. Go talk to this one guy, you know, or gal, right, right. Uh, so I think that's something that is a feature that that is evolving,

How Writing for an Audience and Storytelling helps Develop better Products.

If I could take a little bit of a turn here. You started in editorial,

Jamus:

I did.

Justin:

You were with Outdoor Life, is that right?

Jamus:

That's right.

Justin:

I started in online editorial. It's interesting. I've run into a few people in e-commerce, and they all came from, uh, the editorial realm. I, and I can tell for your your your piece on the ship of Theseus was this chef's kiss. I love that, uh how how did you go from editorial to CEO of Elastic Path? Maybe not the whole way, but how did you get into e-commerce from there?

Jamus:

Um, well, it's an interesting question. I would say, you know, like a lot of journeys it's not always a straight line. Um, you know, one of the things that I discovered in editorial was communication, understanding what audiences wanted to hear and understand, understanding the language that they use, not the language I think they would use. Right. All of those things were necessary skills. And so I was learning a lot of that while I was, you know, editing and writing articles about, um, taking an academic background and as an English major, but then sort of moving that more into understanding consumer storytelling and what that looks like.

I also had an entrepreneurial bent. Um, and so I ended up segueing that into marketing at startups, um, where you're trying to convey often in a startup land, really at the time that I was there, really detailed technical products in a way that laypersons could understand and relate to, and it was bridging the gap between what the technology can do and why it really mattered. Um, and that sort of led on a journey in marketing for a while. Um, and then over into more broader executive leadership and then ultimately to a CEO position. So that's the short, short form of a long story.

Justin:

Well, it actually makes sense, I think that, uh, writing for an audience is so much different than writing academically because, you know, it's the whole RTFM thing. You know, it's like nobody is going to read this if it's long. You have to get start with what you're going to say, you know, and you're writing for an audience and making sure that it's understood. It changes your brain. And I think, you know, that leads into that communication. You know, it leads into trying to find out what's motivating people. You know what, what's compelling to them

Being Mindful of the People behind the Product

Justin:

I got into e-commerce because I enjoyed the, you know, the product management element. But, you know, I saw people suffering in the systems that they were in. The merchandisers just completely overwhelmed. I mean, a lot of the monoliths, you know, of the past, uh were I mean, they're really I mean, there's a lot of complexity now, but the stuff that like merchandisers and the day to day users had to deal with was so overwhelming that I was just like, I need to make their lives better. Uh, and it's talking about what they need.

Jamus:

I mean, I think that's such an important part. I mean, um, you know, our values as a company are around really trying to walk in the customer's shoes. And when we think of our customers, well, we often reference them by the names of the companies they work for. We're thinking about the individuals who are directly engaging with our tools and our people and our products and we think about how can we make their life easier, better, more productive. And we let that flow into what we do as a business, which is predominantly in software and also related services and enablement capabilities. But we start with that's why I mentioned it, which is we think about customer success as the first metric in our business. It just happens that we do that by technology. Um, and I think it's an important way that we differentiate from others in the market where here's your best product here, go for that. But you don't develop empathy and understanding for the broader fabric in which customers operate and what their day to day lives are all about. We push ourselves every day to live in that reality.

Justin:

Yeah, I well, as a systems integrator, in my experience, like one of the things that I really worried about is you would go in and you would see somebody whose entire job was to keep a certain technology running, like they would do, like a daily feed

And they were basically having to do a CSV, you know, data massage to add in a single character. And that was three hours of their day every day. Right. And anything that we can do as vendors and integrators to, you know, prevent that smiting drudgery with gusto, you know, that's great. It's, uh, it was. Yeah, it was that was back from my editorial days. We did you know, that's what we decided our our promise is going to be, um, so it and pardon me because I've never do people do you have SSIS or do you do your own integrations. I've, I have not had the opportunity to work with Elastic Path before we do.

Jamus:

We work with a number of SI's. Um, and we also have our own professional services team. Um personal services team is focused on, you know, obviously making sure our customers are having successful outcomes. Um, and so we work very closely with them on particularly if we're doing new product or a new use case or an initiative, our team will often take the first pass at that. In the spirit of again coming back to our ethos, we want to learn the hardest use cases first so that we can enable and train others. Um, as opposed to, you know, throwing our friends and colleagues into the hardest use cases initially, we're with them no matter what

Um, so we're very open to it. So our customers typically deploy in one of three, three ways if they have an Si partner. Um, we support that partner. If they don't and they want to work with us, we can support that as well. Or we can support the customers often implementing it themselves, which a lot of our customers do.

30 Years of Ecommerce: What we’ve gotten right, what we should work on next.

Justin:

Depending on how you quantify it, e-commerce is about to turn 30 years old now. It's. Yeah, uh, it's funny because there was I remember like in the late 90s, somebody was writing about like the long now and talk about we might be living in the digital dark ages because we haven't. I mean, the Wayback Machine isn't doing it for me. As one of my previous mentors says, as a modern day Herodotus, the historian, looking back upon what are some of the things that that some of the newer practitioners should know about that's happened in these past 30 years?

Jamus:

Yeah. It's fascinating. Um, you know, it has been a journey and it has been one as an industry that has gone through a lot of, um, ebbs and flows. There has been a continual arc, though, in our industry, even if you go back to just dating it by technology, where, you know, we've licensed an app server and built our own framework on top of that, and then that became the full packaged commerce platform, and the commerce platform became the SaaS platform, and the SaaS platform became, um, headless and composable. Each bend of that curve has resulted in a fair amount of transition and change. Yet the constant of it has been a desire for all of us to incrementally work at higher levels of productivity. So by moving from an app server to a full commerce platform, I didn't have to think about all the code I had to write, and I could think about what to do with it. By moving into SaaS, I didn't have to think about upgrades and performance and cloud and all that. I could just work on top of that. Now, as I work into composable, I can think about now, what can I do with the platform? Not necessarily just deliver the platform. So we've been constantly moving in every one of our roles into a higher level of effectiveness and efficiency, where technology is continuing to set a higher bar, allowing us to, you know, now create and innovate on top of that. So this curve for us as an industry has been fairly constant, um, as the need for innovation and advancement continues. And that's something that's just going to continue as a trait of our industry. You know, it's the only as I think about the technology of digital, it is the only enterprise application that I'm aware of that directly touches the consumer. The ERP doesn't, Financers don't, um, you know, warehouse doesn't. Yet by touching the consumer, it's directly exposed to consumer innovation cycles, which are rapid. So we have this, um, if you will interplay of long running technology systems meeting fast iteration of consumer cycles. And that creates an inevitable tension, which leads to what I was talking about earlier. So we're going to keep on that path that is constant. Um, back to sort of a look back on 30 years, and it's remarkable that it's been 30, you know, for all that we've done in digital and it's been terrific. It's been great. Um, we've really only truly nailed one consumer experience on it, which is the B2C shopping experience. Others were still innovating and testing. Um, how best does digital relate to the physical store? How does B2B work? How does B2B2C work? Um, how do we really incorporate marketplaces directly into our online online presence? So much yet to figure out that, um, it's both exciting to say it's 30 years in and it's given this wonderful rise to so many careers and opportunities and, um, advancements. And yet we're still at the foothills.

Justin:

Jamus Driscoll, thank you so much for joining me today. It's been a delight, uh, talking with you. I hope that we get to chat again soon sometime.

Jamus:

Okay. I look forward to it.