S05E03 The Architecture of Scale: Building Repeatable Fintech Products

Speaker A: Foreign.

Speaker B: Hi and welcome to the Story of Software podcast where we have San Sangupta, who is currently the CEO of Finray Europe, a platform designed to automate complex financial operations for some of the world's largest institutions. With a career built at the intersection of high stakes finance and technology, including his time at HSP Group and hsbc, Sam, um, has mastered the art of taking technically dense and turning them into repeatable tech led growth engines. Sam joins us today to talk about the architecture of scale. We're moving beyond the high level theory of product market fit and diving into the actual methodology Sam uses to find surgical entry points into a market building repeatable, uh, product blueprints. Sam, thank you so much for coming to speak today. I'm really looking forward to the conversation.

Speaker A: Thanks Ricky, thanks for having me. It's great to be able to share some of the trials and tribulations from what I guess has been my 25 plus year career journey with.

Speaker B: Very good, excellent. I'm looking forward to getting stuck into it. So look, we always kick off with kind of the podcast with a bit of context and about yourself, your career history and really is what brought you to where you are today with Finray.

Speaker A: Thanks Ricky. So the journey itself is I guess taken many twists and turns. I would say it's really been influenced by three things. First, uh, is there's been this insatiable desire for personal growth and having an inquisitive mind about other countries, cultures, that type of thing. Secondly, decisions about my personal life. That one might sound a bit weird, but I made a big decision to move to Ireland in 2006, uh, my wife being from here. And third, and the final reason again may sound a bit odd, but private equity investment into the firms I've worked for have really shaped the journey as well, both in and out, you know, with their involvement so broadly. I guess I started my career in Morgan Stanley actually, um, having done stints in London, Tokyo, Hong Kong and New York over about a 10 year period. As I mentioned, 20 years ago I moved to Citgo on the fund services side, Dublin, where I continue to live with my wife and um, three children with them. I spent some time in Singapore and the Philippines. I think you're getting the theme of travel with Setco. And then I moved to TMF on the corporate services side to shape it all. At the end there were a few startups in the series A and series B phases of their journey, so they're all wildly different as I mentioned, but things that spanned um, that career journey

Speaker B: Yeah, I really like that. I mean because it's, you've got a great range obviously because working with uber large corporates to startups, to different cultures, different ways of working, you've got a real mix which is for me it's always very healthy. And I love working with people like that because people like you bring so much to the table because you kind of worked with different, as uh, I said different cultures. And you've seen kind of how big companies operate and what's then needed for smaller companies, which is quite important actually when you're thinking about kind of product and product market fit really. So I think it's in one way I'm not surprised because it kind of obviously kind of led you to where you are today and kind of your expertise in the space. So I'd love to kind of get into kind of the meat of the conversation. So we talked, uh, kind of introduced you earlier about the product market, fitcon, Venture Point. And I think that in a lot of ways it's obviously incredibly important but it's incredibly difficult for startup or uh, scale up businesses in a way. A lot of people do the kind of spray and pray and then they kind of narrow in focus and they kind of find their kind of path to least resistance. So I suppose I just get into kind of the first question is like you've talked a lot about the previous conversation about addressable market segmentation as a surgical tool. How do you identify that one specific edge case where a product can really accelerate and start generating uh, meaningful ARR for a business?

Speaker A: Yeah, I think that's a great one. Ricky, uh, you reference, I think my background where you know, I've done sort of product work uh, all the way from the Morgan Stanley days to where I am today. And I think as you mentioned it's actually very, very different in each one. I think the answer is actually partially dependent on the timing. So in a real startup in the early stages I think that spraying and praying is absolutely necessary. I think the other one you hear as well is you know, spaghetti at the wall and see what sticks. And I think with some sort of market and founder intelligence, and I'll use the word logic in quotes, some of that is necessary. So you know, there are case studies where companies have kind of pivoted quite dramatically in that experimentation phase I think, and they wouldn't have really landed on that unless they had done that. So finra, I think is a good example of that. So um, unlike many other technology solutions in the market, were actually quite unprecedented. So the data model, the subledger architecture that we have gives this kind of differentiating advantage for financial services firms. It actually means that the hard part is done. So we did the foundation work that allowed the spray and pray kind of approach and it allows us to go after all of these verticals in a really wide addressable market and then use that cx, UX and ui less difficult to maneuver space to fit the product for that market, fit in that specific segment of the market. So because we've got the foundations, it allows us to go in and out fairly kind of rapid pace, which I think is very important in this part of the journey.

