Rich Aberman: [0:05] It's funny. There are founders that can see the world 10, 20, 30 years out or have this really potent personal vision that they spend a lifetime imposing on the universe. We did not fit in that category.

Daniel Saks: [0:18] This is "Decoding Digital," and I'm your host, Daniel Saks. Every episode, we hear from someone who is working to build something new in the digital economy. Each guest has a unique perspective to share. Together, we work to understand or decode a trend that is shaping our digital world.

Mary: [0:37] Ten years ago, a new company called WePay decided to make a big statement about one of its big competitors, PayPal. The WePay team froze hundreds of dollar bills into 600 pounds of ice and dropped it in front of the Moscone Center in San Francisco where PayPal was hosting its developer conference. A message inside the ice read, "PayPal freezes your accounts. Unfreeze your money."

[1:04] The stunt was the brainchild of our guest for today's show, Rich Aberman. Rich co‑founded WePay in 2008 at the height of the great recession and the early days of peer‑to‑peer payments. Since then, it has become one of the leading online payment platforms and was acquired by JPMorgan Chase for over $400 million in 2017.

[1:28] Today, Rich joins us to share his unique point of view on fintech and why, in established industries like banking, working with a traditional company to innovate from the inside out is often the best strategy. Let's decode.

Daniel: [1:43] Rich, great to have you on the show.

Rich: [1:45] Glad to be here. Thanks for the invite.

Daniel: [1:47] For sure. Let's start at the beginning. You co‑founded WePay in 2008, shortly after you graduated from college. How did you know at such a young age that WePay was the right business idea for you to pursue.

Rich: [1:59] It's funny. There was probably multiple times throughout college and after where you wake up in the middle of the night and you'd be like, "This is the million‑dollar idea." You get super excited by it, and you spend hours drawing wireframes of some target state of what this thing is going to look like once you've built it all.

You tell all your friends about it and get super excited by it. Then a couple weeks and months go by, and you distracted by life, and those ideas whither on the vine. You move on as the uninformed optimism of a new idea gets replaced by informed pessimism of all the reasons it's not going to work and all the reasons why it doesn't make sense to go embark on a journey to go build this thing.

I don't think the original idea for WePay, honestly, was any different than any of those ideas. It was a relatively superficial idea. At the time, it seemed super profound. In retrospect, it was almost obvious. [inaudible] and a lot of people were building apps to make it easy for friends to send and receive money and manage shared expenses. The timing was just right.

I was on my way to law school. My co‑founder was my college roommate, just got off a pretty gruesome year as an investment banker. We were both at these inflection points in our lives and our careers where it lent itself to placing a big bet and going out on our own, just trying something out.

This idea that we were super excited about at the time was the catalyst to make that happen. In retrospect, it really wasn't the idea itself that allowed us to eventually build, by some measures, a successful company. It was a willingness to learn from what was working and what wasn't, embrace the need to change and evolve and iterate until we found something that hit a sweet spot.

It's funny. There are founders that can see the world 10, 20, 30 years out or have this really potent personal vision that they spend a lifetime imposing on the universe. We did not fit in that category. I don't think that we were coming from a place of expertise, insight, or strong inherent vision.

We had a natural starting point, building a simple app, to scratch our own itch as young people that were constantly sending and receiving money from each other. That's where we started. We burned the bridges, burned the ships, didn't give ourselves any other option besides to find some way to make this thing work. A big part of making it work was to change what it was that we were working on.

Daniel: [4:28] What data points did you get to realize that you needed to change to what you do today?

Rich: [4:32] One of the things we did right is that we never really did a hard pivot or really drop this thing and start working on this thing. It was always this bending our path and like a heat‑seeking missile trying to find the right answer.

We were able to parlay some modicum of success and some learnings that we had into the ability to keep going and get more runway. The most stark way of putting that is we always raised venture capital on a consistent narrative. It was always like, "Hey, this is what we were doing and this is what we're going to continue to do, but we're going to evolve and we'll change it slightly given this new opportunity that we've identified and these learnings that we've had."

We never had to go to a new round of investors and say, "Hey, we raised a bunch of money already. We burned through that stuff, but give us more, and we're going to do something totally new." We were able to show it more as a natural arc.

If you go through various discrete points in our history, there were moments of insights that really drove some real change. I'll give you a couple of examples. The first one is probably the most meaningful.

