LaunchPod - Sarah Jacob Singh
===

[00:00:00] 

Jeff: All right, Sarah, welcome to the show. Thanks for coming on today.

Sarah: Thanks for having me. Excited.

Jeff: Yeah, we, we finally got this one on. It's funny, , we got like two thirds of the way through the process about a year ago. life happened and, and you know, luckily it only took us on our side like not quite a year, but maybe 10 months to, to pull it back together. So, really stoked to have you.

It was be a fun conversation honestly, I thi I think, you know, some cool stuff happened over the past 10 months to 12 months where we're probably even have a better, better show today than we would've back then

Sarah: I think that's right. A lot's changed. Really excited to be on today.

Jeff: Nice. so yeah, so I mean, for context, right? You, you've spent y you know, years and years in the health tech industry, , startups, IPOs.

Product rebuilds, everything in between, , just recently got elevated to being not just Chief Product Officer, but, CPTO. So chief product and technology Officer, over at Med Bridge. So congrats on that. I think that's kinda what we're gonna dive into is just the hell is going on with the product role here and, and why is it just keep expanding, expanding, expanding.

But before we dive into that, maybe you can just give us the TLDR and kinda like what's the path that led you to this, to this [00:01:00] role here?

Sarah: Yeah. It's a really good point that you made 'cause this role just continues to evolve. but yeah, I've been, you know, in the health tech space and really only in the health tech space for about 12, 13, 14 years at this point. My first real role was at a EHR startup out in Miami, Florida. Built the product team there, built some really interesting solutions while I was there. Spent six years there, really like, learned my product chops there. Had an awesome time, but you know, at that point everyone was talking about, moving out to the West Coast. Like that's where the real, products are built.

So I find my way to Seattle. I joined a, a great company called Accolade. In the employer space, which is a little bit different, no longer selling to providers, now I'm selling to heads of HR and very, very different motion. And it was interesting 'cause when I was at, I actually wasn't even on the product team.

I was on what's called a solutions team. And so that's really like taking the products to market in a new and unique way. So I owned the p and ls. I worked most closely with probably sales and, and product marketing, which kind of opened my eyes a little bit as far as, hey, like you can build great [00:02:00] products, but to really get them successfully into market, there's a a little bit more involved with that. And so we, we were, we went public when I was there, which was very exciting to see. Did a couple of acquisitions as well, which I had never gone through before. So lots of interesting experience at Accolade and it kind of gave me the itch to like go back into startup land. And so I went to a company called Optimize Health Startup out in Seattle, kind of built.

From the ground up built the team, brought in A-A-C-T-O friend of mine who's a brilliant guy that I'd known for a long time. He built the engineering team and we kind of, you know, ventured into this new space. And I did that for a little while before finally joining Med Bridge, which is where I'm at now.

Jeff: Nice. And then it's only recent that you, that you got elevated to the CPTO role, right?

Sarah: Great. 

Jeff: This expansion of a product roles is not really that new. I mean, you were, you were involved in go-to market.

Quite a while ago, but does the foundational piece of that come from? First of all, let's maybe just start from like, does it make sense? Does the theory hold water of these kind of roles as they have kinda more and more overlap?

Sarah: Yeah.

Jeff: you know, where's that come from?

Sarah: I think honestly [00:03:00] like what, what I've seen over the years, because I've had the luxury of being able to be at different types of companies at different stages. I really think it depends on the stage of the organization, so when I was at accolade and Optimize, for example, we were building brand new products from scratch.

And so I had go to market either in my org or worked very closely with it. And when I say go to market, I'm talking specifically about. product marketing and sales enablement, not just commercial org. And the reason that that's so critical and it became so critical is because you're building new products.

the sales team and the commercial teams have to know exactly how to talk about it, what it is, what makes it unique, how to objection, handle, what are the value proposition. It's not like it's a product that's been sitting there and they've been selling it for five or six years. This is brand new, so all of the messaging around it is new.

The storytelling is new, and so it's not enough to just kind of be siloed and build it. You gotta work with product marketing and sales enablement to make sure that. All of the great stuff that's being built is actually being delivered to the sales team in a way that you want them to talk about Right. And I, and I have found that that's really the only way to sell [00:04:00] successful products.

