Product lessons from Cash App & Carbon Health — Ayo Omojola on going “unreasonably deep”

EP.02 - Ayo Omojola

Ayo Omojola: [00:00:00] Probably the one thing that I'll say that I've taken away like philosophically is to always look for those opportunities where it's easy to stop, where basically it gets tedious. And what that typically is a signal of is that somebody or a bunch of people just haven't gone deeper before. It's always a balance too.

Like you go deep on any number of things. And I think the real art is choosing where to go deep on that's worth spending time, because you know, you have a limited amount of time and you have to be thoughtful about where you spend it. 

Brett Berson: [00:00:32] Welcome to in depth, a new show that surfaces tactical advice, bounders and startup leaders need to grow their teams, their companies, and themselves.

I'm Brett Berson, a partner at first round. And we're a venture capital firm that helps startups like notion, roadblocks, Uber, and square tackle company building firsts through over 400 interviews on the review. We've shared standout company, building advice. The kind that comes from those willing to skip the talking points and go deeper into not just what to do, but how to do it with our new podcast.

In-depth you can listen into these deeper conversations every single week, learn more and subscribe [email protected].

For our second episode of in depth, we're excited to be chatting with IO. Majola, he's a product Wiz and incredibly sharp thinker, but what's most impressive is his depth and breadth. I recently joined carbon health as their VP of product where they're tackling healthcare, accessibility challenges like COVID-19 testing.

Before that he was the founding product manager on the banking team for cash app at square, where he co-created the popular cash app and help build out squares, technical banking infrastructure. He's also a former founder and active angel investor. As IO puts it. He's constantly thinking of new stuff to build from starting several companies to trying to open a restaurant to the running log of ideas.

He's kept for 15 years, it's this mindset, plus all of his impressive experiences that gives him a unique lens into finding and evaluating ideas. The topic we'll spend the most time on today, IO particularly excels at going unreasonably deep as he calls it on any given space. If he can talk your ear off about the Durbin amendment or the physical factory process of producing a credit card, thanks to his familiarity with the heavily regulated spaces of financial services and healthcare.

On today's episode, we chat about the early days of cash app and dive into how he untangles regulations and other market hurdles to find the opportunities where it's easy to stop. I will also tells us why he thinks a lot about problem selection. And makes the case for putting more effort into choosing what to work on.

It's a must listen to, for anyone who's thinking about starting a company someday, or for a product leader who hopes to help a new product take shape. But even if those aren't goals of yours, there's still tons to learn. iOS shares the leaders he learned the most from during his time at square and the frameworks he picked up from them such as how to get better at process setting context and optimizing for the outstanding last but not least.

We get into his management and hiring philosophy, including why he loves to hire former founders. I hope you enjoy this episode. And now my conversation with IO. So thanks so much for joining us 

Ayo Omojola: [00:03:35] IO. Thank you for having me happy to be here. I 

Brett Berson: [00:03:38] thought an interesting place to start would be the founding story of cash app.

And I think throughout our conversation, we'll try to sort of have equal parts business strategy and maybe product building perspectives and ideas. And one of the things that I've been fascinated with cash app is that it's one of the few examples of technology companies kind of in their first 10 years, launching an adjacent product that then goes on to have extraordinary success.

What you generally see is whatever. The one thing that gets a company going generally continues to be that one thing for a very, very, very long time. And many companies only ever do one thing and cash app is just an amazing example of a second tour. I'd probably third or fourth product. I think square is probably a good example of a company that has probably launched multiple products better than most.

And so I'm curious to start by spending some time talking about the origins of cash app and maybe why you think it worked, or what were the conditions or the environment that allowed it to work when it's so rare across technology companies. 

Ayo Omojola: [00:04:42] So I'll start by saying I joined square when cash app was about a year and a bit old.

So I think the first line of code written for cash app was probably written around February, 2013. And I joined square in May, 2014. So there's certainly context that I'm not going to have. So I'll just start by saying that the original core idea behind cash app was about building. A, I mean, there were honestly quite a few things.

One of them was about building a debit focused payment network for peer peer-to-peer money movement. And then obviously once you achieved scale and had a network effect, there are many, many ways that you could leverage that. Thinking back, I'll go through a handful of the core ideas that today probably feel not sure what, the way we described it today are probably more commonplace that were not necessarily a given back in 2014.

So I think cash apps, first iteration, and what we were trying to move beyond when I arrived was I could send an email to Brett [email protected]. I could CC. [email protected] or something. There was an alias that you would be able to append, and it would have an offline flow for handling.

I would say send $50 to Brett [email protected] CC [email protected] or whatever the alias was. And it would check if the sender had an payment instrument linked, if not, it would request that a payment instrument got linked through like an offline email process. And once the sender linked their payment instrument, it would initiate the payment and move money to the other person.

And I always find like an interesting way to look at this stuff is a lot of launches over the last 10 years. Where I think prior to product hunt were launched on hacker news. So you can see, there's kind of like a history that you can see with all the early comments and like how people thought about it at the time.

And at the time the novelty was just this ease of avocado number linked to this thing. And we're trying to make sending money from one person another really, really easy and frictionless while still feeling pretty secure. And when I joined, we were starting to move from email based payments to the mobile app concept.

So the email-based payments does one core idea shifting from using ACH as initiation mechanism to debit was also another core idea. And you can just think of it as the behavior of most consumers. Like most individuals, humans generally have their wallet within their reach, but to get a random person to remember their account or routing number, it's still today hilariously to me quite complex.

The concept was just, if you shift the ease of the instrument to the thing, that's generally within reach, you're just taking out a bunch of stress and anxiety generally associated with payments. A third big idea was around the philosophy of most financial products in the incumbent world, like bank of America and E-Trade and things like this, the way those products generally tend to work.

You're applying for a payment instrument and then they approve you or deny you. And one of the core concepts with cash app was access first. So the default is that you get in and then we work really, really hard to make sure that people once in behave well. And so that's sort of removing friction from onboarding.

And then we had these concepts of what we call like a graduated onboarding, where you try to let a consumer do as little as possible to complete pleat the action that they want to complete. And then only ask them for more information as they need to do more things. And so I would say actually there's like really like a big part of focus on remote moving friction.

And then this is by no means a canonical list. Just the last big bucket that I would describe is we really did try to make our team go unreasonably deep on anything. So there were. Like all the product team for sort of their domain were insanely familiar with the regulatory regime of the product they were in.

So I would have discussions with our legal team about the Durbin amendment and the prepaid rule and things like this. And I think that kind of depth, it's not a thing that necessarily exists if you don't work in a regulated industry or certainly not at the same level of sort of hand-to-hand combat.

And having that level of understanding really did shape the product. And it wasn't just me like Brian, who was the founder of cash and still runs cash extremely familiar with the regulatory landscape and many others on the team. That's true for them as well. 

Brett Berson: [00:09:29] That's obviously sort of like a set of ingredients that kind of came together to make this thing work.