We started the company to build a more social, mobile way to send and receive money for shared expenses. People were now getting smartphones for the first time. There was this thing called an app store.

Facebook had opened up its developer platform, so you could tap into its social graph to make connections between people. We said, "OK, there's these new technologies. Definitely an opportunity for us to build a peer‑to‑peer payment system."

We spent a year in Boston trying to raise money on that idea. Two first‑time entrepreneurs, talking about group expenses in the worst recession since the Great Depression on the East Coast, so could not have the deck more stacked against us.

The first breakthrough or any meaningful progress we were able to make was getting accepted to Y Combinator, which was the really the first time that we had some external validation we're the right kinds of people working on the right kinds of thing.

That brought us out to the West Coast to start building this thing. I remember the first day to have the Y Combinator partners, and Paul Graham does his schtick. He was saying, "Over the next three months, you're doing two things. You're either building a product or you're selling it, and not necessarily in that order."

“Who out here is a developer?" Like 99.9 percent of people that were part of Y Combinator raised their hand. He's like, "All right, who's not a developer?" I was like the lone hand that went up in the back of the room. He's like, "Great, you're selling the product." I was like, "All right, I guess that's what I've got to do, and not necessarily wait until the product is built."

While my co‑founder, Bill, and our first early employees with us for a long time, Eric Stern, were like day and night, writing code to build the first version of our app, it was my responsibility to go out there and build a network of people that were aware of it, that were excited about it, felt like they had a vested interest in our success.

Had validated that the functionality that we were building was going to work for their use case, so that when we finally did launch this thing, it would be in the hands of a community of people that were willingly embracing it, and not into the ether.

I remember sitting there on day one, working on this thing. Bill and Eric are sitting there, writing code, and cranking this thing out. I was like, "Great. Time to go acquire users. How does one do that?" It's a humbling experience, because it's like, "All right, if this is just a peer‑to‑peer app, we don't have any brand equity. We don't have a ton of money to pay for customer acquisition."

It's not like people were searching, "how to send my friends money for pizza," or, "pay the phone bill.” It wasn't like there was explicit demand we could tap into and target ad words or content, so we didn't really know where to go.

What I ended up doing was saying, "OK, well, what's a persistent use case with an identified pain point?" It's, "OK, there's groups, organizations, and associations that have this ongoing need to accept dues from their members."

It was just a use case that we were able to identify and individuals that we were able to explicitly target, based on being a treasurer or the president of some local organization. Naturally, the place that we looked was we just got out of university.

We know that there's all these campus clubs and groups, and so we started targeting them. Before we even built the product, we ended up "pivoting" from a fairly lightweight, simple, pure peer‑to‑peer payments platform to building a toolset for persistent groups and organizations that were collecting dues from their members.

What drove that was an insight that it was just hard to build a network from scratch when the value that we're offering is fairly thin, and the pain point is super ephemeral. That insight of trying to sell the product before we even built it ended up affecting what we were actually building.

We ended up building the first version being more of a group management, expense management tool for quasi‑formal groups and organizations, particularly those that are based in universities. That ended up having its own problems, and we could talk about why we pivoted away from that.

I think that's an example where it wasn't a hard pivot, where we stopped building the ability to send and receive money, but it was a modification of that initial vision to support what we thought was a more effective go‑to‑market strategy.

Daniel:[9:42] In those early days, did you look at the competition a lot?

Rich: [9:46] There's two mistakes you can make. It's like not looking at the competition at all and being totally ignorant, and then just focusing entirely on the competition, trying to play catch‑up, and run the same race with less resources. We definitely made the former mistake.

It's like, "We have this incredible idea that we're going to make it easy to split the check at dinner." It's like, every week, I'd get another email from an entrepreneur that's building the same thing, because everyone feels that pain point.

Yet everyone feels it, but how many of us have never gone to the app store and tried to actively look for a solution to make that easier? It's a consistent pain point, but it's so thin and so ephemeral that even the cost of downloading an application for to solve it, no one's willing to do.

In the early days, if we would have done a real gut check and looked at the competition, we'd say, "There are people out there that do this, anyways." This is pre‑Venmo. They were contemporaries of ours.

Certainly, PayPal was doing it. There were apps that were built on top of PayPal that added value to the use case of group expenses. Why weren't more companies doing it? Because it wasn't a huge market, and it was tough to acquire customers with that being the hook, that we're going to make it easy to share expenses for group activities.

