Episode 192: Brian Fugere’s Blueprint for Merging Teams and Technologies
I had an enlightening conversation with Brian Fugere, a seasoned product and engineering leader, about the intricacies of integrating acquisitions and standardizing product operations in a growing organization. Brian, with his extensive experience in managing marketing, engineering, and product teams, offered a wealth of insights on the Product Thinking podcast.
During our discussion, Brian shared his approach to merging diverse teams and cultures, emphasizing the importance of creating a cohesive and agile environment. We explored the challenges of aligning different product management practices across acquisitions and how establishing a unified framework can drive efficiency and innovation. Brian also provided a fascinating look into the technology evaluation process during acquisitions, including the challenges of migrating legacy systems and the strategic considerations for creating value that drives customer adoption.
Dive into our conversation to understand Brian’s strategies for managing growth, integrating teams, and leveraging technology effectively. Discover how his experiences and insights can help you navigate similar challenges and enhance your own product management practices.
You’ll hear us talk about:
15:43 - Balancing Build Versus Buy Decisions
Brian addresses the decision-making process behind building a product in-house versus acquiring it. He states that time and resources are the two critical factors in this equation. The company evaluates whether acquiring an existing solution would be faster and more cost-effective than building one. Brian is keen to stress that a company must also assess its internal competencies when making this decision. Symplr, for example, is better at buying existing solutions and optimizing them, rather than building something from scratch, as they’ve built teams specifically skilled in acquisitions and improvements.
29:05 - The Role of Subject Matter Expertise vs. Product Expertise in Healthcare
In healthcare, balancing subject matter expertise with core product management skills is critical. Brian explains that in assembling product teams, he intentionally mixes product experts with subject matter experts to foster cross-learning. As he points out, healthcare is a particularly complex field where deep domain knowledge is crucial for addressing nuanced customer needs, but pure product expertise is still required in order to run processes efficiently. For example, ex-nurses who deeply understand the intricacies of healthcare systems may not have the product management background but are invaluable for shaping the right solutions. Getting that balance of expertise right is vital for such an important field.
37:46 - Balancing "Carrot and Stick" for Customer Transition
When it comes to migrating customers from older platforms to newer ones, Fugere outlines the complex balancing act involved. Simpler has a dedicated migration team, reflecting how integral this process is to their strategy. Fugere's guidance to product managers is to aim for "sufficient parity" with the older platform to facilitate a smooth transition. However, they also need to offer enticing new features that encourage users to migrate willingly. The key is identifying high-priority pain points from customer feedback and rethinking problematic areas to add real value—like applying AI to automate parts of the scheduling process in their workforce management product.
Episode Resources:
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn
Intro - 00:00:01: Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perri.
Melissa - 00:00:37: Hello, and welcome to another episode of the Product Thinking Podcast. Joining us today is Brian Fugere, Chief Product Officer at Symplr. I was excited to talk to Brian because he has a remarkable track record in driving strategic vision and operational excellence, particularly in the healthcare technology sector. At Symplr, he has been pivotal in leading all corporate strategy, product strategy, product management, and UX functions. His extensive experience spans various industries from healthcare to media and includes senior leadership roles at companies like Virence Health and GE Healthcare. Brian and I are going to talk about what it takes to merge acquisitions in a company successfully. We're looking at tech implications, culture implications, financial decisions, the works. This is an issue I've seen come up time and time again, and Brian has extensive experience. Symplr acquired 12 companies in the last four years. But before we talk to Brian, it's time for Dear Melissa. This is a segment of the show where you can ask me any of your burning product management questions. I answer them every single week. Go to dearmelissa.com and let me know what's on your mind. Here's this week's question.
Dear Melissa, Scrum, as well as several scaling methodologies, encourage the use of release planning. This approach can help improve the predictability of features being released to customers, to help address feature fatigue, and to help manage stakeholder expectations. However, a common trap is that product managers and product leaders become more schedule-driven versus outcome-driven. What advice would you give to product professionals and their leaders who believe they need release planning to improve their predictability with customers and stakeholders without them falling into, well, the schedule-driven build trap?
All right. I've worked in a lot of companies where this has been the problem. Release planning tends to be focused on what we're delivering to customers, but the problem here is it ignores discovery. So when I've worked with companies that do safe, they love the idea of big room planning because it gets everybody in the room to talk about what we're going to actually do. So many times, this is the first time that different teams in different areas around the business and the portfolio actually have come together to discuss as a portfolio, not just one team, where we're going to build and how we're going to work on initiatives together. So that part of it is great. A big piece of feedback I hear from those teams, though, is that they try to shove everything they want to do into that big room planning. And then when they miss the release, they get penalized or they might discover something that changes everything, but people look at it as set in stone. So it's like, okay, we discover something we're going to release in three months, but we have no room to go back and fiddle with it because it's committed. I've also seen this be an issue in back-to-back scrum. So a couple companies that I've worked with have done it where everybody in the company needs to sprint on the same cadence. So it's like sprint one, sprint two, sprint three. And there is no time for discovery in those sprints. It's just like, if you miss a sprint or you don't plan your sprint, that's it. And again, we do some kind of quarterly planning. They commit to all their sprints. That's a lot, right? That's a lot to do on a company level. And that's a lot to do on a team level, honestly, for a long time. What's happening here is companies are not baking in any time for strategy. So they just expect everybody to keep sprinting forever.
It's like feed the beast, but don't give the beast any time to go figure out what it should be eating. You need time to craft the meal. You need time to actually do the discovery and learn things. And then you need the ability to pivot. So what I find is that we need a balance here because on the flip side too, you do want to do release planning. Release planning is good because it helps you think about financial planning for the company. What are we releasing and how is that going to help our customers? Customer expectations. You don't want to be releasing things in, let's say, healthcare to doctors when they're in the middle of a surgery with patients. It's been done before. You want them to be able to be trained on things and get up to speed with it before you take critical stuff and switch it up. So in B2B, we can't be like, ah, ta-da, here's a bunch of stuff that I just changed on you every single day. So we need a balance here. So we need a balance for the ability to do discovery, the ability to change things that are not working, pivot if we find out that the products we're committing to are not the right things to build. And we do need to be able to plan somewhat for messaging, sales, and customer expectations. So what I see work is that in those release planning sessions, we're only planning for what's already validated. That means that we might not be trying to optimize for filling in absolutely everything in every moment of our time during that quarter. It's more about how do we just commit to the things that we know we're going to be able to do that will produce value. So you want to scope the release about the problems you're solving and the value that goes into it to actually make it solved, right?
Something that's going to go out to customers where they go, wow, and they feel value for it and they come back to you and they give you money and you can adjust and watch your metrics grow. Something that will actually increase retention, something that will actually increase usage, right? That's what release scoping is about, making sure that there's enough value in that release. But you don't want to scope it based on getting every little feature in there. And you don't want to do your release planning to basically mock up every little second of a team's time over the quarter. So instead, I like to think about it as pulling. So you're going out, you're doing discovery, you're validating things, you're breaking them down into releasable chunks. Once something is validated and scoped, you pull it into the release. You say, okay, it's ready for this release. Let's get it lined up for Q2. Let's pull it in. Instead of coming up with a bunch of ideas and then pushing it into the release. That's where people get tripped up. So it's not that release planning is bad. It's that I don't think a lot of companies out there are accounting for the work that it takes to develop what goes into that release is not the only work the team is doing. They still need to do discovery. They still need to do experimentation. They got other things going on. It's not about quantity of things going into the release. It's about the quality, about what they're actually going to do during that release. And every single thing that gets release planned should have an outcome metric on leading indicators that show that we're going towards a valuable metric. I'd make that a requirement for actually making a release plan.
If you don't have set metrics and success metrics that we can measure in a way to implement them on that scoped out product that you're going to release or a feature set, it doesn't make it. It does not make the release plan. That should be a requirement there. We need to also remember that V2 is not impossible. We want to get enough out to change the metrics we care about and to provide some value. We want to do that quickly. So our customers can benefit. But it's not about just shoving absolutely everything we can do into a release. And leaders need to remember that it's not about the quantity. It's about the quality. So what are those releases going to do? I'd rather have a bigger release focused on one major thing that's going to move metrics gigantically than have 15 things that are never going to move the needle. That's a perception that we need to change when it comes to release planning. So I hope that helps. And if you are out there struggling with this, remember, you need to bake in time for discovery. It's not all about sprinting as fast as you possibly can. If you have more questions for me, go to dearmelissa.com and let me know what they are. Now, let's go talk to Brian. Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund's Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at hustlefund.vc/mp. Find the link in our show notes. Welcome to the podcast, Brian. It's great to have you here.
Brian - 00:08:29: Hey, thanks for having me.
Melissa - 00:08:30: So can you tell everybody a little bit about your career journey so far and what brought you to Symplr?
Brian - 00:08:35: Sure. So, hey everybody, Brian Fugere. I'm the Chief Product Officer at Symplr. I define my career in sort of three stages. One-third marketing, one-third product, and one-third executive. If you think about marketing and product, they're two sides of the same coin. And oftentimes, the same leader leads both groups. And I've had the pleasure of doing that multiple times throughout my career. I have been in software the entire time and have really enjoyed the process of building delightful products for our customers.
Melissa - 00:09:04: So we were talking a little bit before we started about your healthcare journey and coming to Symplr. So Symplr is all about healthcare operations. Can you tell us a little bit about the company and what's the history behind it? How did it grow to where it is today?
Brian - 00:09:19: Symplr is a company that's dedicated towards enabling the delivery of care. We focus on healthcare operations, which you can loosely translate as the back office. Everything from provider credentialing, workforce management, contract management, compliance, quality, safety, all kinds of different point applications that historically CIOs have had to manage on their own. And sometimes, I was just talking to a customer the other day, they have 600 separate applications that they're managing across their health system, which if you imagine that as a CIO, it's a nightmare. So we're creating an enterprise platform effect for healthcare operations for the first time. In healthcare, you have a platform for an EMR, you have an ERP platform, you have a RevCycle platform, but nothing in healthcare operations. And so we're leading the way creating that for our customers. I've been in healthcare my entire career. I've led the development of EMRs and PAC systems and RevCycle analytics tools. Most recently, prior to Symplr, was at GE and Athena, where we led a couple different little businesses that one of them eventually found its way to Symplr, and I came along for the journey. When I arrived, it was primarily a credentialing company focused on vendor credentialing and physician credentialing. And since then, we've gone on an acquisition tear around 12 acquisitions that have really broadened us out to be this healthcare operations platform.
Melissa - 00:10:40: 12 acquisitions is a lot. And how many years did you do the 12 acquisitions?
Brian - 00:10:45: Four years. So it was a lot.
Melissa - 00:10:47: That's a lot. I'm sure a lot of people are listening to this and I haven't been through acquisitions and mergers before too. There's a lot of challenges that come along with that, right? Trying to put a lot of different pieces together. Can you describe some of the challenges you've identified and you reflect on thinking about bringing 12 different products together or teams together even?
Brian - 00:11:07: There's multiple facets to each one of them. And if you think about it, the first biggest question that we're always asked is which product is going to be go forward? Is it the one that you have if you already have one? Or is it the one that you're about to acquire? And the philosophy that we've taken is a best of approach. Which one is the best at doing whatever it is? And we try to not have any kind of bias towards any sort of existing product that could be in our portfolio. For example, prior to my joining, we ended up with like six or seven provider credentialing solutions of all different sizes. And we're going to get that down to one. And so if you think about just the acquisition challenge related to that, how do you determine what are the features and functions from each of those seven that need to find their way into that final one? What's the sufficient parity necessary to get a customer to migrate from something old to something new? That's a huge challenge. And then if you extend that, you can look at it from a people perspective, like you said, the teams. How do you know who to keep and who isn't necessarily going to be a good fit from a cultural perspective?
So one of the things that we have is a little litmus test at our director and above level across product and engineering. It's a little bit of a thought exercise. And the way we look at it is if we took two people from product, two from engineering or mix and match, and we put them in a room and ask them to solve a problem, could they actually solve it and work together collaboratively to get there? And if the answer is yes, then they're probably a good fit for our organization. And if the answer is no, then we're something that isn't working out and we need to go dig into why not. Is it a culture thing, a personality thing, a work style thing? How can we help them be successful? And that's really the key that we want to deal with as we bring these two teams together. And then if you then extrapolate that across 12 acquisitions, you're doing some phase of that all the time as you really try to reconcile this portfolio. And it proves to be a taxing challenge at times.
Melissa - 00:13:04: For a lot of product managers listening to this, some of them are probably not involved in acquisition decisions, right? Mostly likely it's leadership who's really talking about it or evaluating it. Even some CPOs I know aren't even involved in those conversations, which I don't think is fantastic or great or probably successful. For the people listening to this who don't have as much experience, can you tell us a little bit about why you would do an acquisition or why you would try to acquire a different company rather than trying to just build parity or feature parity on your own? What are the different reasons for that?
Brian - 00:13:39: It can come down to two major things. When we look at any acquisition, the first thing that we consider is expansion of our total addressable market, or TAM. Does it give us the ability to compete in a new market or sub-segment of the market where we can increase our ability to grow? So do we get access to new customers or does it give us the ability to sell something else to our existing customers that complements what we already have today? TAM expansion is the largest driver of how we've done our acquisitions in the past. What we've started looking at is the other reason to do an acquisition, which is often speed to value. Can I acquire my way to whatever that particular value is that I'm looking for? And will it get me there faster from an ROI perspective than if I tried to build it on myself? Or is there some sort of special technology or special knowledge in that company and the employees that I want to integrate into my own? And so we're actually looking at two small acquisitions right now where we're in the final paperwork stages, where one of them is a complementary technical asset. It's more of a service than actual product, but it fits really nicely with some of what we're already doing. And the other one is purely a technology tuck-in. We have a product that we want to make better. We know how and what to do. This company has an asset that they don't want anymore, and we're going to take it off their hands because it will tuck in really nicely and accelerate our speed to value for improving what we want to do. Neither one of them are very big. We can get through the acquisition process very quickly. It's a grand total of like seven people across the two acquisitions. So integrating them should be fairly straightforward, and we can get to that speed to value curve pretty quickly.
Melissa - 00:15:20: When you're evaluating an acquisition, as I just said, I hear a lot of griping from product people who are not involved in these conversations. Can you give us the CPO perspective of what you're looking at to evaluate if this acquisition should go through? What kind of challenges you'll have at the end of the day? And what's your checklist to say go or no go? And how do you work with the leadership team on that?
Brian - 00:15:42: First thing I look at is market fit. Does it fit within the addressable market that we believe we have the right to win and play in? So that rules out more acquisition opportunities than we actually let through the gates to even take a look at. Hey, this doesn't fit with us. In our particular world, we don't really want to offer clinical solutions in healthcare, so we stay away from those. So anything that smells too much like clinical, my immediate reaction is no. I just don't want to go in that route. So that's the first thing. Does it fit? And then the second one is, then I start looking at the product itself. Is it a modern tech stack? Is it an old tech stack? Are there security issues or not? We have a diligent partner that helps us with those issues. And they go in and they figure it out for us and they're a third party. So theoretically, they have a better access than if we were to start asking questions ourselves. And then we come out of that part of the process and make a determination of, what is it going to take to integrate it into our portfolio and raise it up to the standards that we expect from our products from a performance perspective, technology perspective, whatever it may be. And then that feeds into the entire decision-making process with the executive team of, okay, can we sell it? Can we make money off it? Will it help us grow? Will it delight our customers? Will they buy it from us? And then if all of those are yes, then we look at the product itself and say, okay, what is it going to take for us to raise it up to our level of expectations? And can we afford that given the nature of the deal? And then yes or no comes out at the end of that process.
Melissa - 00:17:12: Sounds like that's not a one-person job either. Who's supporting you on that?
Brian - 00:17:17: No, it's usually a partnership between me, our CTO, our CISO, and then the analysts on our M&A team. And we all collectively work at it together.
Melissa - 00:17:27: So you do have like an M&A team inside Symplr who are just identifying opportunities and working through them.
Brian - 00:17:33: We do. We've got three people on our team and they're constantly feeding me opportunities to take a look at. I try to be a yes, no decision very quickly. Does it fit with our needs, our strategy, our market, whatever the case may be. And so if yes, then we'll take a look at the book. If no, we move on.
Melissa - 00:17:48: When you were first starting out with these acquisitions and first got to Symplr, did you take a step back? I imagine you did, but and build this product strategy from a needs perspective and then say, what was your build versus buy decisions there? Like, how did you first think about creating the strategy and then deciding, is it build versus buy?
Brian - 00:18:06: That's a really good question. When we first started, the strategy wasn't so much around healthcare operations, because even at the time, that didn't really exist, and we've created it along the way. The strategy more was, how do we take this credentialing platform and turn it into more of a GRC platform? And what we found over time, coincidentally, is that hospitals don't speak GRC, but they do understand operations.
Melissa - 00:18:32: What's GRC?
Brian - 00:18:33: Governance, Risk Management and Compliance. That's a big deal in finance and in basically every other industry except healthcare. And so in healthcare, they just think of it as operations. And so we had to pivot a little bit from how we were going to market as well as what's the overall strategy so that when we think about creating an offering for our customers, we wanted to create a robust portfolio that would enable a lot of cross-sell between all the products into the existing customers. And so the initial strategy was take this credentialing platform, make it a little bit bigger, add a few things to it, and see how the customers react. And they liked it, which was good for us. And then the train just kept on rolling. And we kept adding to the portfolio. And over time, evolved to the product strategy into much more of a platform approach, where we looked at how do we integrate the products between each other? What are some common services that we want to offer underneath so that they can all consume the same cloud services to make it easy? Common look and feel sitting on top. And all of a sudden, if you do it right, you end up with what feels like a platform without starting all over and rebuilding it from scratch.
Melissa - 00:19:44: That's really neat. I like stories like that where it evolves out of one direction, but then we start learning and then we say, hey, there's another opportunity over here, which sounds like what you guys came up with. One issue I've run into a million times in companies too is that they will do acquisitions because they're trying to gain a new subset of customers or they will try to get a new market share, but they have no strategy for how to actually integrate that into their existing systems. Or is this going to be upsold to our current clients? Or is this us trying to attract a new market because we're trying to boost our valuation? But how does it all come together? And I've been part of a company where we had something like three or four acquisitions that were probably over a couple hundred million dollars each that nobody knew how to monetize or put into the system because it was like a land grab of, let's get into this, let's get into that, let's get into there. But there was no cohesive strategy. How do you make sure that your strategy stays strong and that the acquisitions don't overrun where you want to go.
Brian - 00:20:47: I have also been in companies like that. And in healthcare, there are a couple examples through recent history where companies have done exactly what you described, where they will go acquire lots of different assets that don't on the surface seem to make a lot of sense. And then two or three, four years later, you find out that they didn't know what to do with them either. And they start selling them back off again at pennies on the dollar. I learned a lot by watching those happen, and I wanted to make sure that as we went through this process, the overall product strategy, the overall go-to-market strategy was the thing that we measured the acquisition against. Did it fit with our overall strategy became one of the key litmus tests as we were going through that checklist, as you described it, of whether or not this acquisition made sense. And if it did, then great, we'll continue on. But if there wasn't a fit, it was just another reason to get to know. And in the M&A world, getting to know fast is really the game of the game.
Melissa - 00:21:43: When you're considering these build versus buy decisions and you are looking at, should I acquire versus should I buy? When would you say like an acquisition is better? Like you're always have to deal with something, right, for the acquisition. You have to integrate it. You have to do that. What's your determining factor when you say, hey, it's better to bring this one in versus let's just build this ourselves? Like what types of things tip it?
Brian - 00:22:05: So a couple of things. When I look at potential acquisitions, is it going to help? Would it be better to build it or buy it? The first key question is time. And so it's time and resources. And so if you think about the classic product triangle of time, resources, and money or scope, time, resource, scope, the scope is fixed in this case. And so it's either time or money. And how much of both are you going to be able to have? The acquisitions give you the ability to have something that's 100% done, 80% done. You may only have to do a little bit of work to get it to where you want it to be. But you may have to do a lot of work to get it to where you want it to be. Or, you can try to build it yourself. And then the question comes down to the competency of the company and the team that you've built on what you're really good at. Our CTO and I would describe ourselves as really good at buying stuff and fixing it. We would not describe ourselves good at building things from scratch. And that's because we've built a team that's optimized for the acquisition deal flow of acquiring something that already exists and just making it better. Building something from scratch is a different skill set altogether. And especially in the product side, you have to have people who are accustomed to thinking ahead with the architects about what is this thing really going to be at the end of the journey so that you make some good decisions up front.
If you don't think in those terms, you can make a lot of decisions that are going to cost you a lot because of rework down the road. We're not optimized for that. And we're optimized for taking something that somebody already built and then figuring out how do we make it better, faster, stronger, more appealing to the customers. That's an entirely different skill set. And so you can do all the financial buy versus build analysis you want. You can look at time to market and speed to value, whatever you want to call it. But at the end of the day, the biggest thing is what can your team handle? Can your team handle building something from scratch? And here's the piece of white paper and ready, set, go. And what is that going to take and how long? And are you really good at that or not? Or are you better at taking something that already exists and then optimizing it for your market? And I think for us, we found that we're better at optimizing and it has shaped how we think about building things from scratch. We still do it, but not very often.
Melissa - 00:24:13: When it comes to the team, do you have any morale issues with that? Are people like, oh, I'm tired of just cleaning up after everybody else and getting handed this thing? Or are they all on board with that mission?
Brian - 00:24:24: It definitely does affect morale sometimes. I think overall, most engineers, most product people would love to build something from scratch and then watch it being used for a long time. I built a PAC system back in 2007, 2008, which is a radiology imaging system for healthcare. And my wife was a patient a couple of years ago, and the orthopedic surgeon was using the thing that I built 15 years later. That was pretty cool. And so there's a lot of self-satisfaction that goes into when you can build something from scratch and it's being used by customers for a really long time. Conversely, there is also a good amount of satisfaction in knowing that you could take something, make it a little bit better, and then delight the customers more so than what that original company was ever able to do, because you can fit it into a larger ecosystem and add even more value than what could have happened when it was on its own. And so I think there's two sides to that coin. And I think people will gravitate to one or the other to get some of that high morale kicked out of it. But ultimately, if you can balance out your stream of work so that people have an opportunity to do a little bit of both, that's the ideal situation.
Melissa - 00:25:37: That's a good point. I do see a lot of CPOs out there. And this has come, I think, from product managers or developers too, where they separate out their teams. And they're like, that's the build and maintain team. And this is the innovation team, right? Or the people who do net new. How do you do that balance? How do you make sure people get opportunities to work on different things?
Brian - 00:25:55: We actually intentionally try not to do that because it creates a have versus have not experience. And so whenever we do something new from scratch, we try to rotate people through there to make sure that they get the experience. Similarly on the like, tier four support kind of teams. We'll rotate people through there as well because nobody wants to be stuck dealing with bugs and defects the entire time either. And so we're very intentional, we'll making sure people get the opportunity to do both and try not to create any kind of environment where somebody gets pissed off because they're a have or a have not.
Melissa - 00:26:33: When you're looking to integrating some of these newer people who are coming in from your acquisitions, what kind of challenges have you experienced culture-wise? How do you try to make it cohesive into one company instead of, I came from this company. This is how we do it. We do it over here.
Brian - 00:26:48: During my time at Symplr, I've led marketing and engineering and product simultaneously for a few years and then whittled down to product. But one of the things I'm most proud of is the engineering and product level of collaboration and sort of integration and how we do what we do. We view it as one big organization. Our CTO and I manage it together and we work across both lines equally. As we do acquisitions, the engineering organization has very much standardized on the practices that they follow and how they're going to do it. And the engineers that come into the organization adapt to those pretty quickly. It's very much an agile organization. They do leverage Kanban in some places, but it's mostly Scrum overarching safe framework. It's very clean. On the product side, we introduced the concept of product operations a little over a year and a half ago. And the entire focus of the product operations team has been to standardize how we do product across all of these acquisitions. So we're far behind the engineering teams from a standardization perspective, but we wanted to focus on engineering first. In the product world, it's very much about getting to a common set of, here's how we do it at Symplr. Here's our way, Symplr way. And what we've asked the teams to do is to adapt to that. And we've tried to take the best from each of the acquisitions wherever we can to make it easier for everybody to just do it one way. And there's something familiar for all of the teams as they adopt this common set of approaches.
As teams come into the building and into our culture, it is a change for them depending upon the level of sophistication that they had as a product organization prior to the acquisition. Some of our acquisitions were more sophisticated and more adept at product management than we were. Some of them are way behind us and where they had a bunch of SMEs doing product, but not people who actually did product. That has translated into this whole need for product operations as a way to drive standardization across all of our teams. So everybody's following the same process, using the same artifacts, coming up with the same outputs in the same format. Thinking the same way because it creates a predictable feed into engineering, which is what they need to go as fast as they possibly can go. And so we've had to deal with some cultural issues. We've had teams that are open and adapting to what we wanted to do. And we have teams that have been doing it the same way for 30 years. And they're not really interested in changing. And there's been a lot of discussion, very friendly, of course, on why are you not cooperating as much as we would like you to cooperate and adapting to this new way. It's definitely a lot of change management, as you would expect, but everybody sees the value of it. It's just a matter of getting them all to sign up and do it.
Melissa - 00:29:37: Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. It's like getting the buy-in from people to actually want to work your way. When you're looking at that too with the product operations team, but also these new people coming in, do you have like a way to collect feedback on how they did it before? Is there any set process or is this just something that comes up naturally once you all dive in?
Brian - 00:30:26: We've been trying to tackle a major chunk of process at a time. So the first thing that we went after was release management. So we defined a number of levels of releases. With each level of release, there were different artifacts that would be necessary, different processes, etc. When we did that, the first thing we did was to go talk to the teams and say, how did you do it in your company, given that you were either ahead of us or behind us, depending upon which. The second one was end of support, end of life, because that's a major function for us. And we're working our way through some of the really big rocks right now. And we try to engage and get buy-in from everyone. What we're looking at now is, do we need to adopt a standardized product management framework? Is it like pragmatic or something like that? And for that, we actually formed a cross-team committee and let them go figure it out. So here's your charter. I don't know if we need one or not. I had my hypothesis. But I want you guys to go make that decision. And if you decide that we do need one, why and which one should it be? And so they've been off on this research expedition trying to figure out what do we need. And if we do need one, how would we implement it within the company, in our partnership with engineering? How does it feed into their processes? How does it feed into marketing from a product marketing perspective to support them? And then how does it interface with the entire rest of the company? And so I think we're a couple weeks away from them making a recommendation. So I can't wait to hear what they're going to say.
Melissa - 00:31:54: I'm curious too what they're going to say now. So when you are looking at these people coming into your integrating processes, what else are other challenges that you found when it's about bringing teams together?
Brian - 00:32:06: Some of the other challenges come up that you would never expect. Some of them have to do with my title, my compensation. Sometimes they're coming from companies where they've neglected product altogether and people haven't had a raise in three or four or five years. And all of a sudden you're faced with a situation where they say, hey, I am woefully underpaid. Sometimes it's the opposite. Sometimes they're coming in with pay scales that are out of whack on the other side and that they're too high. And so you have to figure out how to deal with that. I think that the biggest challenge, though, really is around the depth of knowledge of pure product management principles. And so as we acquire companies, as the product teams join our organization, we look at and evaluate what kind of teaching do we need to do so that they can get caught up as quickly as possible with the rest of the teams so that they can at least handle the processes that we run on a daily basis with engineering. And then we'll take it from there.
Melissa - 00:33:02: Do you see generally across the market or the companies that you're working with that the product management skill sets are lacking, specifically in healthcare or other places you've been looking at?
Brian - 00:33:10: I do. I think healthcare in particular, not the world's strongest marketing environment, and it's definitely not the world's strongest product management environment at all. I've been in enough healthcare companies where you can see that product is an afterthought. Marketing is usually just limited to sales support. And so the requirements, if you will, for products are often driven by engineering and it's direct feedback from sales. And so there's a lot of whiplash that goes on because they don't involve the product function as much as they should. And over time, I think that will change. I think software companies within healthcare are starting to see the value of a strong product organization, but it's just a cultural change that will take time across the whole industry.
Melissa - 00:33:52: Yeah, I see the same thing. I've also seen it in finance. I feel like healthcare and finance have been the two largest industries that I've trained personally over the last 10 years. But in both of them, I think it's a similar thing where we had a lot of subject matter experts come in as product managers, but not necessarily pure product people. So I've worked with some of the smartest people in healthcare, I feel like in the world, but the product management was something that they need to learn. And it's really interesting once they learn it because they go on to do really cool things.
Brian - 00:34:19: That's right. And one of our areas that we focus on is compliance, quality, and safety. In general, quality in healthcare is not an area that most people are familiar with, but we've got some fantastically smart people, ex-nurses for the most part, who really know that area well. We have to help them a little bit with the product processes because the company they came from, it wasn't their forte. But boy, they know their stuff.
Melissa - 00:34:44: It's a good point too. I think a lot of people ask me, especially in these two different industries, but healthcare for one, do I need subject matter experts as product managers or do I need a product manager that's a subject matter expert or do I just need somebody who knows what to do with product management? How have you thought about crafting your teams when it comes to baking in the different subject matter expertise that are required in healthcare versus getting the pure product management principles?
Brian - 00:35:09: I've intentionally tried to get a mix on each team. At the product manager level, I really try to have people who are a mix of the subject matter expert and people who are product experts so that they can help each other out and coach each other so that they can learn and then both of them develop from there. At the director level, I'm starting to lean more towards a pure product person to help facilitate the process who can then go and learn enough about the domain to be dangerous. And they can rely on those subject matter experts that are on their teams.
Melissa - 00:35:40: Why do you think that's important at the director level specifically?
Brian - 00:35:43: At the director level, it's a lot more around understanding how to talk to customers, how to deal with the cross-functional requirements of the company, how to support marketing and engineering in particular, so that you can then be that customer-facing sort of voice of product. Yeah, it's important that you understand your domain for sure, but you don't have to be the absolute expert because you have one on your staff that you can bring into you in a meeting if you need it. I think the understanding of the product process is the higher requirement when you weigh the two against each other.
Melissa - 00:36:16: My follow-up question to that is, what do you think about the leadership levels? So this is a debate I always get into as well. For a CPO, I have a lot of companies who are like, hey, I want to hire this CPO. They don't know anything about product management. They've never really done any of it before, but they're super good at the market, right? They know that market cold. They've been in it for 20 years. They're a great visionary, strategic person here. Do you think they can learn the product pieces of it? And then on the flip side, I've had the other side. This is a great product professional. Can they go learn the market? What have you observed as you get higher in companies? What do you think works?
Brian - 00:36:48: The first person that you describe, the one that has all the market knowledge but no product management experience, should go into strategy and be the chief strategy officer. I think the ideal answer for healthcare anyway, or any market that has a high level of domain knowledge required, is to find somebody who has both. And there are plenty of people out there who understand the market and who've been in there for a long time and then who really understand how to do product management. I think you're selling yourself short if you don't get both. And I think you also are setting yourself up for a problem. Because if it's a domain expert only who doesn't understand product, you're going to piss off your engineers and you're going to end up with a roadmap that is just not coherent. You're just going to chase whatever happens to show up in front of you at any given moment. If you over-index on the other side, where you have somebody who's really good at product management, you're going to have great artifacts, great processes. You'll have a great integration with engineering and marketing, but they won't know what to build next. Or they won't know how to say no, because they don't have the context to understand if this thing is a real requirement or if it's just this one thing for this one customer. And so if you're doing the hiring for a CPO in any industry like healthcare, where you have to have that domain knowledge, hold out until you get somebody who has both.
Melissa - 00:38:07: Have you seen it work? I've seen it work well, depending on how hard it is to learn the subject matter. Let's put it that way. Some stuff in healthcare I know is incredibly complicated, but I have seen it work well where you have a CPO who's very great at product management, but the entire other leadership team is all subject matter experts. So they're like the visionaries or the strategic people. They know this market cold, but then the CPO is like, hey guys, you have 18 different applications out here with absolutely no strategy behind it. We can't package and sell this or what are we going to build next? And they're good at pulling things out of other people to help understand that strategy and understand the market landscape.
Brian - 00:38:45: I think you probably can get away with a situation like that. I think ultimately, you have to have enough of a mass of people with the domain experience to be able to really provide that guidance and insight. Like in our, we have nine people on our executive leadership team. Five of us are what we would call healthcare people, four of us are not. And it works out fine.
Melissa - 00:39:07: So there's a good balance. So from the acquisition standpoints we were talking about before, too, talking a little bit about bringing the teams together, the cultures together, the processes. Let's talk a little bit about the technology. Like I said at the beginning, a lot of product managers aren't usually involved in these discussions about, is the tech good? What do we have to think about through here? When you are bringing in an acquisition and deciding how to integrate it into your platform, what are the types of things you're looking at from a tech and product standpoint to make sure that's done successfully and that you can get your customers from the old platform into the new platform or taking them from one place to the other?
Brian - 00:39:45: So when we're evaluating the acquisition from a technology perspective, the first thing we look at is security. In healthcare, like any other place that has PII or PHI, protecting that data is the number one requirement. So we focus on that. And then the next thing we look at is, what is the tech stack? What's it built on? What's it built in? Is it cloud-based? Is it on-prem still? If it's on-prem, do we need it to move it to the cloud? What is it going to take to move it to the cloud? If it's already in the cloud, what's it built on? Is it a language that we have competency in the company already? Or is it something where we're going to have to go develop it? We did an acquisition a few years ago where we ended up with one of our larger revenue-generating products that was written in a language called Clojure, that none of us had ever heard of before. And what we've had to do over time is create our own Clojure engineers. Because we couldn't go find them. And when we did find them, they were very expensive. And so as we're making that evaluation, how does it fit within our existing engineering knowledge base becomes a super interesting question because what we're learning is that we don't want a bunch of one-offs scattered throughout the portfolio where we've got multiple languages that we've had to support. And that just becomes a problem trying to hire for that or even contract for it. Because if you're going to go contract for those people, you're going to pay a premium on top of the premium you're already paying because they're contractors. And it just gets super expensive. And that doesn't work for anybody either.
Melissa - 00:41:15: AthenaHealth was all built on Perl. And I remember we had to go try to find Perl developers. It was so hard.
Brian - 00:41:21: Yeah. I mean, we still have some Power Builder. We have so many old... We have something that was written in Access. It's just built on a database. I mean, here's some really old products.
Melissa - 00:41:33: It's amazing how many different languages are actually out there too. And you never realize it until you start getting into all these different companies. And you're like, what is this?
Brian - 00:41:41: Exactly. Oh, look, another gift that I'll keep on giving.
Melissa - 00:41:44: So we've got multi-languages to look at. Let's talk a little bit about how are you thinking, like, how do you plan for that migration? What makes you go, okay, this is enough to get all of our existing users over here from the acquisition to say like, hey, let's get onto this bigger platform. Like, how do you think through that?
Brian - 00:42:04: Migration is a major motion for us. We have a steering committee that meets every month. We have monthly working committees for each of our parts of our portfolio. We have actually somebody that works for me that all they focus on is migrations. So it's a big deal for us in what we want to do. The guidance that I give to the product managers is try to create a level of sufficient parity where they can move over and then you can white glove support it if there's a missing piece of functionality that they just have to have. And then you can do some sort of rapid response to put a hot fix out or something to get them what they need to do so that they're moving forward. And that happens. And you just have to anticipate that you're not going to think of everything that they're doing, regardless of how much you plan for it and you think you've covered everything. The other part of it is encouraging them to build something that the customers are going to want to move to. Especially if you're going from on-prem to the cloud, it's going to cost them more. It's just, that's the reality. And so you have to be able to deliver more value when you get them to the cloud. So that carrot and stick approach then takes over. So you're building a carrot, you're handing them a carrot. Is it tasty enough to get them to move? And most of the time it's not, unfortunately.
And so then the stick comes into play and that is like, when do I end of support or end of life these products? And that becomes a really interesting calculus because when you do that, you are inviting your customers to pick their head up and look around in the market and see if there are alternatives that they like better. And so you're inviting risk from a turn perspective. And so all of this has to be orchestrated to say, do I have enough people that have already moved to serve as references to get the rest of the people to move? Is there enough of a carrot to get them to move? And when do I deploy the stick to get everybody to move? And there's nothing trivial about that. It's a really hard thing to figure out. And what we found is that we are starting to push our stick further and further out as we are waiting for people to move. Because we don't want to introduce more risk from a churn perspective. And so there is definitely a balancing that has to go on there. And it encourages our product people to figure out how do I build something so enticing that they'll just move on their own.
Melissa - 00:44:15: It sounds like this too gets into prioritizing some new shiny thing that it's not just let's build it for parody and make it look exactly the same. Like what's that piece of value that's going to make people go, oh, it's worth the headache of moving on to this new platform or paying more to get there. How do you encourage your people to identify that value?
Brian - 00:44:36: So I actually ask them to look at their existing list of suggestions that they've accumulated over time. And typically what they'll find are one to five, say, really high pain points from a workflow perspective in their application. And I encourage them to reimagine and rethink what that would look like. We have a workforce management product, which is about staffing and scheduling for nurses. There's a particular area in developing a schedule for nurses. It's called the balancing phase, where you've figured out who's going to be in the schedule. But you've got to then fit them into the schedule based upon their needs, their desires, their qualifications, the needs of the patients, the acuity of the patients. And so it's a big sort of a mess until you get it all worked out. What we found is that was a huge pain point for our customers. And that's where we're actually applying a little bit of AI pixie dust magic to go help make that part of the process easier for them. And so while it's not going to be the thing that closes the deal, it is a thing that will make them more interested in using it because it makes the nurse manager's life so much easier. And if your product teams can look across their products and say, okay, where are the challenging issues for our customers? Can I rethink that part of the process or that part of the product to make their day-to-day easier? You have an opportunity to really score a major win to get them excited about moving to the new version.
Melissa - 00:46:03: When you're working with them too, like you said, it might not be the thing that closes the deal, but it's the thing that helps the users. When you're in acquisition land, when you're taking users from that existing product and trying to bring them over, is it like reclosing a sale? Are you basically keeping them to the end of their contracts? How should product managers think about that? Because I imagine it's not having a fully captive audience, right? They're going to be like, oh, there's a branch of my system that's got sold. Now I'm dealing with something else. How should they consider those customers? New customers, existing customers, about to churn, what's the pressure there?
Brian - 00:46:37: I think ultimately the challenge is always going to be how do you manage your customer base and keep them moving forward? And the more value you can add over time, the better for everybody. I think with existing customers and even those that are thinking about potentially moving off and churning to someplace else, developing a high say-do ratio is really what's most important. Here's what I'm going to go do. Here's when I think it's going to come out. I'm committing to these particular dates. I'm going to deliver on those dates. You have to have a track record of a high say-do ratio for your customers to feel comfortable that when you tell them something is coming, it's actually going to show up on time. That builds trust. It builds confidence. It builds an understanding. And it also builds forgiveness over time in case you happen to miss. Like, hey, we made it for the last seven. We missed on number eight. That's okay. Just get back to it for number nine. I think for prospects, it matters too because they're going to do a reference check and they're going to hear about it from one of your existing customers. And so ultimately from a product perspective. Yes, you want to introduce new things. Yes, you want to make it bright and shiny and exciting. But ultimately, if you are a predictable, dependable partner who is constantly hitting their dates, your customers will be more happy than anything else.
Melissa - 00:47:48: I think that's very wise advice out there for product managers. If you were going to give a couple points of advice to somebody who's first time leader, product leader, managing through an acquisition or a merger, bringing these other companies in, what would you tell them?
Brian - 00:48:02: Take your time and go fast. Take your time from an analysis perspective to make sure you really understand what you're buying. Because it's always going to be a surprise once you get them on the other side of signing the paper. And then once you get them on your side of signing the paper, go as fast as you can to integrate them into your portfolio. Because the longer you drag it out, the more disaffected the employees get, the more questioning about their future they get. And the customers ultimately wonder, what in the world are you doing? And so it's a lot of preparation. Take your time. Make sure you prepare. Once you sign the paper, go.
Melissa - 00:48:36 Great advice for people out there. Thanks so much, Brian, for being on the podcast. If people want to learn more about you, where can they go?
Brian - 00:48:42: LinkedIn, it's easy to find me. I'm the only one out there. Or bfugere@symplr.com. S-Y-M-P-L-R.
Melissa - 00:48:49: Great. And we will link to that in our show notes at productthinkingpodcast.com. Thanks again for listening to the Product Thinking Podcast. We'll be back next Wednesday with another episode. And in the meantime, if you have any product management questions for me, go to dearmelissa.com and let me know what they are.