Jeff: I think we've all probably run into the world where the product is doing something and sales maybe isn't, we'll give them a lot of leash on this one and say maybe they just, they weren't enabled to talk about it. Well, or, or just, you know, wasn't communicated or something like that.

But like, I think we do tend to see startups, startups move faster, is the general. There's exceptions always, but in that world where you're moving quickly and, and you don't have, you know, a hundred million dollars of a RR under the belt to to kinda rely on it really is you gotta, you gotta arm 'em, right?

And, and so being closer makes sense.

Sarah: Yeah, and I, and I unfortunately saw it the other way as well when I was first starting out in my career at CareCloud. You know, I, I think to myself like, Hey, like we built some really interesting things, like they're not going anywhere. Like, why is that? Right? And it's because just the rest of the organization wasn't even aware of what was going on.

It's like we're just going through our typical product development lifecycle, releasing interesting things. But unless like there's a whole kind of org wide effort around. This is gonna be new. We're gonna put this in the field, we're gonna test some things out. We're gonna talk about it differently.

We're gonna, you know, there's so many [00:05:00] factors to launching a product. And so I, I learned that the hard way. And then, you know, ever since then I'm like, Hey, I gotta stay close to this group.

Jeff: Of the things that I, I feel like you're never prepared for. When you kind of move into more leadership roles is, I always thought I listened a lot when I was when I was coming up, right? Like, I thought I always paid attention and kind of knew the nuance.

And then you realize how much or how important it is in, in almost any leadership role that you have, like the three or four key things that you're saying. And just say 'em over and over and over and over again until you just wanna puke.

It's gonna filter down slower than than you ever think is. It will. And if you're not kind of like just sing the same message to sales, marketing, the product team needs to hear, you know, the go to market message and it all needs to kind of like full circle or else you're just gonna have teams kinda like.

Maybe the marketing team will get it one day and, and the sales team won't see. You'll have website messaging matching the product. so how did you, you know, did you ever find a secret? I just selfishly, did you ever find a a like solve for this

Sarah: You kind of nailed it with like repetition, annoyingly is key, but, but I mean, what, like, my weekly team meetings, [00:06:00] for example, is both the product and the go to market team. So we go through like, Hey, here's what's happening on the roadmap. Like go to market team, what do you think about this? And then they come back and they're like, well, this is what the sales team is saying about this feature.

So are you guys even building it right? Like, no, no, no. We are, here's how that, here's how you should be telling them, you know, how to use it. And it's just , the things that are lost in translation. What I always try to look for is instead of it taking like weeks or months to find out and resolve.

How do we just like shrink that time? Because things will be lost in translation no matter what, like that's gonna happen. Right. And so , the name of the game is like, how do you reduce that feedback loop?

Jeff: Yeah, and, I think, there's always ways to do for a little while. My answer to that was just. Rather than listen to podcasts, I, I just listened to. We we use gong and I just listened to Gong calls they gave me good insight into was the messaging, making all the way to sales and was the kind of core.

Product things. Because in our org, marketing's pretty attached to products, so that wasn't a problem. But it's more like, was it filtering all the way down to sales at the, at the end? And you would just find all these little knits of like, the big pictures may be there, but there's a lot of implementation.

But there, there was no way to do it. Now [00:07:00] ai, you can just, you know,

Sarah: So much

Jeff: feed it all through like some lm and have gong or have a chat PT be like, oh no, here's a call that didn't do it. Right. You need to.

Sarah: No, a hundred percent gong is gold. We I have my leaders, we spend like a day, a week, literally just listening to Gong calls. It's like so, so much easier now to pick out like, oh, okay. That's where the misunderstanding is. Like we need to enable them on this piece.

Jeff: Yeah. I, I, I think there's a killer app in there that, that gong's being close to about just synthesizing takeaways from every call. And like, how do you kind of surface the really, really important bits like log rocket for calls? Can you just synthesize the important bits automatically? So, one thing you, you said kind of, I, I think hit really interesting and I, wanna kind of double tap on it is, you know, you kinda talked about why, why in some works did you have to be closer to go to market? Why does product be closer to go to market?

And it was in startups where things are moving faster, you just, you have to and, I remember kind of when we talked earlier, you kind of had this angle of, of basically with ai, almost every org is a startup at this point. We're all rethinking, we're all racing, we're all [00:08:00] kind of, you know, trying to beat each other with a punch on, you know, taking breadth and everything like that.