We were pretty ignorant, I think, of the landscape. One of the things that changed personally over the past, call it, 10 years‑plus is when we started out, our frame of reference and our context was blind and biased enthusiasm about an idea.

That idea was informed by personal perspective and personal pain point. The sophistication with which we were able to think about the industry that we were in, the time horizon in which we were able to think about what we were doing and why was all super limited.

The only thing that's changed is that we've just spent a lot more time in this industry, and we've gained a real knowledge and expertise around how it's evolving, who the players are, where the pockets of opportunities are, the way it's going to fundamentally changed on a 5, 10, 15‑year time horizon, what customers actually need, want, and are willing to pay for. Much different view of the universe than what we had in the early days.

Daniel: [11:58] How did the idea evolve to what it is today and to what ultimately led to the acquisition by JPMorgan?

Rich: [12:04] I hate the word pivot, because it didn't feel like a pivot at the time, but the first evolution of the product based on when we were building it, in the confines of Y Combinator, which is an early stage micro venture fund.

The second one was we built this tool to make it easy for clubs and associations to collect money or dues from their members. What we realized was different types of organizations had a different definition of what it meant or how they wanted to collect money from their members.

Some of them were selling registrations. The functional need there was a form‑builder to build a registration experience and sell a ticket or a confirmation at the end. Others wanted to send invoices. Others wanted to put up a page that members or supporters can just make donations of any amount.

Others wanted to sell membership packages. You get package A, package B, or package C, which looked a lot like an ecommerce site, a simple storefront. We ended up building a whole bunch of what I would call fin‑apps for all those different use cases that you can use them all in any combination, but they were all these discrete use cases or applications.

We had a really simple registration/ticket sale product. We had a really thin invoicing product. We had a really thin store‑building product. All of those were ultimately built on top of our underlying payment infrastructure.

The argument that we were making at the time was, sure, you can use Eventbrite for tickets, or you can use FreshBooks for invoicing or BigCommerce or Shopify for a storefront, but all of those guys, at least at that point, were just pure‑play software companies.

If part of your need was to accept payments, you had to go and get a relationship with PayPal or some other merchant provider and then connect the two. We were saying, "Well, we're better, because we have a fully integrated solution where it's both software and payments that work better together. You don't need to kludge them together. There's cost benefits. There's experiential benefits there."

I think, all else being equal, that was probably right. The problem was all else wasn't equal, because we were spending all of our time building for 15 different apps or 15 different use cases, and the underlying payment infrastructure underneath, when all FreshBooks was thinking about was how to build the best possible accounting and invoices solution.

All Eventbrite or Webconnex was thinking about was how to build the best possible event management and ticket selling solution. All GoFundMe was thinking about was how to build the best possible donation tool with the best viral loop, where they can convert campaign donors into campaign organizers.

Sure, would any one of them want a more integrated payment experience? Yeah, that would be helpful, but would they give that up in order to have the best possible event management platform out there? No‑brainer.

We had a good solution for everybody, but not the best solution for anybody. The insight, and I've got to give credit where credit's due. The founders of GoFundMe, who at that time were two guys in a garage, called me on my cellphone.

We at that point were three or four folks in a garage. They said, "Hey, we noticed that you guys have this donation tool, like we do, but unlike ours, which is built on top of PayPal with a kludgy handshake between the two, you guys have your own native proprietary payment solution as part of your donation product. How did you do it?"

Being reasonable people and friendly parts of the entrepreneurial community, we said, "Here's the playbook. We worked with this bank and built this. This is the risk, regulatory, and operational things you should be worried about."

They said, "Great. Sounds awesome. Why don't you guys just rip off your [inaudible] and donation product, which is far inferior to the one that GoFundMe was able to build, and just expose those APIs to your payment infrastructure? You guys seem to have done a really good job there, and we've done a really good on the donations side.

"We'll fuel customer acquisition. We'll optimize the use case to the nth degree for donations specifically, and you guys will get the benefit of all that volume if you can just maintain an infrastructure that shields them from the risk, regulatory, operational, technological aspects of 'being in the payments business.'"

They came to us and asked for it. We had an intern at the time as a side project build an API, and that was the API that GoFundMe picked up, and ended up driving their business. For them, they were some of the best product people.

Both engineers, but definitely product people at their core, that I had ever met. They were just absolutely scientific about their viral coefficient. For them, the difference between a viral coefficient of 1.1 and .9 is the difference between a company that transformed giving on the Internet and a company we never heard of.

