#97: What it means to be a forward-deployed product leader | Chase Schwalbach (SVP Product & Technology @ Millie)

All right, we're live, Chase. Really excited to have you with us. Thank you. I'm excited to get the group back together. Welcome. Welcome. Yeah. People probably would not have any way of knowing this, but you were the facilitator in my first Supra cohort with all the early stage heads of product, and I really enjoyed you as a facilitator, and I suspect you're going to do a lot more talking today than you did in those sessions as a facilitator. I always talk a lot. I mean, it's hard. No, what I loved about your facilitation style is you did not shy away from participating in the conversation and bringing your experience to what we're talking about. So you were not just trying to blend into the background. I think you were part of it. So I really appreciated that about you. Yeah. I mean, Chase has done the thing a few times. So yeah, he has a lot of wisdom to share. For sure. So yeah, I want to kick this off with why we're excited to chat with you. So you recently shared some stuff with me and Mark over Slack that we thought was just this could be a really interesting conversation. I personally had a lot of curiosity, kind of like light bulbs going off, and I wanted to save them all for the recording. But you mentioned to us that you recently had, I want to kind of just paint the broad strokes and let you really tell the story, but like you recently went very deep as kind of like rolling your sleeves up, I see, even though you're the SVP of product and technology at Millie and did, you know, we jokingly started calling it. It's almost like you're like a forward deployed product leader. You went into like a new space, figured out a bunch of stuff, tried to protect or shield or just like isolate the rest of the team from like the messiness perhaps of that very early stage. And then when things got to a certain threshold, brought the team along. And we just want to, I want to dive into that story because I think a lot of product leaders potentially find themselves in a boat where they could see the value of doing what you did. And I want to maybe give people something actionable to go with. But how does that sound for how we spend the time? I just kick off. Yeah, love it. Cool. So yeah, what, what, what have you been up to? What was that whole, that whole project? Yeah, I mean, I think we've got to go back to even explain it. But you know, I've, I've been in product for 15 years. I was briefly an engineer before for about three or four years and then went into product because I like talking too much for most engineers, I think. And I was always on technical product. And then the last two stops were really technical. So setting up data warehouses, it was all kind of about data for me in my last two stops at pretty enterprising companies. So Databricks and Kubernetes and all this crazy stuff and not, you know, just kind of far away, but very hands on kind of architect role. You know, at Millie, I, they reached out to me four months after my first child was born. They had no idea about our story. We had had, you know, a really rough birth. And it was one where I thought the, you know, monitoring of my wife's situation and the feedback and everything else was ignored and not escalated properly. And I thought the rough situation, which is better now, so all good or as good as you can be from, from some of this, but I thought it could have been avoided, right? And I was still on paternity leave. I wasn't planning anything, but it was something that was in my head. And I got a call from a recruiter and he was like, you know, we're trying, you know, the founding story is the founder had preeclampsia, self-diagnosed, doctors tried to say no, went to the hospital and basically saved her own life, right? And they were like, are you interested in this kind of thing? And I was like, you have no idea. So you know, stepping in there, I learned that they really were focused on business model innovation in the early stages and data. So that was really all their focus. It wasn't tech enablement nearly as much as, as it was like making sure that they were doing this the right way operationally. So there was a lot of manual work, but it was all kind of data driven, but you know, super classic excels and everything else. So they reached out for me and our head of engineering to start building. So pulling all of this into databases and everything else. Because before you got there, like what was the, like the business or the service they provided? Was it basically just monitoring of the pregnancy and a little bit more hands on or? No, I should explain that. You're right. You know, we run women's health clinics. So we're front to back. We partner with hospital systems who currently in something like a low risk birth, try to use OBGYNs who are extremely expensive and not available. And we're moving that towards a more of a midwife led model. So that's our, that's where we started was maternity patients. We have our own clinics. We operate them front to back and we help with delivery in the hospital setting. So we're partners with a hospital, but we're kind of doing all the marketing and bringing in patients. And then we've got the full nine month, 40 week episode with them. We've expanded into gynecology and we're expanding into more clinics and everything else in the meantime. So what we were doing kind of before he came was just being really good at the operations. So yes, you know, instead of using Epic for inbox, we're using Zendesk, we're using Slack, we're using the basic tools that actually don't infiltrate most healthcare systems. The outcomes data was everywhere. We did have a very strong mobile app. So that was kind of the big tech differentiator was all about like a mobile app experience where you could do your own blood pressure monitoring and check for things like preeclampsia, which was, you know, again, our founding story. And that was all really built out by a external team. So it wasn't connected to our operations and our operations was running very just traditionally. And that's kind of where I came in was to tie these things together and start building out the operations in a scalable way. Right. So it's kind of do the things that don't scale. Make sure, you know, our NPS is high, our patients are happy. We're saving money for the healthcare system as a whole. We're saving money for everyone and they're having a better experience. We're having better outcomes, less NICU rates, less C-sections, et cetera, et cetera. So they were working on that for three years in their first clinic, started scaling, started to bring in the tech in-house. So that was kind of the story of when I came in. And then from there. So kind of getting in the forward deployed PM thing kind of. And you've been at the company almost a year now, right? About a year? Yes. Almost a year. Yeah. Almost a year. So I spent that first six months doing the healthcare stuff that sucks. So HIPAA everywhere in a bunch of new places where we hadn't needed them before. So, you know, getting all the AWS set up, all the Databricks set up, HEX for analytics, getting that HIPAA compliant, everything else, moving all of our data to one place. So moving where we still had Sheets, moving that out, moving Zendesk into something that was actually a database, setting up the Fivetrans and getting those HIPAA, you know, just all of the infrastructure probably took four months. Like no customer facing, like no changes to like customer experience or user interfaces for that period. Nothing done. Yeah. I mean, I think that would be one of the things that I would, will hit on a lot is without the infrastructure there, if you're set up in the kind of old school way in healthcare with Epic running everything and security departments being, you know, the top dog, you can't experiment because there's no such thing as a staging or a sandbox environment in those worlds. Can you talk about Epic? What is Epic? Oh, sorry. Yes. We're not on a healthcare podcast. Epic is the classic electronic medical record that almost everyone uses. So whenever you're in the hospital, they're typing into Epic, which is a huge monopoly now. And yes, there's others, but it's almost always Epic. So that's where your doctor is saving your official record. They are, they don't play nice. So they don't want to let you get data out. You had to rip out Epic and kind of build, replace it with your own? It's actually the opposite way. So we're kind of doing duplicate work on the front end with modern tools and then entering that into Epic. And the thing that you'll hear me say a lot, if you talk to me in healthcare, is that the Epic system is a billing system masquerading as like patient care. So it is really optimized for getting billing codes so you can submit those to insurance and Medicare and doctors mostly don't like it. It's not really meant for like delivering the absolute best care. It's just not where it makes money, right? Having a quality score of 92 or 93 doesn't matter. What matters is you got the billing codes right and got reimbursed. So we actually have a lot of frontline tech that we've put in front of Epic. So scheduling is a big one, intake forms and getting information from people is a huge one so that we can send SMS reminders and things like that. The mobile app is a big one where now we're getting a bunch of data in. Now I'm putting AI on front of all of that so that all of their history and memories with us are kind of stored and then it'll be the same actually with transcription. So ambient charting is a big thing where you take a transcript, it listens and then it puts it into the chart. Since we partnered with hospital systems, they'll all kind of use their own Epic instance and no Epic instance is the same. So it's not like they have an API. Each one is central to this hospital and requires a very large implementation to do anything. So instead of trying to use these cool ambient charting tools, I'm just going to record it. So we'll already have to consent people for the recording. I'm just going to dual record it so I can actually use this data because we'll never get it out of Epic. They have no interest in that. So it's like a dual technology layer. Yeah, it's almost like I think of Epic as like a little bit of Salesforce, but like way more gated and way more custom, like just people really customize it and one of the benefits of Epic is you can share like electronic health records across hospitals too. So there's like some benefits there as well, right, that you can just get information from other doctors or clinics. There's like data portability kind of like implications that make it make it very easy. Yeah. But it sounds like the biggest like, and I know we're not doing a deep dive on Epic, but this is helpful to kind of get the framing is like, you came into the picture when that abstraction layer on top of Epic, or I guess like the front end layer on top of Epic didn't exist is what it sounds like. Yeah, there was pieces there, but we weren't tying them together. We weren't utilizing Macross, but we were doing scheduling outside of Epic, for example, which was kind of core to us. Got it. And then you mentioned there was like an external team that was building like the mobile app, for example. That's like, is that like a dev shop or like an agent, like an agency? Yeah, they were here before me. So we had kind of a static mobile app with, I'm downplaying how good it was for health care and still is, but it's, you know, kind of just shows your week by week pregnancy. If you have any kids, you'll know there's a bunch of these apps, shows how big your baby is or whatever else, but it also showed some articles and things that we had built. So we had spent those three years building out thousands of pages of documents. Every time we got asked a question, it would basically go into some document as an answer somewhere. I don't think the team, I mean, the team definitely didn't know it because LLMs weren't around, but the idea of like a knowledge base for vector databases and AI to look at wasn't the reasoning. It was just operational efficiency. But that, along with hundreds of hours of YouTube videos, are all these resources available in the app. And every time we kind of went down a path where every time there was a question, we were like, we have to put it somewhere so that we don't have to answer it again. And what happened? Everyone stopped reading everything. So then we were back to, okay, now everyone just assumes there's way too much and just ask. So now we're back in the hell of answer everything. And that's kind of where I came in was we had had a great mobile app, all these resources being utilized. It was being, you know, people were logging in, 90 plus percent of people were logging in, but we were still getting a lot of questions from certain subgroups that just had no interest in really looking every week at all the information we were sending them because it was a lot. Some people, it's a persona thing. Some people love it. I was one of the people who would have loved it. Some people are like, I'm not reading any of this, you're just going to have to tell me what I need to know in the appointment. Yeah. I mean, I think in a way they were very lucky to hire you because I think, I don't know if everyone would have had the foresight of like, hey, we need to create this fund. I know we're moving to this future where everything's going to be, you know, like LLM power and there's going to be a lot of advantages to having agents taking action on top of valuable data. And even though it might be counterintuitive to spend in the first, you know, as a head of product, you probably won't have impact right away and spending the first six months just building foundational and not having any customer outcomes to show for. And it might be perceived as a risky move, but you know, now as you're sharing it, it's like, it's like a very obvious first step, right, to then the velocity that it unlocks later on is huge. So it's interesting. Yeah. Yeah. Absolutely. And did you know that was going to be what you spend the first four months on or when you took the job? No, but I did before I joined. So I took the job and then there was a thing that popped up around a large data input we were receiving and the previous CTO. So I'm over engineering AI and product, which is why I'm doing this infrastructure stuff. Most product people would not obviously do that. Reached out and I said, you know, just load it into your warehouse. Like what do we have? Snowflake? And he was like, we don't, we don't have any. And I was like, oh, okay, well, that pretty much lines out my next couple of months there, doesn't it? Because that made me realize, you know, data was in multiple places, not stored in one, you know, in one area. It's probably all in HIPAA compliant silos, which is just the classic death knell of AI and healthcare right now. So I was like, yeah, I'm going to spend all these months with vendors, convincing them to give me data, usually paying them a bunch of money to get data out because they all have special tiers for healthcare to make sure that we get screwed over as much as possible. So that was, you know, just all negotiations and everything else. And yeah, I did figure it out before I joined, but not whenever they talked about the mission, it didn't matter what my first six months were, right? Like it was just, I'm going to join this and tell me how I can help. I'll do it. Yeah. And it sounds like maybe they got even a little bit lucky that you had that experience before, or are they looking for someone that had that like data warehousing and like infrastructure background? Because I feel like in a way it was like the perfect storm, but I'm wondering like how intentional they were about that perfect storm where they just got lucky that they found you and when they found you. Yeah. I would say that they had about 70% of it. I'd say they had about 70% of it. They actually interviewed, so we were merging with CVS at my old company and they interviewed like three people from the leadership team on the product team. And they actually kind of adjusted towards my vision as we talked because they weren't sure they were kind of interested in the AI world and how PMs and tech were merging, right? That was like one of the hypotheses is it doesn't make as much sense to have like a super hardcore tech leader as your main leader anymore. It might make more sense to have that be a product leader. So they were starting with just pure product. And as they went through the interview, whether that was from my peers, you know, and their answers were mine, I don't know, but they went more towards like a technical product leader that someone who's been in architecture and been doing this for 10 years on the technical side and from an engineering type background. So then I think I just sold them on the vision at that point, but yeah. Do you, I think there's also like something very interesting here about like the rise of the like technical product leader or like CPTO, like I'm seeing more and more of that role too. And do you think, do you think it's more kind of essential to have that role when in a situation where you have like a very heavily operational business where there's no that capability but you have to move quickly and build or versus like maybe like a traditional tech SaaS company that already has like really good like engineering talent. Like do you think that's where it makes the most sense? Like do you have a sense of there of like, when does it make sense to hire that technical CPO versus maybe someone who's not as technical? Yeah, this has been a crusade of mine for five years, 10 years. So, you know, I went from a world where I thought products should be separate and that lets us be the arbiter of all the different groups, right? So if you're under tech, then tech always wins. You do too much, you know, moving, what is it, moving the deck chairs around on the Titanic as it's sinking, right? So just tech dead all the time and, you know, just for no good reason, they don't have to prove themselves, right? So it was just a huge, you know, you must keep them split. With that, I ran into all kinds of issues trying to fight for that. And then I kind of led to technical PMs being underneath technical orgs, but keeping product out as like more of a growth product marketing type function. And then I've kind of switched it and actually just said, like, this idea of the CTO being the absolute top person is starting to go away because you can hire proper infrastructure people, you can hire them, they're going to be expensive. I'm not suggesting not to do that. You absolutely have to have really good people who understand tech infrastructure and things like that in a scaling environment. So you don't need the head of technology and product to be someone who understands every single piece of that, but you don't want them to be someone who doesn't understand anything technical or you're not going to get the right kind of technical leaders is my opinion. So you're going to end up in a world where they're like, my boss doesn't know anything about my world and doesn't impress me, right? Your best technical leaders want to be impressed by learning something, right? And if it's just learning how to do TRI tickets, which I'm being a little blasé, but they're not going to be interested. So I've kind of went full circle to pull the group together, hire a technical product leader. That can often just be a fully engineered person forever who's just always been very product focused. That's fine. But I think it's, you know, somewhere that they're closer to the product because there's a lot more feel, right? So I think we've all seen the, the, what's his name, Rick, the guy who does the vibes and Rick Rubin. Yeah. We've all seen the Rick Rubin music, you know, vibes thing. And that's what's happening in the world is everyone is coming with prototypes. Like your marketing team is all of a sudden showing up with a mobile app prototype. And you're like, what in the hell are you doing? Like, why are you doing this? And I think it's starting to be like, okay, we've got a lot more ideas and we've got to, we've got a lot more velocity now. So it's not so much about like, how can we find the time for the engineers? It's what ideas should we work on? And I think that's something that you've got to have a product minded person to help guide that now. Yeah. I mean, if you look at parallel universes of like, let's say they hired someone who was not as technical as you, there's a world in which they start byte coding on top of your infrastructure. They build a bunch of stuff, maybe they deploy it. And then maybe a year later, they're like, oh shit, this is a mess. We can like, that we're spending a lot of money on tokens because our context is messy. It's unreliable. And then you basically just wasted a year of work. But if you have someone like you who knows kind of like the importance of having a good data warehouse and moving everything and getting everything organized and kind of also, in a way too, I think in this case, like a good example of like domain expertise is important too, right? Like you understand like the ins and outs of HR systems like Epic and kind of what can you do, what can I do? Like, yeah, it sounds like you can get to the desired outcome much faster, even though maybe the start looks a lot slower and less exciting, which is cool. And you're avoiding a bunch of pitfalls too, like PHI leakage or huge problems whenever you partner with a group that has a full audit team and they're just like, absolutely not like none of this is going to work and you've got to start all over. And one of the big things I talk about is institutional barriers in healthcare. And if you go down the path that sets you down one way, it's always hard to reverse it back in healthcare because you start layering on things and these HIPAA requirements and everything else and you add a bunch of risks to go down a different path. So you end up just building Frankensteins on top of the original path and then you just get worse and worse. And that's almost every healthcare system looks exactly like that. They basically started on sheets of paper, they moved it to Excel and that's how they ran their operations and they built a whole healthcare system on the Frankenstein of that and it's just not scalable and it's security systems everywhere because they have to be because there's so many holes. So it's so easy to screw up. Okay. So to bring us back to our main trail, because I'm really curious, I'm really curious about it. So how long would you say it took you to get to that point where you felt like the basic, call it pre-work for or the prelude was complete for you to actually get into what you might consider the more fun, the fun stuff. Was that like four months you said? Yeah. I think it was about four months of vendor and all that fun stuff. Now while you were in that initial four month phase, were you starting to have some kind of like thoughts popping up in your head about what the priorities should be once that phase is complete and kind of like aligning with, I guess, like the CEO about like what the priorities are? Or did you, were you like super heads down for four months and didn't even get much time to think about that until after? Oh, we were absolutely, we were chatting about it constantly. I think it's hard to realize what a year ago looked like, right? So I started building kind of an AI agent on a tiny subset of our data in Databricks using their AI. And I asked it, what's the clinic address? And I responded with a made up address. And I was like, I mean, this is probably March or April of last year. Like this is not a long time ago. It was, I think it was a llama model because we didn't even know that Llama 4 was bad at the time. And I was like, oh, okay, this is my first experience. I have a bunch of data science experience, but none of the new LLM stuff. And I was like, this is very far away, right? We're not even going to get close. So I actually had to spend a lot of time working on AI frameworks and figuring out which ones were best. So you've got, I'm using Agno is what it's called, it used to be called FyData, but you know, you've got your link chains and all these link groups, and then you've got a couple others that I forget the names at this point. But I went through a bunch of those and I was testing questions and I was doing that in the public. So in our public Slack channel, so people could see responses and they were seen as it was growing. And that led to all kinds of ideas. So I was really building where our ops team could see it. Just to interrupt for a sec. So if I'm, if I'm like one of your teammates who's in that Slack channel and I'm, and you're like doing testing, am I literally just seeing like question, answer, question, like that's one thread, question, answer, that's a new thread. And then people can chime in and be like, this is wrong. This is wrong. Or like this, like that channel started just getting a lot of like side threads going on. Yep. And that's how we're doing it to this day. It's basically like a. In production. Yeah. It's basically like eval, like an eval, like a team eval channel where basically like everyone is like basically grading the output and calibrating based on that. Yeah. We've got front desk pinging operations, operations pinging clinicians saying like, Hey, is this still, are we still doing this prenatal test? Right. And it's like, Oh no. And they're like, why is it wrong? And I go and do a search, which now I've allowed them to do a search of our vector database and it's in our database somewhere because some old blog on all of these resources aren't updated. Right. And then another thing you have to talk about is your content management system needs to just be set at once and, and use it everywhere. And you've got to work on these like deep set of evals, especially on things you expect to change so that it, it flags it. And that's just a world that was just, we just have the resource and it just goes stale and you have no idea until someone complains about it because they showed up the wrong office. Right. Yeah. I mean, you kind of brushed off this part, but I actually think it's really interesting. You basically, what you just said is that you basically taught yourself how to run evals and how to like set that whole system up, basically on yourself, like you taught yourself that. And as someone who has been meaning to get into evals and just feels intimidating, I'm curious, maybe you have any words of wisdom of how you taught yourself and how was your approach? Because I think that's pretty unique. Yeah. And what did you think it was before versus how would, what do you think it is now after having kind of done it? But yeah, very curious to learn. Yeah. I mean, everything in my career is like, I just go do it. You know, I would say that like I'm a, I'm a builder hacker and I build it and then I build it. Right. And it's probably the first build it part is takes a lot longer than building it. Right. Because I'm just like spraying. So, yeah, I mean, evals coming into it, I thought were kind of big company BS. Right. So it's like, you know, okay, this is just another set of tests. So whatever. And then I first tried them and I was really sure it was big company BS. Because it was kind of interesting. Like if you just ask your first couple of questions and you get a response, it's all it's doing. It's a really simple loop, right? You, you ask your agent a question, you get a response. That response is compared to a response you wrote out and it doesn't have to be the exact response. Right. So a great example is I had a eval, you know, I go one to 10 is how I asked the agent. That's the eval agent. And I was getting a bunch of sevens on appointments, which should just be like a, almost a one or a zero. And my eval criteria said it should return a list of appointments. And my test account ended up the first appointment passed. So there was only one appointment and it was dean at four. It only returned one appointment, not a list of appointments. So like you learn like, oh, that looks really dumb. Right. And then you just have to keep working on that. So there's a bunch of different questions I have, some of which should be closer to one to 10. And I'm prompting an agent that says like, give it a one or a 10 and here's the criteria. And then there's a lot of them that my eval stick at, right, eight. And I'm checking between runs and between model changes and everything else to look for drift. But I don't really care that it's at an eight because it's just, it's always complaining about something. Right. Like some form, because, you know, again, it's looking at resources that are four pages long on what's a doula, right. Which is a birth helper. And I can't say what the answer is going to be. It's not deterministic. So you kind of just have to give general guidance and then say like, if it hits these three important points, it's a seven plus. And if it hits these other ones, it's an eight plus. And you kind of live with that. So I built out a fully custom eval suite that's looking at timing, how long things take to run the tool calls. So I'm running a suite of agents. So it's called a team of agents, the supervisor, and there's a bunch of sub specialized agents who all have their own context. Some of those can look up knowledge so they can go look at our vector database. Others can't. So others have access to our APIs for scheduling. So the supervisor routes, that person answers. Supervisor has an output model that is like the latest chat model usually, and it's formatting it based on their preferences. So the user, whenever they're onboarding is giving like, do you want concise, do you want medical terminology? And then as they're talking, we're saving those. So the agent actually goes and will save memories and say, hey, they didn't like this answer or whatever else. And they'll generalize that. So their next answer from that output model looks like that. So I have to go and look at that, right? Is it calling the right tools for the kind of questions? So in my evals, I've kind of got this huge dictionary that's like, here's the question. I actually format the question in like 10 different ways. So I asked Jim and I to give me, here's a question, give me 10 forms of this question that it wasn't just like, what's the clinic address, but, you know, what's the address for my appointment? Because, you know, AI goes and looks it up and if they don't look up clinic site, they might not find it. So you have to like, keep working on that. So it asks the question 10 different ways, it evolves based on like a bunch of subset of things, and then it's Now it's based on like a bunch of subset of things, and then it's got a bunch of questions on like more deterministic engineering type things. Like did it call the right tool? Did it return in a certain amount of time? Things like that. Or did it try to answer directly without calling a tool, which it could do theoretically as well. So that's eBowse. It's, I mean, I feel you just went from like level zero to like level 10, like the level zero being, hey, like where is the address of my clinic to like now like sharing this like full like team of agents with like multiple tool calls and different permissions. No, no, I mean, but it's pretty like, it's pretty cool to just see that evolution. And, you know, probably in, you know, let's call it like eight months or whatever. But it sounds like, I wanna oversimplify it in a way, but it sounds like the way you learned it was like, just start to get a lot of like input, output, and go through the cycle many times. And as you're running into an issue or something, like, hey, how could I fix this? Oh, maybe I need sub-agents because we're hitting too much. You know, we're like filling up our context window too much and that's hurting like accuracy. But it sounds like the way you build a muscle was like just running the cycle over and over again and kind of build, like continue to build that intuition. And as new problems will come up, go out into the world, look for a solution, test it, and keep tinkering. Yeah, and solutions I would look for, I slowly build out what mattered as well. So for example, the length of a response matters a lot. So really mediocre models have much longer responses because my, for things that looked at my knowledge base, because there was a bunch of useful information. So it would just return a bunch of useful information. And it was, you know, a mix of duplicative information or just kind of repeating information that didn't make sense to add because it was related to something else, blah, blah, blah. So, you know, I ended up adding that as a criteria along with all these different evals, medical sentiments. So just understanding like, did it respond with something that was medically serious? You know, I had an eval based on not just accuracy, but also sentiment of the response. And did it respond like based on this criteria, medical seriousness of the response? So I have all of these happening. And now all of these agents that were kind of trained as part of the eval run in real time. So every time someone sends us a Slack, it sends like new message, here's the theme. So also theme and sub themes are a big thing I used AI for to build out all of our Zendesk ticket themes. And I had to use AI for about 40 turns to get it to like a list of 12 themes of things we get. So yeah, each time we get one, it sends all of that with like medical seriousness. It'll alert us if it's super serious and all of that runs each run basically. So if you, I mean, you obviously have like a playbook that's running right now, seems to be working well, or at least like the system that you built out seems to be serving you well. What has like maybe surprised you about the way that the system is running versus the way you maybe thought it would end up looking when you were done, you know, when you were getting started? Like what are some things you're like, wow, like this is so obvious now that I went through all these iterations, but I had no idea that this was probably like the right way to approach this. Yeah, I mean, the first one is the thing we all talk about constantly, but it's just prompting. Intent is so hard with an LLM. And, you know, we would give these prompts for, you know, a scheduling agent and I would have to give it these directions and it would keep doing crazy stuff. And I'd be like, what's going on? And I'd go in and I'd look and I'd read the words and I'd be like, oh, I get how this could be construed in some separate way, right? So it's like, you have to like really look at every single word because you're basically building an engineering system. And instead of code, which is again, fully deterministic, it's words. And that's just a wild thing because, and unless you test it, you just don't realize because someone asked something in so many different ways. So like this really, I really got down this list because I hooked up our agent. So again, this Agno framework kind of hooks up to Slack automatically. It does the databases for me automatically on like my own Postgres. Nothing hits their servers, so it's all very HIPAA compliant. And I hooked it up to Slack so people could ask. And just the way my operations lead would ask, I'd be like, oh yeah, this is a totally valid way to ask this question. And it's totally failing because of the way I wrote this out. And I mean, and we're only 80% of the way there, right? We will see in real time failures from our patients. And that's why I'm so big on alerting and monitoring. And the app has all kinds of warnings and there's guardrails within the AI as well that make sure that it always responds with like certain caveats. And they have to sign off and all this other stuff. But I'm gonna keep seeing that and I'm gonna have to keep iterating on these prompts. So I think the biggest thing is just how literal a prompt turns into almost code, right? And you just can't be laissez-faire with it. You can't just say like, oh, you're a scheduling agent, like reschedule. It's like, no, you have to explain every single step and write out everything really thoroughly. If you're enjoying this conversation, please check out the links in the show notes to support the podcast. Mark and I do this out of love, but to keep it going, we also need your support. Thanks, and now back to the episode. Anything else that, because it seems like precision when it comes to prompting, super important. And I'm sure you've probably become a more precise communicator as a result too, because you kind of have to. But yeah, anything else that comes to mind? I think the biggest one outside of that was just how capable everything became since, gosh, I guess GPT-5. You know, it went from a world where we were gonna be very narrow in our definitions of what AI could do to increasingly expanding. And you know, if you even look at our clinicians and their use of something like open evidence, which is kind of the clinician version of chat GPT right now or the things that they're building in that Epic EMR system, it's really accelerating. So I think it's just a world where the possible just keeps expanding. And I think you have to build in the world that there are no limits, right? So whatever you think a limit is right now, it will probably be gone in the next six months. So whether that's through engineering and saying like, we'll never allow a PM to push a feature to production, or whether that's what your agent can respond to and say, oh, the architecture will always look like this. Just get rid of that. So that notion of knowing what's gonna happen is impossible in my mind. Like this is just accelerating too fast. How do you do that? Like in practice, how do you do that? Or how do you implement that state of mind that nothing is possible, right? Like how do you plan for that? Is it more just like a speed thing when you see like something that you go for it? Or like, yeah, how do you lift that value? Yeah, it's definitely a mix of things, right? I think the most important moat is speed. So a lot of focus on the infrastructure that allows you to move things quickly. So an example is like, I can't have pieces of my data not accessible. They all have to be in the same place. So that's kind of your classic thing that everyone says they wanna do, and they very rarely do. And I've got to have PHAI protections, so personal health identification, identifying information. And all of that stuff has to be built so that I can add it wherever. So I think infrastructure for speed is super important. And then I think how you build the team is super important. So we had a mobile app developer who was maintaining the app who got there and I started writing out this huge new AI feature to allow people to chat with basically our brain of our app. And I spent, gosh, six weeks. I mean, it wasn't a huge amount of time, right? Like kind of front to back. And I put out a 10,000 line PR or something like that. And he was basically like, I'm not going to review this. Like, I don't feel comfortable with AI in this way. And we had to move on. I was like, oh, cool. Like, this is a great learning for us. And I kind of had to push that on a very small team, but four or five people of like, this is gonna be the world. I spend all of my time reading amazing engineers from amazing companies and like, this is where we're moving. So if you're just someone who's not comfortable reviewing AI PRs, you know, AI driven PRs, you're gonna be in rough shape. So I think if you're a company that was around before LLMs with a large tech team, those things pop up, right? You've got this amazing leader who's maybe defensive, maybe worried about things, and they slow things down everywhere. They find a little small thing that is wrong, but you get rid of a speed up of five or 10X speed for an improvement in safety, or it's not even safety, it's more of like a user satisfaction of 1%, right? There's some small bug or something that happened. What do you actually think the right answer is to an engineer who is now starting to face a deluge of PRs with like massive numbers of lines of code where it's clearly coming from people who are using AI to code? Like, sure, we could tell that engineer they have to get with the times, but like, what does that mean to get with the times? Like, what should they be doing in your opinion? Yeah. Like, should they just not review them at all, or should they use AI to review them and compliment the review process? Like, what do you think? Yeah, I mean, we should be in the middle. So although I'm a very tech forward person, right, we should always find a good middle ground here. I can tell you what we're doing. So one, I'm breaking up PRs. So I'm kind of creating like a stacked PR with features. You know, they all merge into a main branch, but there's six kind of separate PRs that all have kind of a more core theme of what they're doing. That's not always testable because you'd have to go back to the old school engineering way of like really phasing things out and spending a lot of time on that so that you could test each approach. And I don't think that's worthwhile, but at least you have the code kind of in one place so they can understand like, what's this one doing? They can go look through that, take the main branch and test it. So I think a big one is testing, right? Use cases, test cases, things like that. We're using a lot more tests. So everyone I think talks about this, but you know, the amount of tests you can write compared to what you used to do are insane. Looking at those and understanding like, do these actually test the functionality is really important. And then, you know, I think the thing that we like to say on my side, one, right now I'm not, I'm being a lot more thorough with anyone who doesn't have an engineering background. So probably smaller features for anyone who doesn't and more of a idea board prototype for anyone who like has a big feature they wanna iterate on. We've definitely enabled that, but that's not really going to PR, right? That's going to like- You mean like a marketing person or like a sales, like an ops person? Okay. Yeah, even product that doesn't have like a engineering background, it's more focused on smaller PRs are perfectly fine. Changing some content, changing the look of something, simple stuff is always fine, right? But for something that's a huge feature, I'm usually leaving that to like, this is the sandbox, you're playing in it, you're showing it off, you're getting the idea out there. And then we can hand that off, right? The code might be handed off. Or it might be like, we're gonna start, you know, kind of from the scratch and do it with usually AI, but through an engineer, just because you can really get off track, right? So just how our engineering principles are in terms of scalability, if you don't know anything about that, AI can just start going down crazy paths and you don't realize it because you're not following the code as you're going. So I think our view is, can you say that I didn't write the code, but I stand by it? So that's like our big thing. So just to, yeah, because I think it's a really interesting question is like, what is the delta between like .pm that is not very technical and you, right? And like, why are you comfortable with merging like 10,000 lines of code to the main branch and why like it's a terrible idea for that non-technical PM it is? And it sounds like you think you still can probably understand each line of code and how they relate to the feature. It sounds like you might have like an understanding of like the pitfalls of like when you like, quote unquote, byte code an app, like scalability, security, like those are all things that are very top of mind of you, but it might be an unknown, unknown to a PM who is not technical. Is that more or less the? I think it's grayer than that. I don't think it's a terrible idea for a PM. And I think it's absolutely something that I'm teaching my PMs to get to a spot where we're comfortable with. So I don't think you have to be fully technical, but I do think there's a, I think for me, there's the same gate as anyone else. There's a senior engineer in that language that architecture, that app, that understands what we're doing has been in part of all these long-winded architecture programs or back and forth, and they're going to review things. Whether that comes from me or from a PM, I actually don't have a problem with, it's more about an expectation set. So for a PM that's like, what I don't want is them to be so worried about the feature going to PR ready whenever they're like, I don't know anything about that. I actually just think it's like opens their mind more to say like, what you're worried about here is what it looks like, how it feels, the user experience, and then taking that and kind of bundling it into what we want to build. And here's my prototype. And sometimes that really wildly different experience is actually not complex in code, right? It's a lot of front end code or moving things around, totally different experience, but actually the backend stayed the same. There's no security applications. That should pretty much go through. So it's on the engineer at that point that picks it up to say like, is this more of a review or is this more of a rebuild? Or did they kind of half-ass it, right? They demoed it, they stubbed a bunch of data because that's what they wanted to do. They didn't actually build the feature. So I don't think there's a huge gap, but I do think that there's the same wall either way, which is like someone who's worried about our scalability and understands it before it's going to production. Go ahead, Ben. So it's so interesting, because I'm connecting the dots to what we talked about earlier with the convergence of the CTO and CPO into maybe it's a CPO in the future that also oversees engineering or CPTO as a point in time. And what I was just thinking about is there is going to be a question at the end of this, but it was about how as the roles start to blend at the ground level, at the IC level, where a PM can put up a 10,000 line PR and the engineer still kind of is technically the person that should review that. And if they're not comfortable reviewing that, there's like a stalemate where like, like that's uncomfortable, right? Like that's going to be uncomfortable for, of course, basically everyone to iron out while that exists. And so my question for you is if someone is listening and they are kind of in your shoes as the product leader who's also overseeing engineering, and they want to build a culture where the product managers are empowered to operate the way that you've been describing, which is to take the initial stab at the prototype or even suggesting some production, like pushing a PR to be reviewed on the path to production. How are you thinking, like what would your advice be for how to like almost like think about what engineers should be spending their time on to make that possible? Like should engineers start to like spend more time on creating the conditions in which it's like safe for the PMs like push the PRs to production instead of worrying too much about what it means like review the specific PRs they have to right now? Like, or something else? Yeah. Yeah, I think that's, I think there's a bunch of important conversations there if you're, especially if you're taking over something legacy because you can't allow the way things used to be done to slow you down, right? It's just a new world. There's enough really smart engineers that I really trust that are like, this is, it's different, right? Since November, it's different. And just for context, not to interrupt you, but for context, like I know multiple product leaders who have come into new organizations and one of the first major observations is, wow, our engineering team is slow to like adapt to like this new way of working. Like, so I am hearing this question coming up a lot. Yeah, and I think it's a misnomer to say this. Like, I don't think this is true, but one of the things that I used to say is like, if your salary depends on something being true, it's gonna be true. And I think there's a lot of people who think that way, right? So I spent my whole life learning to write code in this format with these curly brackets and now something else does that for me and that's scary and I get that. And you know, I'm more of an abundance thinker, right? This is an accelerator for us. It's not something that we need to cut out a bunch of jobs, although for companies that aren't accelerating and aren't abundance thinking, they will be able to. There's never been an invention that allows us to build more things that did anything but add more jobs. You know, we didn't just build less, all we did was build more, right? We add tests where we didn't use to add tests. We add features where we used to not do them. All it does is open up more worlds, so companies can do more. So I mean, for that, I think the original question was just around how do we get, sorry, say that, I don't wanna say it wrong. It's basically like, or Mark, I'm curious what you were hearing in the question. Yeah, I mean, yeah, I mean, I think the question essentially was like, what should the engineers be doing to enable this world that you described, right? Where PMs are at the very least, you know, building prototypes in a sandbox in an ideal world, maybe they're even committing PRs to the main branch, right? Like, in other words, like the question is like, what is the highest leverage activity that the engineering team could be doing in this new world? Yeah, and I think that's infrastructure to me. So that's a mix of like hardcore infrastructure that AI doesn't touch, but also infrastructure of every repo. So how is it set up? How are we explaining it? So we're actually doing an AI week next week, and our engineers are gonna spend their entire time kind of looking through all of our repos, going through and understanding, what do we need to explain? What context does AI need about how we engineer, where our company is headed, our type of partners and their type of connections, right? So API versus there's a bunch of esoteric things in healthcare like FHIR and things like that. And they're just gonna go through and explain that world. And then you've got to do a bunch of setup, right? So what I want to avoid and a big pitch of mine is like, compared to other healthcare companies, they're gonna spend two years in vendor relationship to sign one model provider, right? And they're like, it's so secure. And in reality, like I can sign, I am literally using Vertex AI on Google, fully HIPAA compliant, but I can use like 30 different models, right? And I'm just able to switch between them with no vendor arrangement. So I think engineering needs to set us up for that. So the right tools, how's everyone doing it? Set up sandboxes, make sure that you're able to kind of bytecode a feature that has no chance of screwing something up in the real world, right? Make sure that all of your areas that are super sensitive, you're splitting up into like their own kind of functional areas. So you can quickly see, oh, what are you doing dealing with login data? Or why are you dealing with patient data here? So a lot of those things I think are super important, like the infrastructure of how we code, moving it from pure code to English sometimes is pretty important. When you say spending time explaining, sorry, Mark, just like a quick clarification. What it came to mind is almost like making sure almost every file in the repo has like a read me or something like that. The engineers making sure that any AI going and navigating the repo will know like the exact purpose and like context for like the files it might encounter along the way. Is that kind of what you're describing? Yeah, AI is getting better. So you have to do less and less kind of explaining because it's able to fit 17 files in its memory or its context window. And then all of a sudden, it's like pretty easy to find things. But a lot of these, they're searching, right? They're just running like a grep search on your repo and these big repos. And you kind of need to provide almost like an index for them. So you need to say like, here's how we store things, we named them correctly. So all of these things that were like kind of silly for a long time, I used to have so many arguments by engineers about misnaming something. And I even had a company where I just fully disagreed that they thought we should make a semantic model of the business world and write the engineering in that way. So like, the concepts were the same in the operations team as the actual code. And I was like, we are wasting so much time here. And it's kind of funny because I actually think that's really important for AI is like understanding what is going on and not just these weird names or these functions that are like scattered everywhere. You actually kind of have to put things together in one file, point and say where it's going. And there's just things to make it less error prone, let alone just context, right? What is this company? What are we doing? Where are we heading? What is our status? What is our stage? How many people are there? Are we letting PMs code, right? How should we do comments? How should we do PRs? All this stuff that you kind of just build a culture around and writing it down was a waste of time because it's like, we have a good engineering culture. Just follow it. You don't have to make an SOP for everything. It's really annoying to do that. This is your common sense or whatever, right? But AI has no common sense. Yeah, exactly. So now it's like you kind of have to do some of these things so that some of these companies that are super verbose are really well set up for letting non-engineers write code. And I think that's where we're moving as well. It's like a lot of time. So we're probably doing a quarterly AI day, which is just like clean up context for AIs and a yearly AI week where we're kind of just focused. Again, it's just, and I don't even know where that'll be, right? I cannot predict the future here, but it just focused on making AI work better for technical and non-technical folks together. Yeah. I mean, it seems like context engineering is kind of like the key bottleneck right now that I think a lot of people are engineering with, given that all these new powerful models have smaller context windows. And from my personal experience, I'm also struggling creating context that's like coding agent agnostic. That's like a whole other thing. And yeah, it's interesting. It seems like the world in which we're moving to most of the engineers are moving to work for the platform team. And the platform team is basically working on developer experience, engineering content, almost like they're working at a really high level of instruction. Yeah, and then like PMs and maybe other customer facing teams are maybe becoming like, eventually in a dream world, we'll become like the feature teams, right? That they're actually like building the front end and the thing end to end. And so I think that's like kind of the analogy that I have in my head. So it's almost like every engineer that's technical like is becoming like that platform engineer. I think it's every engineer who's technical and not interested in the product as much. Like most engineers are just becoming part of that feature team, right? So you've got product people with a great sense of things and they've honed that. And you've got engineers with a great sense of architecture, speed, how things scale and you throw them together, right? So you're both kind of working on something it's a wild world where you can have full on bake-offs with a product and two engineers all building the same feature three different ways. And like, it doesn't take any time. It takes three days to get it to there. And then that's how you build your PRD. And then you just go off that best one. So you can kind of create a model of human in the loop agents. This is what we do with chess, right? It's like chess is human plus AI is stronger than AI alone. So I think a lot of your engineers will absolutely be stubbing out some code and doing features all the time. I do that as an, you know, I, again, as a trained engineer like a lot of my, a lot of my feel for my favorite repositories that I've written from scratch or I'm super involved in, I will write out some of the code. So I'll just stub a couple functions in a couple of different places and point it to there to kind of get started and say like, you know, here's how I want this to go. And it can understand the flow a lot better whenever I lay it out that way. So I, you know, I write code as well. It's not just all vibe coded. Yeah, where my head is going now and Ben feel free to take a different direction is man, like how do you prioritize what to hire for? Because like there's so many dimensions that you can optimize for. And I think you're like a weird unicorn in the most flattering way possible. Like you are technical. You are, have insane domain expertise. Like you've been in this space for a long time and you are- Excellent hair, really, really good hair. Really, really good hair. Which is most important. Yeah, vegan, but we won't get into that. The only downside. But also you are, you're a hacker by nature. Like you're like, you're very quick. You're, you like to build things and you optimize for speed. Like you have like kind of that startup vibe too. And then you also like are like a very curious like self-learning, self-didactic like person, right? And I, those are all like, to me, like are like, wow really important skills to have in this new world that you're describing. But I think it's going to be really hard to find other chasers. So what are you optimizing for? Are you optimizing for like the technical plus speed? Are you optimizing for domain expertise? Are you optimizing for like open-mindedness to learn and use these tools? Also, as you answer that, can you just talk about how big the team is right now? Just so like set the tone. Yep, for sure. So for that last, for the, well, I'll start with the easy one, which is the big, the team. So we're small. We have two PMs, one engineer that's fully dedicated outsourced, one head of engineering and then like a half engineer and then a me who's, I spend 80% of my time as an engineer. So I'm closer to an FTE engineer than I am filling the CTO role. You know, I'm doing, I do fundraising decks and vendor calls and all these other things. But in reality, like I spend most of my time as an engineer. So something like three and a half engineers, two PMs. That's a wild ratio, by the way. Yeah, it's because our PM team is doing ops. You know, as we raise money the next time, what we'll actually do is take a lot of ops work that's touching technology, but it's really just ops work with a, you know, with a SaaS type front end. So this is the EMR speaking again, Epic speaking again. We'll put that more into ops and we'll do more product work. But yeah, a lot of the time is spent on ops, product ops. And product ops can stay around as product ops or it can go into ops. I don't have a strong opinion, but it's product ops is where a lot of our team is spending their time, even though they're traditional product people. To answer your other question, I think the last part you hit on about like openness, but I like to call it like misfits. So I usually just look for people who aren't really big into following the rules and what they've been given because the rules keep getting torn down. And in the world of AI, if you're someone who like really latches onto a way of doing things, it really makes it likely that we're gonna fall behind. So I think it's important, each role and what we need to do with it will guide my technical versus product mindset. So that's just role dependent. I definitely think we will have very few product people who don't have technical chops. So that just means like usually a technical product manager is their previous title. Some will be engineers. Those engineers might fill a product role, they might fill an engineering role, but they'll be expected to write code either way. And pretty much all of my product will be expected to write code. But in reality, what I really am searching for isn't your technical ability, because I think that can go up or down for the role. It's really just someone who's, I wouldn't say disagreeable because there's a lot of those too that are just disagreeable on purpose, but it's just someone who's always kind of been like, there's gotta be a better way to do this. And if you're searching on the internet, you find them a lot. And if you're searching on the internet, you find them a lot faster nowadays. As you're just talking, I was asking myself, is this like the best time ever to make the jump from engineer to PM? And vice versa, really. I think they're just molding. I think it's technical engineer, it's like product facing engineer and technical product. And that's like, you just put them together. Yeah. That's going to move the fastest. We kind of didn't go into it, but we just launched a big AI chatbot. And if I didn't build all of it, the mobile app, the backend, the AI itself, the handoffs and the time between it would have taken so long. And instead, I got the beginning of the mobile app running, I test it, I was like, that doesn't work the way I want. I fixed that, I fixed the scrolling, I then added an appointment viewer, and I just kept going. Which is why I ended up with 10,000 NPR. But it was like, this is actually the MVP that makes sense, it's something that isn't. But if I tried to hand that off in words, my first version that I built for myself, which I handed off in words to AI, was terrible. So it's like, you kind of need these full kind of spectrum people because the handoffs just kill you. So I think no matter what I want, I want engineers who care about the business, care about the mission, are coming to try to solve this mission and not just to build our infrastructure, although there's a place for them, it's just, you know, I'm talking about kind of this generalist person. I think you just got to be on both sides of it. And that's going to be the fastest way to do it. The other thing I picked up on that I want to kind of double click into if you don't mind, Mark. Misfits, like you call the misfits, people that don't play by the rules. You said something really interesting, which is like, if you're the kind of person that needs like rules to follow, you won't do well in this because things are moving so fast that like the rules are being rewritten as we're going. And that kind of led to a couple of thoughts or like maybe a couple of questions. First one is, do you think the people like the people who don't like following rules? Okay, how am I going to frame this? So much of what we do with AI has to be setting the rules for the AI for how to work. Right. So we want to be really good at explaining what the rules are for the AI because we actually do want our AI to be really good at following rules. Right. We don't want our AI to be misfits. Like we want our AI to be really good at following rules. So we want people who are very good at creating and codifying the rules and encoding the rules into the AI. So the first question for you is like, do you think that the kind of people who are really good at setting rules are like, what's the overlap between the people that are really good at setting like creating the rules and people that are like good at following rules in your view? So that's like the first question. And then the second question is, how do you evaluate the kind of like misfit vibe of someone that you might be interviewing and will still be good to work with and won't be like a like a ridiculous person to have around, but also as someone who's, you know, obviously like not shy about throwing away the playbook and kind of figuring stuff out without rules. Yeah, it's a really hard line. The first one I'll hit on is, you know, I think it's the same concept as a white hat hacker. So like, I think the best people at setting rules are the people who break them all the time and always find ways around things. Right. So, you know, that's not always, of course, nothing's always true, but some of the people that I've enjoyed working with the most are the ones who are like, especially for internal teams because you don't do so much white hat kind of thing for your like your product. You expect kind of people to use it, at least in my world, it's always been people that are using it because they want to. And it's usually health care, so it's like it's not someone just randomly from some other country trying to break my product. So it's usually internal and I'm setting up rules or whatever else, and it's like using my best people or the people who are like, yeah, I'm going to I'm going to try to get around this to move faster. And you know, that's what AI is doing as well. So I find a good overlap in terms of setting rules versus people who didn't like following them. Yeah. Yeah. Like in a weird way, like I feel like people that break rules and they understand the constraints very well and then they work like they're very creative from those constraints. Right. And it's from my opinion, it's way easier to be creative when you have constraint as opposed to when you're expansive. I think they're like really good at like kind of back engineering. Hey, here's how it works. Is that what you do given these constraints and these rules that I think I understand how the game works. Like, let's figure out like a system that allows me to beat these rules to get to the outcome that I want. Basically. Yeah. Yeah. The second one, there's there's a cheating answer and then a good answer. So the cheating answer is I've got a very long bench of people that I've loved working with that is probably going to be my hires for the next year, at least as we scale, which, you know, we'll probably plan on adding two or three or four this year, which is, again, in the previous world would have been seven, eight or nine. So we're definitely hiring less to do more work, I think, than what my roadmap would have looked like. So I've got a bench of like people that have either mentored me or I've mentored or stayed in touch with from a lot of startups. I think I'm on my fifth startup and I think four of those have been really great experiences. So, you know, I think I have a lot of people I'm interested in working with again. Then the real answer that actually is like scalable after those 15, 20 people is probably the thing I look for the most is just that you've built something random as part of your resume. So it's like you've just got this job that's like product, whatever, and it's like a line that I often look for is like my classic example that kind of got me started down this path was I was hired, I was employee number 90 at this company that's now a $10 million company and, you know, I was there for five years. But the first thing I had to do was all the other product directors were like, you're taking over QA. And I was like, oh, that sucks, I don't want to do QA. And I automated it, right? Like, so I just went in, old school automation, Python stuff, I was okay at it at the time. And it became a core part of infrastructure, much to the chagrin of our CTO, who they were named the Chase scripts and every engineer hated them because they came such a thorn because they weren't scalable. So I'm usually looking for that. I'm looking for someone, you just built something, right? Like whether it's like, and it's just something that you didn't, you weren't hired to do. So you found a problem and you solved it. So that's a common question I'll ask is like, tell me about a problem you fixed. And then I'll follow that up with like, tell me about a problem you fixed that had nothing to do with your job, because they usually have, they'll probably usually try to spin that first one has nothing to do with your job. So it's usually like, tell me about your favorite problem you fixed and then second one's like, tell me about another one that has nothing to do with your job. Even better if you answer that first one that had nothing to do with your job. Nice, man. I wish we had another hour. I feel like we're just like scratching the surface. But I think we probably should start wrapping. And so two final questions for you Chase before we hit our fun gratitude corner. And one is, what can people learn more about what you're doing? And if you do any writing or anything like that, and then two, like, how can people be helpful to you and Millie? Yeah, first one is I am starting to write on LinkedIn more. Not something I've done a lot. Frankly, it's a recruiting tool. Recruiting doesn't mean employees only. It means partners and people I want to work with. So I did write a big set of posts on our AI launch evals, how we thought about it, how we did it in healthcare and launching like fast but safe. So that's your best bet. I probably need to do a couple more. We can link to that. Yeah. Yeah. Cool. We'll link to that in the show notes. Yeah, I think for me, the way people can help is, you know, I just, like I said, I mean, I'm not really going to end up hiring a lot of people off the street because I have too many people I've worked with that I really want to bring back, you know, get the group back together. So I think it's other partnerships or just people who want to learn about it and stay warm if we hit the scale we expect, I'll run out of my bench faster than I expect. So I think it's people that are interested in, you know, women's health. It's an underserved area, especially in VC dollars over the years or maternity and are interested in, you know, being on the forefront of trying to make a difference there, whether that's partnerships or coming and working with us. Yeah. And we'll link to Millie in the show notes too. So if people are about to enter the maternity care space, you know, they should definitely check you guys out. Or if you need a set of midwives, I'm not expecting a lot of them to be listening, but if you're, you know, a woman who needs a gynecologist or a maternity center, then you can hit us up. We had a birth doula for when my daughter was born and I thought that was a helpful few weeks in preparation for the birth for my wife and I'm just like ask all of our questions and that was really helpful. We have a patient that's from a big tech company and she reached out and like gives all kinds of critical feedback and it's so much better than everyone else's because it's like great I've got a tech person. So if I can get some startup people to go to our clinic, then we'll all learn a lot together and push care. Okay. And then we have our final gratitude corner. So the question here for you is, as we kind of, you know, reflected on your journey to this point, it can be early career, recent, but like, is there anyone you can name, you know, multiple people doesn't have to be this one, but anyone that stands out as someone you really want to thank for the role that they've played and like your, your story? Yeah. So you, you've prepped me for this, so I was able to like prep, but this was the first thing that came to mind. So Una Pippich is my person. So she was my partner in crime at that startup I just talked about, that 90 person where I started and kind of started automating and you know, I think I came into it worried that I pushed too hard and I was too disagreeable and I was too much of a misfit and I needed to play it closer to the best, talk a little bit less, just go up the corporate ladder. And you know, she had had probably 10 more years of career. She was two levels above me and was my boss whenever I joined. And I think she really pushed me to be like, no, you're on the right path. Like you don't need to hone your edges. Like you definitely need to hone the edges and like find where you're going way too far. But in general, like keep going down this path. And I think it made my career at Tipus AI wildly successful in comparison to what it would have been her championing me and covering up my faults and yelling at me whenever I went too far. And you know, I've kept that spirit. So I've just never gotten rid of this kind of misfit hacker underdog kind of thing, even though I'm no longer pretty much any of those things. She just said like, keep it alive. Don't follow the rules. Don't, you know, just button up the suit, like just keep pushing and keep keep moving things forward or you're going to get bored to death. And she's one of my one of my favorites. Una Pipic. We will link to Una in the show notes. That's a great way to wrap this. Sounds like an awesome person. When someone that you look up to can tell you to be yourself, obviously to improve and clean up and tidy up the edges. Like for sure, I have a huge respect for people that can simultaneously encourage the strengths and tell you to double down on them and not to mute your strengths while also making you feel good about getting better on the things you're not as good at or things that could hold you back from letting your strengths shine. Every strength can be a weakness, as they say. Yeah. There's a shadow. But man, this has been awesome. I'm so glad we did this chase. It had been way too long since we hung out and I'm so glad we made the time and really appreciate it. Awesome. Yeah. Thanks for coming on. See you. Bye bye. Bye bye. If you enjoyed this conversation, please share it with someone who you think would benefit from it as well. We really appreciate it. We'd also love a follow or a rating on Substack, Spotify, or YouTube. That's going to let other people find us. And if you have any topic recommendations for a future episode, please send myself or Mark a DM on LinkedIn. We'd love to hear from you.