Derek Baird from Switchboard Health

Speaker A: Foreign. Welcome back to Product and Health Tech. My name is Nick Krabs. I'm a partner and the Chief community officer at Vynyl. Today we sat down with Derek Bayard, the CEO of Switchboard Health, and he talked to us a whole bunch about how, you know, AI tooling and thoughts about how you organize products is revolutionizing their company's velocity to iterate on ideas. Let's jump into the conversation. Well, Derek, thanks so much for joining us. I'm excited to, uh, have a conversation with you today. Um, real quick, I think for our audience, probably best to hear straight from you. Why don't you give a little intro on your background and tell us a little bit more about what Switchboard Health does.

Speaker B: Yeah. Thanks, Nick. Uh, fun to do this with you. So, uh, yeah. I'm Derek Baird, CEO and co founder at Switchboard Health. We're a Boise based digital health company. Uh, our mission is really easy to say but tough to pull off. We connect patients with great specialty care. Personally, um, I've been in digital health my whole career. I stumbled into it before I even graduated from college. And so that was a few years ago. Uh, and I've spent a couple decades now trying to use technology to improve how care is delivered and how providers operate and deliver care and get paid for care and whole bunch of other use cases and needs along the way. There's plenty in healthcare to work on and plenty of areas that need improvement.

Speaker A: Yeah, yeah. And you kind of, you got recruited kind of through the venture process to run this company, correct?

Speaker B: Yeah.

Speaker A: Which is a little different. Can you just talk a little bit about how you got involved and how you kind of, uh, again, it's a little different of a process for a lot of early stage companies.

Speaker B: Yeah. So the idea for Switchboard grew up within a venture capital firm, Route 66 Ventures, which is, uh, based in Northern Virginia. Um, they'd been working on this idea and were looking for a company to invest in that was trying to address some of these challenges. And so they're very much an invest first fund. Um, and then if they see white space and aren't finding a company that they want to back then and only then do they say, hey, should we, should we form a new co ourselves? Um, they'd been grinding on this idea and doing a lot of market validation, market research, um, really pressure testing the concept for depending on how you count, like six to nine months before they said, wow, we're really onto something here. Uh, let's find a CEO, let's put some money behind this idea and let's launch what we now call switchboard. And so summer of 2022 I got to know them as they were just made the decision to launch the business and provide uh, the initial funding and um, fell in love with the idea and uh, love the guys at Route 66 and said yeah, look, being a digital health CEO usually involves a multi year journey and uh, this felt like a great mission and a great part problem that you know, finally needs to be solved.

Speaker A: So, so like elevator pitch level quality here.

Speaker B: Yeah.

Speaker A: Um, what specifically is the idea that you guys were, were grinding on and now you're kind of testing and delivering on?

Speaker B: Yeah, I mean this is, I mean I remember this from a couple decades ago. Like the way that patients are navigated to specialists is. And unfortunately most of us have experienced this ourselves or as dads or as caregivers for parents. Often you're just told by a primary care doc like hey, here's where you go and that may or may not be the right destination or the right specialist for you. Um, or often you're said hey, just go find an in network rheumatologist. Good luck and Godspeed. And so the problem is an old one, which is about 40% of patients then just give up along the way because they don't know what a rheumatologist is or they don't know what in network means or they lose the little slip of paper from their PCP with a specialist's name on it, or they have trouble finding an appointment or oh, that specialist retired or doesn't take their insurance after all. And so you just have a lot of um, dropped balls along the way, which means patients not getting the care that they need, which usually leads to bad, expensive things occurring. Mhm. Um, the reason why this is starting to change is um, either insurance companies, health plans or primary care providers are now financially responsible for specialty care costs. So now you're, you're got a lot of people. Yeah. Uh, you got a lot of people who are much more motivated to ensure that that patient finds the right specialist and can get in, can be seen and could have their care needs addressed. And so the good news for us as patients or kids or the one footing the bill is um, there's a lot more alignment around doing this in better ways. And so that's the rather long problem statement. The solution that we bring, as the name implies, is if you tell the switchboard who's the patient, where do they live, what insurance do they have and what type of care do they need that then comes into our system and we look at all the specialists, like here in the Treasure Valley. We look at what insurance they take, we look at who has availability, we look at their cost quality data, and we say, hey, for Derek with his startup CEO headaches, this is the right neurologist for him. Let's make sure he gets an appointment and gets seen, which is dramatically better than what has been the status quo for a long time.