They were obsessed with how do they complete that viral loop? Their two biggest points of drop‑off were an organizer setting up a campaign and enabling payments, because at that point, it required them to go offsite to PayPal, set up a merchant account, come back, and plug in their credentials, and on the donation piece, donors dropping off during checkout.

They were like, "How do we fix the payments problems, but we don't want to build a payments company?" That was the birth of payments infrastructure as a service. We would allow them to control the front end, and we would manage the back office complexities of facilitating payments as part of the core component of their product offering.

At that point, we still had not went all‑in on that strategy. We were like, "OK, there's this GoFundMe thing. Those guys seem to be taking off, but how big is that market, really?" I think the final epiphany was 10, 15, 20 years ago, if you were a small business that wanted to accept credit card payments, you would go into a retail bank, and you'd open up a merchant account, which would feel very similar to opening up a bank account.

Then PayPal basically took that experience, and they put it on the Internet. That if you wanted a merchant account, you'd go to PayPal, you'd fill out their application, and then you'd get set up there.

The epiphany was, just like nonprofit organizers were no longer getting merchant accounts, they were just signing up for GoFundMe or Classy, or all these other online tools built specifically for that use case.

Small businesses were getting accounting and invoicing software, or they were getting restaurant management software, point‑of‑sale systems, or online retailers were selling on marketplaces or building online stores through a BigCommerce or a Shopify.

Payments was no longer a separate product that was being sold by a payments company. It was a feature of these broader software solutions that not just campaign organizers on GoFundMe were using, but small businesses were using as well.

We said, "Could we do what we've done with GoFundMe for restaurant point‑of‑sale systems, or accounting and invoicing systems, or shopping cart software?" Once we started prove that out, we decided that was where the market was going, and that we had an opportunity to be really disruptive there, be early movers.

Stripe was getting a lot of momentum in that space, so I think if we would have just realized it earlier, we would have been in a different position competitively. I remember the day that we went to our board and said, "Hey, we're going to retire our," what we called, "direct business," which was us going out and building our own acquisition channels with our own proprietary applications in favor of this integrated channel business, which at that point, was a minority of our revenue. We had more business in our direct business.

We had a brand name, WePay, that was built for this direct business. We had an organization in how we did support and sales that was built for this direct business, but we said, "We're going to bet the farm. We're confident that in this business that we started to build years ago," our direct business, "We can continue to grind out value, and we can grow this thing, but we're never going to create an inflection point where this thing just shoots to the moon, and we're never going to be able to disrupt or transform the industry in a way that we think we have an opportunity to now."

That was probably the biggest moment, where we said, "We have this thing which is still incipient, but we're looking around the corner a little bit, and we think that's the thing that we want to do," and we made the decision.

We retired the business that we had spent the previous five or six years building, and we went all‑in on our integrated channel business driven by our API.

Daniel: [20:30] What were some of the lessons learned in the technical architecture that you built, and essentially the API availability in enabling an open ecosystem?

Rich: [20:39] My co‑founder, Bill, our CEO, was a technologist by training, and I think by DNA. I was not. I was more of like a tinkerer and problem‑solver, but neither one of us had worked in a large‑scale professional software development shop before.

There were ton of mistakes that we made early on. Things as simple as like it took us a long time to develop a tools team, a team of people whose sole responsibility it is to make our other developers more productive and more consistent.

I don't think we got as much leverage out of the early...I don't think we were able to ship products as quickly during the early days as we could have. Our code base itself early on was super monolithic, and it's probably made sense to be, because we honestly didn't know what we were building.

We just kept building [inaudible] until we found something that worked. Then you end up with a monolithic code base with a massive amount of technical debt. Then you have to do your re-platforming once you have the conviction and confidence that you're on the right path, and that it's worth making the investment to make something a little bit more scalable and extensible.

Even the programming languages we used and the frameworks we used, there weren't thoughtful decisions that went into that in the early days. It was like, "This is what we're most familiar with, and this is what our friends use."

You can guess, based on 2008, what an unsophisticated developer would, what technology stack they would build on. Massive amounts of technical learnings. Honestly, we never solved those problems ourselves as founders.

What we eventually did is we brought in an engineering and leadership team that was far more experienced and competent than we were. They, from the ground up, rebuilt the organization in terms of the talent, totally changed our software development life cycle, processes and procedures, changed the technology stack that we were, tore down the monolith and rebuilt it in micro services. That journey's never going to be over, because if we ever have a perfect code base, it means by definition that we're not pushing hard enough in terms of shipping product.