Does that affect you think how companies are looking at this and maybe this kind of push where we're seeing more kinda expansion of this, of the chief product officer role, not just in go to market, but also into like other aspects as well?

Sarah: Oh yeah. I mean the, there's no doubt that. That , this new age of technology around AI is gonna shift all of that. And I think it could shift it right or left like from an AI standpoint, like our go to market team, it feels like they've doubled in capacity.

So that's been really cool to see. Just in terms of like. Like right now we're doing an ICP refresh project. Like the, the things they're able to now pull and put in notebook, LLM, and ask questions to, and figure out, pull the closed loss reports and see where we're winning. It's just so much faster and so that's very straightforward.

From a go to market standpoint, I think on, you know, the engineering side, like we're seeing huge shifts in the ability to just literally deploy code way faster. And what that means is you need more product support. Want more customers that you're able to talk to because you wanna hopefully [00:09:00] deploy customer features more frequently.

Right. It's really kind of a spectrum. I think about it as a spectrum between all the way, like product marketing on one side. Super customer facing, you're out in the field and then all the way to like the software architect on the other side, right? And then somewhere in the middle is gonna be this AI enabled product engineer.

And that's where I think the majority of the work is gonna get done.

Jeff: There's a guy who's on the show recently, I think his episode just published. Called AIA DeSay, and he's, he's traveled with us for a lot of, like the kind of product leader dinners we've done across the country as well. He has this kind of framework he's put out called The Three Speed Problem, which kind of talks about exactly what you were saying there is with ai, right?

Like you just are seeing, we're seeing an incredible increase in speed in engineers. Cause engineers suddenly are like unlocking stuff way, way faster. It sounds like you, you kind of have a system here , that you're working on of like, how do you though that throws up the whole balance of, of Right.

You have like product, like what do we work on? What do we build actually building it, and then how do we go to market? And if you speed up one element to that, where historically engineering was the limit. How do you rebalance it? 

Sarah: The whole thing is, is honestly shifting on its head and for me personally, like [00:10:00] I'm not an engineer, so. Being put in this role, maybe 10 years ago or five years ago. Even the expectation is like, okay, well you're, you're an engineer, right? And like, that's not actually the case.

you know, the Idea of there needs to be tension between product and engineering. That I think is a very outdated idea. in the age of ai. and only because of ai. Right. And I think that the reason that that's really changing, like before it used to be, okay, product comes with the business reason of why we need to do this, why we need to build this, and engineering will come with the how and then talk to us when things are done right.

But I think really how it was, you

Jeff: Yeah, it's not, you're not far off. It just, it is just funny to think about it now, like how far it already has changed.

Sarah: Totally. And even like the most brilliant engineering counterparts that I've ever worked with CTOs that are, have become good friends of mine. You know, I, I'll never forget things like, Hey, don't worry about the how, just, just tell me what you need. Like, I'll take care of the how. Oh. And I used to be like, yeah, okay, you take care of the how.

Like, I don't care. But I just think like that whole, it's just shifting on its head with this idea of the, of the product engineer because. My product managers are like, [00:11:00] Hey, like I could submit some code here, there's a ticket. For example, the customer's been complaining that , the text alignment is off horribly on this page.

Like, can I just fix it for them by the time I write the ticket and get it groomed in the backlog for the engineering team to put it into a sprint and put it in production. Like what? That's like weeks of waste of time. It's just things are changing. So, so what, we're actually doing a hackathon in a couple of weeks, an AI hackathon at Med Bridge.

All my PMs have their environments set up to be able to write some code, right? And the engineers are actually coming with some of the ideas we want it to, to flip it around a little bit, just to be like, Hey, we can meld some of these things together because we're just gonna have to be moving faster.

Like, we can't you know, our road mapping process, I, I call it the big bet framework.

And it's a several to multi-month process where eventually we land on a couple of big bets for the year. And I think with the new way that we're gonna be doing the things with ai, I mean, we should be deploying a big bet every week, every month.

