Find Customer Friction, with Bernard Golden and Jesse Bean

Episode 226 · Mon, 19 Jul 2021 12:00:00 +0200 · 34:41 · SRT · archive.org · all Tanzu Talk

Today, we've got a couple more people from our Tanzu advisor team. Why don't you start, Jesse? How would you describe what that team is? We're a bunch of former clients or execs that have come over to Tanzu to help drive the mission of Tanzu about building software anywhere, anytime. But what we truly bring as an executive advisor team is truly on building the right things and actually coming from an app and business outcome down first. So we have a lot of folks who have experience in this, but that was my prior role at John Hancock Manulife, now helping out the financial service and insurance industry over here at VMware. And how about yourself, Bernard? I've worked in the software industry my entire career, live in Silicon Valley. And about 12 years ago now, I got exposed to cloud computing and said, this is going to be transformative and have really focused on it ever since. And I think it's really demonstrated the potential that I saw at that very beginning, the very nascent stages. I had the opportunity to work with a company called Capital One when I was at a vendor. And then they later recruited me to join them as vice president of cloud strategy. And it's a very interesting company in that they're a poster child for all in on technology transformation and all in on adopting public cloud computing. And so I had the opportunity to work there and see how the sausage is made, if I can say it that way, of a company going through a profound digital transformation. And then had the opportunity to join the Tanzu Value Advisor team. Because what I saw at Capital One was that just as critical to the technology capabilities of the staff is the management alignment and commitment and support for that transformation. Without that kind of support and drive, really, you end up with people who are maybe chartered, oh, help us become faster with our DevOps thing. And then they try to work in it and they encounter barriers, organizational restrictions, so forth. They just get frustrated. But when you get the two things together, you've got the technology capability, the staff that you've brought in or that you've reskilled, and upper level management is really aligned with and supporting that and driving it, then things can really come together. So it was a good opportunity at Capital One.

And I came to Tanzu Value Advisors to help organizations make that kind of transition about joining the technology and the, if I can say it, management commitment and structure together. Yeah, I think one of the last phrases you said there is like management commitment. And that's over the years, I've noticed that is obviously required to do anything. I think with a lot of the sort of stuff that we focus on, applications and the infrastructure that runs the applications, it does seem like such a fundamental change that without that management buy-in, like it's exactly as you said, just people are like left improving, but then they don't have the authority to do anything, which is frustrating. If I can elaborate on that, you're exactly right. And what we find, what I observed, I should say, through my career is, you'll often have a situation where the people at the coal face, meaning the technologists, they're ready, they're excited. They've seen how this new technology works. They're good to go. Upper level management is convinced of it and says we should do it. And so they put out a pronouncement, hey, we're going to do a digital transformation. If you don't have them really committed and measured, in other words, okay, and at Capital One, it was what percentage of your applications are migrated to the cloud by X. It's a very structured kind of thing and so forth. What you get is a sort of a feel good, we should do this. And then it encounters the reality of middle executive level, middle management. And I always use the anecdote or example. Let's say you're director of storage at some enterprise IT organization. You've spent 15 years clawing your way up to a pretty good executive job. And then somebody comes to you and says, you know what, we're going to get rid of all this on-prem storage and just go to the cloud. And how are you going to respond? And so having upper level management committed and measured, and then they drive that through the rest of the organization is really, it's a way then to support the enthusiasm and capability of the people at the coal face. And I also think of one of my favorite, I love in a computer nerd world. I don't know if y'all have seen this, but I realized that anytime we call something a law, it just means it's a collection of anecdotes. Like we like to throw that term around as if it's an actual law, but there's one that's a, how do you say it, a law, which is very complicated, many sort of precepts and predicates to it.