Speaker B: Yeah, no, absolutely. I often quite see people going after problems when they. But there's no money there. How do you think about that? So that you're finding, I know people call it like say budget backed problem basically rather than just okay, there's some people need it but there isn't the budget there for it. How do you think about that?

Speaker A: Yeah, and I think that's a really, really important point to get to because invariably it comes down to that, especially when you're at the seed, um, sort of series A, series B piece of it. Typically from an investor perspective you've got to justify and put some validation around the buckets you intend to go after. So I mean if you go into an industry specific example, I think that validation will uh, take a couple of parts. So within a given market segment, applying that differentiation to budget backed spend essentially animates that validation. Right. So something like regulatory fines tied to findings and fines. In our context we talk about MRAs and MRIAs essentially reconciliation tools can be used to match numbers but they don't do anything for lineage and traceability. So we've got to try and take that committed budget with the problem statement, real consequences for an action and then fill the gap that no one is filling. And I think that's where the budget piece of or the budget backed problem comes alive is essentially somebody actually has that problem, they have a budget to go and fix that problem and it takes away the difficulty in trying to justify an increase in budget, which is very, very difficult for some of these organizations.

Speaker B: And how are you finding, is the budget being created because they want to reduce the manual effort or is it additional operating expense? Basically. And what is the pressure point that's actually going to make them buy a, let's say finray, if that makes sense.

Speaker A: Yeah, Ricky, I think super interesting and uh, I'll answer it sort of two ways I think. One is where the regulatory problem scenario, I think that one is quite an easy one because you've got to go solve it, right? There isn't sort of an operational layer to figure out. For example, in Ireland in the fund space there is some daily reporting now that's come out. It is super difficult to try and solve that with bodies. That's never going to happen because of the intricacies in trying to get that information together. The other part, it was interesting, uh, we pitched to a client yesterday and that was the first thing they said was they're in a hyperscale kind of scenario at the moment. And the last thing he's trying to get to is operationally add bodies to what is currently a fairly, uh, lean, well run environment. And the reason for coming to us was not necessarily to remove operational cost or improve existing margin, but rather which I think is actually quite smart, is to lay the foundation so that you can scale with some technology that allows the foundation not to erode your margin as you grow.

Speaker B: Yeah, yeah, yeah, no, absolutely. And what is the state of the fund? So is there a lot of margin pressure? Are they technology advanced? I'd love to kind of give kind of our listeners bit of background in around the state of that industry. Is it mature from a technology perspective or is it not?

Speaker A: Honestly uh speaking, I don't think it is. I think several organizations are struggling, I think in that space to actually implement technology solutions. I think people talk about it all the time, but truly I think that's been difficult. I think the larger you are, the more difficult it is. It's hard to kind of scale back. And I really believe that some of these organizations will have that Kodak moment. Ultimately the technology is getting to a place now where I think disruption at least of a small scale is possible. And I think the players who embrace that now will be able to uh, succeed from that. But yeah, to answer your question, I think it's very, very slow. It's not agile at all. And uh, I think while there's noise in the market about people doing things, I think where, if you dig down to be able to see where they've implemented across their client base or across the entire organization I think is very light.

Speaker B: Okay, okay. So people are almost accepting that they need to do something, but there's very few people who've actually done anything basically. Well that sounds like there's opportunity there which is you uh, know you just almost need the gates to open for you guys at some stage. Getting back to kind of a bit more in around the Product and understanding, I suppose the methodology side of things when you're starting off you're very much like doing everything from kind of like one off sales but then you really want to scale the business. You want to get into kind of let's say the kind of repeatable engine that uh, a template strategy a lot of people talk about. In a previous conversation you mentioned that once you solve a kind of a problem for one major entity you should have a cut and paste blueprint for the rest. How do you kind of ensure your product development stays focused on building a template rather than getting distracted by bespoke big clients? Because I know from being in startups and scale ups that is almost like the biggest thing, that's the hardest thing for companies to do. Your biggest customer says build me this feature. For me it's hard to say no basically but I'd love to kind of get your um, input.

