Ayo Omojola (SVP of Product @Carbon Health, ex Cash App)

Hey everyone, this is Erik Torenberg and you're listening to Execs by On Deck. Execs is a show for founders, operators, and leaders who want to understand the playbooks, frameworks, and tactics that leading tech companies today have used to scale. Our guests are tech execs in key roles at top tech companies who share their hard-won, earned secrets on how to scale faster.

Ayo Omojula is Senior Vice President of Product at Carbon Health and an avid angel investor. Prior to working at Carbon, he was product and business lead at Cash App. In this episode, Ayo talks about what it's like working in regulated spaces like finance and healthcare. He also shares frameworks for engineering, product marketing, and how to go unreasonably deep on problems. Rishi Tripathi, Group Product Lead at On Deck, joined me in this episode as guest co-host. So Ayo, stoked to have you on the podcast. Excited to talk about how to build and scale a product organization and also how to grow as a product leader. Why don't we start with a bit of background and you could tell us a little bit about your story going from Cash App to, from Square to On Deck. Carbon Health. Why don't you talk about what you worked on at Square and how you grew as a product leader?

Yeah, so I'll go reverse chronological order. So currently run the product team at Carbon, been here about 2 years.

And can you define what is Carbon for the audience who might not be familiar?

Yes. So Carbon Health is an omnichannel healthcare company. What that means tactically is we build and run all our own tech. Our EHR is homebuilt, scheduling, revenue cycle and billing, patient application, we build it all ourselves. We build and run the clinics ourselves and the doctors work for us. So, we control everything. Big picture, what makes it really, really interesting is there are a lot of high-quality clinical organizations that are not technical. So, like Mayo Clinic, Cleveland Clinic, just like excellent clinical organizations don't have an engineering discipline. And there are a few technical healthcare organizations that don't own the doctors. So, you can think of those like life sciences research, et cetera. And then there's even fewer organizations with a high-quality clinical discipline, a high-quality technical discipline, and high-quality operational discipline. And of the ones you'd have heard of, you basically think of like One Medical and us. And of those, we are the ones that are mass market. And so, you can think of it as like, and this is sort of my objective, the thing that I always tell Aaron I want to do while I'm here is The feeling of having access to Caesar, who's one of our co-founders, and Sujal, who's our chief medical officer, I want to make that available for everybody. So I joined right before the pandemic. Before that, I spent about 5 and a half years at Cash App. And while I was at Cash App, I worked on a bunch of stuff. I started by working on an API product, which we ended up killing. The main launch that you might've heard of is Snapcash, if you remember the money gun thing. Worked on that for a bit, worked on growth and optimizing our referral program for a bit, and then spent most of my time there working on our banking product and team and launching stored balances, Cash for Business, what's now the Cash Card, ACH, sort of one of the foundational pieces of the Cash App story. And then before that, I started a bunch of companies that, you know, everything from, I think my first try was a restaurant, worked on a photo sharing app, worked on games. And then the last company I worked on was basically Zendesk for mobile back in 2012. And we went through YC for that and sold that to a competitor, which then sold to a competitor.

Cool.

And you also have invested in a number of companies. So let's start from the beginning in terms of when a company is hiring their first product manager. How do you advise your companies in terms of what to look for or when to hire your first PM? How to think about that and then let's go, you know, how to grow from there.