But it basically says to your point that no one wants to change. It doesn't speak hyperbolically like that, but many people would prefer not to change. And therefore, if whenever you introduce a new methodology or something, you'll see this magical thing that managers do, which will, they will totally say that they're doing the new things, but they will just, it'll turn out they're actually doing the same thing. And they've basically retrofitted the description of a new methodology and approach to match what they're already doing. Hence the phrase, we've always done agile. We've just never called it that, which is one of the favorite phrases out there. Yeah, I like to add some color into there. It's really, the middle managers can make or break what you're actually trying to do, even if you have that top level support and bottom people that may want to change. The middle managers, in order to help them move that way, really need to have some incentive, whether it be, we always use the phrase carrot or stick, because there's, it's driven by the behaviors and metrics that they're either awarded on or have consequences for. So getting that aligned between the business middle management and the technology middle management is what may facilitate a lot of that change. And so I've seen it good and bad in my experience, basically on the investment side, where they were not totally aligned. One had one set of metrics for the business and one had another set of metrics for technology, and it completely flopped on both sides. Let's talk about that some more. What, tell me, let's start with this statement. So the key to doing this kind of transformation is getting the right metrics for upper management, because that, the key is a strong word. But like, that seems to be something that I don't see discussed too much. A lot of the discussion is all about, so just, we want to change the way that we do software and the way that we run things to be more closely aligned with the business side of stuff. And if we can treat software as a product instead of a project that we can outsource or ship out, and we get it shipped to us like some box, and we just unload it and we're done. Like, it's much better if the software is actually like agile and evolves with the way that we want to do our business and helps us learn and all that great stuff.

And so, like, the discussion around that, like, I never, I don't see a lot of tips on how to get a set of metrics that enforces management making it happen. And I wonder, in your experience and yours as well, Bernard, like, what do these metrics look like? Yeah, it's funny you say that. Our team had discussed last week, came out of an MIT class, basically, and the professor there was basically saying, your digital transformation are your KPIs and your KPIs are your digital transformation. That was a bold statement there. What I've seen and what is working there are the companies that have actually come out of the cloud native world. So you look at Lyft and you looked at Google and so forth, they have all this data that are driving metrics for folks that are aligning the business and the teams together. Now, stepping into the enterprises, to your point, like financial services that have been around for 100 years, getting there is a much different avenue and actually aligning the middle management to be more digital savvy and the tech side to be more business savvy. So that they grow, for instance, aligning like I need to increase my customer funnel on my robo advisor, but I also need to have stability or a better online experience there that will actually grow your funnel, which is aligned with the business. Like those types of conversations need to happen nowadays, not just here are my requirements, I throw them over the wall, and I have my business requirements to grow my funnel, and I have my tech requirements to implement a new technology. In a way, the metrics flow out of an emotional conviction. So you've got to have somebody who's senior going, this is important enough to do something. And then they've got to have the discipline to say, and the way we're going to incent people to do that or motivate people to do that is we're going to put that in as one of their measures. I like to quote this guy, Charlie Munger, who is Warren Buffett's partner. Anyway, he's a student of human psychology and motivation, in addition to being an investor. And he says a phrase that really stuck with me that he said, I think I understand incentives more than most people.

And I'm still surprised at how powerful they are. Meaning he really understands them, he studied them, and yet he's still shocked at how much they motivate behavior, how much they guide it. And so the emotional conviction is the start of it. Hey, I think we could do better. I think we could grow our revenues better, whatever it is. And then it's, okay, now how would I motivate that and incent that? And then you stick in measures against it. And that's the KPIs thing again. And you put them in place. And I'll just give you an example from one of our customers. There's a lot of enthusiasm for using public cloud within large enterprises, but many challenges. And if you just say to people, you should look at moving your stuff to the public cloud, everybody goes, yeah, that's a great idea. But my stuff is really hard, so we'll just leave it the way it is. Somebody else will do that. So they announced that their goal was to go to 65% of their fleet up in the public cloud. And they said, and your bonus this year, at the end of the year, depends on that. I'll tell you, it was astonishing how much activity that generated. Yeah, yeah, for sure. It was like people went, oh, there's a big carrot. And that does, of course, raise the thing. We've got to figure out how to design those metrics the right way. Your KPIs or your strategy, your KPIs. You better define the right KPI. And that's an art and science in itself. But that's the thing. I look for the emotional. And then I look to, okay, now, once you have this emotional conviction, what do you put in place to do the measurement? Because people tend to respond to incentives quite strongly. To your point of motivations and incentives and things like that, one of the things that I've been playing around, or I talk about every now and then that I get some pushback on, is this idea of money is pretty important, right? In the tech world, especially for those of us who are literally in working at vendors, and we exist in the software and technology world. A huge part of what we're supposed to be, and often interested in, is around passion, and liking what you're working on, and being able to wear flip-flops to work, and stuff like that. But to your point, like, when I discuss with people outside of the tech industry, or I don't know if y'all have this experience, when you go visit their IT department, like, you can see it's usually poorly lit, and there's some, they don't spend a lot of money on facilities for the IT people.