Speaker A: I think everyone's played by something like that Ricky. And I think for me what it really comes down to and I think this is where my experience in sort of very, very foundational startups, that is one of them. We started with a couple of 365 accounts all the way to the large behemoths have given me a good sense of where's that point of inflection in those journeys that you've really got to get this right. So I think coming back to what we're talking about, it really is that product market fit piece of it. So making sure the framework is executed. We say this quite lightly. You know people use these acronyms and they use this terminology when you think about, you know, it's not just product market fit in isolation, it is that addressable market that's meaningful, the segmentation of that addressable market and um, the fit into that addressable market or the segment of it is super critical. Right. So once you've understood that 80, in my opinion 80% or more of that CX, UX and UI piece of it should really fit then into the rinse repeat model uh, that you're talking about. And in past experiences we've used certain technologies. There are widely available products that allow you to monitor how clients are using your specific product. I think that gives you good insight as to whether you see a uh, potential ARR opportunities. Not one off edge cases that you want to go after but that kind of side of it becomes meaningful. But to touch on Finray, I think Finray has been built in this way. We have the core data model, the subnet architecture. I talked about which actually handles 80% of what clients are looking for out of the box. The rest just shapes it for that target segment and it shapes it for what they're looking for. And ah, part of that is quite customizable in what we do. So institutions that want the flexibility to apply the rules and regs on their own terms, we're able to do that and that guidance externally that may be fixed but firms in the way they interpret have their internal policies and external policies allow them to operationalize those in wide ways but within the product. So I think you've got to make sure that you've got it all the way from the top that allows it to make sure it's connected and then in my opinion the rest really should follow through.

Speaker B: Okay. And I suppose I'm just trying to think for. So you've built Finray to be almost like, like the core product solves 80% of the problem and that's based on your research within the market what all your conversations as part of kind of let's say product and then you built. Is the final 20% customizable for everything and still part of the actual product. Is it?

Speaker A: Yeah. So Ricky, the genesis of Finray would have been deep understanding of the financial services market primarily sort of capital markets, investment banking but wider into the fund space as we talked about asset management. But what that actually meant was. And um, one of the founders was also chief data officer who really understood and a product controller like myself so really understood all aspects of that journey. One of the hardest parts in terms of doing that market research was understanding the existing products in that space. And again I won't mention the names of them but there are many limitations in these products. If you think about what an ERP is that's not. ERPs are not designed essentially to do the things that financial services need, but they're being used as that. I think where we have come in is taking a uh, 20, 25, 26 approach to solving some of these archaic systems that never were suited for the job. What we managed to do is put the foundations of that into place to answer the last part of the question what that allows the wealth for tout way the data is normalized, contained and then exposed out uh towards the general ledger in one pipe means that it's very customizable for the different industries where we're able to produce more than what the standard rec tools do. Because we commented a bit earlier, join up the data, make sure that it's clean, channel it into wafer financial services which is actually quite hard to ensure that they are grouped in a way that's meaningful. It allows you to then wreck the two numbers. So I consider ourselves a prerequisite for some of these sort of reconciliation regtech, Fintech tools that do that last mile but need that 80% that we've solved up front, which is really difficult to do.

Speaker B: Very good. And do you mind me asking, do you get a lot of bespoke requests on top of what you built then as well?

Speaker A: Yeah, I mean I think we've had a couple that have been sort of some away from financial services, for example, Ricky, and we've taken a look and been able, you know, in a lab kind of environment to do stuff like that. It's interesting because I did come across an article on LinkedIn the other day. I can't remember the exact examples but companies that started off doing something completely different. Now I can't see Finray ending up in edtech or something like that ultimately, but it's an interesting concept when you think that that kind of segmentation of an addressable market that might be a huge problem in the US or Europe or otherwise in a particular space like that could be the thing that gets. And I think for your listeners, I think that's the key takeaway is that I wouldn't rule things out because it doesn't necessarily fit and it could be an edge case because that edge case could turn out to be scalable into significant ARR.