I think the pendulum has definitely swung in the direction of being a little bit more of a mature technology organization than we were for the first five or six years of our lives. I think there's probably competitors out there ‑‑ some well‑known, some fairly nascent ‑‑ that have different DNA from the beginning and have benefit from that.

They'll have a cleaner code base with a more rational development org structure on day one, and that will allow them to iterate and ship product faster than I think we were in the early days. We were humble, and I think we recognized that, and we made the changes that we needed to when we had to.

Daniel: [23:05] Obviously, there's been a dramatic disruption in the payments infrastructure with digital transformation, a lot because of what you've done and your partners. Where we are in that journey, and where do you think this goes 10 years out?

Rich: [23:20] It's crazy. 10 years ago, if you said you were starting a payments company, people would have been like, "Huh, cool." Now, it's like fintech and payments are one of the hottest arenas out there. I think that's largely because that's, two things.

One is people are recognizing that payments is the onramp or the tip of the spear for broader financial services transformation. I think the second is that, just generally, the incumbents within retail financial services, the world is changing very dramatically.

What made a bank successful for the past 200 years is probably still largely relevant, but it's no longer sufficient in order to compete in an increasingly digital age. Chase and other retail banks have known for years that the value and the purpose of having a large branch network is going to evolve.

Now, I don't think anyone would be presumptuous enough to say that branches are irrelevant, or have even gotten less relevant in the past year. Let's take away the past year. We'll talk about that in a second. Chase was building, I think, 500 or so new branches last year.

That's not because these are not smart people that don't see where the market's going. It's because branches are profitable. It drives customer acquisition and customer engagement, and it's a huge competitive advantage.

At the same time, no one could argue in good faith that a branch is going to be as necessary or relevant 10, 15, 20 years from now as it was in the past, by definition, because there is access to the same functionality online, which didn't exist in the past.

I think COVID has accelerated that transformation. People literally were shutting down branches, and people weren't going into them. They had to do the same self‑service thing and new product adoption online through the Internet in the comfort of their own homes.

There is this massive transformation coming. I think challenge is, as a large, incumbent bank ‑‑ top five national banks ‑‑ it's classic innovator's dilemma. They have wonderful businesses. They have regulatory advantages once they've crossed that chasm.

They have massive network advantages. They have wildly profitable businesses. There's massive brand equity. There's faith in these institutions. There's not the acute desire and need to change overnight these things. They're working.

There's also, they're not technology companies by definition. The "build fast and [inaudible] break things mantra," or, "Iterate, test, experiment, trial and error, technology‑forward software development," it's just not in the DNA of these institutions for reasonable and good reasons.

Change is very unlikely to come from one of the major incumbents in a massive way, for all of these intrinsic reasons. At the same time, it's very, very hard, if not impossible, to transform financial services broadly as an outsider, start a fintech for the [inaudible] reasons.

I think there's Square, Stripe. These companies are doing amazing jobs. I think they're shipping wonderful products. Their growth speaks for itself, but there's a long way to go before they're competing directly in a big way and on a broad scale across the entire suite of financial products with a Wells Fargo, a Chase, a Bank of America, or a Citi.

It's hard to do it as an outside. It's this weird catch‑22, where you can't do it as a bank. It's hard to do it as not a bank. What's the answer? I think that's one of the key pieces of the acquisition is that we're a hybrid.

JPMorgan has acquired WePay as an organization. We're now by definition a wholly‑owned subsidiary of the bank, so we're part of the bank, and yet, from at least a product and development perspective, we operate semi‑autonomously.

We've been able to use the same developer toolkit that we use, the same collaboration tools that we've used historically. Our leveling and hiring practices speak to the needs of a competitive landscape in Silicon Valley for top‑tier software developers.

That's the hypothesis of the acquisition, is that we can take what the bank has, which is scale, brand equity, a mature suite of financial products, from capital to payments to depository products, and the largest, if not one of the largest, two‑sided networks of payers and payees in the world.

We can couple with that a technology‑forward, innovator's approach to shipping products, and trying very intentionally to cannibalize and disrupt our existing business within the firm. Early signs, two and a half years into it, is that that's a model that we think is going to work.

Daniel: [28:13] Plugging you into JPMorgan Chase, what got turbocharged? What didn't?