I don't know if I have a good answer for when to hire the first PM. It's so dependent on like the company and the team's background and kind of what types of problems they're facing. So I think the couple things I'll say is like, one, it depends. Two, everything I say is from the position of an N of 1. So anyone listening should, if the feedback resonates, great. If not, I won't be offended. So most of the time when I talk to founders about like making that first product hire, I focus a lot on what the founder needs and what the organization needs. And so, there are certain organizations that, like, the kinds of problems they're facing, they have really good execution and no organization. And the archetype I have in mind is, like, you know, what I think of as, like, the craft PM or the process-oriented PM. So, like, you know, the kind of archetype that can get that can get a process for shipping on rails, really good documentation. They tend to be generally more sprint-oriented. And typically what that means is you already have some, what you would call product capacity in your org. So there's somebody already doing this work and they just might not be senior or a leader or strategic or what have you. And that archetype also generally tends to work better when the founder— oh, sorry, when the founder is a visionary type. So when the founder is like, hey, I just have a thing that I wanna do And I don't want to run this org. It's not how I want to spend my time. I want somebody who can run a thing. The second archetype is more of a product visionary. And so maybe they're good at process, maybe not, but their thing is, the thing that gets them up in the morning is, I want to make a new thing exist today that didn't exist before, rather than, Getting a process on rails. And so, and I think, and this is not meant to be a pejorative statement, but the sort of ends of the spectrum are kind of like process-oriented or outcome-oriented. And both have very different upsides and downsides. For the process-oriented PM, things are going to feel smooth. They tend to be more reliable about keeping promises and keeping to dates. The downside is if they sort of over-index too much on process, you to get much more incremental progress in your execution. For the outcome-oriented PM, product leader, you are much more likely to be surprised to the upside and to the downside, but there's a high likelihood, like I bet you if you asked Aaron right now what it feels like in our product organization, he'd say it probably feels a little bit chaotic. So the downside is they tend to be sort of less Proficient at process than the alternative. All that's longer of saying, it depends on what you need in your organization. And then you have kind of like, I think I've seen some people sort of break it into 3 and I'm not sure what the third one's for, but the way that I tend to think about it is those are 2 ends of the spectrum. And depending on what your org needs, you should pick closer to one end than the other.

And just to follow up on that, before a founder sort of, or as you're building a product team in the early days, There's often this transition of some of the product vision and leadership from the founders to the product org. What should founders know or be aware of, or product leaders on either side, what should they be aware of as they're going through that transition of having that product vision shift from the founders to the org?

Yeah. So with the caveat that I've only done this once at Carbon. Some of it is probably that I'm good and Aaron's good and some of it is that we're lucky and some of it is the environment. It also kind of depends on what the founder's archetype is. If the founder's archetype is very much business-driven, there can be a pretty good separation of concerns actually because it just probably is the case that a founder with a sales background, for example, doesn't necessarily want to run a product org and build software and they're really, really good at closing deals and building value out of the networks they create. I would say the lesson there is like, just be clear about who's doing what. That's like the number one thing. The number 2, I would say is, I think this is true for all roles, but it's pretty important for the founder and their product lead to be clear what they expect from each other. So I'll give you an example. At Carbon, for example, there are— Carbon has like a pretty interesting story. We're only, I guess, 6 years old now. Aaron has this kind of crazy— Aaron's an engineer. Him and a really small scrappy team built an insane amount of surface area actually that I would say we are still, as we've scaled dramatically, we're still just getting our arms around. But one of the things that happened is there are just parts of the process of building an EHR. Technically, I think we are the youngest or second youngest EHR in the United States just by virtue of how long we've been around. And most of it was built by Aaron and 4 other people. And there are parts of our product where he has insanely strong opinions because he's banged his head up against the wall several times. As an example, we have a referrals platform we built for sending patients to specialists. We're 6 years old. By the way, we have a whole EHR. There's prescriptions. You can chart in it. It transfers data to HIEs. It tells the state when you have COVID. It's kind of a crazy thing. And this referrals thing we're on is version 4, just to give you a sense of how deep it is. And so there are just parts of our thing where had things gone a different way and Carbon was still a much smaller company, it'd probably be Aaron working directly on it. But because we're large, he's just like, hey, I have a really strong opinion about how that thing should exist. And he needs to be very, very hands-on and close to it. And then there are parts of it where he's like, go ham. And I think that separation is pretty important to Knowhere because if you don't, there is just a high likelihood that— it's not high leverage for both me and Aaron to be super hands-on on the same thing actually. And that's generally just going to be true. I think actually that is true for literally every founder with his reports for every function. It's just kind of like there's going to be parts where the founder's going to have a really strong opinion and the team has to make room for that to come to life to take full advantage of the situation. And there's going to be situations where the founder just doesn't care as much or is not necessarily as opinionated. And so again, I say it's an N of 1. For example, I haven't ever worked for a founder who's got a sales background, but I assume that there's something similar there with that founder and their chief revenue officer, for example.