Like, why not? the tools at our disposal are just not things that we thought we'd be able to have in the past. And so I, I really think that the teams are gonna [00:12:00] meld, the roles are gonna, are gonna change. And this idea of this product engineer. I bet, I would bet 10 years from now, like that is the primary position in r and d.

It is interesting on that front because you, on our end, I think, forget, our product, but how we operate has changed a lot in the same way where we have PMs actually shipping to production. Our designers actually are, you know, building prototypes

but not using like a love it lovable or rep, as great as those are. It's, it's you know, using cloud code in our actual code base. And what we found is like, right, the typical what the hip process was, product maybe worked with design. You build a flat Figma file, it just took a ton of time to build like one flat, you called it a prototype, but in reality , it's a flat image file.

Yeah.

Jeff: Yeah, maybe, maybe you did a couple, Hey, here's what it should look like. Kind of partway through the transformation or partway through the flow. Here's, but it, it was still just like. , The equivalent of making a video, which is storyboarding it. And we found now we can enable them to get in. We, we've done the work to train them on this and, and to build their skillset set up, but they can actually build the prototype, the working flow of the prototype in, in our product.

So it has our [00:13:00] design language. And we found the engineers can move so much quicker. 'cause a few engineers, you know, some engineers have great design sense and, and some don't. It's just not what they're optimized around. But by reducing that one handoff. We were able to move a lot quicker just because that design taste was able to move further through the flow natively.

And that's not even like right. You, I mean, you brought up PM shipping to code and stuff. We're not even doing that. This is just like prototyping still

Sarah: I think is, is a critical first step because usually either sat in design or God forbid, in engineering, right? So it would take forever. But if we could prototype, you know, in a few days and be like, Hey, this is actually what I was thinking and, and we're doing that now, like I'm seeing my PMs come to the table and be like, Hey, I built this prototype last night.

This is kind of what I was thinking. So first of all, back to losing things in translation. Now the engineer can be like, okay, I know exactly what you mean because I see the prototype. Here's where I see potential gaps, where things can get complicated. Because the engineer's time should be focused on what is complicated, not what is straightforward, right?

Like let us deal with the things that are very straightforward and then get the customer feedback. You can ride shotgun while we're getting that customer feedback and then see where things are gonna be complicated. And you're right, like the [00:14:00] time to production then decreases. Exponentially, and that's what's so exciting to, to think about. 

Jeff: I love how you put it there, because I feel like that's, everyone kinda talks about like, oh, we're doing more prototyping. You know, engineers have to do less, da da da da, da. It's very easy to kind of. Get lost in feeling like engineers are being minimized or see where engineers go. Like, no, no, no. AI coding is stupid.

That's bad. It's not real coding. And, but it is. But I, I think you brought a really good point. It's, and we've done this in other parts of business. It's just a matter of like, there's still a lot of really, really hard problems where you need deep, highly skilled engineers and just 'cause that bar moves where now some things are easier, that's great.

Now you have more time to do the really hard, interesting problems and let people who don't know it as well take care of some of the simpler stuff and like, you don't have to waste your time on it anymore. It's

Sarah: And that's, and that's what they're, that's what they're good at, right? And that's what they wanna solve. They wanna work on the tar problems. And one of the other things that I think is underrated in this whole thing too, is like they are dying to know how their products are being used in the market.

Like, how are customers actually feeling about this? Like, are they utilizing it? Are they using it the way that I thought they were gonna use it based on how I built it? Like that [00:15:00] feedback loop also now becomes smaller, which is exciting to, to bring them into the loop on.

Jeff: exactly. that, that was not set up on purpose, but I, I feel like I would be remiss. If I just didn't do a quick plug on that note because we are a company that, that sells software that does exactly that. Right? That, you know, that's kind of the point of what Log Rocket , is how do we, how do you give that kinda feedback loop and , it's, you know, watching everything from what you deploy to the session replays, but having the AI watch sessions for you tell you what's important, where are people having that problem, get that feedback back.

To product people, to engineers and, 'cause we've seen that, that loop of talking to product people who say, I don't get this feedback from customer support for three weeks afterwards. So how do we kind of tighten that loop up so you can know exactly how people are reacting to what you're building?

Sarah: Totally to, to add to that, one of the exercises that we did around, Hey, like in 2026, we're going kind of all in on this AI development. What tools are we gonna actually need that we don't have today? And I think two of the most important tools to really do this well is session replay, and like some ab testing functionality, right?

