My First 16: Launching a New Category with Modern Treasury’s Dimitri Dadiomov

Episode Transcript

This transcript has been condensed and edited for readability and clarity.

Seema Amble: Let’s start off by talking about the founding story of Modern Treasury and a little bit of background from leaving LendingHome [currently named, Kiavi].

Dimitri Dadiomov: Sure, well Modern Treasury really came out of a set of pain points we had at LendingHome. So I was a product manager managing the investing side of this marketplace. And on one side, people would come and apply to get a loan, for a fix and flip renovation loan. And on the investing side, we had to create a website that allowed people to open an account, fund it, and then basically select a number of properties to invest in and basically build a portfolio of that. And so we  jokingly would call it ugly Airbnb, because it was  like Airbnb in the user experience, but every property had water damage, or had some sort of issue with it. 

And so that was what you’re investing in. And so there’s like a website and a web flow, and how does the customer actually get in and create an account, but then there was the financial money movement aspect of it. When we fund a loan, a wire would go out that will essentially fund that deposit over an ACH debit or a wire. And then every time that a borrower repays the loan, we would take the ACH debit, split it up, send it to the right wallets, do it all proportionally, there’s  this crazy, crazy spreadsheet math. 

And that number of payments, as the platform scaled, became really, really crazy to manage both in terms of the engineering challenges around how do you actually connect to the bank? There was not as much fintech infrastructure as there is today. And so everybody had to build their own connections. And I started running around asking friends of friends at different companies. “Hey, how do you guys do this at your company,” and I would meet a friend of a friend of a friend who finally would do this the same way, basically. Where like, a lot of people inside the company are building things, one off, and never have enough investment in that to justify why they need to go and do this at a slightly higher quality. 

And it’s one of these things that’s really not a core competency for most of the companies I was talking to. And so they couldn’t justify the right level of investment. And at the same time, it was the same thing that they all needed. And so that was really the origin of Modern Treasury. So in 2018, my two co-founders and I left and started Modern Treasury and went through Y Combinator. And that was the origin story. 

So we were solving a problem that we observed a lot of different companies had, and the solutions that these other companies had were expensive and subpar. And so it felt like it was a place that was ripe for new software products.

Seema: How did you think about, “Here’s the minimum viable product (MVP) that I’m going to build given this pain point?” What was the MVP and how did you figure out the initial product before launch?

Dimitri: So, very early on, because we’re solving our own problem, we had some strong opinions. And one of the opinions that we had was that the only way to solve this problem was something that would bridge the technology and engineering and EPD sides of the company. And those teams really wanted APIs and web hooks and event logs, and those developer things. And at the same time, they were working in a world that interacted with the financial system. 

And so these teams were building things in their writing code that facilitated real money movements in the real banking system. And they ended up in real statements. And so you had this whole host of other teams — finance, ops, capital, markets, etc. — who are living in a world of PDFs and spreadsheets and they needed to know what’s going on. Those teams really need a dashboard, they need an online user experience with a workflow. 

And so the MVP really was an API to initiate and reconcile payments, specifically, ACH and wires is what we started with. So bank rails, and then a dashboard that showed you what was going on and allows you to drill in and click on things and actually see the details of different payments. 

So you can think of it as like 3 legs of a stool: how do I connect to the bank? Do I have the backend integration to the bank systems? How do I surface that in an API to the tech team, so they can actually build that into the product? And then a dashboard for all the different teams that are having to reconcile all of this activity?

Seema: How long did it take to build the MVP?

Dimitri: When we wrapped up YC, we still were not live with our first clients. So it probably took us about 10 or 12 weeks to build it. But it took us a while to find the right clients and to actually go and implement it with their bank and bank account. So it probably took us about 10 weeks to build the MVP in a functional way. And then took us about 5 months total to go over the first customer.

Seema: That’s a great segue into talking about your first set of customers. How did you think about approaching your first customers? Did you go through warm introductions, cold outreach, and who was doing that outreach?

Dimitri: All of the above is the short answer. So we were very focused on collecting product feedback. And then aspirationally, hopefully, maybe one of these customers would sign. That’s a little bit of how we thought about this. 

So we had we started out with really going after companies that we knew had this problem today and just to see what is it that they have in their  toolkit today, and do they have needs that our product would fill? So we would meet with companies that were like 300, 500 people, they probably had like a payments engineering team. It was maybe like a 4 or 5 person team. And they were strapped and they had a lot of requests, and we’re trying to talk to them about what they could actually start using from our toolkit. 

Very quickly, we realized these companies would have too much inertia internally to actually sign up with a small startup. And so we started talking to much smaller companies, you know, 3-person, 5-person, 10-person companies who had not yet built the payments engineering,  maybe didn’t have a head of finance. They didn’t have any of that infrastructure. 

