Decoded: How to Buy Software Well

Phillip: [00:00:02] Welcome to decoding a podcast by Future Commerce, brought to you by Spryker. Keeping up with the Joneses isn't just for the neighbors next door. Today, companies buy software based on what they see others in their industry purchase. And formal RFP processes create a lengthy and expensive buying process slowing down the company. Because of this, eCommerce companies are more open today than ever before to the idea of composable commerce. Today's podcast will address the chasm between the developer and the marketer while speaking through current events, tectonic changes, ecosystem threats, technology trends and platform wars, and how we can build a bridge between the two. I'm Phillip.

Boris: [00:00:52] I'm Boris, Co-Founder and CEO of Spryker.

Phillip: [00:00:55] And this is Decoded. When you buy software for digital commerce, you'll probably make your first mistakes well before the purchase, because if you can't give clear guidance on what you want or what your needs are, you won't get the best solution for your organization. Today's podcast will look at how you can buy digital commerce software well, what the key considerations and some of the biggest mistakes people make are, and we'll also discuss why end users must be central to any software purchase and how developers and operations are critical to your success. You and I both have witnessed this phenomenon, something that we would say in English, "Keeping up with the Joneses." There are fads and fashions in the way that we buy software. And most of that is informed by we do what other people do because they did it and they were somewhat successful. Is that a concern of yours in the way that we make purchasing decisions in anything, but in especially software?

Boris: [00:02:09] Yes, definitely. I think it's actually ironic because Spryker is my third commerce technology business. And I was always in the enterprise space and the B2B space, so to say. And I promised myself that one day, you know, I need to have a B2C business, a B2C company. And the reason is that selling to enterprises or B2B sales is very irrational. What I mean by that is when customers are buying for themselves, then the buyer of the product is always the user of the product. So you decide what to buy because it's for you. You would vote with the most honest thing that you have, which is your wallet. You want to go for this phone or for that phone because you are the user and you are the buyer. Now, in enterprise or in B2B sales, exactly this easy-to-understand correlation and link is broken. The buy of the software is rarely the user, almost never the user of the product. So you would deal with people for months on the buying side, selling them and negotiating with them and talking legal and commercials and doing demos and reference calls, all these kind of things. But very likely none of them will ever be the actual user of your product. It will be completely different people either on the development side or on the business side, which makes the entire thing completely irrational. This is just to start...

Phillip: [00:03:53] Yup.

Boris: [00:03:54] And so the question is now how to get a little bit of this irrationality out of this process. What is it that you as people buying software, especially enterprise software because this is where most of my expertise at least is, what is it that you can do? And I have maybe ten points or so that I can walk you through to try to avoid the most often made mistakes.

Phillip: [00:04:20] Yeah, let's get into those then. There are so many mistakes that we could cover here. What are some that are top of mind for you?