Were there environmental factors at square that you think made this work? I could see them. A lot of other companies. It's a bit of Jason to the core. It's going to take many, many years to get to any scale. There's Venmo, PayPal, there's other similar types of things. And yet this was able to get invested in, and then obviously over a long period of time has grown to just astonishing scale.

And so do you think there's anything organizationally, culturally environmentally that made it? 

Ayo Omojola: [00:10:02] So the real answer is, I don't know, the slightly more nuanced answer is before I joined square, did have a pretty good culture of experimentation. And even after there's lots of hack weeks and things like this, having not worked at other big Silicon valley companies, I have no idea how common or unusual that is.

So it's hard for me to tell like, Hey, it was different here. I think beyond square, there actually were real material macro factors that I should have mentioned in sort of the first preamble, but also were big factors. So I think things like the Durbin amendment and the Durbin amendment rot, I would say a bunch of changes that were like actually transformational for companies like square and Stripe.

So that's one bucket I would say. The rise of the app store and the sort of ability to do more and more stuff in a mobile context made both products like cash app possible. And it also created this distribution channel that was really orthogonal to traditional distribution channels and financial services.

I'd say that's another bucket. And then on square specifically, I think the couple of things that translated to cash that I can speak confidently to that I think were relatively unique is when square. And I think this is true for Stripe as well, but when square launched back in 2009, 2010, the company just had like reams and reams of people who were insanely focused on payments and card networks.

And that's a relatively sort of arcane domain, and there's a really large number of variables, the deeper you go. And so what that meant was the team coming out of square, working on cash app. Ended up being quite knowledgeable about things that were possible, that weren't really in the public domain, public domain is not the right way to describe it.

It's just for years, the core advantage cash app had was for a long time in the United States. If you want it to move money from bank a to bank B instantly cash app was literally the only way that you could do it. You could use wires for instance, and pay $25 and you could use ACH, which is free and you could move money slowly.

But if you weren't sort of in the bracket that one had to pay 25 bucks. To B of a, to wire money to chase. There were years for which cash app literally was your only option and that sort of technical stack the knowledge that it even existed in that it was possible honestly, was what took quite a bit of imagination and just came from in large part that team of people having spent years at square, banging their heads against the wall, working with card networks on things and realizing, Hey, there's this unexploited mechanism for instant money movement over the card rails.

And it happens to be the case that nobody's using it this way, because it's a slog to like pull it all together. So I'd say like that's a big part. And then square, I think for years has a really high technical bar and cash app early on was really staffed with very senior technical people for a really long time.

And I think it's now it's a bigger team. And so the seniority distribution is going to look more normalized. But I think early in its development, a lot of really senior people at square were working on that product for years. 

Brett Berson: [00:13:07] And so does that sort of get at the idea that was as much as sort of a technical innovation as it was a product innovation.

And so recognizing that there was a large technical hurdle, a certain team had to be put together to sort of create this magical experience. 

Ayo Omojola: [00:13:21] If I'm being honest, I don't think it's possible to name any one thing. I think it's under appreciated mark for this, but cash up does like a lot of things insanely well, relative to what's possible.

And so on the design culture, very strong, the engineering culture, very strong, really, really sharp at money movement, pretty thoughtful at risk, really, really thoughtful at marketing growth. And then just to focus on being original on the product front rather than following. There's lots of places that will have like one or two of those things.

There's just not that many teams that have, I would say that level of depth in so many areas. It's not without its weaknesses, but I think when I look at competitive products in market today and sort of given what I know and what I know is possible, and I see the things that they're not doing, it's clear that that team is executing well on us.

Several dimensions. 

Brett Berson: [00:14:12] You touched on some of this already, but what lessons did you take from working on different parts of cash app that you think applied to either what you're currently working on, or you'll just take with you 

Ayo Omojola: [00:14:24] not being afraid to engage with the rags is a big one. Matters more in regulatory industries than not.

It's a useful way to learn what you don't know. And it's a useful way to get an understanding of like, if you think about like how sort of the law plays out, typically what happens is there are some event and laws change and then over a period of time, the agency's chartered with enforcing those legal changes, generates regulatory guidance and.

Candidly, it's relatively impenetrable. Like I'm doing some of this now reading some regulatory material at carbon health. I'm much less versed in it than I was in the financial services space. And I'm like, sort of realizing that, but I think it's just important to not be afraid to go to whatever depth necessary to get an answer that you really understand.

So that's one, and I think it's also incredibly tedious. So a lot of people for whom it's boring, they don't spend time doing it, things like that. And there's a lot of people for whom. And actually, I wouldn't even say there's a lot of people from whom. Even for me, for everyone, it is just easier to take the thing that you are told.

And in a lot of cases, the thing that you were told is correct, but there are enough cases where the thing that you were told is just a series of interpretations. Like the person telling you just got it from the person who told them. And it's been like a long time since anyone's gone close to the metal.

So that's why just not being afraid to engage with like the core subject matter, I think is really important. I think just being mindful of the macro environment that you're operating in. I think it's a, the analog I like to use is no matter how good you are, like, no matter how good you are or how hard you work or whatever your persuasion is, you are never going to be as powerful as forces of nature.

And so if like these larger forces in the economy and the environment play out, and the thing that you're doing is at odds with those, you're probably going to get steamrolled. And so just being mindful of what's happening in the world at large, and how does it affect the thing that I do would be another one.

And then I think there's also this, I understood we were doing a cash app, but we didn't, it wasn't really articulated this way, but I think it's a really nice way to articulate it. Is just focusing on what utility you can provide that is like, how can you make something sufficiently more useful than the state of the art that it like cuts through the clutter and the people who you're trying to make stuff for actually pay attention and are even willing to try you.

And then once they try you, they're thinking, oh, wow, this actually is solved my problem in a way that I didn't realize that I needed necessarily. And that Delta is reason enough to skip. So you can think of it. Like if you create a financial product, that's like 15% cheaper, is that gonna attract some people?

Sure. Probably. But if you create a financial product, this 90% cheaper, it's just inherently going to attract a ton more people because price elasticity will increase the larger, the differential in price. And that dynamic is true, even in areas of utility that you can't directly measure in dollars. Speed is another sort of advantage that you can play with cost is an advantage that you can play with simplicities and advantage you can play with, obviously the further away you move from like really quantifiable, measurable things.

The more judgment you have to exercise, but the crass way to say it is it is actually relatively important to be kind of original, but that's probably just me talking my own book. 

Brett Berson: [00:17:55] In that case. I think some of the conversations we've had in the past, there's kind of this bucket of things of make something 10 times cheaper, which is obviously compelling.

But I think that you've noticed that sometimes just having something that's beautiful or cool or feels good actually makes a difference. And I think you've seen some of that in cash app. And you've seen some of that in challenger banks or other products that just feel or look cool or good. Do you think about that in terms of like the dimension of like quantitative it's 90% cheaper, super easy to grok and easy to understand why somebody would want it versus, oh, this is a cool card with my name on it.

So 

Ayo Omojola: [00:18:32] I don't think that characterization is exactly right. So I think, yes, I have a huge incentive to say this, but I do think the cash card is a really cool looking card, but I think that glosses over when we were first working on the cash card, The state of the art and market was a not really impressive in any real way.