Like, it's not always the best setup. It feels like just realizing that you can use money to incent people is a good first step for motivating people to change. Whether that comes down to putting in brighter lights in their offices where they might be working, or I think on the extreme end, like, I'm always curious. I wonder what y'all have seen with where y'all work and people you talk with. It seems, if you want people to have a long-term focus for the long-term game of transforming and getting better at software, like, it's probably a good idea to give them some equity in the company. That works for us. But it doesn't seem like a very common practice outside of the upper echelons of management. And am I, like, a little crazy here to suggest that people look at their compensation plans when they find some resistance to changing how they're doing software in their IT? I would definitely say that the best teams that I've worked on around digital transformation seem to be, like, singly focused and had a purpose behind it beyond compensation. So looking at compensation is great, but I had, I'll give an example. I did a merger and acquisition when I was at my former job. And basically, we had one focus, and that was to get integrated in basically three months. And it was hell for three months. You were working seven days a week, 24 hours, whatever. It was crazy. But if you talk to any of those people from that time, they were like, that was the best project I've ever worked on because we were, there were no, there was no noise. Everybody knew what was the purpose and goal. And it wasn't about comp at that time. It was like, oh my God, we got to land this ship in three months. Like, how is this going to happen? And it was like a huge success. And if you, I ask everybody, what is your favorite team? What was that thing? And I feel, we talked about this as well on the team, but like giving that purpose. And aligning that purpose is one of the big motivators and changing cultures that we talk about that actually build high-performing teams. And so we talk a lot about that with our clients. I think you're right that compensation is a powerful element. And certainly if you're looking at somebody who's got some particular set of skills and you say,

hey, if you come to company A, you'll make X. And if you come to company B, you'll make 1.2X. Company B is probably, so, you know, that sort of thing. And you can design incentive compensation programs to say, if you achieve this thing by within three months, you'll get this, whatever. Or by the end of the year, as I pointed out. I think you're, the thing that you're really lighting on though, is a larger, more encompassing thing, which is what is the role of funding tech within a company? Right. And within, traditionally within many companies, many enterprises, tech has been seen as a cost center. And it was, we're going to, we're going to give you a percentage of revenues or something like that. And so the focus is always, how do you squeeze that? How do you do next year with less than you had this year? And so it's very much a, and that plays out to things like, can't you use your five-year-old laptop and just sit around while it's doing the compile or those sorts of things. Companies that want to do digital transformation. Okay. Part of it is, oh, we need to have staff with certain kinds of skills, but part of it is, oh, we're becoming, we need to have tech as a core competence. It's no longer a supporting thing. The phrase I use is, IT is moving from support the business to run the business. And so that bespeaks really funding it and supporting it as a core competence. And I'll use an analogy. I'm pretty sure that the person who is in charge of manufacturing for Ford or BMW, that's looked at as a core competence. They don't look at them and go, are you sure you really need to maintain that factory? Can you really, can't you squeeze out? It's if those things don't get built, we don't have a business and it's a core competence. And I would say likewise for the, certainly all cloud native companies view technology as core competence. Obviously, Netflix, Lyft, choose your favorite example. They look on that as a core competence and they have very high expectations and they fund it well. I will say Capital One, it was an interesting company in that it described itself as a tech company, both internally and externally. And so they said, oh yeah, we do credit cards, we do banking, but we're really a tech company and it's supporting its tech in that fashion. And I think that's the future of companies that are going, addressing this digital transformation shift from, oh, you support the business to, oh, really you are the business. You're the mechanism.