Speaker B: Yeah, yeah, no, you gotta be kind of agile or open to it really I think. Really, uh, at the end of the day I think. And uh, yeah, it's a difficult one. I think previous scale up with startups that I've worked in, even the core product that does very comprehensive, you would still get big players going well I want this on top and that on top. And you're gonna have to go to a place where well, what we did at the time was say uh, right, well we're happy to build it but it's kind of going to be a one off custom build and it's going to cost you 5 million quid. And you quickly realize do they really want it or not at that stage.

Speaker A: So at that point Ricky becomes a win win. Right. Because if they take it 5 million bucks, let's do it.

Speaker B: Exactly, exactly. But it can be difficult because often with these big companies they want to bake it into part of the procurement process or like we'll give you the contract if you do this and if you do that, you know, so you Gotta be strong in those scenarios. Yeah, it's difficult.

Speaker A: Yeah. I mean one thing to say on that is that from our clients perspective there's a fairly wide range. So we talk to the large investment banks and when you're thinking about the size of the prize I guess I think there's gotta be a level of flexibility that you should be going after. I don't think you can necessarily just turn around and say that I can't. But in all honesty with all of the conversations we have once we've had that initial kind of deep dive into the requirement and the scope, it never turns out um, touchwood into something where we think this needs a huge amount of the foundational rework. We've not seen that to date so it really always has been to figure out how we can apply AI uh use cases to a particular reg reporting problem. It's been stuff at the top rather than sort of at the foundation level.

Speaker B: Yeah. And look that's obviously the really smart thing to do is just as you were speaking there, it came into my head like we're actually Zartas were dealing, were working with quite a mature fintech business and they basically they sell to banks effectively as well and not particularly in your space but they didn't build it to be scalable. They just literally copy and paste of the code base and did they now have like 20 or 30 banks around Europe. So they were, they're managing 30, 40 different code bases. But that's kind of not what you don't want to get uh because you're building the foundational that can be uh, replicated across hundreds, if not, you know, thousands of clients basically.

Speaker A: So that sounds like such an obvious thing and I think it's one of those other ones where there's always a point of inflection. Again won't name names but various organizations I'm aware of where they've had client specific databases. There's been no control around that development life cycle and drawing features, et cetera or architecture has been consistent and I think that inflection point has been reached where it's out of control and it's absolutely impossible to manage. So yeah, I mean I think for your listeners a great point to think about, you know, at a fund, sort of at a starting point, an early stage really set that software development life cycle into a managed process before it reaches that point of inflection.

Speaker B: Right? Yeah, massively like to kind of move on and talk about kind of ROI now. So how do you start thinking about or frame the products roi. So the customer sees it as the essential evolution of the business model rather than just another tool in the stack. And I think this comes back to kind of what we were speaking about earlier. There's got to be a Kodak moment for people where they kind of think this just has to be there. And how do you think about and how do you frame the product's ROI to them?

Speaker A: This is a good one I think, Ricky, in these scenarios where I think you've got a lot of work to do actually to explain and win business for clients, which is frankly quite difficult, especially in the startup space. I think one of the key things we've tried to do is work with clients at the beginning, at the outset to identify that baseline, for example, around some of the metrics of the business that could be number of people that are needed to run that particular part of the business. How long does it take to get some of the reporting for something like a daily requirement to a regulator? How are you doing that? How are you getting to that point? How many people does it take today? How late are you? How many penalties are you paying? I think that's really foundational work that you've got to do. And the good thing about us, as I mentioned from a fin rate perspective is that's the starting point. But what we do is we augment their existing stack and create that foundation. So what it means is we're not coming in disrupting everything that they're trying to do today. But by augmenting against that, it's quite easy then to see, well, okay, by plugging this piece in, we are able to get this kind of ROI on maybe a use case or one particular example. And that then leads to the next conversation to say, well, if you've generated ROI in meaningful way for this, now we've understood and seen that it works and we know what it's trying to do, we can take the next steps. So that foundation I think becomes non negotiable for a lot of businesses. If they want to participate in the AI piece, in the automation piece, in some of the analytics that they want to do, and especially some of these ROI elements that they're trying to achieve, that lays that uh, foundation. We've heard that all the rhetoric around AI at the moment you're getting folks at the C suite who are asking without understanding what are the gains I can get. I want to see efficiencies in the business and I think without that foundation it's a dangerous place to start promising ROI from CIO or a CTO to a CEO, it's going to fall quite badly. Flat, right?