And B was being executed far below the level of technical capability. So like, I'll say it this way with no offense to B of a, they're a massive company that is obviously very successful. The BBA cards, like the literal physical object hasn't really been played with in a really long time. Some technical features have changed like the emergence of tap payments, additional security features and so on, but roughly speaking the state of the art and the card industry, it wasn't really like looking at all the ingredients and figuring out like, how could we combine them?

So just that just left an opportunity. Like the opportunity really was that nobody cared and nobody thought that the aesthetic appeal would matter. So that's like one part. The second part is for the demographic that we were going after for a long time, which is the unbanked and the underbanked. The best in class products for them were not products.

Like they were products that had what I would describe as negative status signaling. So imagine you are anywhere with your friends and you pull out like a random prepaid card that you could buy at CVS. For instance, there is a feeling associated with that, that a person pulling out a chase Sapphire does not feel so.

One of our underlying objectives was to create a physical card product that people were proud to take out of their wallet. That was part of it. There was a part about making sure that the thing we created could take advantage of the tools of the day. So the cash card was one of the first card products that people like.

We're very, very excited to share on Twitter. And then the third part was we had to be like relatively disciplined about costs. So it couldn't like cost materially more than a BV card or anything like that. So that was sort of a big working objective. And then I'd say the last piece was. We want it to put the customer's brand first.

And so we wanted your pride to be much more representative of you than necessarily representative of us. And, you know, we experimented with that over time. But a big part of it was if you give people something that they're proud to take out of their wallet and you give them the ability to like really, really personalize it.

So they're now even taking it out of their wallet, for reasons that are unrelated to payment, like you take it out of your wallet to show, Hey, look at this cool thing that I made. Then what would happen is you would both have people wanting this physical object in a way that's divorced from the financial benefits associated with it.

So it's not like when the cash card launch, we didn't have like points or anything like that, but if we made it possible for people to want this object, for reasons divorced from the financial benefits, then what would happen is. It's an additional lever of customer acquisition. That's not available to, if you're just like straight up competing on like how much of interchange kind of giveaway in travel benefits for instance, which is kind of what the chases and Amex's of the world compete on.

And so it's like to us, like we're relatively privileged. So it looks like, oh, it's just like, it's a cool, fancy object to somebody whose alternative is a prepaid card off the shelf to which the card issuers slapped their brand all over it. The intent really was to change like the way they felt about their card and in 2016.

And I mean, we spent an insane amount of time and effort optimizing that like. I spent probably in combined hours in factories, probably a few weeks along with Robert who's the lead designer on the product. And for the first, probably six months of us working on it, there was just nothing that we felt actually I should give them credit.

There's nothing that Robert felt would like meet the bar. And it took quite a lot. And I think it ended up paying off. Like we launched it. Literally thousands of people share their cash card on Twitter. That's free. Those are impressions that you don't have to pay for. And it drove like viral grows of card acquisition.

Brett Berson: [00:22:57] I want to spend more time talking about going deep, particularly in, you were talking about the regulatory space, but I think that's an incredibly underappreciated idea. And to your point that you kind of go on this voyage of discovery and you find out that the common wisdom. Is actually true. And then sometimes you go on this voyage of discovery and you find that the common wisdom is wrong and some incredible opportunities are created by that.

And so I was hoping maybe you could go a little bit deeper in that area and maybe tell a couple stories. And I'm also curious, do you have a framework now that increases the odds? When you go on this voyage of discovery and you're reading and learning and talking to people that increases the odds that you will land on conventional wisdom, that's proven wrong, or do you just start the voyage each time hoping that it lands there and you never really know.

Ayo Omojola: [00:23:49] So the phrase I like to use, and this really was Brian who coined this was going unreasonably deep on a problem. And I think in, it's kind of weird, I think like if you're working on really hard technical problems, like if you're trying to solve climate change or something like that, you don't have a choice for.

Domains where the technical innovation is new to the world. In order to even be relevant, you have to be technically quite knowledgeable to create anything new. And so you see this, the types of problems that like aerospace folks are solving and natural resources people are solving. And so on. Like those are like hard science problems in domains, like financial services, where a lot of what you're doing is business model innovation.

And it's generally rare that your edge is going to be like a scientific breakthrough, the place where you can go pretty deep is in the regulatory domain. And so you can think of it, like what will happen a lot of the time is you run into a problem and you say, okay, in order to solve this problem, like this problem is, is some legal regulatory thing.

And you go to a lawyer and you say, Hey, I've run into this problem. Help me figure it out. And your counsel will, you'll do some original research. They'll talk some experts and they'll come back to you and they'll say, Hey, you should do this. And I think a thing early on that cash app did, was it started with, Hey, let's really put the customer first and make sure that what we're doing is customer friendly or customer oriented.

However you want to describe that and then really go dig in with like we had, I can think of a handful of discussions we had where there's a few of us with our regulatory team sitting in a room with a section of some regulatory, like guidance blown up on a projector. And we're literally just reading and just thinking through, Hey, a lot of this context was written like years ago before the technology that's available today became available.

And so. I think, I think what happens is an N of one in this, so don't quote me, but I think the thing that happens is the further out that you go from when regs are written. The more ambiguous directs seem because a lot of the time, the things that were available at the time have now like really, really changed.

And so what we spent a lot of time doing was thinking about, okay, this technology that is available today is like really, really different from the technology that was available when this was written. So how do we resolve it? So, like an example I would say is before the year 2000 all bank accounts are basically opened in a branch.

Maybe if you had a bank account at Edward Jones or something, you'd open it over the phone. And what would happen when you'd walk into a branch is you'd walk into a bank branch and you'd sit down and they would ask you much questions. You need to fill out some forms. And then they would ask you for identifying documents.

So they would say, Hey, you need to provide a driver's license along with two pieces of mail from either a telecoms or utility company that match the address on the driver's license. So that's like a way of, you have to go to a real Tory authority, like the DMV. To get the driver's license. And then you had to interact with, you have to have power at your house and like somebody has to pay for that power.

And so there's some reliance on the PGNE doing some level of verification that you at least own the place. And so if PGNE, if you're on a bill, And that bill is mailed to your address. And that address matches what's on the DMV. There's some other computations, like sometimes they last for a passport, things like that, but essentially the bank has done its due diligence to reasonably say that you are who you say you are.

And there's a question that we have to answer early on about like, how do you implement that operating model in a mobile app context? Because part of the verification process you can imagine is there's a person sitting at the branch and they're like looking at you in the face and they're looking at the image on your driver's license.

And they're like, Hey yeah, you Brett look like the Brett on this driver's license and so on and so forth. And in a mobile context, or even on a web context, like there is no one who can do that. And even if they could do that, there's things like defects and things like that, that that could create problems.

And so one of the things that we were trying to solve was literally looking through. I forget the exact name of the rag, but there is a, I think it's the FinCEN examiners manual that goes into real deep specifics about, Hey, you have to verify these pieces of information. Here's how you can verify them.