You made mention of the blog post I wrote about my auto financing experience. And the sort of backstory is I wanted to apply for a car loan. I went to two different places to apply and one place I applied online and they came back within 30 seconds and said, you're approved. Just make sure that whoever you buy the car from sends us the paperwork. Okay. That was great. The second site I went to, I filled out, it came right back and said, oh, you're pre-approved. We just need to have this paperwork and, or do something. And so I sent a, oh, we're supposed to fill out something online and it said, oh, you can sign the contract, but it just kept coming up with the pre-approval form. So I sent an email saying, how do I get to the thing? Nothing. Crickets for days. And then finally, days later, I get a call from them, from somebody there saying, oh yeah, I'm following up on this thing. I'm sorry that we didn't respond, but I was out of the office. And my reaction was there's one person who, if that person is out of the office, this car loan, what I'm trying to say is that experience crystallized this kind of, it's a core competence versus this thing that's grafted on. And the company that sort of says, this is a core competence. We have to support it. We have to enable it. We have to budget it. We have to build the skills is one that's likely to be more successful in this digital transformation world. I always like examples that most everyone experiences, right? Like getting a loan to buy a car is a pretty common experience. Retail is always a good place to draw examples from. But what I'm going to assume that one of the differences between those two lenders, to be all jargony, was one of them was probably like, one of the things we should care about is not having a person have to manually approve this. And like with your factory example, right? Like we should try to automate the factory as much as possible. And we should also try to make it easy to, I don't know, factory stuff very well. But the other difficult thing in a factory, I think, is like when you have to switch over to doing different work, like to switch your machines over. Or when you've got a defect and you have to do some sort of rush work through it, all sorts of things like that. And I think that's why, at least for me, it's always fascinating reading about lean manufacturing, because it's kind of to the point that a lot of that you two are talking about, where there's this extreme focus on the tools and realizing that like the efficiency of your

tools is what is, there's no talk of like factory business alignment in the sense that we have IT business alignment conversations. It's just like the factory is the business. There's no confusion about that. And so it seems a lot of the conversation we have, or at least I encounter about talking about digital transformation and stuff. Maybe y'all don't experience this, but after 10 or 15 years, it gets a little boring for me to hear. But I think that repetition is necessary because this point has to be made that you're making where like, you should realize that if you have to have a person approving this loan, you're not really like thinking about the business in the best way possible. And unless, unless from the top, people are thinking about that way, there's really no chance for bottoms up stuff to, to improve the way things are going, which I don't know, getting that mindset in place. That seems like the core challenge, bootstrapping that, that shift in thinking there. That goes back to your middle management comment. I think that's where you need to get that mindset change that they, that's where the work is done. That's where the strategy is made. That's where it's delivered. So hardest part, but that's the most effective area. Your loan example makes me think of something else I've been thinking about recently, which is let's call it like rapid release fatigue. And that, that is figuring out for everything that we just said, like how frequently, how does someone figure out like how fast they need to work or fast is the wrong word, but how frequently do they actually need to be changing their software or improving it? We as a group try to do this with the outcome driven workshops to help managers across the business line and the technology teams figure out what to focus on and drive kind of strategies and metrics down there too. But to your original question, like how often do you have to change? I think the project to product book does a great job with that because depending on where your business is and how that application supports that business, whether it's a growth business or a mature business kind of defines like how fast you need to release features to your user community. And obviously if you're in a brand new startup, you're releasing as many features, trying to

find product market fit as much as possible. But if you're a bank releasing to your loan applicants, it may be like once a month, once a week, like that may be satisfactory to your current client base. It all depends on the application, where you are in your business landscape. And I found that project to product flow conversation is probably the best to have in those instances. Yeah. Yeah. And to your banking is where I thought about this a lot. Again, it's another good example. Most everyone banks. So we know what that experience is like. And I remember a couple of years ago, there was a lot of discussion of banks fearing fintech startups and things like that. And when I moved over here to the Netherlands, you got to get such as American banking as it doesn't really work over here. So you have to get like a local bank account. So I signed up with one of the new bank startups and it was like a moderate letdown because I was like expecting something cool. But then it was just like banking. There was nothing. There was like nothing revolutionary about it. It was just you put money there and then you get money out of it. And maybe it'll try to identify monthly subscriptions that you have. And so like that kind of got me thinking of, yeah, there's some things that maybe don't need a lot of evolution. I don't know though. But then when I read your example of the Carlin thing, Bernard, it was also making me realize that, oh, maybe it's the UI is fine. It's like the backend where all the work needs to actually happen. The stuff that we don't see in the UI layer is where the hard work and where you probably people like me would benefit from shipping software every week. I was going to also cite the project product book. And the guy who wrote it, Mick Kirsten, has a really very interesting way of, he calls it flow and he uses auto manufacturing as his model or whatever. And he says, you want to figure out what is the right blend between new functionality, security requirements, because there's a security compliance, regulatory things, so forth. Technical debt and bugs. And technical debt is one of the areas that sort of is implied by what you were saying, which is, what is all the change you have to do in the backend to support greater facility in experimenting in the UI?