Speaker B: Yeah, 100%. And one, a lot of people don't understand the art of the possible with AI, but they also don't understand what's actually required for uh, things. So what we've encountered is they're uh, like there's loads of stats in around like 5%, 50, 95% of POCs are uh, failures. In the main it's because they just wanted to have AI and there was no actual problem to solve. What also goes with it is that they weren't set up correctly for it. Okay. And a huge part of that is kind of like data is not in the right way. They haven't gone through a data cleansing kind of exercise. They haven't set it up for AI. And I suppose that kind of brings me kind of next point saying like look, things are moving into the AI space and what you do is really, really important for, to be, for companies to be successful and to actually generate ROI and actually become, maintain competitiveness in a way. I would say like you know, it's you cover talk with the Kodak moment like that is going to, going to creep up on people very, very soon. So I think I kind of love to ask you, kind of like what is the critical kind of data pre work a product team must do to ensure their AI features actually deliver value instead of kind of just noise or whatever?

Speaker A: Yeah, I mean Ricky, uh, it's such a fundamental question. I've written about it on LinkedIn a couple of times. It still baffles me to this day. Uh, you know, data is not a sexy subject. People don't want to talk about it. I've been in various organizations where it's been easier. It's ignore it. I've been in some organizations where it's too big a problem to solve so it's been left alone. Because of that belief though, I think the problem then becomes, is that you are then essentially building things not even in the AI space but pre AI where you're wasting time and effort where you're not going to get a result so you're going to get caught out at the end anyway. So I mean in my mind the actual advantages of prioritizing data. Finray for example tackles some of these head on. And let's talk about maybe there are three critical ones to mention. Um, the data collection piece. Right. So garbage in, garbage out. Everyone's heard that if it isn't uh, relevant, if it isn't uh, properly collected as We've said AI is essentially flying blind. I mean smart AI actually needs that smart data right from the start. You can't just kind of do that at halfway in the journey. The second thing is the integration piece. So as we know different systems of record data is absolutely everywhere. Hard not only to get it together, to bring it all together from our product perspective, SMEs themselves, you know, the democratization of this to business users where they can use our intuitive mapper, uh, Finray normalizes it all on the back end so you don't have to sweat any of the details. And this then gives AI the full picture for the sharper and the better predictions that you're looking for. So you know where so many of the organizations are still operating in silos, those silos are actually obviously killing insight. That integration fuels the insight that you're looking for. And the third and final piece is that data transformation bit. So raw data is always difficult to work with. Finray for example, has advanced functions that transform the data so that AI is able to understand and um, use it effectively. So you know, we see scenarios where we're all using tools these days where the feedback you're getting makes no sense. I saw an interesting one, I don't know whether you came across it yesterday, where I think somebody had asked, I won't mention which organizations tool, but something along the lines of if you have I need to get my car washed. The car wash is 100 meters down the road. Do you think I should walk or drive? And the chatbot basically articulates where you should walk. It's healthier for you, you feel better and I'm sure they can help you when you get there. Fundamentally missing the point that you need the car to get the car washed. And I thought that was brilliant. But I think again context and data is obviously one piece of that. But context around having it grouped and able to be joined together is so critical for this exercise.

Speaker B: Yeah, because it is that context. Like, you know, that's why the vector database or graph rags are really, really important. And unless you have all of that context in there, it's missing it basically. And uh, particularly at a kind of enterprise led enterprise side of things that can be dangerous or damaging. But it is difficult for organizations if you think about like they've gone through decades worth of siloed information and even thinking about trying to clean it up and put it in a place for you, uh, is a headache in a lot of ways basically. So I can understand why people are