There's this concept of documentary sources where you enter your name, date of birth SSN, and the financial institution can compare that information with information available on a database. Well, so that opens a question, what databases are eligible to be compared with things like that. And then there's a section on non documentary sources of identity verification, which is it's roughly speaking to driver's license path, but then it begs like a couple of other questions, which are like, okay, Somebody shows up with the driver's license.

There's like a number of ways in which it could be fake. It could be straight up just forgery. It could be a real driver's license of somebody else. It could be expired, et cetera, et cetera. And so there's like all these questions you have to grapple with. We spent a lot of time trying to make sure that we did that thing.

Right. And the easy thing would have just been like, take a picture of a driver's license and then like get on video, chat with someone. But then what happens if somebody doesn't have a phone that's video chat cable, what happens if someone has a crappy connection? There's like so many sort of, of these trade-offs that you have to balance and to really understand what the parameters are.

A lot of the time you have to like really get to a combination of what does the guidance actually say? Does it address the cases that we're looking at? And if it doesn't, what's our process for going from something written on paper that was written some time ago to, Hey, we can implement this and know that we're doing the right thing.

Brett Berson: [00:29:39] So sort of building on that. If I were to go to sign up for IO guide or course to going deep, are there other lessons or tactics that you would teach people to adopt this philosophy? Or maybe how does this show up in either angel investing you do or now at carbon health? How does it show up or where is it done?

Well, or do you often see it, but it's not done well. And then that creates its own set of challenges. 

Ayo Omojola: [00:30:04] Yeah. Yeah. I've been at Carmen for six months and I would say there are areas where we are looking at and thinking about these, but it's just too early to tell, to be honest, I did see this kind of model play out a handful of times at cash app.

And so I'd be lying if I said I have a guide, I think like right now, the way that I think about it is when looking at problems types. So this is obviously not the same type of problem that exists. For instance, if you're building like a social network or a SAS software, but when you're looking at a problem of this type that has a heavy regulatory committee, I think you just have to be willing to continue to question anything that you don't think makes us.

And in order to do that, you have to be willing to read everything on the topic, like from a regulatory perspective. And then the reality is. Sort of the legal community has tools like really good tools for validating and perspective. And so what I try to do when looking at this stuff is get as close to the metal.

As you can build a perspective and then find a person or a group in the legal community, that's on your side to talk through, Hey, I read these things this way. Here's how they might play out. What do you think? And I actually try to do that honestly, as early as possible, because I think that community can give you like shortcuts to, Hey, the question you're asking was really already addressed here, go here and look at this thing.

So I do that where possible, but. I wouldn't say there's like a formula as much as in the context of square, in the context of carbon and elsewhere. I do see sort of almost every time that I've gone deep enough into any regulatory environment, too, to form an opinion, you always realize things that you didn't think were possible.

The question is like, are they useful enough to change the decision you would've made without knowing it? I think for what it's worth, that's not just a regulatory thing. There's a, I think that really is true. And like, as an example, when creating the cash card, we spend a lot of time physically in factories that were doing card manufacturing card personnel  and going in, I made a lot of assumptions about, oh, this is like generally how this thing works.

And they're all the same. And lesson number one is they're not all the same. Like they're quite, these are literally different organizations that are quite different from each other. So that was like sort of one dimension. To the literal level of, if you think about what a card is, and I use a card because it's what I know, but I assume that like very similar things are true across like all manufacturing and all like technical domains.

But for us, we have a bunch of credit cards and debit cards and they like, kind of all look the same and they're all the same shape. And like you can swipe any of them into a terminal and it'll work and so on. But under the hood, there's a whole industry of people like manufacturing the machines to make those cards literally mixing the plastic that gets molded into a card shape at some point.

And I think there was one particular card design that we looked into where, sorry, there's one particular, not even cards. Then there's just literally one particular aspect of the card manufacturing, where we literally tried 200 different combinations of like power settings, thicknesses, et cetera, et cetera, to get to the thing that we eventually shipped.

And the easiest thing to do would have been to send an email to someone and say, Hey, make this look like this. And the hardest thing to do was to like, actually understand what are all the toggles, right? And then in a lot of cases, you look at them and you're like, I'm not an expert on this. I have no idea.

And so then you just literally have to try. And so I think like the same is true. And honestly, probably the one thing that I'll say that I've taken away like philosophically is to always look for those opportunities where it's easy to stop, where basically it gets tedious. And what that typically is a signal of is that somebody or a bunch of people just haven't gone deeper before.

It's always a balance too. Like you can go deep on any number of things. And I think the real art is choosing where to go deep on. And I've certainly not mastered that. I kind of know what to look for that, like, this is a domain that's interesting. I'm not yet necessarily good at choosing the area that's worth spending your time because you know, you have a limited amount of time and you have to be thoughtful about where you spend it.

And 

Brett Berson: [00:34:18] so for you, it's mainly random. So there's, let's say there's seven dimensions to this product that we're building and for this customer experience, and we could drill down and spend weeks on any of those. And so do you just kind of go down each hole and hoping to find something fantastic and 60% of the time it doesn't work.

It's such an interesting idea. And I think profoundly important and it gets the idea that where you spend time or what you choose to go deep on, just because there's only so many hours in the day developing that muscle is a superpower. 

Ayo Omojola: [00:34:48] I mean, I would just say, I wouldn't say it's random. I do think I have some aim.

I just don't think I'm great at it yet. I know enough to whittle things down, but there's like at some point you kind of have to choose. And so I think what, like my gut is not looking at myself, but like looking at others who I see doing this stuff. If you have a, like, I have an economics background, if you have like a scientific background or a legal background, a lot of time, like there's just procedural things that you knew, Hey, there's a dead end here.

Don't go there. I don't have those things, but I know like broad areas of interest to go look in. And so I can say, I can go from looking at the whole thing to probably looking at 40% of the thing and just cut out like areas that I have relatively high conviction are not worth spending more time in for, you know, whatever objectives that I have.

But I would say like at some point you can come up with a rationale, but at some point you're just picking and like, you can't distinguish well enough between a set of choices to know where exactly to pick. There's just always some trial and error of like, you go down one route, it's a dead end. You gotta stop sort of altitude shift and then like go down another route.

Brett Berson: [00:35:59] So from going from a hundred percent to that 40% of which there's a subset that will ultimately lead to sort of these aha moments. Can you teach me how to do that? Or it's just an intuitive thing that you've built up. And so you can look at that a hundred percent and get it to 40%. I'm sort of thinking of the metal detector on the beach analogy.

You have this huge beach, you don't know where to start. And so what I'm hearing you say is you can kind of get into a general vicinity where you think there might be some metal, but you can't get to pinpoint accuracy. And so you just kind of have to start to wave the metal detector, but when you zoom in on that sort of smaller area, is that based on some heuristic or framework or it's just, you've gotten a lot of reps and now you have this intuitive feel for that.

