George Jagodzinski (00:00): Why is it that to create a more human-centric e-commerce experience, all we had to do was chop the head off? Today, we talk about headless commerce. Why is it so hot right now? What's going on with it? Are you ready for it? Why would you move to it? And what's that journey like?
I'm joined by Furqan Munir, who is the head of product at fabric. You can find fabric at fabric.inc. They're a headless commerce platform. We have no invested interest in them, other than talking to interesting folks that are playing in this space. Furqan has a great point of view from his years at Groupon and now at fabric. And he is really pushing the boundary on a really human-centric roadmap for headless commerce. So, please welcome Furqan.
Announcer (00:43): You're listening to C-Suite Blueprint, the show for C-Suite leaders. Here, we discuss no-BS approaches to organizational readiness and digital transformation. Let's start the show.
George Jagodzinski (00:57): Furqan, thanks so much for being here.
Furqan Munir (00:59): Yes. Thank you for having me here, George. Really excited to get this going.
George Jagodzinski (01:04): Yes, yes. Today we're going to talk headless commerce, which is not new, but we were talking earlier about how Forbes wrote an article about the tremendous amount of investment that's going into headless commerce right now. And I'm curious if you have any hypotheses on why now? Why is there such a push into headless commerce right now?
Furqan Munir (01:24): I think over the last two years... I think with the pandemic hitting us, recession now on its way, I think the businesses to go digital has accelerated. That is one area where I think headless can really solve a lot of the problems, which conventional retail businesses were facing, especially with the cost of technology. Headless provides a very, I would say, easy way into scaling and growing this business.
So, I think all the right catalysts are there now for businesses to take that next step. And then, headless provides that, I would say, architecture and that path to move forward with that technology.
George Jagodzinski (02:05): There's a combination of many technologies maturing at the same time that organizations want to be more flexible than they've ever wanted to be. Over the pandemic, I would imagine... Some of them have been our clients, where they wanted to be extremely flexible during the pandemic. And then, they realized that their monolithic systems were not set up for that. They want to go in different directions, but they're just bound by it.
I'm curious, what catalysts do you typically see when people are saying, "Hey, we're now finally ready to move over to headless commerce?”
Furqan Munir (02:38): Just taking a step back or maybe trying to answer that question which you were raising. Why? And what did businesses learn?
One thing with the monolithic systems, let's say you are a merchant operating with ten or thousands of stores. You have warehousing. Now, pandemic hits, everything is in a lockdown. How can you service orders from all your store? You want to utilize that inventory. With monolithic systems, buy online, pickup in-store, curbside delivery became a major problem.
Retailers did not know how they can support this. That's where headless commerce really supports that. You can plug in a module very easily and say, "Hey, by the way, for all my online orders, here is my aggregated inventory across all my stores. Where is the customer location?" And based on that, you start fulfilling. You're selling, even if your store is not operating at a hundred percent capacity or you weren't allowing walk-ins to come in.
So, that is one of the, I would say, catalyst as how businesses learned to evolve.
George Jagodzinski (03:37): That's a big one.
Furqan Munir (03:37): It's like everything is on sale, even though you're shut down. So, that's where businesses went back and say, "Oh, my god, simple stuff." Cross-border shipping as well. I have a lot of inventory across the border. Between Canada and US is a classic example. You don't want to stop selling. Canada had a... literally, the supplies were not coming in. However, you could still ship stuff from the U.S.
That's where businesses like Amazon really took off because they could do that with ease. You could go into Amazon.com and you can put in your address from Canada, and then it'll show you options. Enabling that cross-border option, again, was one of the things which retailers could not do with their monolithic systems.
George Jagodzinski (04:18): It's probably also another example of where the pandemic just put a magnifying glass on an issue that was already there because I think what you saw, or what we definitely saw, is you'd see... maybe it was a B2B organization that they wanted to pivot to B2C and they need to do it fast. So, they just spun up a second system, maybe a second monolithic system in parallel with their existing system, and maybe a third or fourth. Now, there's a whole bunch of batch ingestion and batch integrations where it's a lot of CSVs that are floating around there and spreadsheets, and it's integrated, but it's not really integrated.
Now, that things are settling in, they're saying, "Geez, what a mess we have on our hands right now. How can we simplify this mess?" That was not a pandemic issue. Any time you saw through mergers and acquisitions, you have multiple brands within one umbrella, or you made the decision to move from B2B to B2C or B2C to B2B. This is a pattern that's been going on for decades. I think, now, it's the sweet spot of everyone's probably both feeling the pain, and, then, the headless technologies are maturing all at the same time.
Furqan Munir (05:27): I think what you just stated over there, I think that is why headless was born or it came into picture. It's that cost of technology. How do you have a single playbook which defines your technology strategy? There's a lot of tech costs and especially merger and acquisition. How do you bring different parts of your business into one tech stack?
Same with companies which operate across multiple geolocations. You have a business in Europe, the setup is primarily very different. You operate in U.S. or North America, the operation and setup is very different. How do you consolidate that into a single tech stack with monolithic system? This span of multiple instances, and they were working. But, then, the overall technology cost was so much that they needed to do something which was drastic.
That's where headless commerce, or, I would say, SaaS and all of the cloud solution came into existence because they provide that platform for companies to reduce and manage that cost in a much more better way.
George Jagodzinski (06:36): It makes it easier to select your solutions. I love stories from the trenches.
We have one where we're evaluating e-commerce platforms, and it's a global organization, and they need to accept Bletos as a form of payment. For those people who don't know what that is, it's a ticket-based cash system in Brazil because a lot of Brazilians don't have bank accounts. So, they use cash. They go to the corner store. They get a ticket; it has a barcode.
And so, now, all of these e-commerce systems you're looking at, you're now whittling it down. You're like, "Well, we have to choose one that supports Bletos.” And that might not be the best platform that's out there. Whereas, in a headless environment, you can choose really what is best for us, and we don't have to go to a lowest common denominator, or, perhaps, overpurchase because maybe the only ones that support all those global things are the super-duper complex enterprise that you don't really need at this point.
Furqan Munir (07:32): Definitely. I think that, again, brings up another thing around payments as well. Payments is a big problem for a lot of e-commerce companies out there. With all these evolution of wallets, people feel much more secure using their own where they don't want to share the credit card details or debit card details with the service provider. They'll go and they'll store it in ApplePay, Google Pay, or PayPal, which makes it very easy for the customer with one single checkout.
If you analyze the conversion on these checkouts for single-click, Amazon, it's leading it. But any other retailer who has, on the e-commerce side, has done that is seeing a massive, I would say, increase in conversion on those particular customers. Where you have a conventional input of credit card, people are still... They'll go in, and if the form is too big or too long on the end of the checkout, they'll simply... they won't complete the transaction.
So, I think having these technologies and these integrations available to customers, and completing that digital experience, I think is very, very important now.
George Jagodzinski (08:42): It is, it is. One of the other big catalysts we see for moving to headless is the merchandising, the storytelling. There's so many brands, and they tell stories in very different ways. Even if you're a multi-brand company, each brand tells their stories in a different way, all being forced into the same container of, "Oh, well. You can have these product sets. You can have this imagery. Maybe you can have a video". It's very limiting. And, I think, that that's truly where brands can find the true value and demonstrate the value to their consumers is when they can tell their story, but tell it their way.
I'm curious about your experience from a product management perspective.
Furqan Munir (09:25): I think that is very important. Again, that's where a lot of people don't better understand headless in a pure form. It's actually decoupling the backend from front end. Over there is the presentation there. With monolithic systems, it is very limiting because you're using a template. You cannot customize your storefront experience. With certain personalized brand, especially within furniture, we saw a lot of use cases with our furniture partners. Where do you want to tailor that experience for their customers? They want to have collections and pages set up, which give you a whole, let's say, living room, all the way from sofa to curtains, to carpet, to a coffee table in the middle. Even some example, they even throw in a TV which will allow you to complete the whole collection. That customer can do one single click to purchase that.
So, that is how brands are seeing these things work. With headless, this becomes very easy because, on the backend, you can compose different services to provide or build that experience. On the front end, you have an option of going limitless, almost boundless, in terms of what design and what customer experience you want to give to your customers.
George Jagodzinski (10:40): That limitless aspect is an interesting one because, well, you're at fabric, so you obviously love headless commerce. And I do, as well, just given my history and the work that we do with their clients. But I also hate to see someone choose the platform that's wrong for them, that they're not ready for yet.
I do think there are... This isn't to say that monolithic systems are necessarily bad. There's a time and a place, so if you want to be able to expand and have that flexibility and tell a better story. But if you are limited on resources, or if you're hyperfocused on what it is that you're doing and you know that your roadmap's not going to change that much, it might make sense to adopt the processes and the structure of a monolithic system. I think the important part is for people to realize when they're ready to move outside of that world, or if they know that they're not going to want to be locked into a monolithic system.
So, it's not bad. It's just different, I think.
Furqan Munir (11:40): I totally agree, and it's the size of your business. I think it's a very important factor. It's like, what is your operating capacity? How do you want to scale your business? That scale will drive what changes you need to make. Let's say, businesses operating with 10 million, 20 million, even up to 50 million in GMV, they can operate with the, I would say, monolithic systems because they have small operational teams which do multiple tasks.
So, having a closed system, which allows you to do end-to-end functions, is very good. But as you grow bigger and you want to have dedicated customer service team, you need to have a dedicated logistical team, you need to have a dedicated operational team. Then, that's where headless commerce really plays a very important part because you can either implement or bring in a full end-to-end system, or you can take one service out of a system and plug it in to build the function you need to build.
So, that's where I would see, like, when businesses are evaluating, they need to see how big or what is their expansion plan. Based on that, they need to take that decision with some data.
George Jagodzinski (12:56): Yes. You need a certain maturity to your internal engineering teams and product teams as well. When I was trying to think about why headless is getting so much investment now, one of the things I thought about also is... I was part of the team that did toysrus.com and we built it fully custom. And then, we moved it to Amazon, which was, at the time, it was one of the first headless platforms at that point. And then, we built more mature systems with microservices.
I found in the early days of microservices, it got messy. There were so many dependencies and you couldn't manage releases. They're tangled. It was like the tangled web of Christmas lights that have been left in the garage over a year. I think, now, there's so much maturity to the software development lifecycle. There's so much maturity in the development operations and release management that's out there that you can really orchestrate and stay away from those dependencies.
I'm curious. From your roadmap, and what you guys released, have you seen maturity over time as far as how people can manage those dependencies?
Furqan Munir (14:00): Definitely. I think one of the key things to understand is the way we have been building our technology is like we are taking our focus on being modular. What does it mean being modular? Composability is another one. So, we break down the services into individual, I say, components. And then, on top of it, we'll put them together to complete a product.
For OMS, for instance, it's a combination of inventory management system. It's a combination of order orchestration. And then, you have your fulfillment logic which sits on top of it. It allows you to manage different rules: where the order gets fulfilled as opposed to where the inventory is or where the customer is. So, all of that coming together as an experience, modularity allows you to do that. Retailer who just wanted inventory aggregation can just use inventory as a service - does not have to use order orchestration.
Release management across, when you have individual services, becomes a lot more easier because then you're managing and you can build on features. It gets a little bit tricky that you have to make sure that there is enough mapping in the way you set your rules, or how do you orchestrate the services. Having that orchestration service or that ability to manage those services in the way or transformation is really, really important.
If you have proper tooling to do that, you can. But, if you're not, then you might end up in a problem where if you update one service and if it's not talking properly to another one, you could have the same problems as a monolithic system.
George Jagodzinski (15:38): That data orchestration is so key. I could tell you, after almost 25 years of doing this, I can maybe count on one hand the number of legacy systems I've seen fully go away. It always lingers in the corner somewhere. In one of my earlier podcasts with Tom Goode, when we talked about how technology just really accumulates, it's advancing, but you're just accumulating more and more and more of it.
And so, I don't care what organization you are - you're going to end up with these old legacy systems that are sitting, managing some function of the business, some back office function, something. And so, you need some level of data orchestration and service orchestration to be able to loop that into your whole headless commerce platform. I'm curious, how much of a need are you seeing that from your customer base, and what are the roadmaps on that type of stuff?
Furqan Munir (16:30): I would say we’ve seen this a lot more now because the element, I would call it differently, is configurability low code. To the point we were talking earlier, how do you minimize costs?
If you have a platform which allows you to configure and change the way you want to orchestrate your services is, I would say, the real value is there because you could have a developer come in and they can look at like, "Okay, where is my item data? Where is my inventory data? Where is my pricing and promotion data?" Combine them together to create an orchestration for, let's say, cart and checkout.
It's really limitless what they can do with it. That's where we have been really focusing on and saying, "Okay. How do we make this very configurable, as opposed to having it being coded,” because that then requires changes. And then, you have to do dependency mapping and a lot of that work. It's a very long cycle to deploy something. Whereas, configurability allows you to go in there and change something. And that, if you have the right, let's say, presentation layer as well, it's very easy to propagate those changes into your front end and have the end-consumer utilize that.
George Jagodzinski (17:45): If I put myself in the mind of a head of e-com at an organization that's expanding globally or changing direction, and I've decided that I'm now ready to move to headless e-commerce, how can I best prepare for that? What makes a good customer of yours as they can best prepare and best kind of map out a playbook?
Furqan Munir (18:06): I think I would start with the problem statement. A lot of the times, when businesses go into these investment decisions or they want to change platform, they don't really understand why they want to do re-platforming.
George Jagodzinski (18:18): They just want to buy new technology. New technology's fun.
Furqan Munir (18:28): You need to have a very clear problem statement. Do I need to merge? As I was saying earlier, I have stores. I want to have that inventory available to my online customer. Is that a problem statement? You start with that. Do I want to offer more better shipping methods and options?
So, all of these are problem statement, which need to come. And then, they need to be clearly tied to KPIs. What do I intend to do after that? Is it, “I'm growing my top line?” Is it, “I'm reducing cost to make sure that my gross profitability is operating at a level where I need it to be?”
So, all of these KPI need to be tied with conversion data, customer traffic, all of that. It needs to be put into a plan, and that's when you can really advise a customer. That's what, I would say, an ideal customer profile would be. Sometimes, we even go in when our customers come and they say, "We have a problem.” And we'll say, "Okay, this is how we would like to advise you.”
And then, again, defining that problem statement and putting it into a project plan which basically ties it to each KPI and say, "By the way, if you make this enhancement, your inventory offering on your website will be real-time. If you make a price modification, it'll be real-time." And that's a change. What does that drive? Does that drive, let's say, customer for an ideal retailer. They were coming in and they were seeing a lot of customers coming in and not converting because the product was out of stock and you put inventory, but it takes 24 hours for that to show up on the website.
Now, it's real-time. How much reduction have you seen in traffic dropping off from your website? That’s like your top-of-the-funnel conversion ratios.
George Jagodzinski (20:07): Starting with what the actual problem statement is so critical. I see too many people just buy. It's human nature. You just want to buy new stuff.
So, I'd like to get into your head a little bit as that product manager mindset. Something I'm curious about because, at Groupon, it's more of the whole experience that you can own - here, in a headless environment, people can do whatever they want with your baby with the modules that you provide them. As I was thinking about this, one thing that always bums me out about more closed ecosystem products is, when you're evaluating it, I always tell my clients, "Hey, we're evaluating not just off of the functionality, but we're evaluating based off of the team and the roadmap. Where are they going?"
I think that applies to you guys, as well. But, in more of a closed ecosystem, if you really need a feature, the product manager might get pressure from enough customers. They'll put it in and, maybe sometimes, it'll be bare minimum just to check the box so that, when they're being evaluated, they could say, "Hey, we support X, Y, and Z functionality."
But, in evaluating a headless commerce, or that’s more module like this, if I'm evaluating it, if you guys don't check certain check boxes of functionality... I don't know that I care that much because I can just plug and point solutions into that ecosystem. I wonder how that changes your mindset as a product manager. Does it cause you to wait longer before you add a feature and really make it perfect? Let me inside your brain a little bit on how that works.
Furqan Munir (21:35): I think that's a great question. That shift is what I would call is working for a technology company, which is just supporting one business, as opposed to a SaaS offering.
So, in a SaaS company, product managers really need to make sure that their features or what they're building is generic enough that it can support multiple use cases. They have to go across industries, let's say, in manufacturing, to retail, to food industry. How does auto management [sic]? How does orchestration of cars? What are the different feature sets? How does promotions apply? What are the different engagement tools, which you need to build on?
So, as a product manager, you have to think vertically and horizontally. You have to really go and see how your technology will be used and then determine it. Second thing is it's very important, when you release something, it is thoroughly tested. You need to ensure that it works. It's backward compatible with all your other services because you have multiple customers on your tech stack. If you release something which does not work, it can break things for your current customers. The blast radius is huge. Whereas, working for an individual company and owning a technology roadmap for that, it's much more easier because, if something happens, you revert the chain.
Over here, it's expectation management across multiple, or, I would say, thousands or hundreds of customers. So, it's very important. So, there's a lot of, I would say, in-depth research, which goes into when you're defining or designing a feature. You have to look at what would it do? How would it increase benefits for your end merchants and retailers using that technology? So, sometimes, we even go and look at how can we tie it to a KPI. We increase or we develop something on promotions. How are merchants using it? Are they seeing more engagement now because now merchants can offer better deals to their customers? Is this really changing things for them? So, that becomes very important. That's a very important feedback which needs to come back to us. We try to go in front of the customer as much as we can to learn from them, to take that feedback.
George Jagodzinski (23:47): The cross-industry aspect's got to be so difficult. I can't tell you how many e-commerce platforms that we've come across, and you look at a certain feature. So, maybe I'm working with a fast-moving consumer goods company and we're using the platform and you look at some of an area functionality and you're like, “Oh, I bet this functionality was built only thinking about retail or sports apparel or something.”
You can just sniff it out in there that this was not thought of cross-industry. How do you even manage thinking about that many industries in use cases?
Furqan Munir (24:19): So, I think it's around, I would use the word, again, configuration. We based a lot of that stuff, for instance, in pricing. You have promotions. You have ability to create coupons. How do you apply them across your assortment? Do you want to limit it to one brand, to one category? Everything is a configurability, so it doesn't go out to everything. Do you want to segment it across a set of customers or a region?
That is where the level we will go down to basically making everything configurable, so it's easier. If merchants don't want to use it, they can switch it off. If they want to use it, they can use it against what is their target audience or their target assortment. Same with when you're setting up your catalog, as well. A SKU in retail, for instance, is very different to a SKU in, let's say, the furniture industry. It'll have length, weight, dimensions, and also material.
So, how can you add attributes to your catalog data that is configurable? You can add the different number of attributes to capture that data. In the same way, in retail or fashion industry, you have to have sizing charts. You have to have color and variation of the same item. So, that is, again, configurability, which allows you to basically build a catalog on that.
Association between different types of products, like I buy this product or I want to sell this. This product is associated or bundled with this product. So, creating that, again, is configuration. So, we think through what are the different use cases, how retailer will be using our system. Of course, we can not cover everything, but we try to do as much research. And then, I think the other part of it is extendability and scalability, which is very important. How do they build on top of those headless APIs? What is the scalability? So, we have to know our boundaries and limits. Have we done enough testing? What is the latency within our API, or how much data it can render to the front end at what speed?
So, those are the things we really consider when we are developing.
George Jagodzinski (26:30): I'm curious, how do you think about some of the data standards that are out there? So, a long time ago, I worked with the company that was working on GDSN, which is the Global Data Network for Synchronizing retail data. It was a very extensible XML model, but it ran into some issues. I mean, anything that's managed by a standards body always runs into issues. And then, people interpret the standards differently. And then, you end up with a bunch of different - a Tower of Babel situation where people are just talking different languages.
Do you think much about various data standards that are out there? How do you embrace them? Do you create your own?
Furqan Munir (27:13): Again, very good point. Why headless commerce? Again, going back to re-platforming, one of the biggest challenges is how do we manage data? How do we syndicate data? How do we import data from multiple sources.
With headless commerce, that becomes very easy because there is a transformation layer, which you can add to transform data, and you can clean it up. Having a good catalog allows you, and with all the right, let's say, attributes, variation, captured color, combination, SKU, IDs captured, you can really syndicate your data to all sorts of different platforms to really maximize your fulfillment or maximize your offering. And that, in conventional companies, can not happen.
Even as simple as companies trying to go on Google Play, they need to have three things at a minimum. Otherwise, Google will not show their data or show their offering. You need to have a brand name. You need to have a SKU identification number so they can manage you across other retailers so they can see where you're coming in. And, you need to have the price offering validated.
So, these are the things which are very important to have. As retailers are growing their business, they're finding more and more. That's why they would go to a platform where data can be managed in a much more systematic way. It can be configured across multiple different systems. You have a system which is purely for catalog management. You can manage where is your catalog coming from, who is the vendor or the manufacturer providing that, all the way to a merchandising team owning a pricing system where they can schedule pricing or manage promotions to a logistical team managing inventory because they are holding, they understand where the stock is, what is the positioning of your stock.
George Jagodzinski (29:00): Yes. Not having your merchandising team have to worry about how exactly things work downstream and all the various data syndications that are going on. That makes a lot of sense. So, what are you excited about most in this space, looking forward?
Furqan Munir (29:15): What really excites me is I see every day there's something new which is happening. I'm excited to build stuff which really solves the problem for the merchants. How do they go across different geolocation? How do they extend their business? When you go in a room, and a merchant is explaining their problem, and they're like, "Oh, I've got a solution for you. I can make your life really easy." Example I’ll give you: We recently went live with a merchant where they had a use case of multi-sites. And they wanted their customers to start a journey from one site, and they add something to the cart, and they would go to the secondary site and add something to the same cart and should be able to check out on either of the sites.
For us, it was a very easy use case to solve for. But, for them, they've been struggling with it for years trying to do that in-house. So, that's what really keeps me going and exciting because building technology which can some way or the other help ease out the pain retailers have seen.
George Jagodzinski (30:17): It's so funny with... by not having a presentation tier, you're able to provide better user experiences and get closer to the humans at the end of it. That makes a lot of sense. It's just funny.
So, always like to finish with a fun question. Throughout your years of experience, what's the best advice you've ever received?
Furqan Munir (30:37): I think one thing which I would like to share is active listening. As being a technology company, as a product manager, you really need to listen and understand what the problem is. I keep repeating myself, but I think that is the best advice, I thought, was to listen. And then, speak and absorb. And then, channel it. Break it down into sizable chunks. So, I would almost say, in order to be successful, I think, active listening is very, very important.
George Jagodzinski (31:09): So easy, yet so hard. Very good advice. Furqan, thank you so much for being here. I appreciate it.
Furqan Munir (31:16): No. Thank you for having me, George. It was a really, really fun conversation. Thank you.
Announcer (31:21): You've been listening to C-Suite Blueprint. If you like what you've heard, be sure to hit subscribe wherever you get your podcast to make sure you never miss a new episode. And, while you're there, we'd love it if you could leave a rating. Just give us however many stars you think we deserve. Until next time.