Rich: [28:20] By definition, the scale of the portfolio that we serve is probably the biggest and most exciting for us. Pre‑acquisition, WePay said, "We're now an infrastructure company to software platforms that have their own acquisition channels, their own value proposition, their own portfolios, and users, and merchants."

We're going to go to those companies ‑‑ let's use FreshBooks as an example ‑‑ and say, "Hey, we're going to give you payment infrastructure. That's going to power FreshBooks's payments, and then you go out and you incorporate that into your accounting and invoicing tool.

Go acquire customers, and we will get the benefit of that distribution that you have and that volume that you have. In that sense, they were always a channel partner to us. We never wanted to be in a situation where WePay was one of the three or four or five options that an end user could choose from when enabling payments on one of these platforms.

If you're choosing between WePay and PayPal, or WePay and Bank of America merchant services, and WePay and Chase merchant services, for that matter, no one's ever going to choose WePay, because by definition, they don't have a preexisting relationship with us.

The only way they can get that relationship is through this partner, and they're not going to recognize the brand, and certainly not with as much trust and confidence as they would for one of these established players.

We were intentionally pulling ourselves further behind the scenes and embedding ourselves in the fabric of one of these ISV platforms or software platforms that had their own distribution channels.

Fast‑forward to acquisition by Chase, and we're like, "We don't have a distribution problem." Half the households in America have an issuing relationship with Chase. I think it's like 10 percent of small business bank with Chase. I don't know the exact number. It's like 4.5 million, 5 million businesses.

We have customers. The question is how do you then use that base to drive demand to accept payments through us and these partners that have these value‑add capabilities for particular merchant verticals? Where we're now distribution and acquisition channel for them, as opposed to them being an acquisition channel for us.

Now, we fly under the Chase brand. It's no longer, if you're a small business accepting payments through WePay's technology, you would never see WePay. You would see it as Chase. Our goal is to, if you're a Chase banking client, we'd never want you to even think or have the temptation to look elsewhere to accept credit card payments.

We want the ability to accept credit card payments to feel native to your existing Chase relationship. There's no how quickly could we onboard you or get you started, or am I going to get a competitive price point, or how good is the reporting?

It's, "Look, you've already made the decision to bank with Chase. You now have the ability to accept payments through Chase," while at the same time, recognizing that we're never going to build a restaurant point‑of‑sale system.

We're never going to build an ecommerce platform. We're never going to build an invoicing solution as robust FreshBooks's. Taking the customers that we already have and that we've encouraged to accept payments through us, and then pairing them with the right software solution on the back end is a huge game‑changer for us.

It's no longer just selling infrastructure to third‑party software companies and using them to get distribution. It's being the infrastructure within Chase that enables payments for an existing portfolio of merchants and the connective tissue that's able to then pass that onto these same software companies that are able to add more value on top of payments.

Daniel: [31:47] What are some of the cultural challenges that emerged being a part of Chase?

Rich: [31:51] We and Chase were very intentional during the acquisition process that this was a marriage that was meant to be, culturally. I think it starts at the top. There's a reason why people know who Jamie Dimon more than they know who the other CEOs of major banks are.

I think it's a firm that's been managed with integrity and sincerity, and the right kind of conservatism in terms of not willing to over‑extend or take unjustified risks. It's one that invests billions and billions of dollars in technology with massive engineering teams that wants to own its own proprietary stack.

That was the home that we were coming into that. I'd say, from that perspective, there's a shared vision of the way the world's evolving. There's a shared belief that technology is going to be the driving force there. There is a desire to recognize the need to play both offense and defense when we talk about this transformation agenda.

There's a belief that WePay has something special in our ability to innovate and ship product very quickly, and the need to protect that core of our culture. That's worked out really well. I think what's been a challenge is that all of the real opportunities ‑‑ these one plus one equals three opportunities ‑‑ require a merging of assets that WePay brings to the table with assets that the broader firm brings to the table, which requires technical integration and collaboration across various lines of businesses and teams.

The reality is, by definition, a 400,000‑person organization with a lot to lose works at a different pace and with more bureaucracy and more complexity than we do. We've had to find some way to interface with that broader organization in a way that allows us to realize these synergistic opportunities without fundamentally interfering with how WePay builds and ships products.

That is a daily challenge that WePay's leadership team spends more and more of our time making sure that we're managing effectively, at times playing that interface ourselves to shield our downstream teams from some of the impact of that.