Ayo Omojola: [00:36:37] So there's some that I've already done for myself. So for instance, the domains that excite me the most, these days are generally domains that I have a high amount of regulatory and technical complexities with them because they're just rich in opportunities. And a lot of the times the people that you work with or compete with for any number of reasons, either haven't gone, I'm super close to the metal for a really long time.

Or haven't had to sort of, what's possible with technology now is just like, So different from what was possibly even a decade ago, that there's just going to be some opportunities. And those are like, the way that I think about them is it's like financial services, healthcare logistics, natural resources, and mining, aerospace, construction, energy, and climate change are like, in my mind, I'm like, oh, very interesting, heavily regulated space, really, really large addressable markets touch people's lives in like many, many ways.

I spent five and a half years in international services now I'm in healthcare. And so I actually, candidly, I would say I've gone like a little deeper than that, but my aperture is obviously at the moment sort of bounded by like I work at carbon, we're focused on accessibility in healthcare. And so sort of everything I look at is through that lens.

But I wouldn't say that I've gotten like much further than that. Like for instance, if you put me into like social media as a domain, I probably wouldn't even know where to start. To be honest, it's just like, not a place that I'm strong and it's also not a domain that has like anywhere near the regulatory complexity of a domain, like finance.

So actually there's one more thing I could say. It's not a domain that has anywhere near the regulatory complexity of a domain, like finance or healthcare. And so there's no natural, like what are you gonna look at? Like how the FC treats something it's like, not that useful. The one thing I will say is a lot of the time, a pattern that I've seen now, a few times I saw this cash and I've seen this carbon, is there these things that you go after?

And you're like, Hey, can we do something else? And people tell you no, but they can't really tell you why. Or the why is like ambiguous or the why is, uh, why that could clearly be solved by something else? And so that's probably as close to heuristic, cause like what's really happening there when the person who's most knowledgeable about it has to give you like a slightly ambiguous answer.

And I'd say it's like probably 50 50 on you asked the question the wrong way. And so you're getting an ambiguous answer because your question was bad. The other half is like, that thing has changed. There are other ways that you could solve that problem, that the people that you're working with haven't necessarily encountered or, or they're not aware that it exists and things like that.

Brett Berson: [00:39:09] We sort of kicked off, well, this conversation by talking about this idea of going unreasonably deep, and it's something that you picked up from Brian who still leads cash app and was the founder of it. I'd love to spend a little bit of time on who did you work with the closest at square that maybe you learn the most from and what are some of the things that you learned.

Ayo Omojola: [00:39:27] So I worked pretty closely with a guy named Robert Anderson, who is a, sort of as a lead designer at cash for a long time. And now he's since left. He was the earliest designer at square, actually, early on, when we were working on the cash card, he made this comment where he was like, dude, people are going to share this thing on Twitter a lot.

I was like, who the hell is going to share a debit card on Twitter? That's crazy. And he was literally bang on in the center of the target. And so I want to say something like a crude platitude, like the power of design, it stuck with me that only in hindsight that I kind of realized. Like in foresight, I kind of was like, oh, Robert is sort of optimizing for this perfection thing.

He really was optimizing for outstanding. And it's a subtle difference, but it's a good frame to look through because obviously the cash card has evolved and we've made a bunch of changes and there are things that were possible then that we could have done that we chose not to. And that we've since adopted and all that's a long way of saying it wasn't perfect.

There was room for improvement, like for the category of product that it was, it actually was outstanding. And that dynamic is, I wouldn't say that I've nailed that, but I do think about that quite a bit. There's a guy named Dungy, who I worked pretty closely with early on, on a few things, including launching early versions of the cash card.

I learned a lot about high fidelity communication with an engineering team and like how to, I would say actually how to partner when you're sort of working in close quarters with people for a long period of time. Brian had some good frameworks, like the going unreasonably deep thing that like really stuck, who else.

There's a guy named Jesse Wilson, who was, I think he's still senior engineer at cash app. And even today I find myself like applying engineering frameworks that he and I talked about like years ago. So I'd actually say there's like a couple of other people that I can name, but I'll say Jim Esposito, who was the head of operations, the cash app and Emily chew who's on the sort of strategic development team are both people who were in functions that I hadn't had a ton of exposure to before I joined square.

Yeah. That I really gained an appreciation. For what those functions were capable of doing that? I didn't know before, like I worked with Emily on a handful of projects, I'm a really outcome oriented person and I will bend any process to the outcome that I want. And I honestly did everything. That's a strength.

It's just like I do it. Cause it's like my way to brute force things and watching Emily run a process is like a thing of art. And Jim, I would say I'd worked with Jim. He was at square for a little bit, left, ran some stuff at Etsy and then came back and joined cash app. And I used to joke that he was the margin expander, just a guy who would like, just look across the business and find areas of.

He would find these areas of opportunity and I'm very technically minded. So all, like I just think about like, Hey, if we build this thing this way we can like get this type of leverage. And Jim is like, one of the ways that I think about him is he's like, if you talk to these people this way and like put a package in front of them that looks like this, they will make a different decision.

And that's not a thing that I'm good at. And I always really appreciate it. 

Brett Berson: [00:42:42] There's so much to jump off of there. I wanted to go back. You mentioned Don, you said this idea of how to partner in this case with engineering on how to, I guess, work really well in close quarters. Can you talk more about what that actually looks like or what the approach or framework is that you learned?

So 

Ayo Omojola: [00:43:01] his name is Don G D H a N J I. One of the things like I think an early mistake that I used to make was only ever sharing with a person that I was working with, the context that I thought they needed to get the task done or get the job done. However you want to describe it. And I would say one of many things that I got from Don G was sharing as much context as possible with a person you trust to like, get something done is like a super power, because it's almost like downloading your brain, it's their brain.

And what I saw happen like several times was he would just have questions about stuff that I just didn't think about. And it forced me to be better at like my knowledge of the subject matter. So that was like one advantage. And that basically meant like, sort of better communication across the board.

The second is having all that context about like business objectives and like what's possible. And so on, there were areas of knowledge where he just had like way more context than I did. And it would allow him to iterate in a way where, like I had this dynamic with him and with guy named Ryan Lee, who was my counterpart up until I left, where like we would talk about something and then we'd like, get really deep into it.

And then I would wake up the next day and a new thing would exist that didn't exist the day before. And like that dynamic. It's like, it really is beautiful thing because it's just like this crazy sort of iteration speed that you get. And it wasn't until I had internalized that this is going to sound so trite, but it's just like sharing all that context.

It's just a better way to communicate. And it helps like fill in gaps that you might not know are there. And I try to do that as much as possible 

Brett Berson: [00:44:41] about Emily. And you said watching her run a process is like a work of art. Can you talk more about that? Or how does that influence the way that you think about running processes today 

Ayo Omojola: [00:44:52] without describing any of the projects that we worked on?

I've always worked really well in like smaller groups where you have really strong pairwise relationships. And in those contexts, rapport is really important. Chemistry is really important and those things like have real leverage. I saw Emily run a couple of cross-functional processes that like involved wrangling lots of people across the organization, many of whom were senior, many of whom she didn't know before the process kicked off.

