Text Version of Interview
Can we kick off by telling us a little bit about your experience?
Absolutely. So I got my start at Mercer, which is a consulting firm and focused there on M&A consulting.
A lot of due diligence for private equity firms, dabbled a little bit into integration planning as I got more interested in it, wanted to move away from the risk management numbers assessment, and more into strategy and long-term vision for a lot of larger fortune 100-500 companies.
So after doing that for a little bit, fell in love, went to WeWork. Was part of their beginning of their integration program development. And then after that, left New York and then joined Twilio out in the Bay area, because I wanted to really get into tech. Started their M&A integration program about a year and a half ago. And am now at Coinbase.
Traditionally we've always focused on valuation, strategy, finding the deal. But now all of a sudden, there's this big emphasis on integration planning much more so than there was previously. Why is that?
Yeah, it's definitely an interesting trend. My role even exists now as an integration focused person, but we always have corporate development focused on the valuation for the deal we're going to get on this company, that it can further our strategy, new customers, new market, new region, but then we're not realizing that there's a huge gap in the what now.
You spent so much time investing in this company, financing it, and we have this great set of talent tech. But what do we do with it? How do we build that into our existing roadmap? You have two entirely separate bodies of companies with different operating models, different financials, different approaches to product, different cultures.
There's a huge gap in how do you then merge those? And it's not an overnight practice as I'm sure you've seen in a lot of your conversations. This is like a one-year, three-year, five-year work, and you have corporate development who's onto the next big thing.
Leadership, board of directors, they want to buy the next big thing to further our strategy even more, but then you have this huge investment that isn't actually seen through. So there's so much more interest and focus now on making sure that we get the right ROI for these big investments.
Can you share with us how you position yourself in a proactive way to optimize the integration planning process? Where do you insert yourself in the deal process?
I love having worked for the companies I do because they're pretty small and move very agiley and it's really easy just to reach out and say, "Hey, what are you working on?" It's a little different when I either report into corporate development itself, because then at least we're under the same hood. I hear about what is in the pipeline all the time. But if not, if I sit in a separate org, which I also have, then I usually have weekly check-ins.
Have to have strong relationships with folks in Corp dev to know what their priorities, how fast a deal is moving and just see what's coming down my way. It's the active engagement and constant checking in with corporate because their timelines are, I'm sure you've seen, they're really slow until they're not.
Until you get to almost a term sheet and then it's like drop everything, let's go. I try to involve myself as early as possible to know what's coming down the pipeline.
I have a couple of questions around that, cause you've mentioned two distinct scenarios that I come across, whether you're a part of the Corp Dev team or sitting outside Corp Dev team. What's actually better?
Verdict's still out. It's funny because probably the biggest thing I noticed is if I'm part of Corp Dev, then I hear everything, right? You get the whole nine yards, the hundreds of companies they scope for investments, for ventures, for partnerships and for acquisitions for acquihires.
You hear all of it and you want to get involved in all of it or you actually don't know which ones you should get involved in when. It's like a grab bag. But it's good because you get to see the full scope of what's coming down your way.
But if I don't report into Corp Dev, I only hear about things when they hit a certain threshold, when it's 60% likely to happen, 70% likely to happen already presented to board. And then that's when I can really dedicate my effort into it. Both have pros and cons, not sure which one's the right way to do it yet.
I hear about getting involved earlier from 90% of the people involved with integration. How early?
That's what I'm struggling with because how early is too early, the 60, 70% threshold, I think is the best when you're about to do a term sheet, when you're about to submit a memo to the board or leadership team.
If I get to see that and be part of that conversation and start commenting, start thinking about the, what next. That I think is ideal. Knowing way too early, when we have first conversations with the founders, that is almost too early.
But even then, couldn't you bring some insights to the table? Wouldn't you have some perspectives on that since you're the one that has to carry it out?
So the funny thing is, I typically love to have our perspective on that and have a lot to say in the background, but I realize a lot of integration planning is a lot of what we can or can't do.
I'm usually the one saying:
"Oh, this is what you want to do? But we have to be mindful. It will take a year, not the three months that you want."
And no one wants to hear that at the beginning, when you're in the middle of negotiations and trying to court a company.
You don't want someone from integration saying, "Oh, that sounds like a brilliant, big idea and lots of fun." But then you have Johanna coming in saying, "Oh, but we really can't do that." I'm the voice in the back of Corp Dev's head at the very beginning, but they usually don't want me bringing all the obstacles.
Can you walk me through the steps in developing an M&A integration program?
It's interesting you asked that because coming into WeWork, it was a really, really immature process, but we built it into an amazing process with an awesome ecosystem of partners throughout the company who we did deals with every time. And it was a well-oiled machine.
At Twilio when I was there, same thing, you start from nothing, but then you build it from ground up and everyone's marching to the same beat. And at Coinbase I hope to do the same.
So the way I've been approaching it, first, what I love to do, especially because these companies are, they're disrupting the industry and whatever industry they've been in.
So I always want to listen first.
- What is the secret sauce?
- Understand the lay of the land?
- How is the org structured?
- Who are my key stakeholders and how do they operate?
- How do they manage their teams?
- How do they communicate with their ecosystem and their leadership?
- How do you make decisions?
- Even that's a big one for us because when you're moving so quickly, and re-orging all the time, no one knows who picks decisions anymore.
My first thing is to just listen, to understand, codify some processes, document as much as I can. Once I have some processes mapped out of what they've done in the past for acquisitions, who's usually involved what works, what hasn't worked. That's when I start bringing in my experience and matching up with programs and processes that have worked previously.
I always have to do that a little bit delicately because you want your company to move super quickly, but you also have to bear in mind how scalable is it? I've been in situations when companies that report can't scale. So we just hire more folks to cover our bases, but is that really the right way of thinking about it?
It's not my tough decision of, we're growing so quickly, we're getting an influx of talent and people through acquisitions and then how do we actually build this into something that's repeatable and scalable? So that's when I kind of marry the previous way of working with my experience and building out a new program for the company.
Once I had this program mapped out, I love to partner with the business units as well to get their partnership on it. A lot of times I can say, "Hey, I think this is going to work for corporate technology" because it's what I've seen in the past.
And then they can say, "no, this is not how we do things at all." We don't use JIRA or we do or reasonably different or using the homegrown. It's less about what I bring to the table and more about being a thought partner with the business unit leadership to build out this program.
And so that's kind of the first big part of like the chew, but then after that, it really becomes important when you socialize it.
Socializing and getting buy-in from leadership and your ecosystem team is so important because documents and processes are great, but if no one wants to do it, if no one actually believes in it, if no one thinks it's helpful, it's dropped like a hat.
No one will actually follow it. So my big thing is socializing it, getting buy-in from leadership, and then lastly, actually trying it out. I kid you not, Kison, the number of acquisitions I've done, and the number of lessons learned I've conducted, there are always lessons learned.
I think there will always be lessons learned for me, I can never always cover my bases. Every company's different, every acquisition is different, every region of the world is different, every founder is different. It's always trial and error. No program is perfect. You always have to approach it in a way that it's dynamic and it's breathing and it's living and it's always improving.
I want to dig into that change management piece because I feel like that's where everybody struggles with it at the end of the day. How are you getting that alignment?
I think I've had the luxury of coming into companies that have previously done quite a number of acquisitions before they even hire me. Whenever I've joined, I meet everyone and they immediately know that this is a pain point for them.
So I have the luxury where they say. Thank God you're here. We've needed this cross-company coordination and connective tissue because we haven't had it before. Proving that this is needed in the company is not so hard.
But to your second question, change management, how do we actually get this to be bought in? It is a lot of bottoms up work, of constantly just understanding the processes and how I can slot in a different way of thinking. Every team will operate their roadmap, their priorities, how they trickle down information across the org a little differently.
So it's for me to sit with them a lot, have a ton of meetings with them, understand how they want to approach it, and then add suggestions. I am hardly any sort of specialist in any company. I'm more of a "Jack of all trades". So my positioning usually is a thought leader. I'll sit with you, understand what your priorities are, and then I'll say, okay, this acquisition wants to focus on this.
This is what leadership wants. This is what we're making investment for. How do you think you can marry your prior way of thinking to how I'm trying to accomplish this goal. And that's when we discuss and formulate new plans, which is why it's so important to have a dedicated stakeholder whose interested in M&A, and wants to work on it and is willing to stretch their role a little bit.
When you're trying to build a company, you're like, "I'm going to do A, B and C, this is how to set goals, this is it for 2020." But then you have to readjust and say, "well, now we have this huge acquisition coming in.
My first three priorities have to be deprioritized because now I need more resources to focus on integration activities." There's no way that I can tell someone that that's what they need to do. It's always the partnering with them, getting the input, seeing what they can stretch, what they can move around and how we can work together.
To change management, it's a slow process, but you're exactly right. Otherwise you can't get buy-in and you can't get people committed to this special project that I'm asking them to do outside of the day job.
Do you have an approach that you follow in terms of, how you get things done, how you get others to get things done?
Yeah, my approach is a little more hands on going back to what I was saying, I love to learn. It's helped me actually plug in. I think whenever a team is two straps or if things change so quickly that they don't have time to pivot, I'll lean in as if I'm like part of their team.
So, let's say compensation, that's something I should have done a lot. When you have a total rewards team that's super strapped, I'll be the one who steps in, helps with those conversations during due diligence. I'll do the side-by-side and I'll make a recommendation based on whatever knowledge I have about that company and our company.
And then it's easier for the total rewards team to respond to what I proposed because I have full picture, I've seen this happen before, as opposed to just giving them a blank slate and saying, "Hey, I need you to tell me what the new compensation structure is."
Which then oftentimes people think, wow, that's a lot of work you're asking me to do. I think the luck that I have is that I get to kind of slot in and help out every team as they need.
How do you balance that between carrying out your integration objectives, but still trying not to disrupt this pace of growth, that rapid rate that's happening with the organization?
That's like an agile framework, every day is different. No two days will be the same. It's constantly learning. Everyone's roadmaps will change.
I've been at companies before where, I kid you not, if we said, okay, ours at the beginning of the year, they'll change at least five times, whether you like it or not, your resources change, your priorities change, acquisition comes, you move a ton of things off, or we restructured the org or we hire a new executive and want teams to move in different directions.
The overarching answer I have there is just to stay agile, stay on top of it, stay agile and continue listening to what's going on.
I like the way it sounds like from you, it's more mindset than anything else. it's just literally have such a change oriented mindset, that you know you're in environment that's going to be constantly changing and just go with it.
Yeah. I love that you say that change oriented mindset. That's probably a better buzz than agile, right? Because agile is usually tied to the PMI framework, but change oriented is that, anything can change at any minute and you have to be okay with it.
In consulting, a lot of times when small things change at much larger companies, the entire process is broken and everyone doesn't know what to do. Tons of meetings now about how to restructure everything, and our approach is entirely changed, whereas in these high growth tech companies, when major things changed, everyone's almost so used to it, they were like, "okay, what next?" And I think that's what I thrive into.
It's always someone coming in and be like, "how about we think about this differently?" And then everyone goes, "okay, let's play it out." And you play it out, if it's the right thing to do, we do it. That's a great way to continue growing as a company.
I will say it's not always fun when you're leading these large scale acquisitions and trying to welcome in tons of employees into your org that itself is changing, but you got to roll with the punches.
I'm curious about when you are going through an integration, but then there's almost something that comes up that may be a great opportunity to shift plans, to capture additional value. Do you have any examples of something like that?
This has actually happened more than once, so it's not so common that large pivots are happening and easiest example, many times I've acquired a company and we're saying, we just want their people, or we want their tech, or we want the region, or we want their customers, but we're going to deprecate the platform, we're going to deprecate their product, we're going to move customers over.
That is just a very common way to approach integration activities because you come in with a bit of hubris, right. of the acquiring company, and you're like, ah, we don't need what they have, we don't need their connections, we only want to parse out this value and it's going to help us grow so much.
But then the few times I've gone in, and then after a couple of months of integration planning with the acquired company leadership, you actually dig into their systems and you're like, actually, they do have something really good going on here. They really do have some soft footing in the market or the tech, or they have some relationship with employees and they can attract talent in a way that we can't as the acquirer.
So then you say, you know what, maybe we don't deprecate the platform or maybe we don't rebrand them, or maybe we don't get rid of other customers. Maybe we want to keep them and grow that customer base because they're able to give customers some sort of value that we, as a larger company can't.
Large scale integration plan has changed. Everyone is affected when you do that. But at the same time, you can capture so much more value that way. So not uncommon.
We talked about getting involved with diligence early. What are the benefits of building out your integration process, pre-diligence?
So, I think there's so much value into building out your integration process, pre diligence. Because a lot of the times I had seen, or at least early on in my career, the traditional way of thinking is we do diligence, and then you take the outputs of diligence and you develop an integration plan.
The milestones, the planning, the huge project plan that everyone has to align to. But then there's so much information that you could have gathered during due diligence. A lot of times we repeat the diligence questions.
So for instance, in due diligence, you ask, what are your benefit plans? Because employment counsel wants to know if you're up to snuff. If you're actually providing benefits that are legal to all your employees, or if your premiums are okay, you're not overcharging your employees, if you have any legal issues at hand.
But then two months later, you go into integration planning, you asked the same questions, but in a different light and you go in and say, "Hey, what are your benefit plans?" You hear about all the plans, but instead of trying to find out if it's legal, you're now trying to find out, okay, well, what's important to employees? Is having cheaper premiums on your health insurance plans important to employees? Maybe, maybe not. And that's so important when we try to merge things like that.
That's why I love to have integration early on during diligence and maybe even before to start thinking about that. How do we kill two birds with one stone. It also helps us move faster. It reduces the amount of conversations and documentation that founders have to provide.
You, of all people, know the questions we throw out founders are massive, a million tabs, tons of questions, so much redundant conversations. They're exhausted, they still have to run their own business, they're making a huge decision. That's how I think it's so important to marry these two processes and get ahead of it so that we can start planning ahead without wearing down founders with redundant questions.
What is the mechanics of that build-out process look like?
During the diligence phase, you have all these folks in corporate development focused on red flags. That's what we always hear "red flags". What's going to kill the deal, I'm going to say with 99% certainty, I've never seen total rewards kill a deal.
For them. I like to have them in the conversation early. Yes, you can ask your legal questions, but having them ask a little bit step further and that's usually when I come in a little bit of that partnership and coaching before the call and say, "okay, it's great to ask this one question, but can we push on this a little bit more?"
And oftentimes even I'll jump in and just like, wait a second, can you tell me more about that? So not just total rewards, but let's say payroll, or accounting, you'll ask, "Oh, how are you doing your books? Are you doing it US gap? Or are you doing it international accounting practices?"
And they'll be like, "Oh yeah, we're doing it like this". And I was like, "Oh great." But then it's on me to either coach my business unit partner, or for me to just speak up and say, "well, that's not how we're doing it. We're not accounting in that way. That's not the frequency that we do it. We do it monthly, or we do it quarterly. You're doing it off cycle."
What's the uplift going to take when we do integration? Is this actually something that we can write off and be like, okay. Later on, we'll tackle it or is this a big gap? Is this something we can't actually overcome.
In the US maybe not too big of a deal, but when you think about internationally, if we're acquiring a company for the first time that's international and we're so used to US-based accounting practices and reporting, and SEC filings, when we acquire someone in Asia that doesn't look at finances the same way we do.
Just even though they're doing it fine, and above board, integrating that with what we currently have is a huge uplift.
Walk me through the relationship cause it sounds like you have integration conversations with the company that you're going to be integrating. What does that conversation look like and how are they looped in?
It's definitely a partnership of all sorts. So you have Corp Dev who leads due diligence, I work with them in the very early stages to identify integration milestones obstacles before we even moved to functional stakeholders.
When we get to the due diligence conversations, Corp Devs will still lead, the functional stakeholder will still lead. I'll be in the backend, like coaching on the back end of how do we think about the what if?
Helping the leaders across it, where you think about the, what if and poking them to really think about long-term planning. So I'll be in the background and also join in just more tactically.
That's when I started developing my high-level innovation roadmap of what our biggest obstacles are and trying to align across the board, timing of how everything should happen together and how we should stack.
Not unlike event planning, if you were to plan an event, you need, people A, B and C to arrive at a certain time, you need your caterer to now come and join the conversation. Then you need your DJ to show up at a different time and your balloons drop at a different time.
While I get to sit into these due diligence conversations, it's on me to say, "okay, so what are some of the gating integration milestones that we have?" "What do we need to align?" "What is it dependencies to something else?" Mapping those out and then feeding it back to the functional stakeholders and saying, "Does this sound right to you?"
How do you build out optimal milestones for the various work streams integration? And what do you use to track them?
It kind of differs, can't speak too much about Coinbase since I just started. At other places, it depends on what the company likes to use, what tools they already have in place.
Ultimately it dials down to what the business is comfortable with. These companies are moving so quickly. You can't just force a project plan upon them.
And I learned that as a consultant, moving in industry. I came in with a big spreadsheet and said, "These are the milestones. These are your trackers. This is what everyone needs to fill in. And give me your dependent views, your due date, your status, the whole nine yards." Not even joking, Kison, they just ignored me.
Everyone throughout the board just ignored my biggest spreadsheet. No one touched it, there's like this, "We're not doing it. This is too much." I'm so focused when we work at a hyper-growth company to be a partner to them.
To see what they respond to, how they like to track their metrics, what are their existing metrics to, what have they already set for ,for 2020. And how do I build in my priorities to align with their priorities?
Like two birds with one stone, I'm helping them. They'll helping me, we're working on it together. I can't just force upon them, all these new metrics that they know nothing about.
Are there other technologies or tools that you use to keep that robust dialogue going?
It's a mixed bag. It's this change oriented mindset that anything can always happen so you have to be able to pivot really quickly. It's a lot of multimedia, hyper aware approach.
We're moving so quickly, some people respond to slack, some people respond to emails, some people like face-to-face calls. My approach is just all over the board. Of course I'm big on documentation.
So I'll always document everything, all the processes, all the decisions that have changed and the implications, but then my approach is pretty bespoke. I'll stop people saying, "Hey, make sure you check this out. By the way, there was a change." Or if I think there's more dependencies, I'll be like, "Hey, can you hop on a call? Let's talk through something that just happened. What do you think? What are your responses?"
Going back to the business unit partnership I'm so focused on. It's so important that I don't just take a decision and say, "Okay, this is what's going to happen next. " It's, "Okay, well this is an opinion of one person, how will this affect you? How should we be thinking about it? How does that affect what we had our reading previously decided?"
I'm multi-media faceted person who approached it all angles. I also think if you're moving so quickly and you're making decisions that change every day, you can't expect that if you drop something into a document or a Kanban or a Smartsheet, that people are going to see.
I'll do that, but you got to notify and bring to everyone's attention and make sure that we continue marching to the same beat of the drum.
What's the BPM? Why have you found them beneficial?
So what a BPM is it stands for B is the big picture, P are your priorities, and M are your milestones.
So this kind of starts at the big picture of what are we even doing? Why are we even here? Priorities is identifying the values. What are our value drivers? What is making us actually want to pursue this opportunity? And milestones are really the things that you're tracking towards. The more numbers oriented, with the key results of an OKR, so to speak.
You're moving so quickly in an acquisition, especially at a tech company in Silicon Valley. The reason you're acquiring company may be different than that you got about yesterday versus tomorrow, or the way you get there will be different or what's important, or what an obstacle you discovered suddenly during due diligence, you discover something past due diligence that changes the entire way you think about it.
But what's so important about having a BPM, which is that big picture and your key values is that when you have a deal team of 60 people working towards on this acquisition and executing upon the integration, it's that North star.
Even if little things come up, you look at this North star and you say, "Okay, we'll take a step back, take a breather. We all get in the woods, but why are we doing this first place? "Are we doing this because we really just want to presence in a new country. Okay. That's the reason then don't get so hung up on customer acquisition or branding.
Like branding is important, but if we're really just want to have a presence in a new country, that's what we should be focusing on first and foremost, that's what we should be using board of director time for it, or executive team time for us to talk about how we really establish that goal.
That's why I just love the idea of going into any acquisition. Honestly, I'd love to kick off due diligence process with my ecosystem with that big picture. I think it's so important, even as you're going to due diligence, like we said, you have to have the integration lens on, what's the lens that you put on for this acquisition particular in that big picture really sets it. We're all aligned. And we don't need to check in with every little decision made. You give every little bit more autonomy in running their processes that way as well.
It's a very common thing to talk about the loss of alignment around the deal objectives. This sounds like a good approach to it. How does it stick? What's the consistency to make sure it's utilized and referenced?
Kind of the M of the BPM is the metrics or the milestones. It trickles down, if your big picture changes, then you need to reevaluate your priorities and your metrics. And what I typically like to do is, every week or every month, depending on how large the acquisition is, you have this feedback loop with all your stakeholders and say," Hey, remember this and big picture.
These are the milestones tied to it. How are you tracking towards it?" And then later on during the integration, I actually do regular checkpoints with the executive team.
I have one person from each of the functional teams come and report out on how they're actually working towards that big picture. And that's really helpful so we don't lose sight of what we're actually doing.
We don't get lost in the weeds. We don't get distracted. You actually have to come to our CEO and say, "This is what I'm doing with my team to progress towards what you originally want to do and get out of this deal."
We talk a lot about synergies in these deals. What's your approach? I'm curious how you track it and what's your approach to managing it?
I have not looked at that in quite some time. When you're at a company that's just high-flying and focused on growth, that is the least of our worries. It's interesting, I think that's just definitely more traditional way of thinking about it. Synergy is of course important.
At the end of the day, when I have downtime, I would love to be able to look back and consolidate things and clean things up a little bit ,and I have. I have done that when I do have the free time. I do focus on like vendor contracts, systems migrations, things of that nature that will get us dollar value synergy. But yeah, I wouldn't see that as a priority, as much as it used to be.
It's almost like a different category, everybody talks about costs and revenue synergies, and here you're thinking gross synergies.
Yeah. Exactly. My synergies today are no longer cost synergies, it's more like, wait, these two people are so brilliant. If they sat in the same room, they could probably build this amazing product for us. And that's what I'm going to capitalize. That's what I'm going to focus on. The IP, the tech, the knowledge share, is just so vast in the companies out of that. That's definitely more of a focal point.
What do you do to ensure that there's realistic synergistic fit to achieve ROI?
I think this is more on culture fit is where I would actually see the biggest obstacle. I'm not sure I have the right answer. It's a lot of conversations. It's a lot of evaluation. A lot of value setting, I think more often than not.
Going back to Twilio, I have only the best things to say about that company first of all. They are so focused on the Twilio magic, that when we will look at companies, and we see is the founder, is the way that they work, does it actually align with the Twilio magic? Do they truly care about being an owner when all else fails? If shit hits the fan, are you willing to step up and not pass the buck?
And really, and we also said "draw the owl", to build something out of nothing, to create a new process and to make the best out of what you're given. That kind of mindset was something we cared about a lot in the companies we acquire, or if they come from the same cloth. And if they are, then our teams will work together and hopefully jive well together and achieve our line.
So your view around synergistic fit to deliver the ROI is really more around culture.
I'm super biased. With tech companies, we're not really developing like a physical product. We have no supply chain issues. Our highest cost are our people, our talent, our people, their capabilities, and the way that we work well together. One plus one, hopefully with two people come from the same cloth and really excited and curious will be three.
Do you tend to keep the founders around or does your view about earnouts and their implications for integration?
This one goes either way, because this depends on the founder entirely. Personally, I don't think this is something that an acquired company should decide, ever.
It's always should be an open conversation of, do you ever want to stay around? Are you a serial entrepreneur? Why are you selling your company? Are you doing it for the money and you want to exit and start something new? Do you actually want to join us for a greater mission? Do you actually think that you also see the value we see in you and you want to be part of our growth?
I think that should be a completely open conversation. It also helps us structure the deal instead of designing all these complicated retention strategies and the purchase agreement. A clear conversation of, "Hey, I want to exit ." It's like, "okay, then we won't kind of retain your for five years." Where you're unhappy. We're unhappy.
It's like, this is what you want then you should be able to step away if you actually only want to see this for three years, because you want to help out with the integration, that's all the gas you have left in you, then great.
We'll try to structure retention program that'll help you stay for three years and do the best that we can do to support you. I don't think this is ever something that a buyer should determine.
Before you actually purchase the seller, don't you do the due diligence on operation by asking at least 150 or so questions for the idea?
Yeah, it's not even 150. I'm sure it's like a hundreds , it's like a hundreds of questions on due diligence before we actually integrate. And maybe what you're trying to get at is, before you can start to look at integrations, I guess the purpose of this talk was more to say that integration planning does come in during the due diligence phase process, right? Like integration planning, if you're doing it post acquisition, your really late to the game
Would you say you should've access to all of it?
I like to have access to all of it. The more information, the better, the more I can plan, the more obstacles I can identify.
Simple example is, if I know that one of our teams is looking to expand their product in a certain way, or we're trying to enter a new market, but at the same time, we're trying to acquire in any market or acquire a product.
That's something that's good to know ahead of time. So at least I can start having those conversations in marrying the two parts of the company. So we all talk, not too early because then I'm just spinning up an entire integration plan or not, but early enough that I can at least identify those high level conversations that's going to happen.
Hey, I want to thank you for the time today. This was a great interview. Those of you listening, want to follow us or challenge us on Peloton. I have a hashtag M&A science going on. Hannah, first person to join that hashtag cause I just made it the other day. Until next time. Thank you so much.