That's the job, and that's what we signed up for. I think, if we can manage to do that, this'll be one of the few success stories that are written about a major financial institution buying a small technology and making it a successful acquisition.

I think that challenge that I just described is the single existential challenge that we're going to face. I'm confident that the leadership across the board at JPMorgan understands that that's the existential question and has done everything in their power to make sure that we're going to end up on the right side of it.

There was an early joke. I guess I'll give you two anecdotes. One is WePay became known as the butterfly early on, because there was some leader somewhere up the food chain that said, "Don't squash the butterfly. Just don't squash the butterfly."

They handled us with white gloves and really extended, I think, in very robust ways around the tools that we were allowed to use, where our infrastructure was hosted and things like that, that I think, if we had to fundamentally change would just crush our butterfly.

One quick anecdote that I think was super funny is we were in the called seventh inning of the acquisition. At this point, we had both leaned super far forward. We knew that we both wanted it. We were working on the agreement. We were still negotiating the final price.

I remember we were in, I think, our attorneys' offices in San Francisco, because it was a neutral middle ground, and no one wanted the home field advantage. It was like principal to principal. It was Bill Clerico, my co‑founder and CEO, talking directly to the then‑CEO of Chase merchant services.

We took a break. I ended up going into the bathroom. I was ‑‑ not to get too crass, but ‑‑ in a stall. Two of the Chase folks that worked for the CEO of Chase merchant services walked into the bathroom, didn't realize I was there. I could hear one of them say to the other, "Great company. It's just a shame that we're going to destroy it." [laughs]

The reason why it's a happy ending is that they were saying that out of genuine concern that if we weren't very careful in how we made the integration work that we were not going to realize the value of the acquisition. That there was something special about WePay that had to be protected in this broader environment.

Those two people ended up coming over to WePay, not by being pushed by JPMorgan as parachuting their people in, by being pulled by co‑founder and I, being like, "These guys get it. They understand the stakes, and they understand what's going to make it work out right and what's going to make it work out wrong.

One of them is now WePay's COO, and the other one is WePay's CFO. There are pockets. It's such a massive firm. They've got billions of dollars in technology budget and tens of thousands of technologists working every day.

It's not some monolithic entity where there's universal truths. There are some pockets that I think have innovated really well and some that have struggled. I could say the things that we're bumping up against challenge‑wise, but I don't want to speak out of turn.

There's a business case approach to getting funding and building products. It's like, if you read "Innovator's Dilemma," it's like exactly the two problems that you have to deal with. The first is value happens on an S‑curve. You hammer away at a problem.

WePay/Chase has this really big, exciting product announcement that's coming. I think it's going to be transformative in the industry. There'll be headlines around it, and I can guarantee the initial adoption, this isn't old‑school financial services, where you launch a new credit card, and it's attached to your brand name, a massive marketing campaign, better rewards, and you're now the market leader. Chase did that. They did that really well.

Software, it's like the launch of the thing is not the end. It's literally the starting point to start iterating on this product. I can almost guarantee when we launch this new thing, it is not going to achieve the kind of growth and revenue expectations that everyone's hoping for.

For me, that's not a sign that therefore this whole agenda is screwed. It's, yeah, now, let's go look at the funnel, and let's hammer away at all these points in the funnel until we make it work. That's like building product and shipping software.

The first is, when you're early in that S‑curve in a large organization, you don't have that same patience to get to that point of inflection where you start driving the real value, but that's what you need to do in software.

That's the first. The second part of the Innovator's Dilemma is that a billion‑dollar market is not particularly exciting for JPMorgan Chase. It's like, anything you want to do, and anything you want to get real resources to pursue, you need to be able to build a business case that is a massive, massive market opportunity.

What we've seen with all the successful software [inaudible] technology companies that I look at is they never start with a... Maybe they do in their fundraising deck, but the initial solution is always niche. It's narrow‑ended. It's not broad and shallow.

I remember in the early days, it was like, "Oh, Square's only going after micro merchants. The minute that they get big enough and care about pricing, they're going to use a real [inaudible] ." It's like, no, Square will eventually...

They're going to start there, and then they will build more product to make sure that they can support a merchant throughout its entire life cycle. Maybe they're not there yet, but they know that they need to get there.

Or they'll say, "Oh, Stripe's margins are super thin, because all it does is payment processing. What do big companies really care about? Easy integration, and it's only a one‑time expense. What they really care about is full‑featured robustness."