Boris: [00:04:29] Yeah. So I think the very first one is for you as someone who is running a business, owning a business, or being responsible for a business to ask yourself is do you actually want to be involved in this process again? So kind of speaking to the irrationality. Is this decision making, is this important to you? Or do you want to involve the people who will be using the product? And I think it's an easy to ask question. And to what degree you want to include them into this buying process, which, again, many companies are not doing. So they keep it separated. There is a purchasing department, people doing the legal stuff, doing commercial negotiations. So I think this is very important if you want to have a good quality choice and you want to actually get the value out of the product, not just buy something for your peace of mind, but get actually value and the problem solved because most likely this is the underlying reason for you to buy an expensive enterprise product is to involve people who will be the ones using it, be it the practitioners, the marketeers, the content managers, the digital commerce manager, or the developers if it's a technical product, don't disconnect. It's very... Just don't disconnect, period. I think this is maybe number one. {laughter} This is number one. The second one, which is maybe equally interesting, is I always say MVP over RFP. So RFPs are the way of buying enterprise software in a structured way, writing down requirements, and collecting them. I want to have a search as this competitor of mine. I want to have this as fast as that competitor of mine. I want to have a recommendation engine as good as Amazon, blah, blah, blah. So first of all, this rarely has something to do with your actual problem. So this again, why it is very helpful to involve the people who are supposed to really work with it. What is it that I want to do? Do I want to reduce costs? Do I want to increase value? Do I want to increase conversion rate? Be very explicit on what problem you try to solve because otherwise you'll end up just copy pasting and finding RFP templates of other people on the internet and just merging them together into an even longer spreadsheet. And then all of us have seen this. It's always this 500 line Excel spreadsheet, with the typical bullshit Bingo, which is very generic. Every vendor you send it to responds with, "We are fully compliant." You can do everything by configuration and then you find out the seven digit project to implement. So be explicit on what you actually want to do and then instead of doing RFP, go for POCs or MVPs. Because there is no better way for you to really get under the hood of the product, to really get a feel for the technical capabilities, how easy or harder it is to adjust, to adopt, customize it, or how easy or hard it is to really configure if it's a configurable business product. So slice out a cohort of users, a line of product, a business unit, something where you can easily within... I'm typically giving this advice for every piece and every piece should not take longer than 100 days. So this is kind of a magical number. If an MVP takes more than 100 days to implement, it's not an MVP. So it is. But then the M stands for Maximum Viable Product...

Phillip: [00:08:07] {laughter}

Boris: [00:08:08] So go MVP, not RFP. Rather give yourself the shot that gets you real hands on it and then take it from there and the product delivers and you expand the scope and you build the next country, the next line of product, the next category. But be explicit on what you want to solve and go MVP and not RFP. I think these are kind of the next two ones that come to my mind.

Phillip: [00:08:33] To use an overextended analogy, you don't jump straight into marriage when you are trying to form a long-lasting relationship. So you date a little you know, you get to know their groups of friends, you try it before you buy it. I think that's such an interesting model too because I don't know that a lot of software, especially software as a service platforms these days are amenable to the RFP lifecycle. A lot of enterprise software maybe is more architected towards you going down the route of qualification of a bunch of the features and fit and functionality or looking at case studies, the SaaS products seem to be heavily indexed toward just start it, just try it. When you try it, you're going to understand what the capabilities are.

Boris: [00:09:42] I think this is kind of the most complicated now because especially in enterprise software, to be honest, the products are so complex and so sophisticated, no one gets it. I mean, everyone who tells me they understand what exactly they are buying, they're lying. The products are just they're just huge. Tons of microservices, tons of package business capabilities, tons of old school suites, if it's a monolithic application. So it's very, very hard. This is why, again, it's so important to have the people involved who will use it, to be explicit on the problems because then you can ask the right questions. Only then you can try to get an objective opinion. You can't just read a Forrester or Gartner report. I mean, they try to make it objective. Right. But at the end of the day, it's one analyst or two analysts writing. So it is subjective, right? It's what these guys think is state of the art, what these guys think, or what they hear from a small snapshot of customers they have the time to talk to during the year. So it's very hard. You need to triangulate. Of course, this is a helpful start to have a look into what they do. I think increasingly, customer review platforms help a lot. You know G2, Gartner, Pureinsight, TrustRadius, and CS-Score are good initiatives where you can check out what actual customers or partners are saying and how they feel about it and just get a kind of triangulated opinion. Obviously, reference calls to customers would help as well as long as you are talking to the right customers, with the same problem, same size, and same starting point. Just if you are in an organization that doesn't have any developers and will rely heavily on an SI implementing the product, reaching out to a very tech-savvy organization with 250 engineers doing everything in-house will not give you any meaningful data point. So if you talk to the vendor, especially to the larger ones who have enough customers, try to be very explicit, "Hey, I'm this business, that size. I'm here in the maturity, my digital maturity curve or journey. This is how I want to get from A to B. Is there someone you can connect me with who was at a similar point in time with a similar problem and was on a similar trajectory?" Not just give me your top customer, you know, who will always praise you. I think there's another one. And then obviously talking to SIs and partners, you need to be a bit careful though, because as SIs have kind of the counter interests and counter incentive maybe to you as a customer. Unfortunately, many SIs are still primarily making money from selling or renting out developers by the hour, so to say. So not every SI has adopted a true value sales methodology, trying to really think through how they can impact your business. So if you want to do an MVP or PoC, you try to actually slice the project, and make it smaller while talking to the wrong SI with the wrong incentive, you know, could lead to someone making the project actually bigger. So try to find the right SI who shares, who is willing to enter the right type of relationship with you, sharing risk and reward, say, "Hey, look, guys, let's talk about a different type of contract where we both know we will now go into a PoC MVP with a clear intent that this will become a three-year engagement for you guys. So I want you to take some risk in the first phase. And I want you to really focus on that and help me prove the point, prove it to my shareholders, prove it to my management. But at the same time, you have my commitment of if this point is right, this will turn into a longer-term relationship so that you guys are not just putting your interns on this PoC project because you don't see value from building a long-term customer relationship." Try to find the right KPIs and bonus schema for them and then kind of merge this all together. What are the vendors saying? What are the analysts saying? What is it that I read in customer reviews? How did my PoC go? What is the feedback I get from partners? And then you kind of bring it all together and then you should have a pretty good feeling for something which is still very opaque because it is enterprise software by definition.