Speaker A: Oh, for sure. Well, and also, I think you're really tapping into this cost control nature. So specialists generally, um, they get used a lot more in kind of the most expensive situation in our healthcare system, which is chronic health issues. Right. You have a lot more specialists involved in those. Um, I don't know if the statistic is exactly true, but, you know, it's over 50% of the healthcare costs tend to come from, um, kind of chronic healthcare issues, which, again, involved a lot of specialists. So you're definitely tapping into one of the big, just from a cost control standpoint, pain points that bears across our health systems. One of the things we like to do on this podcast, um, generally is kind of give our guests an opportunity to like, ring the bell on something that's, that's, uh, happened to them recently that's been a big victory. And you have something right now which is that you recently acquired, uh, Conduce Health, uh, and get to bring a Google alum alongside you guys, and some data science on the team. Can you talk a little bit about that acquisition? And I don't have a bell to physically ring, but we'll get the cheer anyways.

Speaker B: We can add one on. We'll do it in the post editing process. Uh, really, this was, um, gosh, the end of September now, uh, we announced the acquisition of Canduse, which was working on a similar problem set. Um, I mean, we left their website up there. You can go check them out@conducehealth.com, but was also working to improve how specialty care is delivered and how it's connected and how patients don't get lost. Along the way. They'd really been focused on, um, developing AI and predictive models so that it's not just about who's a good neurologist overall, it's which neurologists have shown that they're really good at taking care of patients. Like hypothetical Derek in this situation. Um, so some really, really fantastic technology that over the last few years, Switchboard's been very focused on building a front end and getting integrated with other systems like EMRs and so the marriage just, you know, the more we looked at it, the more it made a lot of sense to take the AI capabilities that they developed and some of those team members and, um, put it into our platform, which is, you know, brings this magic to life in the middle of, uh, the workflow or the point of care. Um, so for us, it's. We get great technology, some great new team members, um, that we would, you know, that would have been a long recruiting process to find data engineers and data scientists of this caliber. And so. So, yeah, it's been great.

Speaker A: Certainly at the stage that you guys are, you know, if. If you can pair the. The IP needs with a little bit of aqua hire, for sure, you know, you can certainly make a puzzle piece kind of slide in really nicely. Well, like I said, I don't have a physical, Physical bell to ring, but congratulations. I know that was a big step for you guys. I know that was something that you'd been working on for quite a while. So, um, kind of pivoting this conversation and really one of the big reasons I wanted to talk to you and kind of get this recorded and get it out on our podcast is that you and I had lunch a few months ago now, probably longer than. My brain is just slipping on time. And one of the things that you had kind of piqued my interest was you were exploring this idea of almost eliminating the product management, uh, role in its traditional sense, uh, within your organization and really using a lot more AI tooling and kind of spanning those things across multiple M team members. And so just like, hearing you kind of talk through this, which at the time was really, ah, uh, maybe a more radical thing to be testing. I think there's a lot of people looking at this now, but several months ago, I think you were kind of a little bit more at the forefront of exploring, um, what that might look like in an organization that's trying to move fast, that's trying to cross bridges as quickly as humanly possible to seek opportunity. Um, I really want to check in on that experience. I really want to hear a little bit more about. So maybe we can go back to even before you and I had a lunch meeting several months ago, maybe set the stage for how you started on that journey and then tell us where it's gotten you.

Speaker B: Yeah, well, uh, before people turn this off because they think I'm a CPO hater or someone who doesn't believe in product management as a function, I mean, I grew up in product, so 23 years ago, most Tech firms actually didn't have product as its own team. So I grew up in marketing and at the time, what we now think of product today was sort of half of it was done by engineers, the technical product management and then marketing. And I've just by default did the other half, which was all the product marketing management. Um, turns out I really liked the product side of things. So um, after starting in marketing, I then went into product for a good number of years. So I'm not a product hater. I'm one of the biggest product fanboys you'll find as a discipline and as you know, I think a uh, really, really interesting mix of art and science.

Speaker A: Right.

Speaker B: Um, and I, I used to use this line which was like I loved product. I think it was one of the most stimulating roles I've ever done. I also think at the time it was one of the most thankless roles I'd ever done. Um, um, but just know I'm a big believer in that is, um, a key function. And really I think for many young tech companies the key to winning I think largely hinges on whether it's a person, a team or a function that's diffused within the company. I really think that's the largest fulcrum for success. I just think to get to our conversation a few months ago, I think the way that you organize around that just needs to be very different in 2025 than it was even two years ago.