Because those are [00:16:00] the things that help you go faster. Because if you have, if you don't have a tool and it's extending your timeline, it doesn't really matter what cool technology you're using to 

Jeff: the whole thing is how can we compress time of decision making and make sure that we, you know, someone brought up like, oh, with ai, don't we kind of have, aren't we nearing like the world of infinite code? And, and maybe, but there's still other limitations realistically on this where you still, you know, velocity, right?

What is it? Velo, someone said one of the dinners we were at, and it was really, really smart. Velocity is a vector. People forget not just one thing, and it's magnitude, which is speed and direction. It's very easy to like rocket ship directly into a wall if you're not careful.

Sarah: I've been in healthcare my whole career, so highly regulated industry, highly fearful of change. And also just an industry where technology in general has been super behind every other industry until And it's, it's so fascinating to see like the AI adoption in healthcare is above most other industries, which is truly shocking to me.

But that is more of a reason and more air cover, frankly, to be like, yeah, this is what we're [00:17:00] doing. This is the only way that we're gonna do it.

Jeff: We had a couple people from health tech companies on recently and you generally think healthcare is right, kind of a, a laggard, not in a bad way, but just because you do have, the joke is always, oh, we're not, you know, no one's gonna die if we mess up.

But in health.

Sarah: In this case,

Jeff: It could, yes. Like, that's always my like big get outta jail free card if, if anything goes wrong. I'm like, well, it's not like anyone's gonna die. not true in this case. But but they were doing everything from, you know, synthesizing patient doctor interactions so the doctors could be more present to how do you predict supply chains better and basically not have cases where you suddenly, you know, as a provider, find yourself.

Missing important equipment that, that you need and, and you know, so you can provide the best care. And it's just really wild to see like all the stuff going on in the space. It's not just, the simple kind of use cases. I'm sure there's a lot on the engineering side too, that's allowing you guys to move faster.

Sarah: Exactly. I, I'm so excited about the shift that we're gonna see from, you know, so far the AI tools and healthcare have been a lot of like. Automating the back office, if you will. Right? Like a little bit safer, ? [00:18:00] But eventually, like you're gonna need to get into the care space and that that's what we're excited about doing.

And you're gonna need to help actual providers take care of more patients. Like they just don't have enough time in the day. And this is exactly what these type of AI tools are, are meant to do. It's like, how can I see more patients? How can I be the, in the top 1% of providers because I have all of this at my disposal.

Jeff: Right. And that, that is really exciting, right? 'cause that is, I mean, I know. Several doctors in my family and, and friends and, and it's tough, like the volume of stuff there, it is not just seeing patients, it's all the work around that. It's like being a teacher too. Like similar thing where the actual work that, that the public sees is, is probably, you know, a fraction of the real work.

But if you can abstract some of that away their ability to execute and, and do the kind of, you know, stuff that we all think of core, core doctor work, but care, really, really escalates quickly. Which is really cool. So one thing you said, I want to kind of take more time on this idea of like product engineer. Because I, I a hundred percent agree. Like you said that, and you know, light bulb went off in my head where I was like, that's gonna be a thing. Like just the name alone is, is too cool.

Can you maybe talk about [00:19:00] like, either what does that look like at Med Bridge now, or, or how do you see that kind of developing what, you know, what does that, 

Sarah: Yeah. 

Jeff: that go?

Sarah: Well, it's funny you say the name is unique. 'cause I've already had a couple of my PMs be like, when do we change our titles? I'm like, okay, hold. Hold your horses. 

But. 

Jeff: You need 200 GitHub commits.

Sarah: I like that. But yeah, I, I just think, you know what we touched on earlier, like the roles of both the product manager and the software engineer are gonna meld. So what does that look like? Right. I don't think it's for everybody. I don't think that that means every single Pm an engineer is gonna turn into a product engineer.

But I do think there's gonna be a right? And I think a lot, we're gonna see a lot of product engineers over the next several years. And what I mean by that is basically the product person, instead of, I hate this terminology, but they used to call PMs like the business, right? 

Jeff: Yeah, 

Sarah: a thing.

Jeff: they're all the business.