One of the things that I pulled out of your last response that stuck was around how making sure that founders and their execs are on the same page with regards to where each wants to get their hands dirty in any given function. In your time, having gone through the hypergrowth of Cash and then the hypergrowth of Carbon, Have you picked up any communication tools or expectation-setting frameworks that you use in communicating with the leaders you work with to make sure that things go smoothly and that nobody's surprised or upset?

Yeah. I don't know if what I'm going to say will be super widely applicable. I think— so, I'll say what I do and then what I've seen work that I'm trying to learn from some of my colleagues at Carbon. So, I think it's important to know where to be extremely direct and where to be more obtuse. And for me personally, I try to be extremely direct when I can be really articulate about what I'm trying to say. And then, when it's kind of I have an emotional signal and I haven't articulated it yet, I kind of have to wait. The example I'll give is Carbon is now like a— we're not actually that big a company, but we look big, but we just have actually a lot of things in flight that different teams are working on. And there are a handful of areas where both Aaron and I have extremely strong opinions. And because they're just areas I know, things like growth, SEO, things like this, when he and I are extremely direct with each other, he's like— the other day he was like, hey dude, I think you suck at SEO. And I was like, all right, tell me why. You know, we talked through it and then I was like, well, I think you're wrong as fuck. Let me show you why. And then there are other times. And so I think like that part, that thing about when you know something really well and you can be really articulate about it, it is valuable to be direct because you just reduce the likelihood that there's like confusion or misunderstanding. And then there are other things where Aaron will give me a piece of feedback about maybe the way a thing was executed that I haven't really thought about. And I, 9 times out of 10, will be like, give me some time to walk away and give you a thoughtful response to this. Because if I respond to you now with the level of understanding that I bring to the table, I'm just going to give you a jumble of stuff. That's my style and the dynamic we built. And I think the only thing that I feel pretty strongly about there is just when you're articulate, being direct is super valuable. When you're not articulate, being direct, it's coming off like a highly misunderstood out-of-context tweet. What I've seen, so our CTO Claire is really incredible at a different way of doing this. I think just requires different skills that I don't have yet. I'm trying to build. So for example, There are many interactions where I have a very similar, highly overlapping thought with Claire, just about— we're in a team meeting or something and something is happening, and she works out the thought kind of in public. She's extremely direct, also extremely highly emotionally intelligent, and can simultaneously be direct about what's happening in real time, pick up on signals in the room. about how people are responding to it and adjust. And it's an incredible skill because you also— and this is just a really nuanced thing about organizations that one of the most important things inside of an organization at every level is the speed of the feedback loop. And so anywhere you can reduce the— anywhere you can flatten a feedback loop, you can think of the fastest organizations just have probably short feedback loops everywhere. And then the slowest ones are like, The projects they're working on are big. And even after those projects are shipped, it might take years to know whether or not they worked. And I think inside the skill that Claire brings to the table is, it just saves a metric ton of time. And just imagine the compounding effect of that over years.

It's really interesting that you ended that response talking about feedback loops, especially given in some of the industries that you've worked in, they've been fairly heavily regulated. I'd actually love to just try to understand, given the teams that you've built over time, how do you take these groups of incredibly talented people who want to move fast and who want to make a lot of impact, right? And then inspire them to work on these very messy, often frustrating, regulated problem areas. Has there been anything that you've picked up just within finance and banking, and then now that you think has served you in terms of storytelling?