Because a company like that first bank that I mentioned, the first financial institution I mentioned, I'm going to guess they probably didn't get it right with their flow the first time. The old model was like you'd go into a branch or something and fill out some papers or this kind of thing. When they said, oh, we're going to do it digitally, I'm going to guess they probably didn't get it exactly perfect. So they have to iterate. Now, should we put the sign up here? Do we need to highlight this in bold and a different color to indicate how important this step is? Whatever it is. But you need to have flexibility also in the backend. And that's that technical debt. Because typically, those backend systems are written to be to a spec and not very easy to change. And so there's a lot of work to be done to get them to enable that kind of more rapid experimentation. To circle back to the question that you asked at the very beginning of this section, which was, how often do you have to release software? And can you go to a place where you're releasing it too frequently? And I guess what I'd say is, I think almost any organization I've ever encountered, and that includes cloud native companies that I've worked with, most of them never experienced the problem of, oh, we're releasing too much too fast. They're generally, gosh, wouldn't it be great if we go faster? And particularly many of the enterprises that we engage with, their challenge is, how do we go from a twice a year or maybe once a quarter update to something that is more frequent that can support the kind of technical debt retirement, the more flexible backends, the ability to experiment, and so forth. That's what I'd say. I'm waiting for the customer who comes and says, we are going as fast as we want to go. We get as much done as we need to. We're good. Thanks. Yeah, exactly. It'd be like going to the doctor and having them say, maybe you should cut back on the exercise and vegetables. You got a little too much. You should try to sit around some more and eat more bacon. You should get fatter. That's right. Yeah. Yeah. We in this world like to throw around the, what would you call it? A prefix is for a word. I don't know what a prefix for a phrase is, but blank, I guess this would be a suffix, but blank as a product. And what y'all are making me think is that we talk about platform as a product and your software as a product. And there's probably also your back-end business processes as a product. Cause I like the way you're tenderizing that out Bernard, which is sure.

You may not be changing your UI or even your business around a lot, but when you get to that three month window of working a lot, you will be right. And you're not going to have time to go and pull apart, like the concreted out plumbing of how your back-end works. And I think you, you identified it. What I see a lot as well, Bernard is like these back-ends were built on a, almost a project basis, which is to say like a very static definition of what they should provide. Like the interfaces into them and the data that gets put back out. And there's not a lot of assumption put into assume we're going to need to modify this every six months. Assume a lot of agility in this. It's more just, this is like the platonic truth of how our business operates. So therefore it's impossible to change. No one emerges from the cave and it's to be where a lot of benefit could come from. Cause the UI layer, that's relatively easy to like getting your ERP system to change. Like you can always, I don't know, it seems like the mobile teams are always the ones who have the most success because they don't really have a backend to deal with. In the late 2000s or the early 2000s, being digitally savvy was that mobile front-end change of user experience. I think recently to the loan example, like that is the backend is now where executives are actually making their biggest impacts from a CIO perspective to their business partners, figuring out like, how can I change my business model because of this backend? One great example is where all the financial industry is trying to go with T zero or trade settling in zero days versus one, two or three days. And this is the big backend we're talking about working with some of our clients and you hear technologies like blockchain come into here and all sorts of things, but that's all around that back office settlement experience, part of the industry. And so, which will have a huge impact on revenues across the board. So if y'all were to recommend, so as a couple of initial projects to work on, what would you recommend people do? Should they work on a backend sort of thing or should they work on something that's more