And just like the ways that you ask people questions to hold them accountable, the way that you frame things for, Hey, I need you to do this by this time because it's blocking this other person. And so like this other process, can't start until you, like, you get your thing done. And here is a scaffolding for you to execute your thing into.

And if you execute your thing into the scaffolding, the person who is depending on you will have exactly what they need to like get the job done. So like just things like that, like helping. So one is, again, it's a little bit of that sort of context thing from earlier, but it's also, so there's like a lot of creative tasks where people have like the blank slate problem.

Where a lot of times, like you procrastinate, just because you're like, oh crap. Like, I don't know how this is going to look in the end. This is not rote work. And that concept of here's a way for the shape of your output to look as a way of helping people bridge the black slate gap. And if something is call it sort of 80% wrote work and 20% creative work, and then you go to them like scaffolding, you've taken like 6% of load off their plate.

And they like, kind of know exactly what to deliver and they're much more likely to deliver it much more quickly. And then just scaling that across an audience a was impressive to see. And B for things that I asked my team at carbon companies that I work with on the investing or advising front friends that I'm helping build stuff.

My projects, just that like scaffolding thing. Like I just, I do that all the time. So I recently had a company that I'm still working with and they have. A very, very healthy consumer product. And they're building out now, like they're building out B2B product. That's like super high quality and very exciting and like sort of maps to how I think the world should work for.

Like the thing that they did I do. And I was talking to the founder and he showed me the way that they're sort of presenting this new B2B opportunity. And I have like been lucky enough over the last six months to like, watch like, uh, incredible enterprise business really scale. And so I was like, Hey, actually, This is a way you present this information to your team, your board, et cetera, in a way that's like really actionable for them.

And then I like produce it and imagine a you're talking to a very consumer focused person and you're showing them an enterprise sales pipeline. And I filled out like the first end rows, and then talk through it with him about like, Hey, here's like for each thing, here's the objective of showing this data.

And then we sort of debated if that objective actually was what they were going for and then sort of left them off to the races to run with it. It went from the ask being, Hey, you really need to communicate this information in an actual way to here is a frame and here are the actions. And so at that point, it's just plugging.

Brett Berson: [00:48:16] Another thing you shared a minute ago is that Emily was particularly good at sort of framing questions to people. Can you explain that in any more detail 

Ayo Omojola: [00:48:27] that company has. Several thousand people as tends to happen at large companies. There's very often projects that require people from multiple specialties to participate.

And generally when these things happens, it's not as though the person that you need in the finance team or in the accounting team or in security. It's not as though they have like an empty slate. They have stuff to do. They're generally going to be busy as well. And so getting them to. Getting like the thing that you're working on prioritize and getting them to like attend to something that you need from them.

It's just complex. And if you don't have personal relationship with them, and it's not like mission critical for them, like, you know, they're not like rated on it or anything like that. It is complex. Like get those types of jobs done and then multiply that effect by like the larger the organization, the more larger organizations tend to be more specialized, more specialized organizations mean that cross-functional efforts just have like a lot more humans involved in them.

And so, like, I think some of the stuff that I saw her do was like building out a grid of like, Hey, here are all the things that need to happen to make this thing come to life. And here are like the objectives that we're trying to achieve and then having. Participants sort of chime in and pitch in. And there's a part of this that is if you work at a company and you see something that's going to affect your area, one, you're probably going to speak up and to a lot of the times, if that thing that affects your area, if no one's paying attention to it upfront, it's just going to make your life difficult later.

And so she like a couple of things that I started where like just describing out, Hey, here's all the stuff. And here's how it all ties together. Get feedback and input from people on what things might affect their area that haven't been considered. And then figuring out, Hey, maybe the person in the room speaking for this part of the company, isn't the person who's going to be doing the work, but figuring out a process for getting them to either delegate or report back managing all those followups.

And then once you have the right, like directly responsible individual for like doing whatever that task is or whatever that project is, then making them understand, Hey, you're on this timeline. The reason you're on this timeline is these other things depend on you. And then the kind of social pressure of you're on this timeline, these other things, depending on you at the next check-in making everyone aware of, Hey, the reason your thing can't start is because this other thing has been done.

How do we get that done, et cetera, et cetera. Like there is an art to managing these like big cross-functional type groups. I'm certainly not good at it. 

Brett Berson: [00:51:01] It'd be great to talk a little bit about some of the different frameworks rituals, things that you do in your role that you think pay out-sized dividends or have the most impact.

So that could be the way that you think about org design. It could be the way that you hire and things that you look for. It could be the way that you coach and mentor. It could be the way that you communicate product strategy and vision, but these sort of little things that you do that you rely on or lean on or find have particularly large impact.

I've 

Ayo Omojola: [00:51:35] only been at Karbon six months. So it's early to tell, I'll try a few that I'm like consciously thinking about, but bear the timeline in mind. So a few of the things that I think about are like one this point about like distributing context and building like. A narrative or a story that is that enough exists that people understand where you're trying to go, but there's parts of that narrative that other people need to write in order to like, I can't do everything obviously.

So a thing I do think about a lot is how to, like, I don't have a solution for this, but it's one how to start, how to frame, where we're going, the reasons that we're doing the things that we're doing and do that in a way that, where there is sufficient room for other people to take ownership of the parts that they're going to be responsible for and do that in a way where, like I also don't have all the answers.

So doing that in a way where people who are faster, stronger, better, smarter, whatever dimension that you care about than me can make sure that like, Hey, we are going the right way. And B there's enough meat to chew on while filling in the gaps. So I think just sort of the narrative construction and the distribution of that context, Is a thing of that I think a lot about, I do think a lot about team construction and personally, I am really enamored of the idea of hiring people who are better than me in every way possible.

I think a lot of this is also just like personal preference in my mind. I want to create the people I work with kind of like do their best work and they don't want to leave them alone to just do it. And for that to work, you have to have people who are better than you really, really driven. And there is a little, like I am human and I do have some insecurity and it is a little bit daunting to sort of be in that environment.

But I think it's the right thing. It makes me better. And then I would say a really big thing that I come back to frequently. And for people who've managed larger teams, they probably already learned this, but there was a period at cash app when growth went vertical. So me and Ryan would wake up every day and like, look at the metrics and we'd be like, yep, still going.

And. I had never worked on a thing that had gone through hyperscale before. And as a result, my first instinct was to believe that I was inefficient. Cause like I got super busy, a bunch of stuff stopped getting done. And I was like, oh, I just have to like get more efficient. And so I started doing what I would describe as like productivity hacks, where I would say, oh, you know what, I'm just not going to do anything in real time.

In real time, all I'm going to do is take notes and then I'll process everything as synchronously. And I like never got great at that. So there was that there was just getting better at like parallel processing problems, things like that. So there are all these attacks that I did so that I could get more efficient and I got like insanely more efficient as a consequence.

Now, when I look back, I realize that that was like not at all what I should have done and the right answer and this I'm going through a similar experience at carbon. And, um, or at least trying to put this into practice, the right answer would have been, or what I think now would have been the right answer would have been too.