Phillip: [00:14:27] Let's examine the RFP lifecycle. The modern enterprise buys software today by attracting vendor bids from around an ecosystem. This request for proposal is in theory a list of requirements that should define the outcome, time frame, and budget for a given project. When buying eCommerce software, the software buyer will often lean on outside vendors to help them create the requirements definition. This outside team performs interviews, examines the existing state of your various sales channels, and will write the requirements definition. Sometimes they may even run the vendor assessment process. So by its very nature, the RFP introduces risk, despite its sole purpose being to mitigate it. This type of enterprise risk is what has created the environment for failed implementations and bad integrations that have plagued the eCommerce industry for years. It's also what's led to a new era, one that no longer requires IT and DevOps teams, one that gives full control back to the marketer. I think that's the challenge here when you're thinking about needing to rely on an outside source for project support. And what we're seeing more and more of these days is in the software as a service era, we're seeing larger organizations have smaller, more capable teams that are having to do more with less. And so they don't have outside partners at the scale that maybe they used to. And they're doing more of the trial proof of concept. My concern would be somebody listening to this and saying, "Well, proof of concept is great. When we get past the proof of concept and we've proven that there is a market there and that we can reach the market we need to grow up. What happens if we've chosen a platform that doesn't have a five-year horizon for us? We'll quickly outgrow the boundaries of that platform." Have you now created a different kind of problem in your selection process?

Boris: [00:16:49] Yeah, there is such a term as future engineering, which is actually an anti-pattern in a way, right? So you need to find a good balance between solving problems that you don't yet have and very often you will never, have and trying to kind of solve for something three years out from now, five years out from now, in a market in which, as we all know, changes so fast and so rapidly that there are a million reasons why this problem might never occur and maybe a million reasons why they might occur. So solving for them is kind of gambling, right? So I would always advise being rather on the not that much of a future engineering side. I think you need to kind of challenge the right things. I'll give you one example. Scalability, right? It's a good nonfunctional requirement. You would often see performance scalability in requirement documents. Now, you know, if you say I want to have a scalable platform then very likely every vendor will respond to it by saying, "Yes, we have a very scalable platform." Now, what is it that you actually mean? This is the important question because if you just compare side by side, a platform like Shopify might be super scalable for hundreds of thousands of very small merchants with one or two line items per order doing up to 50 orders per month. Super scalable, right? But not scalable at all for a huge, complicated, and sophisticated B2B use case with thousands of line items doing hundreds of millions or billions of transactions per year and vice versa. So if I look at our platform, our platform is designed for enterprise organizations. So are we scalable in the Shopify way? Can we operate hundreds of thousands of merchants? No, we can't. We are not scalable against this definition, but we are super scalable for the use cases we power. So to enable billions of transactions, hundreds of millions of transactions, sophisticated use cases, large cards, etc. So the question of are you scalable, but what is your approach to scalability for me? And for me means this and that. Same goes for pricing, for example. I mean, it's a big difference whether you need to solve pricing complexity around "I have one SKU, one price, and then I have a discount engine and promotions that allow me to discount up and down" versus "I have one SKU in a B2B scenario with hundreds of thousands of customers with customer-specific prices." Which can lead to billions of price combinations. Completely different use case, not better, not worse, just different. So [you need to ask the right question. What is your approach? There is no generic performance. There is no generic scalability. There is no generic one size fits all PIM or CMS. So I think if you are explicit about it then you can check for it and avoid finding out later that what you as you said, in the PoC everything was fine because you just had ten users, but now you have hundreds of thousands. That just doesn't work anymore.