Sarah: Yeah, they can do more than understand the customer requirements, you know what I mean? So taking the customer requirements building their own prototypes, building their MVPs. One of the things that we're gonna change in 2026 in our road mapping process is [00:20:00] the MVP will be built by the PM. It's not gonna be passed over to the engineer based on some requirements and a prototype for the engineer to build.

The MVP will be built by the pm so that's already a huge time saver. Now the engineer who's really interested in getting closer to product I you, the future product engineer, they will then ride shotgun with the PM to get feedback on the MV. So they're listening to the customer conversations, they're listening to the gotchas.

They're listening to like, well, here's why the MVP doesn't really work, or Here's why it does. Here's what I like, here's what I don't like. That way you're again, reducing that feedback loop and then the, the engineer can go back and be like, I know exactly what to do to make this, you know, a post MVP product, right?

And so it, it's really a combo, like I said, a spectrum. On the one side of the spectrum, you have the product marketer, and on the complete other side you have like a software architect, if you will. But in the middle, there's gonna be a huge group of product engineers who do a little bit of everything, and so we're trying to implement steps every part of the process to get closer to that.

Jeff: we're seeing that in a lot of places too. 'cause we have, you know, on the marketing side I think called the [00:21:00] go to market engineer. And similar to your point, it's not everyone. We still have brand marketers. We still have. non-engineer marketers. But it is just the ability to kinda take on more of, you know, there used to be things that you just had to have an engineer to do and it's now, you know, we're being enabled to do more of that stuff and you can just move faster.

You can test faster because you can just do it yourself versus having be like, can you make this change? Let's see what happens. Can you make this change? On the product side, that's gonna be even faster. I mean, to take it like to an extreme we had a guy named Zach Ha on. You know, several, several weeks back on the show.

He's from a company called Luxury Presence. They do, have you ever watched, like, selling Sunset like high ticket real estate shows or anything like that? 

Yeah, yeah. Bra Bravo is fantastic for that kinda stuff. But so they basically the website for all these like high-end real estate agents, like, they make all those like really, really brilliant websites that they use.

It's, they're like a CMS for it. It's not where you would expect. Huge volumes of AI innovation coming from. But they, they kinda got in early on this kinda what you were talking about, about the PM team can, can build prototypes. They can, they don't need to be [00:22:00] spending three weeks. Between, you know, five PMs and a couple designers to create one flat file prototype.

They can, they can do this in a week. And so they started kind of going to that model and seeing how far they can push it. And now basically, you know, in that kind of two week sprint, they're, they're building eight prototypes or something. Ridiculous. Yeah. They're testing with real users and they're shipping you brought up right.

The, the, the, why can't you ship one big bed a week or whatever. That's kinda the point they got to pretty quickly. It's really cool to see they're moving 

Sarah: Awesome. Yeah, that, I mean, that's using it correctly, you know what I mean? Like that's fantastic. And even on the other side where like you mentioned the go to market engineer, like that's, that's really interesting. But even non-customer facing product solutions, like every time now we think we need a tool, we ask ourselves internally.

We'll, so for example, recently it came up that we need a new RFP tool, And so we were gonna go down the route of like evaluations and understanding pricing and packaging and all this stuff. And then we're like, well, why can't we just build an agent? To figure out how to pull all of the information that we need that an RFP tool might do.

Right now there's gonna be, but at least it's good practice to be like, I can [00:23:00] do this by myself. 

Jeff: Well, it is, is, you know, I think we all heard the chicken littles kinda saying, the sky's falling on sas because everyone's just gonna build their own everything. And that it's just patently absurd at this point. Maybe one day, but like,

Sarah: We're, we're definitely not, not there. And it depends so heavily on the industry that you're in and the people that you serve, and how trustworthy are they of your solutions. And there's so many factors to that.

Jeff: I will say like a couple things we've, we've rolled our owns to buying now. It's the simpler stuff. I think there's a lot of like little pointy solutions that kind of are gonna get hit. Not really big things, but I think it helps just in doing the exercise, like, could we build this?

What would we need to? And by kind of going through that,

Sarah: It's just emotion. That's really important because we wanna get people comfortable with like the capabilities that exist.

Because that's how you start thinking about more interesting functionality.