So, 2 things. For the most part, both at Cash App, And at Carbon, the teams were extremely motivated anyway. So it wasn't like a— there wasn't much to solve for in like, you know, using Carbon as an example, it's like if you came here in the last year and a half, you worked on like vaccinating millions of people. It's hard to not be motivated by that. Do you know what I mean? So I don't— the motivation tends not to be the problem. So I'll say 2 things. Cash App, there's just like, there's a thing that's very specific about like my time at Carbon that I just don't know how it will play out in any other 2-year span, which is COVID, which basically inserted a gigantic unifying extremely rapid feedback loop into healthcare. Everything just moved 10x faster. The FDA literally moved faster, government moved faster, regulation moved faster. More people got sick with the same disease. Do you know what I mean? It's kind of a crazy hard-to-replicate thing. And the reason I don't know how repeatable that is, is that for almost everything we tried and like succeeded at or failed at during COVID we kind of knew pretty quickly whether or not it would work. And so it's not clear that like us building an enterprise business or us building some of these SEO tools that we built. would've grown as fast in a normal environment. So, all that's a long way of saying, like, I have to caveat my experience in healthcare because there's just this, like, weird macro thing that was happening. At Cash App— so, on the feedback loop, so 2 more things. So, one I think is, and I've talked about this a bunch in other places, but when you don't work in a regulated space, it's kind of— unless you're doing something that's, like, extremely criminal, It's kind of hard to break the law actually. When you work in a regulated space, the law is not a rational body of knowledge. It's just path-specific. It's just whatever was passed at whatever point that no one has come back and looked at even if the reality on the ground has changed. And so, you have to engage with it. And as a consequence, I think that one of the places that I see people get tripped up, and we're struggling with this now at Carbon and we're addressing it actively, is if you come from a non-regulated space, typically the lawyers rarely say no and you always listen. You're always just like, okay, we can't do that. We can't send a text message to that person because we didn't get the right consent, as an example. In regulated space, and our GC said this to me a couple of days ago, she said, the advice we give is fact-specific. So if you don't know all the facts, it's just very likely that the advice we're going to give you is not specific to the facts that matter to you. And The way that I interpret that, and I saw this done really, really well at Cash App, we had a practice of really spending time with the regs to come up with custom, extremely productized responses. And so what that would mean in practice is, this is back in the days when people actually were in offices consistently, is it'd be a couple of product people, a designer, an engineer, and a couple of product counsel folks. in a room with a specific reg blown up on a projector and a specific section of text highlighted, debating how to— debating different configurations of product execution that would meet the letter of the law, meet the spirit of the law, but might not have been implemented before. And there were many ways that went. There were times when we were like, nope, we can't do it. There were times when we were like, Oh yeah, we can do it. This is like a no-brainer because now phones exist. And then there were times where we were like, hey, there is some risk here, but it is actually the right thing for the customer. So let's, anywhere on the spectrum of we spent some time with outside counsel, we spent some time with the regulators, or we would just memorialize how we did it and put really good measurement and instrumentation around it so that if we ever had a conversation with a regulator in the future, we could— show sort of how we got there. And sometimes that would work out and sometimes it would not, but at least we tried. And it wasn't just like we slipped into doing this in a mistake. It was a conscious decision with all the parties at the table. And I think that does 2 things. One, it means that for every rep, you're getting a really, really high conviction, high fidelity view of whether what you're doing works or not. It's kind of like, If reps are cheap and you can do a lot of them in the same period of time, you can kind of be like, hey, we're just gonna take the no. Maybe it'll work, maybe it won't. And then if it doesn't work, we can like go back and revisit. But if reps are expensive, and as you get larger they tend to be, like as you get larger, like projects get bigger, execution time gets slower, it's just kind of natural. You wanna make sure that in each shot you really considered What was happening? And that sort of— the risk goes up the more regulated the domain is. And so I'll say healthcare has a slightly different dimension where mistakes we make could harm patients and we have to be really, really careful about that. So the feedback that I give to my team is, one, just ask why. Just understand. We might say no to something and decide not to take the risk, but you should at least know why. So, just hearing a no is not— it's not sufficient. That's one. 2, make sure the person giving you that context, giving you that answer has all the context in your brain. Don't assume that they know everything you know and know what you're trying to do. And then, with those 2 things, you'll tend to get sort of better answers. And then, the 3rd thing is if it's the right thing for the patient, we should very seriously consider taking the risk. Because there's actually lots of weird stuff that's interpreted in the most conservative way is actually not patient-friendly, but it is risk minimizing for an organization. And so we just have to— I think the main thing is I want us as an organization to be conscious about that trade-off as opposed to just the compound effect of every rep takes the risk minimizing path. Does that make sense?