visible, modernize an application or like what? So the clients I talk to, so I deal with mostly financial services. The common thread that I always get is ease of use. So it's not that fancy new login, but the app is really on client onboarding, right? Financial, I always hear that client onboarding and identity access. Those are two of the main focus. You want security and you want to make it easy to get on to their platforms. And so a lot of these financial services companies have grown up in different business units and I may be a client across six of their business lines, but they don't talk to each other. So when they think about this and they want a friendly mobile experience where I can actually go from my banking relationship to my investment relationship, hence Bank of America and Merrill Lynch, I want one login. And so this is not that fancy front end, but this is like making it easy to transact and go across all of their applications. So we've seen it at the large financial service institutions, this is now going down to the next level. And so making that easily integratable and done is where a lot of the focus has been. I wouldn't have thought of that, but that's a good example on one of the things in your blog post about five digital transformation mistakes that you mentioned, Bernard, is like, to put it in my own words, you need to build up a track record of success, right? Like that you can basically boast about and use as proof points. I think you put it a little more elegantly than that. Something like customer acquisition, but then even cross-selling or whatever the term of art is in finance synergies across lines of business and kind of land and expanding, as we would say in the product world. That's a good example because it seems like it is, I wouldn't say easy, but it's possible to do like it's technically possible to do. And it has immediate, highly visible, measurable results. That result being that like more people are signing up for accounts. So it's tangible that it works. And then when I think about this kind of thing, like starting small and building up, it also has this other criteria that I say in a kind of a snarky way, which is like, if it doesn't work, it already wasn't working. So it's obviously it's bad reputationally and the time and money you spent on it.

If it doesn't immediately work out, but it's mildly low risk as far as like making the situation worse than it already is. How about you, Bernard? I think a common thread among all of them, because there are different kinds of businesses. I work with oil companies. I work with oil companies, work with financial services companies. If you're hearing a little bit of meowing that star who has decided she's ready for a bit of attention. That's what cats are for. Yeah, exactly. I guess what I'd say is all of them want to have a strong customer focus. And so it's, how do I ease customer use? How do I make it more convenient for customers? How do I reduce the friction? And depending on the company, that might be, gosh, I want to make it so that somebody can use their loyalty points more conveniently from our mobile app. Our mobile app maybe enables you to request your bill to be mailed out or something, but you want to add on some new functionality to it about how do I use loyalty points to purchase a getaway vacation or a barbecue or something, whatever. So that's sort of customer convenience. How do I onboard? With oil and gas companies, there's a strong need to say, gosh, we have a changing customer demographic that's more interested in sustainability. How do we provide new services to them that they're interested in? So a common thread is how do I respond to the marketplace and either roll out new functionality or how do I ease engagement? And just going back to this loan thing, as you pointed out, clearly one of those companies really sat down and said, how do we streamline this? How do we reduce anyone having to manually interact with this loan in these circumstances, which is to reduce variability? And the other one wasn't able to do that or hadn't done that. And so that sort of, what's the core capability that we have? How do we streamline it? How do we avoid somebody having to touch it? Those are common drivers and common applications. But it varies according to the industry they're in. Because one is somebody wants to check into a hotel room. Another one is somebody wants to change their energy supplier from X to Y. Yeah, I like one of the general, not principles, but general approaches or filters that you're

going over there. The idea of, let's call it customer friction, I think you said. And it's an example where being a little cynical is helpful in the following sense that a lot of the conversation I've seen recently is around what you want to, when you're trying to improve the way you do software to make your business function better, you want to deliver on better customer experience, which sounds awesome. But if I sit down and think about it, I always think, what does that mean? Customer experience. Like, obviously you want them to have a better time, but it doesn't really like help me target what to do. But then what a couple of, y'all have both said this a couple of times, but finding where that friction is or that bottlenecks or where the slowdown is, which is to say, this is where the negative version of, the negative version of customer experience is friction. Something's frustrating or it's bad. And so it's almost like in selecting those projects and you, both of you rattled off a few of them. It's, I think maybe the thought exercise with whoever's in the room is like, what's some stuff that like our customers hate or that we don't like that takes a long time that like is friction. And I think that's why I like value stream mapping or whatever you may do to find that flow. Like it really helps to identify those problems. And that kind of helps point you towards the direction of fixing things, which I think picks back on something you were back in the compensation area, you were saying, Jesse, which is I think the major pushback I always get about what's all about compensation is that developers and other people, they especially appreciate it when they can just do their job and do well at it. Like where they don't have to ask, go to a lot of meetings to ask for things, do governments, wait around for their labs. As we like to say, that path to production is really fast and that in itself can be a reward or at least it, it keeps people, it keeps not only their heads, but all of them way above water of being distressed and they're happy in what they're doing. You've probably experienced this since you moved over to Europe, but I travel a fair amount and travel to Europe and in particular to Britain quite a bit. And with one credit card company, it would be like, oh, you're going to go to Britain. You have to come to our website and fill out a form that says, I'm going to be going to this country from this date to this date. Because otherwise, if we see a transaction, we're going to reject it because you've probably