Jeff: yeah. But , even just, you know, buying a solution, like, I feel like it can only make you more aware and, and able to buy, you know, be a better buyer. If you first thought like, what's really important, if I was building this, what would it do? And, and. That's an interesting thing, but now all I can think about is, you know, you and the team [00:24:00] building putting out an RFP for RFP tools, so

I don't know why I got stuck on that.

So, 

Sarah: i'm super adamant that like we should only spend our time building things with valuable IP for our specific markets.

Jeff: yeah, yeah. That, that, I, I, I, I think it's gonna be a long time before AI is so turnkey that you can just be like, just build me this, build me that, because. Everything you build an engineer of ours at one point who, who is on our kind of growth engineering team, kinda brought up one day like, we can build this.

Sure, I can spend three months. But now it's not just that we built it, we're done. Now that's tech debt forever that I have to service and now I can't do other things. And like, med Bridge does a specific set of things. Log Rocket does a specific set of things. It doesn't make sense for us to build our own like.

Interface with our, with our insurance company. 

Sarah: You mentioned you had the guy who was from type four. We use Typeform and we love it. 

Jeff: yeah. 

Sarah: But like type four is a great example. Like we could have built that into the product that we launched, but like why would we spend however many months doing that when we could spend that time building actual IP for our business, for our [00:25:00] customers?

Jeff: Why build, you know, what is essentially gonna be a cost center when you can build an asset that is gonna be an appreciating asset potentially.

Sarah: better way of putting it? Yes.

Jeff: So at this point, like, where are you guys on, on this journey? Like, is it mostly now you have PMs kind of building prototypes and, and working with engineering?

Is it, is it, that's an aspirational 

Sarah: started. 

Jeff: shipping every week kind of

Sarah: Yeah, I think we're just getting started. I think we have to phase. A lot of things out and a lot of things in, I think we have to get over a few hurdles of just, just folks doing things differently. I think we have to understand like who's actually interested in, 'cause again, it's not for everybody and that's okay.

'cause you need kind of everybody on that spectrum which is a good thing. But yeah, there there's a lot to figure out there. And especially like in our highly regulated industry, like we gotta be really careful about what we put in production. What kind of hallucinations are gonna happen when the doctor is asking questions?

Like, there's just like more nuanced things that we have to think through. But I think we've already got started and I expect us, in 2026, I expect us to have a completely different road mapping process. [00:26:00] I expect us to be able to deploy, coded to production in a much more, you know, faster fashion.

I expect PMs to be able to, you know, to deploy their own code. I expect engineers to have. Fantastic ideas like PMs normally do. So I, I think it's, it's coming and it's coming quickly. But I also think it's a process.

Jeff: On that front, I'm, I'm always kinda really curious about how, you know, probably, 'cause it sounds like you guys, you know, there's still aspirational room to move, but it sounds like you all have made really good progress already to date. How have you kind of gone about upleveling the team on, on the tools available 'cause you're not, no one goes from like zero to mastering.

All these things out of the gate, you know, you gotta, there's a process and everyone has had a different one, but what have you seen that worked to kinda move people in the right direction? And I mean, even conversely, like where have you found you tried things that just didn't work or, or people rebuffed the, the attempted move towards progress?

Sarah: Yeah. I, it's a, it's a great point. I, I think a couple things. So. First of all, it's not enough to just put AI feature on the roadmap that's not gonna get it done right. Like, you need more of a nudge than that. But I think, I think a lot of it is [00:27:00] like, obviously we have to make room for it on the roadmap.

Like if we're really gonna invest in this, it's a, it's brand new functionality. It's a brand new way. Of building product that they have not done before. So they need more time to get comfortable with it. That, that's time, I think is an important element of it. But the other one is, is just tooling and upskilling, right?

So we spent a lot of time in 2025 aligning on the tools that we need. Aligning on the programs that we're gonna send engineers to and some PMs as be like, Hey, like go, we're gonna invest in you. Go spend six weeks in this AI program and when you come back, I expect you to teach the whole team, you know what you've learned and then how we're gonna change operational.

Tactics going forward. And I think that's been huge. Like that, that's been a huge, like from two perspectives from the engineer's perspective is like, okay, they're serious about this. They're investing in this, this is the direction that we're going. We're not turning back. And then the other perspective is just around like.