Yeah, I think so. Erik, go for it.

I was going to segue into a different topic, I/O, which is hiring a VP of product.

Yeah.

When should companies think about doing that? How should they think about doing it well? Why don't you talk a little bit about that?

Yeah. I'll give a pretty unsatisfying answer. I think generally for the best people, the best people are in control of the timeline a lot more than companies are. And as a consequence, and I'll say the way that I look at it, as you go through your career, you spend time with people and you hear about people and you have kind of one-off conversations. And I've, for a long time, had a list of people that I want to work with. And so, it grows by a couple of people a year. And so, my advice is mostly like, I bet the two of you have that list in your head right now. I bet right now, if I ask you to name 5 people that you're like, I'd work with these people in a heartbeat again. And I don't think this is like VP of Product specific thing. I think if a person comes loose that is sort of domain-specific or domain adjacent, would actually add value to your organization and you can get them, you should just get them. You should just try and find room for them. And in abstract, you can think of a VP of Product as a role, but if you just sort of narrow, make it more granular to the specific person you're hiring, The value they add to your organization is not just that they fit the VP of Product seat, you know what I mean? The value they add to your organization is in an organization that is small, exceptional hires actually inflect that org. And by exceptional, I don't just mean big names or expensive. I just mean that if you imagine you're a team of 10 and you add one person, that one person is now 10% over your organization. And like that, the right person, like the right hires early on can have like a much greater impact on the org than on the company's trajectory than just the number in the employee number that they represent. So, well, that's a long way of saying like, for the people that you think are good and you would like to work with, you should just make room for them, whatever the room is. Actually, most of the time it won't work. Like most of the time, this has happened to me and it's actually the reason I started investing. is I had this list that I'd been keeping for a long time and I was looking for the right opportunity to work with these people and then they all started starting companies and the only way that I could work with them was invest. So for a good person, make room whenever you can and mostly it won't work, but when it does, it's beautiful. I don't know that there's a, hey, this is the time to hire a VP of product. Again, a lot depends on the situation. So I would just think of it as where you get leverage. So for instance, you could be a really small organization and there's just enough to do that the founder needs to focus on that it's time to delegate a bunch of that responsibility away. And that's the right time for that organization. Or you could be an organization of the same size and actually all the leverage is in the product. So the founder actually really needs to continue to focus on that and you don't actually need that person. So it's more about, it's a very organization-specific thing rather than just a general rule that you can apply broadly.

And how do you think about yourself as an example when you compare yourself to your peers as other VPs of product? Where do you kind of spike and not spike just in terms of thinking about the different archetypes almost of VP of product? If you're a CEO, who you should complement yourself with?

Yeah. So Everything I'm about to say is from the outside looking in. I spend a bit of time chatting, just, I think healthcare is a very different business to work in as a technology person than even fintech was. So, I spend a bit of time chatting with other people who run product teams in healthcare. And I think I would say without question, the thing that the vast majority of them spike on relative to me is they are much better at running orgs than I am. I can just tell, just the way they think about it, the way they communicate with their peers, et cetera. The thing that I would say that I spike on is I am really good at making a thing that doesn't exist to exist. I am just scrappy as hell. And so, there's trade-offs, right? Carbon's product team is 30 people. One day it will be a 1,000-person product organization, and I don't yet— I've never done that before, so I don't yet know if I will be good at that. But like, for example, uh, not to name names, but like Claire Vo at Color, she'd probably be really good. Like, I can just tell, just smart as hell. The, the upside you got is you got a lot of new stuff. I bet you if you ask, if you ask the, uh, the rest of the Carbon team I bet the big knock on me— I bet the big upside of me is new stuff, you know that it'll happen. The big downside is it's a lot of new stuff. So it just depends on what you're looking for.