Speaker A: Oh, for sure. Yeah. I mean like I said, I'm seeing a lot of different organizations trying to test right now. Uh, I'm seeing a lot of kind of like diffused responsibility across several other disciplines as a way to cover the same discipline, but not necessarily a single person or role that owns it all the way through. But you still have to cover the functions. And again, using a lot more AI tooling as part of the um, speed to test those ideas and get feedback quickly. So anyways, yeah, so again pivoting back

Speaker B: and I think that, and I think for a seed stage company like the CEO should be playing m a very active role. Maybe my team might quibble with um, how active uh, that should be. Look, I think even for later stage companies, if you're not acting as an individual contributor in the mix of product strategy and prototype development and uat, I think you as a CEO are failing your business. And so um, we've sort of moved away from having product as a team or an individual and have said, look, the way that we prioritize ideas is going to be diffused. Ultimately, I have decision rights on that. Um, often I'll change my mind because the team M convinces me that my original idea is the wrong one. So that's not like ruling by fiat. But ultimately I make the calls on what we do and what it looks like. I think that has helped us go faster. I don't always make the right calls, but no one does. And it has just brought real speed and clarity and alignment to the process.

Speaker A: Well, it seems like when I talked to you before, um, and you might have been getting there, so I didn't mean to cut you off. But so many of the decisions you were talking to me about at the time were really about, you know, opportunities that you had in the marketplace that were coming directly from either perspective or current clients. Right. Which is when you think about the discipline of product management or product generally. So much of it is about how do you make good choices on what to build and how do you get the feedback from either the market generally or directly from your existing clients on how to get there. And then there's just a velocity core question like, how, how. What's your speed to design, build? And then go put that in front of the people who've now given you the feedback. And I think what really piqued my interest is, is when I was talking to you is your, um, your belief in the CEO's role, um, in understanding at a really deep level what the market or your clients are asking for. And that's, I think a lot of times something that a CEO is, is involved in, but they're hearing it almost secondhand. Right. And that did not seem to be your philosophy, which I thought was really, really interesting. Right.

Speaker B: Yeah.

Speaker A: So maybe you could talk about that for a minute.

Speaker B: Yeah, I mean, I think I. Again, I think this day and age, like the CEO has got to be like, at the coal face and just, I mean, out there in the market, hearing firsthand. Um, and so I think that's going to continue for, well, for as long as I'm at the helm. I think that's regardless of stage or maturity or how many current clients you have. I think, um, the way to compete and win where the tech is increasingly commoditized and the way to earn an unfair advantage versus competitors big and small is just being out in the market and hearing those insights firsthand.

Speaker A: Yeah.

Speaker B: Um, then I think from there, like, okay, a lot of CEOs or product leaders have been doing that for years, but in the past it's like, okay, well then let's write up a prd and let's have several weeks of meetings and then let's build some wireframes.

Speaker A: This is a velocity question now.

Speaker B: And maybe we'll feel like overachievers and we'll have some clickable prototypes. And then like eight weeks later maybe if you're lucky, you go back to the client and they're like, is this what you mean? And they say, no, you got it wrong. And then a six week redo ensues. And now it's like, look, I fly to Florida tomorrow, I'm going to learn a bunch in the two days that I'm running around down there, I'm going to come back, we're going to have one meeting and decide on at least one thing that we're going to build on a prototype on that'll probably be measured in days, not weeks. And then we're back at the client six days later with a real clickable application saying, did we hit the bullseye or not? And they'll probably say no, but you're on the dartboard. And then the next cycle's three days. And I think, um, just the pace that you can reach and maintain with that type of, with those types of loops for me is like really exciting and invigorates the whole team.

Speaker A: Right? Well and just from a, maybe just a purely blocking and tackling standpoint, I mean once you, it sounds like you've gone and done learning with this client, which is great, you know, and then you come back, you have one meeting with your team, can you talk a little bit about then how the work actually gets dispersed, right? And what, maybe what tooling you're currently using. I mean this is changing so fast right now. You reserve the right to be wrong in a week, right? But right now, today, yeah, right now,