Speaker A: dragging hills, but yeah, And Ricky, I know I'm sitting here plugging Finray, but I think one of the great things about the solution is that it takes us typically six to eight weeks to join that data. So we've seen the kind of wow moment on clients when after six or eight weeks, um, they see the results of what we have been able to do. And so I agree with you. I think two parts to that. Firstly, no one wants to sit and invest in a two year project or a four year project. Some of these generic data tools, you then have to get a bunch of consultants in, you know, spend another 5 or 10 million to build it. The appetite for that has disappeared and we're seeing that a lot. We're seeing a lot of the big banks and others who are not willing to engage and get burnt a second time around. And which is where I think uh, you've got to be smart around the quick results piece of it. You're able to show that leave your existing stack as it is. Especially when it comes to things like the regulatory reporting that I'm talking about where this isn't a nice to have, it's not, well, let me go and fix my architecture or fix the stack to get what I need. You need something that's going to come in, help to join it, get some results straight away, get that problem fixed, move on and then see what you're going to do next.

Speaker B: Yeah, because I think uh, particularly with the regulatory piece, I mean it's just a baseline requirement for a business these days and you need technology to enable you to deliver it. And if you want technology enable you to deliver it, you have to have your data etc. In the right way. I think the moment, the thing that you said, like the Kodak moment is it's coming for a lot of businesses not just within like say fund administration, but right across the um. We are, we're all, we're already seeing it in a lot of ways where not so much from a, let's say regulatory perspective but like AI native competitors are coming in and they've got a completely different operating model and capturing way more margin and could be way more competitive. And that's really a pain point for some of the more bigger incumbents, you know. So I think that's going to come at a lot of people and we're seeing it already in a lot of instances, you know.

Speaker A: And Ricky, apologies if this sounds ruthless. I would love to be part of that wave of disruption that does that. I think, you know, to have legacy in this industry I think if you're part of that movement, who's able to show some real innovation and show that it's possible, disrupt commercial models, disrupt operating models, disrupt what people are doing today? I think that's a hugely exciting opportunity.

Speaker B: No, it is massive. It is very interesting. And look, we're also working with legacy companies that are trying to react, and that in itself is super interesting because we are big believers that the way things are, business has been done before, needs to be completely reimagined for AI, basically. And I think a lot of businesses are going to have to completely reimagine how they do things. And that is an exciting step for businesses when they actually fully commit to it, basically. But there's a lot of, I would say 98, 99% of companies are still resistant because they don't need to yet. Until they've actually got a fire burning under them, they won't do it.

Speaker A: Um, then it's potentially too late.

Speaker B: Yeah, yeah. Because they're not quick. They're not quick, um, exercises. It's a year to two years to completely reimagine and rebuild your entire operating model with AI and stuff like that. So. But it's a super interesting time within our space at the moment. I want to kind of get your thoughts in around agents and people and who's in control and who's not in control. How do you think of it? Like, what do you think is going to work best for humans and AI agents working together?

Speaker A: Yeah, I think this has been a challenging one, I think, for people generally out there, because I think there's been a lot of hype. I think there's been a lot of misunderstanding around what agents are intending to do. I think maybe in the finray context, we see that interaction between, uh, humans and agents as potentially defining opportunities. So I don't underestimate what I think that can do. But again, it comes back to that infrastructure that allows them to operate seamlessly, but only with that data integrity, the trust in the outcomes that become so meaningful. And, um, in financial services, the big challenge here is that 99.9% accuracy is just not good enough. So you can't actually suddenly just turn around and say, I can get agents into this entire process. It's just not going to work. Right. So I think what, you know, you've got to do is get that data layer right. But, uh, when an agent is what is acting inside that workflow, we essentially, from a finray perspective, are able to provide that layer that gets your data essentially aging, ready Right. So having that structural foundation, aligning ah, controls, having some process orchestration, this is a huge one, right? People you can't, you've got to have repeatable processes. Ultimately orchestration is the thing, the layer that will allow humans and intelligent agents to operate seamlessly within the guardrails because ultimately from a client customer experience they should not really be aware of what's happening and by whom. The beauty of that is, you know, essentially you can introduce agents into these complex workflows perhaps on the more simple ones where you have a clean lineage, kind of tracked, policy aligned ah, environment. But what that means is that you are then able to deploy agents, AI agents into the journey when you've understood enough about those cases in something like finance where you've got it to 100% instead of 99.5. Right. So in a practicality sense, where I see, I think in general people are struggling is understanding how to go about actually doing the implementation even in a lab environment that allows you to start the process, to start building that into your workflows so that it doesn't impact decline.