And so for them it was a much easier decision to go and basically opt into using a new solution for their product. Our first customer there was a mutual friend of ours, and he was starting a new company. And it was just him and his co-founder, and I think one other person at the time. And they were starting a new company that they knew they had to go build a money movement system that was fairly sophisticated. Because of the nature of the product as a healthcare  benefits product, there’s a lot of money movement going on inside of those accounts. Like every time payroll runs, they get funds coming in, they have to reconcile them, they have to put them in the right reserve account for vision, medical, dental, things like that. So there’s a pretty complicated spaghetti diagram of money movements and reconciliations. 

And they trusted us enough to say, “Okay, you guys can be at least our early solution, we’ll see if you scale,” and that really put us in business.

Seema: How did you think about building trust and getting these initial customers to trust you with their money?

Dimitri: I think having a personal relationship is super important in the early days. I mean, there’s sort of nothing else that can replace trust. I don’t think it’s an accident that our first client was somebody that actually knew us from before. And I had known this person for quite a long time, like we had a lot of prior history together that allowed them to feel trust. 

So I think for something like an infrastructure decision, first of all, there’s a technical question of can we solve the problem? But then there’s a second question of, can you solve the problem for a long time? And that’s actually a pretty hard question to answer. Does somebody else have to believe that you’ll still be doing this 5 years from now? And you can, as a founder, you can say, like, “Well, I’m very set on that.” But obviously, there’s a number of other circumstances that have to come along, that makes sure that that’s actually the case. 

And so, it’s something that you have to answer forever. And every time we sign companies, they’re wondering in the back of their mind, “Will you be around for a long time?” Because they’re making a bet, not just on feature and functionality, but also on the availability of the feature and functionality for a long time. And I think that’s something that is particularly hard to do in a startup for infrastructure. 

So a lot of it comes down to the cheat code, which ends up being: you develop a personal relationship, they trust you, they know that you’re serious about it. You don’t do a lot of pivoting and trying to test out other business models. So I think there is, you have to have a lot of conviction that like this is what you want to do, just at a personal level, that’s actually something that you have to decide for yourself. And then you have to stick with it so that they see a mounting campaign of signing new customers, adding new features, adding new banks. And that’s a lot of what we did later on, we started thinking about our brand and our content and announcements and things like that. More of like a strategy to build trust, but really signaling how serious and long term we were about this topic.

Seema: It almost sounds like you were doing marketing back to your existing customers. Did you think about it actively as marketing to your existing customers, and maybe celebrating wins? 

Dimitri: I mean, we thought about it actively not just for customers, but also for recruiting. So that first company that I mentioned was in healthcare and our first hire, she was joining from a healthcare company. And of course, we’re like, “We’re huge in healthcare.”  

Of course, you’re always leaning into the things that are working and you try to build up confidence. I think there’s an element, as a founder, it doesn’t really matter what product you’re  in, you’re always trying to build confidence across the ecosystem. Your customers feel good about your team, your team feels good about your investors, your investors feel good about your customers, like all of that has to work around you. So that’s very much a focus. 

When we thought about marketing, what we thought about more than anything is like we’re trying to create a category of payment operations. It was not really a topic that people talked about, obviously, it was present in a lot of places, but nobody thought about that. And so we were focused on let’s talk about what the common challenges in payment operations are.

Seema: How much did you have to educate potential customers saying, “Hey, this is this is a real problem that you need to solve with software” versus them thinking, “Okay, we have this process, but we haven’t really decided this is a category that we want to buy software in?”

Dimitri: I think different companies approach solving this problem in different ways. So the problem is not made up, the problems are real. But how you solve it is going to be different across different companies. So there’s going to be some companies that are going to be very engineering first about every problem that they see. And they’re going to try to build and automate and build the technical solution, even before they have any volume in any real pain.

And there’s other companies that are actually the opposite. They’re very comfortable spending time on doing things in Excel sheets, and uploading CSVs, to bank portals, and so on. And in some cases, you have companies that grow very large, in some cases for decades, and they’re still doing that. And so, there’s definitely an element of what has been the process that has worked for you for a long time, you understand how it works, you know how to train people who are coming into the organization and make them do that. 

And if you think about certain industries that have a lot of paperwork around them, you think about real estate or healthcare, like you just associate those industries with a lot of bills and invoices and paperwork. That’s very different from maybe certain industries that have gone through this digital transformation, if you will. 

One of the things that I think about is how do we make sure that we can serve both. So our product isn’t narrowed to one or the other. Like, it’s okay, you can build. So one of the design principles that we’ve had is everything we build is available in both the API and the UI. And you can do things by hand, or you can automate them. But nothing is going to be 100% automated, the world is going to be like at best, 99% automated, there’s always going to be one offs and refunds and new things. And somebody’s going to want to do it by hand. And so how do we make sure that you can build to do both? That’s something that’s very important. So I think you can define your product in such a narrow way that actually it doesn’t solve the totality of the problem. You have to be careful about that.