Speaker B: if it's something with a front end, like we're partying and lovable, right? And we've used V0 for some of this, but right now for rapid iteration and stuff that even I can do, and I'm a non technical founder and knock on wood, I have yet to break one of our lovable apps with a terrible series of prompts. And I say apps, we really think of these as prototypes. And that just, it gives you an idea of the contours of the idea that you're exploring in a way that I don't think you can get from an old fashioned written document or even a bunch of flat static wireframes in Figma. I know Figma has tooling that allows this, but a lot of our action has moved out of, well, Google Docs and Figma and into well, let's just jump ahead. And the quickest way to pressure test some of these ideas both from a feasibility can we build this standpoint? And a will the client be delighted by it standpoint is using lovable, um, and then for more backend and more of our automation use cases, we've got some safe spaces to spin up some models or some orchestration routines that again we can show to the clients. And if they don't love it, that's okay. We didn't spend eight weeks on it.

Speaker A: Right.

Speaker B: You know.

Speaker A: Right. And that's, you know, and if you just think about startup land and failing fast and iterating quickly and again, a lot of this is just about what is your velocity. Velocity to get through ideas and test those with, with the marketplace and whatever form that takes. I mean you're going directly to individual clients, but there's a lot of different marketplaces that you test a different way on how you get that feedback. And so um, you know, again it's, it's, it's very interesting how quickly that velocity. Now do you typically have um, your engineering team managing kind of the clickable prototypes or are you still holding onto that yourself as a CEO?

Speaker B: How does that work get dispersed? Yeah, it's both. I mean, um, thankfully the engineers have been leaning into this and want to be kind of on the leading edge of this prototype development and working on things that may then graduate to mainline product. So we even call it switchboard labs just to make it really clear to us and the client and the prospect like, hey, this isn't production grade. We're a high trust certified company. And so in order for something to make it into our core infrastructure and mainline product, don't confuse that with what we're playing around with in the lab. Um, but you've got a great mix. You've got. Yeah, I'm in the mix, but I would say I'm more of a supporting actor than a lead actor. We have people who are like me, recovering product managers that have other roles within the company but then are able to participate in that process and bring uh, m some really great insight and a really great way of thinking. And then we have engineers in the mix kind of keeping us honest and doing the lion's share of the prototype development just to make sure we're not like charging down a cul de sac so that if and when it becomes time to promote something to mainline product, we haven't gotten all excited about something that's not going to be feasible when we decide to promote it. So, uh, I think it's a fun. I mean, look, we're a 12 person company. I mean a lot of this is like we're all together on the line riffing on this, which I think is pretty invigorating for everybody. No matter what your job title is at Switchboard.

Speaker A: Well, I think every company, regardless of size. We've seen this a lot at Vinyl when we work with Fortune 500s. Right. This idea of how do you make decisions quickly, how do you iterate quickly, how do you get the buy in quickly, what stakeholders have to be there? Um, for a long time we used to use the Google Ventures Sprint process. And the truth is that process, it's not dead. I would say that there's still a lot of value in why you go through those steps, but certainly there's a lot of ways to shortcut, um, the output of a process like that. Um, I don't know that I would recommend that book now. For a long time I used to walk around like, have you read this? This is what we do.

Speaker B: Maybe specific pa, but not the whole thing.

Speaker A: They have a lot of stuff in that book about how you get the right stakeholders and to get the buy in you need in order to make decisions quickly to have something to test. And I think the bigger an organization is, some of that stuff is still very relevant. Right. Um, but then the actual learnings that you're taking from whatever the prototype is that you're taking out into the world like that is all super shortcutted and you can do it many, many, many cycles in what used to be maybe one or two tests that you'd get. You know, you said eight weeks. I mean it all is variable depending on the organization and what you're doing. But now you could run a similar process and maybe have 20 tests that you could do and take up the same amount of time. Right. And that's a pretty unique, um, advantage for companies and individuals who are taking advantage of uh, of this aggressive, I mean a lot more aggressive way of testing this stuff.

Speaker B: Yeah. And it's not like me or a product person like off in the woods toiling away for a few weeks and like everybody's in the mix the whole time. Which again, I think, um, helps us go faster but also leads to a better product. And you can shortcut a lot of that. Like, okay, I'm reemerging from the woods and now as a product person, I need to spend a few weeks getting everybody Bought in and catching them up on what I've been doing. All that just thankfully gets a lot simpler and easier and I think more fun for everyone.

Speaker A: Well, in the technology space there's plenty of roads that get built to nowhere in this stuff, but at least in this world you didn't have to spend a lot of resources to put those two miles of pavement down and be like, eh, you know, not that one. Um, so, you know, I think you touched on something that's maybe a little bit interesting to dive a little bit deeper and that's trust in this new way of doing it. Right. And so you've literally like put some marketing language around this to kind of sequester or head off, uh, maybe a trust issue that you could run into with a prospective client in using uh, new methodologies or new tools. Um, and again for you this is all about trying to gain market signal on new pieces of your product. So that's an interesting dynamic to navigate. Can you talk a little bit more about either the advantages or disadvantages on why you put together a switchboard labs to communicate this idea, uh, while you're going out and bringing a new methodology into your organization?