Like replace myself everywhere as early as possible. And if I had been able to do that, then you get to, it's kind of, like I say this all the time, a carbon, I want to make myself obsolete. And to do that with confidence, you have to hire people who you think are going to do a better thing than you could do that job.

And then you want to give them the environment to like kill it. And if you do that well, then the organization, like the results that you get are like, tend to be positive surprises and the organization can like run and execute without you in the room. Very, very well. And then you now have spare capacity to think through like, what are the areas of leverage that might not be getting taken care of?

And so that's like a, it's a weird personal thing, but it's just literally in the last three months I've been like, oh, actually looking back at like that period of time, trying to take it all on, like was a mistake. And I, I think, you know, we left some potential on the table as a result of doing that. And I'm trying not to make that mistake again.

Brett Berson: [00:55:44] So not surprisingly, what you're saying is obviously get incredible people on the team and then try to get out of the way or get incredible people on the team, do an exceptional job of building context and narrative, and then get out of the way. Can you talk a little bit about how you approach hiring?

And everybody says they hire exceptional people. I think most people don't hire exceptional people. Everybody says, I want to hire people that are way smarter than me. I don't think most people actually end up doing that. And so I'd love you. Can you teach me a little bit about how you approach hiring or what you're looking for or what your process is that you think increases the odds that you kind of build this incredible talent density around you?

Ayo Omojola: [00:56:23] So the couple of things that I do are, so I noticed this thing at square and just sort of in environments, Silicon valley, where coming out of YC and being a founder for a while, I had a lot of friends who were startup founders, and I noticed this thing over and over again, where. You start a company, you raise a bunch of money.

Everything's great. Maybe it works. Maybe it doesn't like, maybe like you sell it for a song or you have great exit or it shuts down. And what happens a lot of the time is these founders have like spent a lot of years just focused on this thing. A lot of the time there, your social network has atrophied.

You've let a lot of friendships go by and you have this grab bag of skills that is quite difficult to fit into like a regular company role bucket. And so I love friends who were like incredible founders, just beasts. And they would go for interviews that Facebook, Google, Amazon, et cetera. And they would always be bounced out.

And a lot of the time, like my perception of the problem was. That what a lot of companies are looking for is a lot of companies are like, oh, this person was a PM at Google. And that's like, what they want to hire actually. And they might say a bunch of stuff, but what they really want is they want the person who did exit at a big brand company that they know.

And ideally that will give them a little bit more of the ability to be like Google and maybe some fairy dust. And so one of the things that I've tried to do, and it's early, I think I made the first hire of this type in July. I look for founders who've are in transition from their last company and are figuring out what to do next.

And I think you and I talked about this at some point it's like these founders in transition are in search for a mission and I'm transparent with them about, Hey, I want to hire you for this purpose. I understand that a lot of the time like me, they will have a chip on their shoulder and they're going to want to go out and build something new.

And so like, I completely understand that, like, they're going to be flirty with ideas and I want to support that. And so I stayed up front, I'm hiring for this purpose. This is the type of thing that we want to do. I try and create an environment where they have like maximum creativity and flexibility.

And then I just ask that they're transparent with me on how they're thinking about what's next. And when they're thinking about what's next, so that we can like, make sure that the org is sort of able to run so that, like I'd say that's a big one. And I would say that's early, but it's a, the short way to say it is.

I think founders that are not in the like, oh, You've won. And you've had, like, these massive exits are actually generally undervalued by the market. And I try to hire them 

Brett Berson: [00:59:06] in terms of, I was actually evaluating a former founder that you may hire or somebody that came out of another job or another role.

Are there interesting parts of your interview process, practicals that you deploy or questions that you ask or ways that you approach it that you found particularly? 

Ayo Omojola: [00:59:24] So this is a work in progress. I don't think I've nailed this. I think one thing that I really like to do is a lot of the time for founders, the company that they founded, like there's a product that you can use.

And so one thing I do like to get into is how they made the decisions to get at whatever outcome is there. Like so much of the time, it's very easy from the outside. And I do this all the time to like look at a product and. Make a bunch of assumptions about how it's constructed, but a lot of the times, most of the products you use are the result of tradeoffs, architectural decisions, et cetera, that were probably relatively complex and in the weeds to make.

And the nice thing about hunting for founders in transition is generally you don't have to worry about whether or not they can ship because you have available evidence of like you have public artifacts of their work that you can try independently. So it's like very much show, not tell. And then a lot of the time the discussion is about why they made the choices they made so that you can get into like their thought process.

Brett Berson: [01:00:26] One other thing I wanted to spend a little bit of time on, on this theme a few minutes ago, you talked about the importance of context, setting, context, loading, and narrative. Are you able to talk about that in any more detail or. Share what that looks like when you're doing it. Well, I really liked when we were talking about the square example where it's just easy to try to share enough information for that person to quote, do their job, but going above and beyond what you're saying, pays these huge dividends.

And my guess is that either people are lazy or just don't think it matters. So they want to cut to the chase, but actually sort of the full movie versus the trailer has a lot of unintended upsides. But I'm curious if there's anything else to that, or if you were going to teach me how to do a better job of context setting and narrative setting, if there's anything you could share on that.

Ayo Omojola: [01:01:13] So, I don't think it's like a laziness thing. I think it's a speed thing because it's obviously easier to just say less stuff than more stuff. So I think there's a few parts. One is, I don't know if this is true for everybody, but it is true for me. I have for a long time in a lot of domains, it's kind of a default assumption that people are coming to the table, the same context as you and I now think that's true much less of the time.

It's more often not true than it is true. Like most of the time people just have very different contexts from what you have and what their perspective on the objective is, is not necessarily aligned with yours. So if you're busy, for whatever reason, it's obviously a lot easier to say, Hey, do this task.

And that's not to say that. People do a bad job. And it's not to say that every time you talk to somebody, you need to give them like a whole song and dance about why you're doing what you're doing. But it is to say that somewhere along the line, and probably earlier, rather than later, it's important to give with whoever you're working with, share a full picture of, Hey, here's what we're trying to do.

Here's why here are the areas we have really good definition on. Here are the areas that are like a little bit more ambiguous. And one part of it is just, I actually do believe that giving as much context as possible as early as possible is just better. That's one to this. I don't know if it's universal, but it is true for me.

I find that a lot of the time when you do this with people, it's better to describe problems to them. Like basically say, Hey, here's what's happening that we would like to change. And here's some constraints we want to put around it. We don't want to spend X amount of time on it. It has to be above or below this cost threshold, or it has to not break this other thing.

And then I think the instinct a lot of time, at least for me, is I'm always problem solving. And so most of the time I go ask somebody for something, I have an idea of how it should work and. When you're trying to distribute context and lecture a narrative, I think it's really important to enable people to come up with a solution themselves and then debate.

And it's easy to give somebody a task, but what happens a lot of the time when you're executing is if they don't have context, they're going to need a bunch more feedback from you over time in order to like, get to the end because you give them a task, they go into it, they realize like something there.