experienced that. Another credit card company I use says, oh, we're going to see you coming from that. We may send you an alert that says, hey, you just got a charge from XYZ. Is that okay? If it's a problem, let us know. Meaning they approved the transaction and did that. The friction of the first versus the second is quite dramatically different. And what I'll say is, and coming back to your backend versus front end. So the front end is, oh, one, I have to go do a pre kind of thing and I have to remember it and all that. The other one is I have to respond as an exception. If I wasn't in London and I got a thing saying, hey, you just charged in London, I'd go, oh, I treat that as an exception. There's no friction to me if I decide to do that. The backend implication of that, and this is something I learned working at a company that did a lot of credit cards, is one would think that in the industry, there was very sophisticated fraud analysis and assessment. And oh, this person is a left-handed person. So this and that person was wearing a sports shirt. No, it's really crude, surprisingly crude. And the company that I was aware of was really putting a lot of effort into improving their fraud assessment of charges to reduce the number of false negatives or false positives or whatever it would be. In other words, somebody is charging something that they should be able to charge, but it shows up as not being able to charge. That's a backend process. They were rewriting their fraud system to offer better functionality or greater satisfaction to their customers, reduce the friction. And the net of that is, guess which credit card company I would be, and the phrase they use in the industry is, which one of those would be first in wallet? Which is the one I'm going to reach for? Guess what? So there's a whole range of things. How do you reduce the friction? How do you induce use by the customer? How do you adjust your backend systems to enable that? And then they have to build a system that says, oh, we need to bring in a new fraud assessment mechanism. It's not just left-handed and sports shirt. It's also flip-flops versus whatever. You've got to have a backend system that can say, oh, we can add in another analytical checkpoint. And so you need more flexibility in the backend. And if you've built something that says, well, once we get this thing done, it's done forever. It's going to be hard to do that. If you've built in a system that says, gosh, this is likely to be an area of significant change.

So we need to be able to update it frequently. That's going to, that's going to direct you as well. So that's an example that encapsulates several of those things that you were bringing. I like that example because just to rephrase exactly what you just said, it's representative of focusing on making your customers' life easier, or at least not their whole life, but their interaction with you, the business. You can't promise that they're going to be able to make a better sandwich because you put that in there. But like, it also directly points out the consequences of a project versus a product mentality. And the project mentality being like, all we can do is have them basically update a field in a database. There's no way for us to like push out a notification to them and then collect what their response is and then integrate that back into the system. Like we just, they can just go update a field. And like the idea that we would change that backend has not occurred to anyone or not that it hasn't occurred to anyone. Cause of course it has, but it hasn't occurred to someone to prioritize that high enough because they, they want to deal with that friction and make the experience better. Well, give us a little overview of some of the other people that you have on your team and kind of the industries that you work in case people are interested in following up with that. We definitely have a team of experts in financial services here, myself, Bernard, and Henri Vandebook. We also have JT, expert in healthcare. Gotham is on our team, Gotham Palapa. Dr. Gotham Palapa is a retail expert. Nick Clark, obviously former MasterCard head of cloud, also huge into telco prior to that. And then Carl. So if we're looking for manufacturing, we talked about cars. He's the person that works a lot with people who build planes. And so we have covered mostly every industry at this point. I think we're looking to get into more fed stuff. I think we have some, any industry examples, if folks are looking for around digital transformation. All right. Great. I appreciate you two being on and having a discussion about this stuff. So with that, as always, this has been Tansu Talk. If you want to get the archives for this show, you can go to tansutalk.com. We post many of these things, including this one's as a podcast, but there's also videos.

So you can find a link to all the videos that we have. And with that, we'll see everyone next time. Bye-bye. you

Tanzu Talk · 🍕 Get more pizza.