Speaker B: Yeah, I think from uh, from an external standpoint it just makes it really clear to clients. I mean look, there's too many companies in tech that present features as if they're fully baked and ready to go. And look, sellingwear is a thing. It's still a thing, right? Selling futures is still a thing. And so I think this just makes it really clear like, no, this isn't ready, we're not going to ship this to you tomorrow. Okay. Um, and so I just, I find that that's made it very black and white versus what has often been shades of gray. And I think the clients really appreciate that because I think many of them have been sold gray things that truly weren't ready for primetime. And so I think it's refreshing for them to know like, you know, this is, to use the old fashioned term, like this is still in beta or in alpha or just internal prototype sometimes.

Speaker A: This also helps in the sales cycle too, because when clients, either prospective or current in almost any organization, feel like they're part of the feedback loop on what's being built when it actually comes time for them to pony up and sign up for it. If they've been part of this iterative cycle, uh, they're usually much quicker to adopt and much assuming that you're selling features in that way. But like, they're much quicker to be like, oh, yeah, well, I've seen iterations of this for a long time.

Speaker B: And even if they don't adopt or buy that new feature, they see like, wow, Switchboard is like they are moving fast. They're always working on new stuff. Like I may not want the thing coming out of the lab, but um, you know, it sort of shines a light on, in a good way on you know, the fact that like we're really, really busy testing new ideas and working on new stuff. And then I think internally, you know, that distinction between the lab and something that's ga, um, I think also makes it really clear like what processes and methodologies are we using. Right. Like obviously the QA and the security and the way that we treat production. Exactly. You know, um, is and should be very different than when we're, when we're working away in the lab. And so I just think sometimes I've seen this where products sort of end up in between and people are like, well, do we need to we like multi factor authing that thing or not. Like it's sort of like in the no man's land. And so I think it's been helpful

Speaker A: for us internally to separate the two out.

Speaker B: Absolutely. Yeah.

Speaker A: So in that same vein, if, you know, if someone's watching or listening to this podcast right now and they're, you know, maybe they're currently a, uh, working product or they're trying to think about how to, you know, add some again velocity, uh, in this cycle or they're trying to bring new methodology into their organization or they just want to learn more. What's like maybe one piece of evergreen advice you would give to, to that person trying to explore not maybe just how to use some of the tooling themselves, but to give some organizational buy in to do this in a different way.

Speaker B: Yeah, well, I'm not sure it'll be evergreen. You know, we reserve the rest of Google Maps.

Speaker A: Change our minds. Exactly.

Speaker B: We've already talked about books. Part of them not aging well. But I think right now if I were still working in product, I think what I would be um, thinking about is um, expanding the scope of what I can and should be doing. And I think there's two ways that I think about that. One is if you're not playing around with prototypes, um, and building using tools like V0 or Lovable, I think that's a big mess because I think you need to get in there to really understand the contours of m these applications. Uh, just the same with the LLMs and the frontier models, you can't just read about them or listen to podcasts about them. The best engineers and product people I know on the weekends are building stuff for themselves in these applications, um, and using the LLMs for personal reasons, because then I think you can figure out where they're really succeeding and where they're not quite there yet. And so I think if you're a product person and you're not building, uh, I think that's a real mess. And I think separate from ah, but related is from a design and UX standpoint, I think, I think about it similarly. So I think successful product people will um, be able to thrive as the kind of lines between engineering UX and traditional product management. Like those lines are already blurring. I think they're going to collapse altogether.

Speaker A: Oh, I think you're completely right.

Speaker B: And so I just think you've got to be a lot more versatile. And I just think the learning really compounds on this. And so you've just got to get into, uh, learning and playing around mode to keep pace with what's state of the art in wherever the heck we're going to draw the box around product management going forward.

Speaker A: Right. Well, hey, I think that's a, uh, pretty great place to lead this conversation. I know you and I will probably meet up and continue to have it after this podcast over. Um, I just want to say thank you for coming down and having a, a quick conversation. This was again, invigorating and interesting to hear you talk about, uh, your company and, and the things that you guys are up to right now. Um, you know, I appreciate you a ton and, and we'll, uh, we'll see you around soon.

Speaker B: Yeah, thanks, Nick.

Speaker A: Appreciate.