Isn't what you assumed it was when you gave them the task. So now they're like, oh, I found this, how should I solve it? And I think giving people as much context as possible when you're working with them, allows them a lot of the time to see it because they understand what you're trying to trade off for.

They can make those trade-offs themselves and that's requires less interaction from you. And the sort of downstream dynamic of this is for a long time cash app was. Or actually the catch-up still is a very distributed team. We had, you know, an engineering team in Melbourne, Australia, Sydney. We had some people in Hong Kong, Stockholm, Toronto, San Francisco, New York, and scattered around the country.

And there's like this weirdo dynamic, where if you're working with somebody on the east coast, you have like four working hours a day when you're both available. And so versus somebody that you're co located with, it adds kind of like a day of feedback cycles. A lot of the time, if your schedules don't line up.

So if your schedules don't line up, you got up just starting work at like eight or nine. It's already noon. There are lunch. You have your meetings whenever, like, whatever it is that they need from you. You have to solve by 2:00 PM. And if you haven't solved it by two, then you're waiting until tomorrow.

And so if you wait until like the end of your day, because like you've been in meetings all day or something like that to like give feedback. Now you've added like this layer of a day of feedback in between they're like executing and being blocked and getting unblocked by getting additional context from you.

And I, at least I found that like sharing as much of that context as possible as early as possible means you have less of those interactions and probably gets even more complex. Like the folks I worked most closely with, uh, cash on the engineering side, where in Melbourne, like I worked with the Melbourne team, the San Francisco team a lot more sort of later on in my time there.

And then early in my time there the Waterloo team and. It always kind of stuck in my mind that this one day feedback cycle, it's like, I think I've read for like get lab and other companies like this, that the way they describe it, as you need to have really, really good documentation and for a product like cash app.

And I think that's true for carbon as well, where you're just moving crazy fast. Almost all documentation gets out of date really, really fast, and like the likelihood of a person consuming, any documentation you create is negatively correlated with the amount of documentation that's out there. So like still synchronous communication really, really matters.

And I just, actually, this is something I would love if somebody could figure out, I actually haven't figured out how to do really good asynchronous communication. Well, 

Brett Berson: [01:06:01] and so for you, most of the time when you're context loading, you're just sort of literally explaining one-on-one or in a meeting what's going on as opposed to sort of coming up with standard documentation.

Ayo Omojola: [01:06:12] Correct. And it's provides some basic documentation that like sets the frame and then like follow that up with synchronous communication to make sure that like you weren't misunderstood, et cetera, et cetera. 

Brett Berson: [01:06:23] So I wanted to end our time together talking a little bit about your thinking around problem selection, you know, what do you choose to work on?

Ayo Omojola: [01:06:31] So I've written a bit about this. I would say this applies to anything in this conversation that might have been construed as advice. And I will say this about this, what I'm about to say as well is I'm speaking from my perspective, it's an N of one. And I think it's just like really, really important to always remember that when advice doesn't resonate, you should feel free to discard it because I can't say for sure that what's worked for me is work for anybody else.

In my context, my whole life I've always been an ideas person. And so I always, I have like a running log that I've kept for like. 15 years that are just different ideas that I've had. I would say I've probably actually executed on like one or 2% of them. And I'd say probably the truth is most of them are bad in some way.

And probably the truth is a lot of them are things that somebody somewhere is working on anyway. So it wasn't necessarily like the right thing for me to do it. But I think this is a little bit as well of the way that I was raised. My parents were very educationally oriented and in most school contexts you can just work harder and get a better result.

Like, if you think of the concept of a test, the concept of test is somebody gives you questions and you answer the questions and all you're being tested on is your ability to answer the questions. And I don't think real life is really like that. I think like at least in my life, it is important to be good at answering questions.

Yes. It is much more important to be certain, or as sure as possible that the questions you are answering were worth asking to begin with. And so like the way this manifests is when I look at my last company, we spent a lot of time. It was me and my brother and a friend. We were the co-founders and then we had a small team and we spent a lot of time working on, we kind of picked something that was technically interesting.

And we were like, yeah, we'll figure it out. And then we like cranked for years and just worked so hard and it just didn't matter. And the conclusion. I came up with, or that sort of lesson for me was we had put so much effort into. The actual work and not put nearly enough effort into choosing what to work on.

And that was a much bigger determinant of our outcome. Like a much bigger determine of our outcome was that we were building like a chat app for mobile apps and web, and that wasn't at the time and still isn't a large market and it's not that impactful. And even for the people it's impactful too. It doesn't matter that much people don't like to interact with it, et cetera.

And then I kind of saw like the opposite cash app and I've seen the opposite at carbon. And one of the lessons for me was if you pick a big domain, that's like rich with opportunity. Like it does matter how hard you work, but you get so much more leverage just because the domain is rich with opportunity.

And I think what we're taught when we grow up sort of the way that I was raised, it was all about like, my outcome was a hundred percent correlated to like my effort. And so I've just assumed when things aren't going well, I just need to work harder. It's like, honestly, almost an instinct at the moment.

And it's ingrained a lot of habits. And I try really hard now to like disabuse myself of that notion because it's not an accurate view of how the world works. And I just generally tend to think choosing a problem that matters, even if your average will on average yield a better outcome than choosing a terrible problem, even if you're excellent 

Brett Berson: [01:09:50] in the definition of a great problem is just scale and complexity or are there other ingredients because I tend to agree and I think like this whole area of where should you start either, if you're working on a new product at a large company or a startup, what is sort of the real estate that you're building on?

Right. The product surface area, I think is just hugely undervalued and it's almost like real estate, right? Like in many cases, you know? Sure. You can take a bet that you can build an old part of town. That's not that great, but all things equal, like location, location, location. And so is there anything to finding that right location or is it just like the obvious things like healthcare is very big and broken or financial services is big and broken.

Ayo Omojola: [01:10:31] I don't know that I have like a good generalized, like, Hey, here's how you pick up problem. The way that I do it, that I think has worked for me is domains that are regulatorily complex. Generally, once you establish a beachhead, there's like kind of higher barriers to entry and that complexity is like a reason.

People don't tend to try it. And a lot of the time that complexity reflects itself in the products that people use, because the easiest thing to do is to make a bad product spirits. And so the way that I've modeled it for myself is. I think I mentioned this earlier, but it's like these seven or eight industries, financial services, healthcare logistics, natural resources, climate, et cetera, where it's kind of a given that they're large problems.

It's kind of like, yeah, everybody needs power. Everyone needs money, urban needs healthcare. Like people need to move from point a to point B. They're just touch every human's lives. And I would say that that's, as far as I've got, I have a hypothesis that the age of the leading product in the industry or the age of the fastest growing product in the industry is like an indicator.

And the older that is the more opportunity there, but I haven't yet proven that out. 

Brett Berson: [01:11:37] Well, that would be a great thing for us to pick up next time. Thank you so much for spending all this time with us. This is wonderful. No 

Ayo Omojola: [01:11:44] worries. Thanks for doing this. I hope it was actually interesting. It was.