Seema: Did you think about consciously coining the term “payment operations” or “money movement” or was that just sort of happening around you?

Dimitri: So we shouldn’t take any credit for our CEO, she started out really focusing on brand and marketing. And it was really her conception of it as like, let’s actually define how we talk about this. So people know what they’re buying. And one of the side effects of category creation is that in the beginning, you’re the only one in it. So there’s a marketing benefit of being able to point to this and say, “Hey, we’re trying to solve this problem. And we’re leading in it.” 

Well, you made it up, of course you’re leading in it. But I think it’s something that is important to think about, if there should be some place or something where you can tell a customer hand over heart, we’re actually the most focused on this problem, or the best at this problem. 

Seema: How did you guys think about marketing versus sales and what to prioritize?

Dimitri: Yeah, we did not have a sales team for a long time. We invested more heavily in marketing upfront, and we got a lot of inbound leads coming from bank referrals, coming from other activities that we’re doing. So it really wasn’t until probably 2 years or something into the journey that we brought on our first dedicated salesperson. And I think the benefit of that is that everybody in that company was selling in some way, shape or form, and everybody in the company was focused on spending time with customers or prospects. And for good reasons or bad, we weren’t in a huge hurry to get the sales machine up and running, because we really wanted to make sure the product was good. 

Seema: Your first few customers, they’re probably giving you feedback, saying I’ve got all these other things that are broken in my payments stack as well. How did you think about prioritizing feedback and feature requests from there?

Dimitri: So I took a biology class in undergrad and one thing that stuck with me, the professor was a big like birding hobbyist. And he would always talk about how if you think about all the species in the world, birds are ones where we actually know a fair bit to a certain degree of certainty that we know all the species of birds, because the marginal bird that we’re discovering is increasingly small and gray or small and brown. And so, it’s harder and harder to distinguish between them. And so I think there’s an element of insight in there around feature requests. When you get feature requests, in the beginning, they seem to be random, and they seem to be  all over the place. And as you talk to more customers, and you do more product discovery, you discover more and more of the feature requests are really small, or increasingly smaller changes from what you already have. And of course, you find completely new species and completely new things that you may not necessarily want to go build. And it’s a conscious decision to go into that or not. But in the narrow area of what you’re trying to solve, you do get a lot of similar requests. And that actually gives you a lot of certainty or a lot of confidence, that like if I build this, I will probably build something useful to a lot of people because so many people have asked me for the same thing. Yeah, you discover new features, you file them away, perhaps and you say maybe someday we’ll go do that. But you have to focus on things that increasingly look like the most boring new species of birds you’ve just discovered.

Seema: How did you think about new competition coming up and how your product was differentiated?

Dimitri: I think it’s really customer use cases and customer stories that I think tell the whole story. So when you actually are talking to specific customers, it’s obviously always a good practice to find out what else have they considered or are considering? Or is there something else that they could be doing, and making sure that your product can stand on its own 2 feet and win against that? So I don’t think that it’s like an overwhelming focus for us, we’ve always been of the opinion that if we build really good software for companies that are good businesses, then we’ll grow with them.

But of course, there are companies that are starting new things all the time. And you take a look at them, and you look for things that make sense that you haven’t thought about before, and you improve your own product.

Seema: It feels like you’ve been very focused on just doing the right thing for your customers in terms of building product, versus spending a lot of time thinking about the competition.

Dimitri: There’s a saying that it’s very rare that companies die of homicide, they usually die of suicide. Companies usually mess up in some way that is actually just very internal. So when you read a lot of business books, I think people talk about competition, but the reality is when you think about the big crashes of businesses in the past couple of years, it’s all things that they’ve done themselves. Like, it’s not actually decisions that were brought on by an evil competitor. It’s like, No, you just did something stupid. So I think as a founder, you’re like, how do I make sure that we don’t do something stupid internally in our company, and as long as we deliver value, and we get customers to use our product, and we’ll listen to them, and we like fix the things that they don’t like about our product? You know, it’ll all work out.

Seema: Other than don’t do something stupid, what advice do you have for early stage founders who are starting their company trying to acquire their first few customers?

Dimitri: Even though we were mostly focused on product and usability, we spent a lot of time thinking about the business model and pricing and things like that. And maybe it’s good to think about what might be around the corner, but at the end of the day, I think early stage founders spend too much time thinking about the business and not often enough about the product. I think the reality is that in the early days, you don’t know what you don’t know about how people use your product. So designing the right pricing levers, you want to have some confidence that this product is useful. And you could charge for it. Obviously, if you don’t, I’m not saying don’t charge anything, because I think if you don’t charge anything you, you aren’t discovering the real willingness to pay. And I think that’s a problem. But I do think that from a business perspective, it is much more important for early stage companies to build a product that people love. And then you can figure out how to turn into a business.

Seema: Well, Dimitri, thank you so much for joining me. This has been great.