I'm assuming that given that you said a lot of the product leaders in healthcare, they have the org building bent and you have the scrappiness and the zero-to-one kind of How do you figure out where, if you're too far to one side or the other as you're building in some of these industries where you want to go fast, but you also have to take it with what the market and regs will let you?

Yeah. So just caveat, my comment isn't that they're not scrappy. It's just simply that I have seen, I learned from them in terms of how to build an org. So I know they're better than me. I don't know if I have a general answer. I know that the place that I spend the most time on with my colleagues at Carbon and my peers elsewhere, and even with my team, is just thinking about building an org well. And the analog I use is when I joined Carbon 2 years ago, I was shipping products and now I ship teams. And so my primary output is actually a high-quality team that functions well and can execute fast. and is smooth and there's not a ton of tension and stuff in the wrong places. I think in general, as a professional, there's kind of 2 routes you can go, right? Over time, you can just become more of the thing and go hyper, hyper deep. I have colleagues in fintech who are just deep in the payment stack. They're looking at RTP, they're looking at FedNow. They're like, how do I ship these CSV files to the Fed faster? And there is a path you can take where you can round out your skillset. And in this phase of my career, Carmen, the thing that the organization needs from the person in my seat is to be able to ship teams well and run a good org. And so the signal to me is like, yeah, I need to get good at that rather than get good at the scrappy thing. And then I do scrappy stuff once in a while just for fun or because the organization needs it or there's no capacity elsewhere. to get that thing done. And because kind of every time I do it, it kind of validates that I should continue to get better at building an org because it's easy and there's not as much learning there. You know what I mean? I'd say it's not all like, hey, there's a gap I have to fill. There is a really deep pleasure in Watching somebody fulfill their potential. And I really believe that one of the worst things you can do to a person's career is inflict a bad manager on them. And in order to help people fulfill their potential, actually have to get good at building an org, if that makes sense.

Talk more about what it looks like when you're integrating the VP of Product with the rest of the team, both I'll talk a little bit about the relationship with the CEO who was previously perhaps leading the product, but also the product leaders underneath them or product managers underneath them who maybe they were leading stuff and now they have to report to someone senior or aren't determining product vision anymore. Talk more about how to integrate successfully.

I didn't really have to do that at Carbon. How do I say it? I didn't really have to do that at Carbon, one. Two, There's just a lot about the way the last couple years played out that's like so weird. It's kind of like I joined Carbon and 2 weeks later, like, you know, the world shut down. And what the world needed from a healthcare company like us was so acute, I guess, like it was so necessary that there wasn't like room for us to like, there wasn't like really room for conflict. It was kind of like, hey, you know, there are things that a company like us can do to help alleviate the pandemic. Let's go build those things. And they were just like more than enough for everybody to like some stuff done and have their vision achieved. And we had super fast, insanely dedicated teams, so we got a lot of stuff done. So I think a lot of the conflict that you're describing, it's really around maybe there's a CEO, maybe there's a product person, and then somebody comes in between and layers that person. And how do you handle that person? And I think you should give— and the reason I say this just doesn't necessarily apply to my situation is We didn't have that person at Carbon when I joined. But if you give— I think it is valuable to give the person at the bottom of the thing the ability to spend time with and evaluate the new person coming in. And there's a lot of reasons for that. Some of it is just about creating a release valve if something is wrong. But theoretically, if you were making the right hire, it should be kind of natural, right? Theoretically, if you're making the right hire, You should be like, oh, well, this person is coming, but they're great and I'm going to learn these things from them and the organization will be better. And I, as a shareholder of this organization, want the organization to be better. I want this value to accrue to the organization because it will also accrue to me. I know that's kind of a rosy way to think about it. It just happens to be the case that I haven't actually faced that situation tactically and I certainly haven't faced it enough times to know how it will go wrong.

Over to you, Rishi. I was just gonna ask, like, with everything on the horizon and with like the past 2 years of crazy time at Carbon, like, what are you most excited for during like this next stage of growth, right? There's like a new— Carbon is stepping into its own, and also the world is shifting in various different directions. Some would say back to normal in some ways health-wise. What excites you about the next part of this journey through Skell?

