Co-founder and CTO of Propeller Health, Greg Tracy, shares the Propeller story through their acquisition by ResMed.
I've known Greg Tracy since before founding Redox, connecting over civic hacking projects in Madison, Wisconsin. As the co-founder and CTO, Greg helped Propeller Health from its inception to serving patients across the globe and through its recent acquisition by ResMed (for $225M), where he now serves as the chief architect.
Greg shares the Propeller Health story, their early choice to go through FDA clearance, and how they built the business into a global brand, as well as the constant struggle to prioritize projects, no matter how large the organization. He’s always been a mentor to the up and coming developer-leaders in Madison; this conversation exemplifies this. Thanks for the great conversation Greg!
Find Greg on Twitter (@GregTracy).
James: [00:00:00] Today's guest is Greg Tracy. I've known Greg for many years since before, even founding Redox, where Greg and I connected over a civic hacking projects in Madison, Wisconsin as the co founder and CTO, Greg helped drove propeller health from its inception to serving patients across the globe and also its recent acquisition by ResMed's.
Whereas currently serving as the chief architect. Welcome to the show, Greg.
Greg: [00:00:58] Thanks, James. It's great to be a great to be here. And, um, I wish we had more opportunity to do stuff like this and spend time together.
James: [00:01:05] so maybe it just to get us started. Could you tell us a little bit about propeller health and who you serve , and where propeller health is today.
Greg: [00:01:12] Sure. So our stated mission is to make life better for every person and community affected by chronic respiratory disease. and, and in practice sort of week over week within the business and in the market, that means sort of having a novel combination of hardware and software that is, really a digital therapeutic that is attempting to arm patients with, an experience, sets of insights and transparency around their disease to allow them to have better control over that disease.
, we build small sensors are probably best known for our sensors. So they're add on devices. This is for an inhaled medications, all of the common prescriptions that folks with asthma and CIPD have, and then we're just passively recording when and where they're using those medications.
And that data flows back through our backend, where we find insight in that data, and, has two main main purposes for the patient. And that is we try to build better behavior around compliance to daily medication, and then we help them better understand, when they may have triggers what those triggers are, what could be leading to the, to some exacerbations, that they may be having.
And try to maybe sort of pull the cover away so that they have a really more insight and transparency about what's going on. Th those same insights, yeah. And interventions go back to care teams as well. So we have, we have, we build clinical tools that allow their care teams to understand, what's happening with the patient populations that they manage.
even when those patients aren't in the clinic.
James: [00:02:49] . Could you tell us a little bit more about, how you got to propeller and, you know, this is a podcast for folks who were often. starting out in their, in their journey in healthcare. It, so just, you know, anything about kind of how you, how you found your way here or, you know, what, what led you to health care and a little bit of, of the, the story of how you ended up here today would be awesome.
Greg: [00:03:09] Yeah, sure. It's a tangled story. and with a lot of luck, I would say, but, yeah, I'm a trained computer scientist, so I've, I've been writing software in my whole life. And studied studied computer science as an undergrad, and I am quite old so that it was in the early nineties, worked for a little while, then decided to go back to grad school later in life.
And that's, that's what brought me to Madison. So I came back to go to grad school here at UWA and had an, a, got a master's, one of the sort of first stroke of luck. There was that, when I was a grad student, I was looking around for things to do on the side. And I wound up taking a job in the physics, the medical physics department, working on a PACS viewer.
So this is the, this really very much in the transition from film to dance, digital for radiology. And so I was helping that department build a PACS viewer, and then one thing led to another and there turned out to be a startup here in Madison that was building a commercial version of a PAX viewer.
And, introduction was made and I wound up becoming an early employee at that startup called ultra visual. And the founder of that business and CTO is a guy named Mark Gehring and, Mark and I then went on and did three. So that was the first company. And then we did two more after that, including propeller.
So that was sort of the first stroke of luck of, of meeting him. that business grew like gangbusters. It went from 20 people to 300 in an IPO in 2000 and. Six 2005, 2006. and it was a wild ride and, learned a ton about building software. Commercial software learned a ton about managing really fast growing teams.
and it was fun, but also really got burned out. And there were a group of us that decided to leave and go start another company. And it was a, It was a consumer web company. This would have been 2006 through 2010, and it was called Sharon deputy. And we attempted to build tools that really democratize the creation of software.
So enabling nontechnical people to borrow, components that technical people in the community made in a drag and drop environment. So think of it as think of it as get hub with a gooey on it. and it was a really a bold, like big, giant idea. It was probably under financed and poorly located in Madison, Wisconsin.
but, that was really my first foray to company building. And, and we wound up, we, we started to close that company around 2010 and that's when. That's when we ran into David van sickle, who's the third cofounder and acting CEO, and he's an asthma epidemiologist and has really been studying asthma, his whole career and studying outbreaks and, trying to understand why outbreaks occur and how we can prevent them.
And, And doing a lot of that work at the CDC, but at the time he was, he was at the medical school here on campus and doing this work and he started to build some rudimentary, sensors that sit on top of inhaled meds. And had started to build evidence that you could change behavior and improve health outcomes for those patients and published a bit on that and decided to bring that work off campus and commercialize it.
and then just like another, just another, bit of luck Mark and David knew each other socially through their kids at school. And Mark said, Hey, you should meet Greg. he's, we're winding down Sharon, deputy's looking for something new to do, and then, you know, lunches and dinners and beers, over the summer of 2010 turned into, Oh, wow.
There's actually like a really big company here. Let's go make a run at it. And so the three of us formed the company in, in the fall of 2010 and, and we were off and running. So, I guess to answer your question about the sort of like getting into health care. So I actually have a background of that, both Mark and I did, and the software that we built for the PAX viewer that's, that's a class, two medical device, requires, it getting through the agency and you do something called a five 10 K.
And when we had originally started propeller. We thought we would need a five, 10 K as well. We assumed it was a class, two medical device, and we didn't know the answer to that in the beginning, but we also felt like there was a strategic advantage of going down that path and would probably make some sales opportunities a little bit easier.
So one of my favorite stories at propeller is that the very first hire we ever made was a regulatory officer. It is not. You know, it's not as not a sexy story. That's not, we didn't go hire a bunch of like whizzbang, engineers to go write a bunch of code. We really started at the bottom and said, we need a QMS.
We need a quality management system. That's gonna help us, sort of dictate process and flow and make sure that we do this right, so that when the product is ready, we can take it to the agency. And, And we don't have to sort of bolt on something, at the, at the end and we should be able to get through the agency relatively quickly.
So always really quite proud of being smart and prudent. And I think that's probably speaks to the scars that we had or the experiences that we had of doing that, in the, in the PAX world. we tried to replicate that here at propeller as well.
James: [00:08:29] Can you talk a little bit about that kind of dynamic of just leading an engineering team, in a, in that FDA certified role? I think it's very different than, You know, maybe the world of, outside of that, where, you know, agile and CIC and, in a real time deployments are happening all the time.
And you know, it, can you kind of talk about how you've merged engineering, general engineering practices into that FDA certified , domain.
Greg: [00:08:55] I w I would say first that I speed in quality are definitely compatible and I. I think that there's a perception that those two things aren't compatible. but I really do believe that they are. So, yeah, you can't just push code into production, with a, with a commit, right? Like we can't do that.
There, there are some checks and balances there, but you, like, if you just zoom out a layer, you can still automate most of what you do. within a team to sort of get right up to that point. And then you start doing that checks and balances, and you have a quality team that's double checking your work and running through test plans.
And so, like, I think you can, you can still automate most of what you do. And then wrap that around with a quality management system that has, that has a few extra checks and balances about. And, you know, in the beginning I was writing a ton of code and so it was just sort of heads down, go, go, go. And we were releasing on a really poor cadence.
No, I would say it was every couple of months, but it was a manageable thing because you, if you have fewer than five developers, you know, on Monday morning, you can all look at each other and agree on what to do and, it's manageable. But then once you get over that, it really, it's not manageable. And the engineers were getting angry with me and asking for some more planning and more automation.
And I don't know, it was probably four or five years ago. I hired a really great guy, a guy named Mark Samer. Who came in to run engineering for me and his secret sauce was to like really legitimately put speed and quality together in a compatible way and brought in awesome, amazing process. both on, like, if you think of like on the agile side of deploying Kanban and, and making it much easier for the developers to operate, but at the same time, he was actively writing bugs against our quality management system in order to get it to be a little bit speedier as well.
And, he just did a remarkable job of it balancing, the needs. Of engineering and the velocity requirements of the business and product and balancing that against the needs of our quality and regulatory team. and it's, it's definitely doable. I don't, we don't do, We have push button, automated deploys, but we don't have, Hey, it's Thursday afternoon.
We're going to deploy today just because we pushed a commit through, there's still some level of, like I said, just sort of checks and balances there, but their speed and quality are definitely compatible even in healthcare.
James: [00:11:38] what were some of the. Really hard decisions you had to make as a, you know, from like the product and engineering side, along your, on your journey. I think, we'd love to hear sort of inside of, of some of those decisions and what, what contributed to them and what trade offs you had to make.
And some of that.
Greg: [00:11:57] Yeah. You know, the hardest part I think for. Product and engineering inside a propeller is, is managing the diversity of the business. So we, we actually sell in a bunch of different ways. We, we sell in like a very traditional sense. We sell into healthcare systems, usually big IDN, where they have some financial risk for patients.
There's a workflow that, the clinical users are operating on there. And then you have a patient experience when they're, you know, the patients are outside of the clinic. but we sell, we sell the payers, we sell through retail pharmacy, we sell through, PBMs. and then we, yeah, we have very big relationships with pharma.
So in, You know, recently we made a couple of big announcements. We're we have a part we've had a longstanding partnership with Novartis, but we, they just launched a new drug in the EU that came co packaged with a digital experience. So when patients pick up their prescription at the pharmacy, it comes with a medication and, in the same packaging, they get a, they get a device, they get a propeller device and a subscription to the propeller experience in that same packaging.
and then we just announced the, we also deployed propeller in partnership with Novartis in Japan. That was just announced last week. So you can imagine in all of those, like the prioritization that has to happen within product and engineering to go service, a big international pharma company, where the regulatory requirements of getting into a package of a drug is going to be vastly different from what you might need to go deploy.
Propeller to Walgreens users, right. Or Walgreens customers. And so that, that oftentimes is where most of the friction comes. And it's most often where we technically, wind up making compromises, because it's, it's hard to really service all of those things equally. And so, you know, we will sometimes consciously make.
Decisions to take on technical debt and move on. and hopefully you don't, you don't do that too often. and, and one thing I love about the team is they came up with, they came up with a great concept to help manage and balance all of the, some of these decisions that we're making. And they came up with a concept of that's called the suck.
have you ever heard of the suck meeting?
James: [00:14:27] No, I haven't, but I'm excited to learn about it.
Greg: [00:14:29] Yeah. So there's usually beer involved. It's usually late in the afternoon. but there are like, I'm not allowed in the stock meeting. the product managers aren't allowed in the sec mean the marketing team is not allowed in the sec meeting. But all of engineering is there.
And there's often some like a storytelling about the week and stuff that, that may have gone wrong. But what they do is they try to articulate and describe where the biggest pain points are like as an engineer, what makes my job and how do I eliminate the suck for my job? And, You know, those things are hard to prioritize for product managers a lot of times.
but this team does a remarkable job of, of really sort of force ranking those things. and they're very technical discussions. Oftentimes, sometimes it's refactoring code. Sometimes it's working with the infrastructure and dev ops team to automate tasks. Sometimes it's working with a customer support team to automate triaging and troubleshooting field issues, but there's a, there's an effort there to, to prioritize and rank technical investments that we need to make.
To pay down some of the debt that we consciously chose, but in other cases, you know, solve things that maybe we didn't expect. And it's, the, I think the most beneficial thing here is that those, the team really feels empowered to go create the job job and the environment that, that makes it great for them.
If that makes sense. And I think if you look at it, I, this is probably true in most creative fields, but I think particularly in engineering, if, if somebody, if feels like they have a certain level of autonomy, to go like create something great for themselves and for other people, there's a, there tends to be a lot of job satisfaction in those situations.
and so if there, if there, if there's a part of the product or a part of the tech stack or a part of the job that leads to dissatisfaction, empowering them to go fix that is a pretty rewarding culture, I think. And it's worked really, really well at propeller.
James: [00:16:45] Yeah. It's, it's maybe a little bit cliche at this point, but it, it reminds me of the concepts from, from that book drive of autonomy, mastery and purpose, and, you know, kicked off connect all of those and, and, yeah, at least to a, satisfying experience.
Next up, I would, I would love to hear a little bit about, your journey through this, acquisition by, by ResMed. I think it's, something I haven't personally gone through and, and something that I think maybe some of our listeners will be interested in, just, you know, so maybe a little bit of what.
Led up to it. And then, definitely kind of on the other side of it, what the engineering, efforts are and are you merging together your tech stacks or, you know, just how that, how that world works. now the propellors and, alongside ResMed.
Greg: [00:17:27] Yeah, and just a backup on the history here. We had done a fundraise in the. Of 2018 and, mostly early on, we had a lot of institutional investors. so really great partners with safeguard scientific and social capital and amazing partners. Gary Kurtzman and Ted Battenberg were on our board and really terrific, really terrific to supporting the business later on though, the last few rounds were largely strategic.
So we were, we were doing fundraising with, like the venture arm of GlaxoSmithKline, 3m. And then later on we did McKesson and then later on, yeah, in that spring of 2018, ResMed's participated in around. And their interest at the time was that they, they have a, they had a respiratory business that was largely focused around devices and they, they believe they believe that, like a digital aspect to compliment that device is really important to operate in the.
Future ecosystem of healthcare that just selling devices is going to become more and more difficult, as they sort of become commoditized. So they sell a lot of devices and sleep. They sell masks for those sleep devices, and they sell oxygen device or a portable oxygen concentrators, and then ventilators.
And so 20, 2020 has been a busy year for ventilators that ResMed. And, and, but in 2018 they had a, a longterm view of needing to take the data that was streaming back from all of these connected devices and then supporting new business models by finding insight in that data, serving it back to patients and, as well as clinicians.
Most of the devices they sell in respiratory or for an older population. and through propeller, they are able to really move way, way up, further in front of the progression of COPD and start to build relationships with patients, payers, ITNS, the health systems. right when patients are getting diagnosed with CIPD.
So they were really trying to expand the size of the market, the addressable market they had instead of just sort of end of life, late in life. So COPD patients, then you want it to build relationships with respiratory patients, right. Really from the beginning of diagnosis. So that's really, that's really what led to that, to the investment in the beginning, over the course of 2018, we started to work together on some very specific projects.
And it became clear that it was difficult to navigate ownership. So it was difficult to navigate IP ownership. the contracting got complicated, potentially got complicated, just on rev share and whatnot if we were selling together. And, so those things led to a conversation, and M and a conversation there in the summer and into the fall of 2018.
And then we ultimately closed that deal in January of 2019.
as for the, the, I would say post acquisition relationship, it's been, it's been great. I think ResMed's has been quite smart with their approach. , , it really came up in conversation during MNA that the, they, they recognized and saw what made propeller special. They appreciated the speed and the velocity of the team.
They love the brand. They love the relationship we had directly with consumers that they didn't have. They liked the modern tech stack. They liked us operating in the cloud. They loved their data infrastructure, so they didn't, they didn't want to merge for the sake of merging because they didn't want to, they didn't want to disrupt what made us special.
So I give them a lot of credit for being smart. The, the exceptions to that though, is that like collectively we recognize that propeller was starting to get right. Really good at things that we don't need to be good at. So like, examples of that are like device manufacturing, fulfillment and distribution of those devices drop shipping them to patients, getting them outside clinics.
, we became really good at that because we had to be good at it, as a standalone entity. But when you're inside of a $2 billion public company that has a global footprint, then let's hand over that part of the business to the, to the experts. And so really right out of the gate, we started to migrate some of the, like the fulfillment systems over a lot of the operations and device manufacturing work.
it's still getting moved over there. So we've been targeted and tried to be smart about where those integrations are and it's gone quite well. So far so I've, you know, they've, they've made a handful of acquisitions, so they've, they've done it before. And they came into it with a sort of, really sort of a strong point of view in it.
And it worked well for us because, it allowed us to really just focus on building a business and, not sort of hit the pause button so that we could go migrate systems.
James: [00:22:41] And I, I gotta imagine that having them on the investor side helped. you know, smooth, some of that transition through I've, I've definitely heard, kind of anecdotal horror stories from other people of, you know, not really understanding what the, what the technology was going to be like when they, when they got acquired and then trying to, very much spit it for the square pegs in round holes.
It sounds like that's not the case for you all. And that's, that's good to hear.
Greg: [00:23:03] Yeah. You know, we had built a relationship with ResMed's over a few years that, and that ultimately led to an investment. And then that relationship over that year led to some minimum, they didn't mess around the due diligence. I mean, they, they really did their work and looked hard, so they knew they knew exactly what they were getting when that, on that purchase occurred.
James: [00:23:24] So, you know, that kind of brings us to current state or, you know, present today. What are some of the, hard decisions or challenges that you and your team are facing right now?
Greg: [00:23:34] yeah. You know, in many ways, it's the same problems that we had the seven years ago. I would say that, And it's interesting cause now, you know, I'm wearing a hat I'm chief architect at ResMed's now, which, but I still have my CTO role at propeller. So I'm like on paper, I'm spending 20% of my time there and 80% of my time at.
Propeller. It doesn't really work that way. It's really just 120%, but it's, it's interesting is now that I'm operating inside of ResMed regular it's, you know, that's a huge, huge company and they struggle with the same exact thing we do. And that is just having the discipline to focus on fewer opportunities.
and like both being smart about the ones you pick and, and having decision velocity so that you're ready to pivot and walk away from things when, when it's not working. it's a big $2 billion company. we're we're still a tiny, tiny company in that, in that. on that scale and we had the same problems that they do.
So, when you look at a fixed number of resources within product and engineering, where do you go put them to work? to get the most out of them that creates the most opportunity, both in sort of like near term revenue perspective, as well as longterm strategic value back to ResMed. And, you know, I'm sure that you all experienced that at, at redox as well.
It's just one of those challenges that, that never really doesn't seem to go away. I, I keep waiting for it to go away, but, but it doesn't. and I, I tell a lot of people, I, I hired a couple of years ago, I hired a guy to run product. his name is Ted burns, and I tell everybody at propeller that he has the hardest job at propeller because he, you know, he, he really is the gatekeeper on prioritization.
And, you know, the marketing team is coming to him. Like commercial team is coming to him. The engineers are going to him, the customer supporting. David's going to him. He has a never ending set of asks to go do things. And then, you know, he has the, an enviable position of, of telling people that they don't get what they want.
So those, those are hard jobs. And I wish I could tell you that we had some sort of secret sauce here, but the, I think the one attribute that we have that I love is that, we will. Try to come up with some sort of secret sauce and we'll go try it for a couple of weeks. And if it's not working, we'll go try something else.
we're not, we're not really set in our ways, words, there's sort of that like constant learning mode. whether that's something in the tech or just like company building aspect, where we're always just trying to get better. And that's just as true and prioritization exercises as any, any other part of the business.
James: [00:26:29] Yeah. Maybe if you don't mind, could I double click on sort of how that, decision making process works to, to kind of go through that go no go type decision of, you know, sort of who makes the call and what kind of inputs you look for for, for kind of saying this idea or this, this direction's not working.
Let's, let's try something else.
Greg: [00:26:48] Yeah. And do you mean specifically inside of the product or the process part?
James: [00:26:54] more, more, the more the process part, you know, I think one of the, one of the challenges that I see within redox is to, how much certainty do you need before you, say this isn't working? is it just, you need to try a little bit harder or is it that it's actually not working and, you know, that kind of, that kind of actually making the call to.
to make a pivot is it can, can be, more, more art than science sometimes. So yeah, we just love your perspective on that.
Greg: [00:27:19] Yeah. So here's where I think Slack is not doing its job, honestly, that Slack needs to have a mechanism for measuring the, the level of cohesiveness or, The amount of, tension that's happening in a team and then feed that back in smart ways to bring some more insight into what's going on across the team, because that's honestly like that's usually the first signal that trips when something's not working, where everybody sort of agreed on a process and how we're going to force rank and prioritize the work over the next couple months.
And then the DM start flying and the tension starts flying. And one on one meetings are getting put on the calendar to come up with another plan. It's like we left the prioritization meeting, agreeing on what they were. And yet the Slack machinery just went into overdrive to like clump, come up with plan B, like how did that happen?
Right. But. You know what I mean? Like that usually actually is the signal is there just tends to be a little bit too much tension, and stuff bubbles up to me, or it goes up to David and it comes back down and we have to sort of level set a bit, to try to get, get down to it and re agree on one. Why we're choosing the things that we're choosing.
no, cause that's usually what happens. I mean, we have, we, I think we have a lot of standard process in place we use OKR is sort of at David's level. you know, there's only, there's not many, it's like five, I have objectives. They all are very well articulated, key results. We have dashboards for those key results.
I mean, they're all for the most part, they're all measurable. those translate into sort of BI weekly prioritization meetings, that includes product operations, marketing, commercial engineering. and so you sort of translate those okay. Ours into a plan of what's what's happening over the next couple of months.
So I don't know that, Trying to articulate like a really great story of how we pivoted from that. I think that that's the, that's the basic framework and, but there's almost always some sort of back pressure that causes us to go back and reevaluate. But the, that, that underlying like framework is actually stuck with us now for probably about a year, I would say.
James: [00:29:48] Very cool. Well, thanks for joining us, Greg. in closing, do you have any recommendations or resources for developers getting into healthcare or folks who are already in healthcare that are looking to learn more?
Greg: [00:30:00] best innovation often comes from the, from people that are maybe a little bit under-trained I guess I think that, as, as great as healthcare quote unquote is in the United States, like the delivery of that care, the payment models of care are too entrenched. And like fundamentally broken in my mind.
and so like having too much experience in that, I don't know, serves you particularly well. So if, if there's, if there are folks listening that they're wanting to get into healthcare, but worried they don't have experience, I would say don't, don't really let that slow you down. I think you should come at problems with your own like creative energy and experience and look, and attack problems on some new vector.
and don't get too caught up and worried about whether or not you, you sort of have a ResMed to play in that field. The, the one I'm sorry. I, I guess I wouldn't point to a specific resource necessarily other than other than yourself, I think great ideas come from within with us. Very small number of people oftentimes, that, but I would say that I don't underestimate the need within healthcare to build evidence that published evidence that demonstrates the efficacy of your solution.
So it's, I think it's pretty rare in healthcare that a product just sort of wins on its own, you know, like best UX, the best design. You really have to come forward with, with published evidence that demonstrates the efficacy of the platform. And I give David all the credit in the world for, for bringing that.
And he has an academic background. Cause I could say in the beginning, I'm like no heads down. Let's go. Let's build, let's build, let's build. We will sort of, we will have a following by build integrated products and And it's just not true in healthcare necessarily. Like it's very difficult to sell into that market without having published evidence that demonstrates that your solution has efficacy.
and that was true in 2012, when we had our first five, 10 K. And started to sell commercially it's even more so, more true today in 2020, where there is just so much noise. I mean, digital health is just sort of a little bit off the charts on, the number of entrance, the amount of financing that's going into starting new companies.
So it's, it's even more important today. I think that you're sort of leading with evidence rather than leading with leading with a product demo.
James: [00:32:46] thanks so much for joining us, Greg. If folks wanted to reach out to you, well, what's the best way to get in touch.
Greg: [00:32:52] You can find me on Twitter. so at Greg Tracy, G tracy@gmail.com is my personal email. Feel free to shoot me a note there.
James: [00:33:02] Very cool. Very cool. Well, it's really been an honor to have you on the podcast here, Greg, and, look forward to catching up again soon. Thanks so much.
Greg: [00:33:08] Yeah. Thanks James. Take care.
James: [00:33:10] Thanks again to Greg Tracy CTO of propeller health, and now chief architect at ResMed. And thanks to all of you for listening and helping us get this new podcast off the ground. Please subscribe, leave us a review. And if you have any feedback or suggestions for future topics, send us an email@podcastatredoxengine.com. We'd love to hear from you.
Until next time. Thanks for listening the shift six podcast.