Speaker B: Yeah, yeah, no, completely agree. I want to finish up with one final question for startup scale ups that have got a bit of traction. What is your advice for building a truly repeatable engine? What would they do, what would they focus on for the 90, 100 days after they really start to see that coming together?

Speaker A: Yeah, Ricky, such a hard one. And again having been part of real kind of startups and then having seen at the other end of the scale what you should have thought about it, which part of even beyond 90 days, but especially in the first 30, 60, 90. I think ultimately it is about defining and uh, building and setting those foundations at the outset. Right where you do have customer or client experience at the top of mind. Again that's overused as a uh, notion. But if you really are trying to achieve that, for example in professional corporate services, fund admin, to understand that framework, uh, to scale at the start is really important. What are the layers you need is have you got the right lp? How are you managing your lead to revenue process right from the beginning? How do you create that orchestration? It might just be a simple ticketing tool to start that prevents you getting into the realms of email and spreadsheet looking for a secure environment that you're actually going to be working out of at the beginning. What are the client Personas and what are their needs that you're actually trying to build for that experience platform, um, putting those in as foundations, having that kind of good, better, best, uh, philosophy where you are able to get started with something with perhaps 10% of AI agents in place in that 30, 60 day, 90 day period is good, right? It may not be better and best, but you've started with something and laid the foundation to put the next 10% of agents in and the next 10%. But it's that philosophy I think that you've got to achieve in the 30, 60, 90 days, which is so hard to do because Ricky, believe it or not, everyone still defaults to a spreadsheet. As much technology as you give people, they will still go back. So in my opinion, the agent scenario is, is sort of a second or third hurdle. You've got a long way to go when you're trying to transform in the transformation realm of some of these large organizations, where I remain cautious about AI deployment into some of these. So that Kodak moment becomes quite real. As to when that happens, I don't know, but we're on our way.

Speaker B: Yeah, I know. Um, the only thing I would say is like, you can build agents into spreadsheets these days, so

Speaker A: that's entirely true.

Speaker B: I'm not sure if you tested Claude in Excel or anything like that. It's particularly impressive. Yeah, no, look, I completely agree with everything you're saying, but it's the discipline which is kind of the most difficult thing I would say. Fabulous speech. We always like to finish up with, really get a bit of download from you in around there. Any kind of resources, be it books, podcasts, mentors, people that have shaped your kind of thinking and around product to leadership or personal growth or anything like that.

Speaker A: Yeah, I think very briefly, Ricky, you know, the three parts of the, that I started at the outset in terms of what shaped the journey, I think they've all brought a lot of positives, negatives, learnings. I've always been somebody who wants to try and learn something different and take the best things from the different parts, whether uh, industry or people that I generally tend to kind of listen to. I tend to read a lot. Um, I tend to listen to a lot of podcasts. Obviously your one is excellent, Ricky. I thoroughly recommend, I suppose, podcasts like Thinkcast, by Gartner, HBR on strategy. These are all good sort of plane, train and driving kind of things to do. One caveat for me as I mentioned, books and podcasts, et cetera and consulting, it's still, and I have, I think throughout my career, uh, still seen a massive gap in the execution side. I think some of these podcasts are excellent in the sense that the directional stuff, they give. But I still see a massive gap between sort of how you go about putting that into practice in some of these organizations. And I think that's really, in a core, in a nutshell, what drives me. I love to take that and try and translate that into execution.

Speaker B: Fabulous. Very good, Sam. Thank you so much. I really enjoyed the conversation, as always. Fabulous.

Speaker A: Great to talk to you, Ricky.

Speaker B: The Story of Software Podcast is a Zartist production brought to you by Adnan Tukar and Lariana Fantoni.