My God, it's really a lot actually. So I think like there is a I think Carbon is a company that a lot of people don't understand and it is a little bit— and I think the reason that a lot of people don't understand is because they just haven't seen anything like this before and they just haven't seen anything like it be successful. If I asked you to name a national brand for coffee, you could just be like Starbucks and a national brand for burgers, you could be like McDonald's. If I asked you to name a national brand for healthcare, they're just—

Starbucks.

The closest thing is probably CVS. CVS, not doctors' offices. And so, there are a lot of ways I could describe what Carbon is, but the stuff that I'm super excited about is, well, 2 things. A sort of morbid advantage of COVID is because it compressed so many feedback loops, the advantages of an organization like Carbon became clear because it was really, really difficult It would be really, really difficult to do the things that we did if you don't actually also control the technology and you don't also control the people. And so, the example I'll give of that is, so last year we helped run vaccinations for the city of LA. For that, we were the software layer and we also provided a bunch of the staffing for Dodger Stadium, a bunch of places around LA. And in order to do that, like, I, I was on paternity leave when this happened. So I was on paternity leave, Aaron and a bunch of the team had a meeting with the city of LA, and then 11 days later we'd built the application we'd use to vaccinate. I think we ended up doing something like 1.5 or 2 million vaccinations.

Wow.

In the first 2, 3 weeks, we had teams on the ground and the team was shipping 2 iterations to production daily. It's just impossible to do that kind of thing if you don't have really, really tight integration. And I'd say even now, there's just a bunch of places where we don't have that tight integration across the team and you can feel that it's worse. And so that's the thing we're working on as an organization. But if there wasn't something like— if there wasn't a public health thing happening that really, really compressed feedback loops, it wouldn't be obvious to anyone what the advantage was, right? Because otherwise it would be like, You do a thing and take a few months. So, I think what that brought us was it helped us keep a bunch of promises. We made a bunch of predictions about what would happen, what Carbon could be, and then we became those things. So, the stuff I'm excited coming down the pike are now taking that deeply integrated thing and applying it in a bunch more places. So, we have a bunch of stuff coming out around software, hardware, service integrated chronic care programs for people with diabetes, hypertension, asthma, et cetera, that I think people have built pieces but no one has built the whole thing before. And, I think that combination will really make a difference in helping people get better. And, that's kind of the promise we're making and we'll just see if that ends up being true a year or 2 years from now. This goes back to that feedback loop thing. Now, we have It's going to take years to know if this stuff is working. So that stuff's pretty exciting. I think another pretty interesting thing is we scaled the team super fast over the last 2 years. And as I mentioned earlier in the chat, Aaron and team built something with a really incredible surface area. Just literally every day I learn the product can do things that I didn't know. I'm just like, oh, we do that here? So the second thing that's really interesting is it's taken a little bit of time for teams to get up to speed on all the stuff that we can do and all the stuff the platform can do. And that has— now the team is in a spot where we're operating and making progress and it's just improvement by 1% every day or whatever you want to call it. And one thing that's pretty exciting is now seeing Starting to see people who are good and also have context on the system that they're working on start to execute faster and faster. So, I'd say the second. And then I'd say a big third is, at heart, the atomic unit of value we provide is not software. The atomic unit of value we provide is a patient and a provider interacting around their care, like a patient getting better. And, a thing COVID did was it really held back. There's just lots of people with sort of untreated medical conditions out there that they suppressed because they didn't want to be in a hospital during COVID or didn't want to go for a checkup during COVID And, I'm excited for and our teams are excited for, Carbon now is— when I joined Carbon in 2020, we had, I think, 7 clinics.

Wow.

And now we have 120. And I think you will actually see from a clinical perspective and a patient getting better care perspective in the places where Carbon is in, I think you will actually see us making a difference. And that's pretty awesome.

Kind of building off like the things that you're excited about, how do you think about companies winning with their second or third product or product lines? You mentioned there's some full-stack integrated, like, care solutions that you all are thinking about or something like that. And then at Square with Cash App being sort of one of multiple product lines.