It's like, it's that mentality that, "Oh, those guys are nothing," or, "That market is nothing," or, "We don't need to worry about," that's scary. The reality is, that's where you should start. You want to go super narrow and super deep, and then you could always build broader value thereafter.

I think in a big firm, in the most valuable bank in the world ‑‑ certainly in the US ‑‑ it's hard to find a starting point, because the starting point by definition is never going to be big enough.

Daniel: [40:34] What advice do you have for executives, managers, or leaders within other big organizations on how to best drive innovation and work with people in the tech sector?

Rich: [40:44] I guess I am as good of an authority as any on that question, given the fact that we're three years into an acquisition by a big bank, but I don't consider myself an authority, because we haven't proven that it's going to work yet.

I'm optimistic. I think we're doing the right things. I spoke about some of them earlier. You've got to both be integrated in ways that make sense and allow you to realize those one plus one equals three opportunities, but you still need to build a moat around a culture of innovation, and particularly the way we build product and the way we ship software.

Our release cadence is different. Our testing cadence is different. Our development tools are different. Where we host and how we host is different. The third‑party services that we use for testing, for monitoring, and auditing, it's fundamentally different than what the firm's doing.

I think the firm's coming in our direction, which is good, but that's got to be protected. I think, if I'm speaking specifically around advice for an acquisition, that's probably what it would be. It would be go slowly and cautiously. Be absolutely clinical and surgical about where you choose to integrate and where you don't, and decide what it is that you're acquiring.

If you're acquiring a piece of technology, which in and of itself is valuable, and you need to drop that into the mothership, that's a very, very different narrative than buying a technology and a team that has to and needs to iterate, innovate, and ship products very quickly. In which case, you've got to protect it a little bit more.

I think there's a lot of examples, like where to begin? Capital One made a massive bet on innovation. They had this innovation team and this innovation group.

I even think they had an office in downtown Palo Alto. They hired really smart people. I thought they went about it the right way, and it just withered on the vine. You look at BBVA, AcquireSimple, they have their open API, down marketplace agenda, which seemed like they hired the right people, acquired the right company, had the right strategy.

Maybe it's COVID‑related, but now, they're winding it down a little bit and not investing in it as much as they were before. I honestly don't know. There's not a lot of examples of success stories. I brought up two, Capital One, which I thought was doing it right, and seemed to have not really gotten off the ground.

BBVA seemed like they were doing it right, not really getting off the ground. I don't know. It's a tough road to hoe, for sure. There's no other option. You've got to do it. I can't tell you how many conversations I have a week with leadership within JPMorgan Chase authentically interested in what we think is working and not working as a way to evolve the playbook for how to make an acquisition successful.

I think it's that self‑reflection, self‑criticism, desire to change, and to learn, mixed with the appetite to acquire innovative companies that is going to be JPMorgan's recipe for success. Whether that's applicable to other major banks, I don't know, but I think that seems to be JPMorgan's strategy, and it seems to be working so far.

Daniel: [43:33] In one word, what advice would you have for an entrepreneur?

Rich: [43:38] One word? Oh, god. I don't know if you or your audience is familiar with Paul Graham, but Y Combinator was him and Jessica and their team's brainchild. He's also an essayist, a great essayist, and he spent a lot of time thinking about that.

What one word best describes a successful entrepreneur? The best he could do was two words.

Daniel: [43:56] I'll give you two.

Rich: [43:58] I don't think I can improve on it, so I'm just going to steal it, "relentlessly resourceful."

Daniel: [44:02] Love it.

Rich: [44:03] That's what separates the successful entrepreneurs from the not is, "Are you just relentlessly resourceful?"

Daniel: [44:12] Amazing. Rich, thanks so much for joining us.

Rich: [44:15] Great to be here. Dan, it was a pleasure to catch up.

Daniel: [44:17] Amazing. Take care. On the next episode of Decoding Digital.

Laela Sturdy: [44:23] In cultures of innovation, you can't be overly prescriptive on saying, "This is exactly how it's going to be," and very top‑down driven. You have to allow small teams of brilliant people to come together, and you try and move as much of the bureaucracy and things out of the way as possible and let them operate.

Daniel: [44:44] General Partner at Google's Capital G, Laela Sturdy. Listen on Apple Podcasts, Spotify, or your podcast player of choice. To learn more, visit decodingdigital.com. Until next time.

Read less