Now there's, there's real expectation that this is gonna be delivered in production, so I better, I better upskill in this area, right? I think you need both the tooling and the time, but also the investment in the actual people so they can go learn [00:28:00] because this isn't, this isn't typical SAS engineering where you can just learn what you need to do through like osmosis.

You actually need to go in and learn it and experience it and use it.

Jeff: Yeah, I mean, I think that's been one of the bigger things I've seen. I've been trying to get the team to just go, even if you don't think it has any relevance to what we do at all. Go just try and build some zany thing because just doing it, you're gonna get better. It's just exposure. On the Med Bridge side, I mean, to get a little operational, but it, it's interesting, I hadn't thought about this before, like for us on the marketing side, because we don't, we don't have the PII kind of from the product. That's not something we're, we're always using. So like for that side of the team, I was just like, you know what, just go build stuff.

Use whatever model you want, just expense things. Be realistic, like, you know, and kind of keep an eye on that. But we had , the kind of head of product and CTO from Zuora on, and they're not medical, but they're billing and there's a ton of PII in, in that dataset and they were a lot more. Approve, you know, approve the the foundational knowledge you can use, and what's the interface and how do we ensure and do training to ensure people understand data [00:29:00] risks.

Were there elements of that over at Med Bridge? I, I have 

Sarah: Yeah, 

Jeff: there's some, a little more formal than we were.

Sarah: For sure. I, I mean, and that's like pros and cons, right? Like the con is like, okay, you're obviously gonna move slower and there's more things to consider, et cetera. But there's pros because you really have to be able to do it really well, you know? And so this is what we're doing in this hackathon.

Basically the mandate of the hackathon is like, hey, like the top three features are gonna go into production. And you need to not only think how to build it, but like how to get it tested, how to get it deployed and like what safeguards need to be implemented. Right. And that's not your typical, you know, hackathons are normally a little bit more vibe Cody but you know, if you're gonna put this code in production, like we gotta be. Super extra careful. You gotta have the human in the loop, very likely. And we're probably gonna have to, you know, beta test it for several months. Like, there's just a lot more considerations in the health. Tech space particularly, I mean think about like selling to like a large hospital system.

They're gonna be, well, hold on, I need like IT review, I need legal review, I need this, I need that. So there's just like different considerations we have to think through. But I think these types of events like this hackathon forces you to think about that. Like this two step [00:30:00] process is actually a 10 step process and that's okay.

We just have to account for that.

Jeff: Yeah. No, that, that, I mean, that's going another place where I think you're gonna see, you know, engineers, any, anyone. It's actually not that hard to code a single little thing, right? Like to, to edit a little bit of code. you know, you don't even really need ai. I think even most product people, you could have Googled it before and probably figured it out.

But like, where I, where I've run into problems was, you know, there's like two or three branches on something and how do I merge it and commit and like, what's all the nuance around that? And then add in, you know, test test coverage like you all the, you know, legal and compliance things on, in the medical side.

On top of that, like. Engineers, , that's the expertise that's really hard. You can write a little bit of code. It's the rest of it that that's really, you know, makes that job really robust.

Sarah: And I've had several of them tell me like, Hey, like I've used these tools so they can write the code a hundred times faster than I can. But it's about merging it and testing it and deploying it and making sure that it's didn't break something else. And there's so many other factors that it's not 

Jeff: Yeah. 

Sarah: to your point, like writing the code.

Yeah.

Jeff: Awesome. Well, as [00:31:00] much as I, I want to talk to you more about about especially the product engineer role, 'cause that sounds really cool.

You do have to go back to, to your dual role as CPTO at Med Bridge and keep building this innovative stuff and helping the team move forward. And you had a hackathon to plan for it sounds like. But appreciate you coming on. Thank you so much that this is fantastic. I feel like I learned a lot.

Hopefully others. I'm sure others will as well. But if people wanna reach out, if they have questions is LinkedIn the best place or is there a better way to do that?

Sarah: Yeah, LinkedIn is great. But this was, this was a lot of fun. Really love talking about this stuff, so I, I appreciate the time very much and I'm looking forward to, to listening to it.

Jeff: Yeah. Well thank you so much for coming on. Hopefully it's not, you know, 10 more months before we can wrangle together talking it all again. So you. Have a good rest your day. Thanks.