Yeah.

So how do you just think about, like, multiple product lines winning and how PMF works and scaling, et cetera?

Yeah. Yeah. So again, N of 1. I think it's a lot about the way you set up the team. You know, we'll— we're replicating or not replicating. Like, I've seen this dynamic play out again at Carbon, so we'll see if it ends up being true. I think it will. But there's a way that companies try to do stuff that's— that like companies try to do stuff as they get bigger where it's like executive-driven and the executive thinks about it as, oh, I just got to add a couple engineers to this thing. I don't know if you guys have seen this. It's like a funny Twitter account called like Tech Executive Emails that has this exchange between a couple of the folks at Google around the YouTube. acquisition. It was like a year before they bought YouTube. And I've definitely fallen prey to this. And they were debating like Google Video versus YouTube. And one of the guys in the email said, he was like, oh yeah, it looks like they have like, you know, something in JavaScript. We just need 1.5 frontend engineers of time and we'll like beat them. And I think, I just think that like, that thing is, that approach is just like So much less likely to work versus there's somebody in the company who's a strong executor and has a strong vision and opinion about what should happen and they drive and you build a team around them as an anchor. But it's not like the exec team says, hey, let's do X, and then they assign some people to it. It's more like this person says— this person convinces the company that this thing needs to exist. And then they go out to prove it. And I think we have a couple things like that at Carbon. Cash App definitely was that. Cash App was like Robert, Brian, Bob Lee being like, doing some experimenting, like some hack week stuff, and then being like, oh, there's something we could do here. And building a strong, distinct culture, product, ecosystem approach to marketing. I think early on they were like, oh yeah, we're going to leverage Square's distribution. And they're like, no, that's— we ended up discovering that that wasn't going to help us build a consumer ecosystem. And then we built a distinct sort of flag for ourselves that was separate from Square and obviously benefited from the resources of Square as an organization, but not as a product. And so A way the companies try to codify this, you see it now with Block has broken out into, hey, we have these business units because they're bigger and mature. You see it with Alphabet and you see it with Facebook, Meta, et cetera. And I think it's codifying that. I have a hard time believing that at scale, a company that is at scale and employees are comfortable trying to set up a new, a second or third product line as a side project. to, as a side project, like hanging off something else. I just think that's like always less likely to succeed than like a focus group of people. I hate the phrase like a startup within a startup because I think it's like garbage. But I do believe that like, I forget who told me this. There's this, so I think it was Brian who said, he was like, hey, I think at some point Google Pay like launched a P2P thing. This must have been like 2015, 2016. And I remember being in a meeting where somebody was like, well, how are you going to compete with Google? And then I think Brian was like, do you think like the best people at Google are working on Google Pay? And I really— and, you know, we could argue about like whether the Cash App team is the best team at Square. Like, that's— it's not as important as it's a focused team with an original vision. And like, it also might not work, but it's a hell of a lot more likely to work than like a like a, hey, let's just assign a couple of engineers to this thing, which I think is like the way a lot of— I think the default way that a company likes to think about it is like, hey, let's just assign a couple of engineers to the thing. And I haven't seen that work. And I think if you look at, for example, the way Square's executed its developer strategy, it's followed very It has suffered from that problem.

Ayo, I want to be mindful of time. Thanks so much for coming on Execs and sharing a lot of thoughts on building a product org, growing as a product leader, and integrating with the rest of the team. Really appreciate you coming on.

Awesome. Thank you both for having me.

Awesome. And any great entrepreneur would be lucky to have Ayo on their cap table. He's a fantastic investor and advisor to companies. Thanks so much, Ayo.

Yeah. Yeah, my DMs are open. DM me. Excellent.

Okay.

Awesome.

Thanks.

Thanks for listening to today's episode. Execs is produced by On Deck, where top talent goes to start companies, find their next roles, or invest in their careers. If you're looking to start a company, uplevel your career, or navigate a career transition, I encourage you to visit beyonddeck.com. See you next time.