Phillip: [00:20:14] Well, that's my constant mantra as a former engineering lead is, you know, there's a tendency to pre-optimize. And this pre-optimization of code is something I think most engineers can sort of understand. There are best practices. And most of those best practices are things that were learned in a scale that very few developers ever have to encounter or fathom because very few are platform developers. They're not writing an operating system. Most of them are consumers of a platform, and they're working on, by comparison, very small improvements or engineering changes that are on top of the existing platform. So okay. Yeah, solid is a great example of that.

Boris: [00:21:12] And don't forget that unfortunately, the SaaSification of the industry is actually leading to many developers losing skills. Because by definition, the more you're forced to not worry about what happens under the API, don't care about what happens in this microservice or this packaging business scalability. Scalability, security, performance. It's a commodity service. Just don't care. You build your nice experience on top of that. This is why I'm saying you need to distinguish between is someone a software engineer or a software configurator? Because many of the people lost their skills over time, as with the SaaStification kind of our industry, because they had to worry less and less. So they lost this engineering ability to think from a down state of a requirement that, hey, it's not just building the functionality, it's there is a ton of nonfunctioning that I need to write documentation. I need to test for load, for performance, for scalability, security, blah blah blah blah blah blah blah. So a whole bunch of things on top of just writing the functionality which unfortunately many people forgot over time just because they didn't have to worry about it anymore. And if you think of all low code, no code. Going forward, it's even worse. So I think it's very interesting to observe how the industry evolves here.

Phillip: [00:22:39] There's one last thing that I do want to touch on here, which is the idea of Internet-scale is something that I think we've all encountered if you've been in eCommerce for probably a decade or longer, there was this idea that achieving some sort of mass scale was something that we had to, factor in, in the way that we built applications or consumer experiences on the Web. But what I've witnessed over the last five years, in particular, is that more and more people and more brands and more consumers coming online means that outside of Amazon, really, that scale is not as concentrated as it used to be. There are very few brands who will ever experience that scale. Now it's more diffuse than ever, right? So it's you have a larger surface area on which you're spreading, you know, consumer activity across a number of brands. I don't know if this helps us in the way that we sort of decide which problems we want to try to solve rather than trying to solve an Internet-scale problem like how are we going to grow over five years where we're trying to figure out how do we create an opportunity for our brand to become so successful that we have to solve a scale problem later on? It's a reframing of the problem as not that we haven't considered it, but how can we actually bring that into being to become problematic for us to have to solve it later? Thanks so much for listening to Decoded. You can find more episodes of this podcast and all Future Commerce podcast properties at FutureCommerce.fm. You can also subscribe to our newsletter, which comes out three times a week at FutureCommerce.fm/Subscribe.

This special series of Future Commerce is brought to you by Spryker, the Commerce Platform to futureproof your business. Hey, it's a challenge right now in 2022. You have to be about more than just selling online. The market is shifting and new technologies are changing the game every day. And that's why innovation and agility should be at the top of your list to be able to stay competitive. If you want to learn more, go to Spryker.com/FutureCommerce to learn more and register. That's Spryker.com/FutureCommerce.

‍