 Hello everyone and welcome to this week's product school webinar. Thanks for joining us today. Just in case you didn't know, product school teaches product management, product leadership, coding, data analytics, UX design, and digital marketing courses online and at our 16 campuses worldwide. On top of that, every week we offer some amazing local product management events and host online webinars, live streams, and ask me anything sessions. Head over to productschool.com after this webinar to check them out. Today we have an awesome guest presenting. I'd like to introduce you to Bill Erdman. Bill is a high tech product management veteran, having worked in the profession for the past 30 years. Bill's specialty is in product areas that are disruptive, where new product entrants challenge the norms of an existing product market. He has experienced many of the business and product risks associated with bringing disruptive products to market, where companies under invest as the outcomes are unknown and then acquire to catch up. Bill has onboarded several of these acquisitions into much larger companies as former director of product management for both Cisco and VMware. Feel free to leave any questions for Bill in the comments of Facebook and I'll be sure to ask him them at the end. Without further ado, let's welcome Bill. Thanks for joining us today. Great. Thank you, Dan. Good morning to everyone and good afternoon. Before I get started, Dan, where do I get my presentation up and going? The same button is not there anymore. It might be at the top of your screen. Okay. Gallery view. Let's see. Start video. Stop video. Start video. There's no screen share there now. See if this helps. Sorry for the interruption. Those are on the session. We'll get going in a second. Are you seeing the screen? No, I still don't see it. You could share it with me if you'd like or let's see. Sometimes Zoom just it disappears. The button to click screen share. Are you in, do you have the presentation pulled up in full screen in the background? I do now, yes. And no, there's no button for it. Wow. Let's see. Share. Let me try this. There we go. All right. Nice. Great. Okay. And that's in full screen. Well, great. Thank you for the great introduction, Dan. As Dan mentioned, yes. I am a product management veteran. I have worked for multiple different high-tech companies in my career out here in Silicon Valley, primarily in the networking space. So you're going to hear about my experience being very network-centric. But, you know, and those who aren't familiar with networking, it is an infrastructure technology tied to computing and storage and a series of other things. It's basically the backbone that connects the world together these days from an information technology perspective. I've worked in the market since its inception early on in the 80s, where it was a $200 million business. It's now a multi-billion dollar. I work in the data center space, which is actually a $10 billion market in business opportunity. And of course, there has been a lot of interesting advances in that technology. Now, as Dan has mentioned, I have worked on multiple different product areas. Some of those where the outcome has been based upon the company not investing, under investing, and needing to make an acquisition. And those can be very disruptive. So it is really my pleasure today to basically talk to you about, you know, the difference between what I would call product management. And that's certainly how I worked in my early days as a product manager in product leadership. And I think that's one of the primary differences when you start to think about whether you should build or buy from a technology perspective. Product leaders have a much more open view on technology. They're not as wedded to their own product. They're more wedded to the success of the market, the company, and the customer versus just the success of their product alone. And all too often, I think product managers get caught in their own vortex of the company and the product they're representing versus that in terms of what the market and the customers really need in having a broader perspective. So I'm going to go through all of that. And then I'm going to talk a little bit about what it means once you acquire and bring in a company because it's not all rosy and pretty. There's a lot of organization work that needs to be done. There's a lot of work to get the go to market to get the product out to the customer itself. And then there's issues with regards to it being disruptive, even with customers who may have been buying your product to begin with. And now you're going to be switching them out and having them buy something else. And when you are in the technology space, customers make a three to five year technology investment, typically in your product. If you're switching them out after they're a year or two down the road, it is very disruptive and can be very disconcerting to them. Okay. So as this slide says, M&As, well, they look sexy and pretty. And I know in a lot of B schools, you study how an emergent acquisition can really leverage the company and add a lot to the books, whether it's from a finance perspective or from a technology perspective, most acquisitions fail. I think 90 to 90% of acquisitions do fail and it's either because the decision was made incorrectly upfront and or there was poor execution in terms of onboarding the technology and building into the product revenue and product streams. So having said that, I think a good place to start, especially for those that are fairly new in their careers and aren't necessarily familiar with how senior management thinks and behaves. And as I've grown in my career, I've certainly had a lot more exposure to senior management. I typically work now at a VP level. And I can tell you quite honestly that most senior management resist acquisitions. And if you as a product manager come up with the conclusion that you think you should be making an acquisition to cover the market and or better compete, don't be surprised if you get a negative reaction. And it's primarily because the senior management believes that they've already had their bets covered. A lot of big organizations work top down. They have a big investment portfolio. They've made their decisions for the years in terms of how they're going to fund the business units and the products behind them. The management teams have led them to believe that their bets are covered, that they've got the right level of investment. They've already made 10, 15, 20, $30 million worth of investment in a given product area. And so why should they go out and basically have to acquire and bring in a new technology and add more to their cost, if you will. And a lot of senior managers will view acquisitions as a weakness in how they've been managing. So they're fundamentally against it. If they have to go acquire, it means that they haven't been executing correctly internally. So these things you should definitely keep in mind in terms of if and when you're in a position to make a recommendation best way to address your market space is through a merger or an acquisition. Don't be surprised if you get a lot of pushback. And I will discuss how you can address that pushback with a well-documented business case when and if you get to that point. Okay. So having said that, let me give you a couple of the pitfalls I have seen as a product manager. And then I'm going to basically discuss with you what you can do to overcome those pitfalls. And it's really sort of a mental framework in your head, if you will, versus anything else to become more of a product leader. So all too often what I've seen is the product managers get lost in their own organization and look at, you know, if they only had these three more features, they would win and beat their competition and they would do marvelously well. And so they are really working hard as they should be pushing on the organization to build in the next set of capabilities so they can better compete. So they're working with their manager to sponsor perhaps a little bit more investment. They're working if you're in high tech, you often will work, you work directly with engineers on getting the development done that you need. And in high tech it typically takes six to 12 months to get any feature out of significance. And you're really working hard and outlining that feature, talking directly with the engineers, articulating that feature out to the salespeople itself, talking directly to customers, and just basically pushing really hard on your organization to get something done. So you get a little bit myopic, if you will, and rightfully so because it's your job as a PM to really push and enable the organization to get the things done that you need to make the product successful in the marketplace. It could be a go-to-market, you know, it could be a sales issue, it could be a channel issue. Typically for most product managers it is a feature or product development issue. So they spend a lot of their time pushing really hard on the organization and being very focused. Often they're unaware of the resources really required to achieve success. They may be, and I've been in this situation many times, especially when it's a new product to market, that, you know, the organization believes in engineering has told the senior management that, you know, you can do it with 20 engineers and that when you look out into the market, actually look at the competition and maybe it's a focused startup, they may have 50 or 60 engineers. So while your engineers may be great and most engineers think they are great, it's hard to basically make up ground when you have 20 engineers and your competition has 60. And that's a perfect segue into the next slide. And so from a product leadership perspective, you take a broader view and you have a broader understanding of the market. So instead of being focused on just what your organization can develop and deliver and what you can push on to get that organization to come up with something so you can be successful, you actually build out your understanding of the market. So you understand competitively what's going on. You have to have an ear to your competition. The more networking that you can have out into the market, whether it's peers that are working for a startup and or you you establish relationships with analysts that are basically looking across the market. And they basically are writing reports about what's going on in this space and or in actually where the best information often comes is from customers. So being out and talking to your customers and hearing what they're seeing from the marketplace and from the competition gets you a stronger, broader view of the market. And that's where the leadership really starts coming in. And so you become the expert, not just on what the current product is that you represent and the features that you're driving, but you understand what the competition is doing, how many people that the competition has in building out that product. And the product leaders are recognized as the experts and product managers are recognized as experts as well. But the differences is that a product leader is recognized as a market expert, as a competitive expert, as almost an analytic expert, not just that you are the one that knows your product best within the company itself. And that's really the difference here. And so then the product leaders, when you have a broader set of information that you're working with, you will know fundamentally whether your product that you're representing is going to make it or not. And then that is where the true leadership comes in. And it will be something that you have in your head. You'll know neatly whether it's going to make it or not. You'll know quantitatively based upon the resources, the investment, the features, your pricing, and even your go to market. Those are all quantifiable. But you're going to also know just innately based upon what you see in the marketplace itself, whether you're going to make it. And then at that point, if you fundamentally believe that you're not going to make it, this is when you begin to start thinking about, and especially it's really coming from a mid or big product company perspective, when you start to think about making an acquisition that's going to really address the space. And that I think is sort of the tipping point. But you don't get there by being just focused on your own product. And you don't get there by just being focused on a set of features that you think the engineering can build in. You get there from an acquisition perspective by having a broad understanding of the market, a broad understanding of the competition, and a broad understanding of what the customers really need. And though fundamentally that you're going to have a product miss. Okay, so once you get to that point, where you know fundamentally you're going to have a product miss, you begin documenting the business case. In the business case at that point will come easily, believe it or not. You think, oh, geez, you know, business cases, they're 10 pages, they're 20 pages, they're 30 pages. And I've seen the gamut. I've seen acquisitions made based upon, you know, a two page PowerPoint presentation. And typically, the best way that things are socialized in today's environment is actually through a PowerPoint presentation. And you begin to document, you know, all the things that I just mentioned from a competitive perspective, from a from a future perspective, from a customer requirement perspective, you begin to really start pointing to the gaps, you're realistic, and you have the ear of your your executive management, that your product development team is not going to going to make it. Now, this is where, you know, you've got a little bit of, how do I say it, a little bit of an issue where you may disenfranchise your best partner, which is the team making your product. And if you go to management and say to them that your team that was really the ones that are developing the product aren't going to make it, you've got a little disenfranchise going. But remember that if the product misses, you all lose. So at some point, you've got to disenfranchise them. If you fundamentally believe that you've got to get out of this, you know, the way to get out of dodge, if you will, is through this acquisition. So what are some of the business imperatives? Well, in the technology world, there are a lot of strategic and solution reasons why you'd make an acquisition. And technologies can get very complicated, especially if you're in the infrastructure space as I am. And I'm actually going to walk you through a good technology example of what I went through when I was over at Cisco where Cisco knew they wanted to get into delivering voice packets across Ethernet technologies. They thought it was just a transport technology play. But voice needs a set of applications to really fundamentally deliver a complete solution. Customers don't buy networking for voice. They buy voice for business productivity. And it's not just the way you transport the packets, if you will, or the voice information. It's all the productivity that goes with it, that being voice known a series of other things. So the point being here is that you might see a gap in what you're doing because it's not a holistic complete solution. And the customer basically might want to buy your piece of technology, but if it's missing something else that needs to go with it to complete the product itself, that's where an acquisition may come in. So it may be something complimentary that you need to actually drive the success of your own product. Or again, it could be a product that is better than what you're working on. And it's just that you're not going to get there from the way the company has been building it out and so on. There are other financial reasons of why companies make acquisitions. I'm not going to go into that. That sort of is outside the realm of product management in my view. Now acquisitions do come in and people do have to manage those because typically in the high tech it is some sort of product or service offering one of the company. It does require product management to help go drive it, but it's not really the core of what I see as a product owner when you see there's a significant gap in the product space you're working on. It's either typically because you don't have the right feature sets and you can't complete or you're not going to be able to sell your product because it's missing other components that have to complete the solution for the customer to have a success on it itself. Okay, now there are a couple of things that go with the product in the acquisition itself. The acquisition can help drive the core vision, core business. And I've seen a lot of business cases made where the company needs to acquire to actually deliver on the core business goals. And again, I'll go back to I'll touch upon this example as I talked through the Cisco experience I had. And also, as I just mentioned, the product is a direct fit from a product solution perspective, you actually can drive a broader product portfolio, increase the revenues of the company itself. And actually something I learned early on in my career is that in a fast growing market where there's a lot of product entries and the company really wants to get ahead of it, they'll make multiple different acquisitions to basically capitalize on the market itself. So there are a couple things that you need to understand when you start to think about an acquisition. Basically, one of the things is is making sure that that acquisition aligns with the customer's sort of acquisition models. And in the enterprise sort of infrastructure market, customers have well known acquisition models. So an acquisition of a product needs to make sure that it is fits into their stack from a technology perspective. But in some cases customers like new technologies, but because again, as I mentioned, it's typically a three to five and often a seven year investment, they don't necessarily trust a startup. If they were to basically go buy somebody's product, in that company where to go belly up after a year, and they invested it in heavily, and they're running their business on it, they don't want to be left out in alert. So sometimes an acquisition makes sense because it fits into your stack. And if you're in a bigger company, and you're giving the well backed sort of guarantee that you're going to be around, no one gets fired for buying IBM, no one gets fired for buying Cisco, sometimes the startup products fit better into a larger company because a larger company can financially back them and give them the sort of the guarantee that the customer's looking for. Okay, so let me give you a good example of what I went through. And this was back in the early 2000s. I was over at Cisco and we were in a rapidly expanding market where we were selling switched Ethernet and basically selling Ethernet back in the old days when people actually had desktop computers in their cubicles. We were selling a lot of data ports, but we knew that that market was going to get mature and that basically the 30 or 40% sales growth we are seeing year over year was going to slow down because there are only so many desktops that people are going to connect. And so what we realized is that if you could also ship voice over the data ports and those connections could be not just for desktop computers, but you could also plug your phones in, we're going to sell a lot more switched Ethernet ports. So we basically worked figuring out how to ship voice packets over data transport technology that being Ethernet. And we did a really good job at the transport layer and being able to deliver voice in a real-time way and with non-disruptive it made it made voice very clear and whatnot. And I was a product manager behind a lot of that infrastructure transport and actually a product manager where we actually came out with an Ethernet phone, if you will, which is pretty much the norm in today's market itself. The problem we were having though is that people didn't want to just buy a phone and they just didn't want to buy another connection to the on the data center switch or the campus switch. What they wanted was a complete experience of when they picked up the phone, they were able to get voicemail, they were able to transfer a call, they were able to do a bunch of other things, they were able to get what we call an integrated voice response system where they could basically provide a menu of options in a series of other things and there are a bunch of other pieces that were already in the marketplace for people using phones that were being delivered on an alternative transport technology. So we thought we had enough engineers to go develop those apps. The company was pushing really hard on getting the revenue going as fast as they could and we had a 70 person team developing these voicemail apps in a series of other things and when you looked out across the market which you quickly realized that it really required a 500 person team and sales couldn't hit their numbers because they couldn't sell a complete voice infrastructure and that goes to the full stack that I mentioned earlier. So what was driven actually through sales was the need to make acquisitions of technologies that delivered the applications that ran on top of the voice transport and so I was there as the product manager trying to drive those applications of people with a 75 person team. We were under invested. I was completely focused and working with that engineering team and we thought we could deliver on it but the field said no we can't. So we ended up buying three companies and those three companies came in and they took over my space and so because I was so focused on my own success of the product and the team I was working with, basically I lost the leadership role in driving those applications and the the companies we purchased came over and took over the leadership roles in those spaces and I actually had to go off and do something else. So my point here is is that there is especially in high tech you know solution reasons of why you want to make an acquisition. We were trying to drive a core capability here. We needed these applications to go drive the core market. We are under invested. I was too focused internally to realize that we weren't going to make it. We had to make an acquisition. It was driven by the sales team saying the only way I can hit the numbers is by doing this and it was organizationally disruptive in terms of what I was doing even though I was the owner and I actually knew the space really well. So having said that once and I hopefully touched on you know some of the reasons and the differences between a product manager and a leader here when you get to the point of making an acquisition once you make that acquisition it is really important and I can't emphasize this enough if you are behind the acquisition and hopefully as the product leader and you make a recommendation to make an acquisition and they basically make you an owner of it. It is then really really important for you to ensure that there's a successful integration and a successful execution of that acquisition and as I mentioned earlier on you know there will be a lot of resistance to an acquisition coming in and believe it or not especially with the engineering team that wasn't able to deliver on it there's going to be a lot of pushback and there will be people within the company that want to see that acquisition fail. So you as a product leader have to work really really hard I think is the best way to put it and making sure that acquisition is successful especially if the company has spent a lot of money for it and the acquisitions can be 300 million 500 million a billion multi-billion the bigger they are you know the bigger the stakes the harder they fall if you will and you know HP Cisco lots of different companies have failed miserably at it some of them have heard their stock price and a lot of it has to go with the good be with good leadership bringing the product in. So the first thing I would tell you is is that you need to what we call de-risk the roadmap and what that means is is that you've got to rationalize the new product coming in with the product going out and often if it is a product that is meant to basically take over for the product that you've been working on because you haven't been able to compete you're going to have to come up with a roadmap that basically says obsolete this or obsolete that and not basically continue down two tracks of the same technology because that's not worth the investment and it's really hard and it takes you know school of hard knocks to figure out which product you're going to basically obsolete and which one you're going to go forward with but it's really really important that you rationalize that because if you don't customers are going to be confused engineering is going to be confused sales is going to be confused and it will lead to bad results. The other thing is is that if you're going to bring this acquisition in and that product has been outshipping in the marketplace it's really important to get that product onto the company price list as fast as you can to basically get the product rationalized into the look and feel of the concept of there's the company logo some company documentation obviously you would put a product pricing and ordering behind it and to get it out to the field as fast as you can with a good product data sheet and basically a PowerPoint presentation so they understand what it is in the sooner and faster that you can get it to market basically price listed and understood by the field the better the execution and the better the excess success and track rate so what I have seen and I've been behind several very successful acquisitions is the better you can execute on the product coming in through the company and getting out to the market the faster you can do it obviously following a lot of the product management practices of the company from a pricing and and and part number perspective the more successful you're going to be okay so it really comes down to after the acquisition at least initially having a really good go-to-market plan and my best advice to you if you're in that mode is to have that go-to-market plan baked before the acquisition is completed and what I've seen VMware has been very successful with this Cisco got better at it as time went on is is that once the acquisition has been agreed upon at the executive level typically there's a two to three month cooling out period the SEC has to approve it a series of other things it doesn't mean you just sit and wait for for the acquisition to happen you are working with that team coming in coming you know working with them and coming up with the go-to-market you're taking their product part numbers you're mapping them over into the company product part numbers you're building out the price list you're building out the product collateral so the day the acquisition closes you're ready to ship the product that is really good execution from a go-to-market perspective and the other thing is is that you want to ensure and this you know we have said in our industry over and over again that sales people are coin operated and if you understand what that means is they are pay to play they will sell what they get paid on it's really really important to make sure that the product that is coming in through the company now from an acquisition is compensated either the same in a lot of times even more to make it successful so sometimes with a new acquisition if it's viewed as really strategic or really needed to basically overcome a competitive issue or to go drive the core product and it's a clear strategic driver executive management and you as a product manager will recommend that they actually get double the compensation on it so that will incent your sales people to go sell it if they know they're going to get paid twice as much commission on versus something that they've already been selling so there are things you can do that basically go drive you know a very successful go-to-market okay and so as I mentioned as the product comes in you have to rationalize it from a roadmap perspective you have to begin to understand if they're overlapping roles if it is something that's overlapping with what you've been doing you're going to need to understand that and you know from a personal experience perspective where I had a 75 person engineering team we replaced it with three different acquisitions we ended up with overlapping roles a lot of those engineers mean and product management itself we had to go look for new jobs so there are you know disruptive things that happen organizationally and you just should you should just be aware of that again these things you know they're not all rosy if you will so my half hours up my final takeaway here is as a product leader the best advice I can give you is to remain objective keep your eye open on the marketplace don't get sucked into the vortex of your internal organization and think all the time that you know that if you get these next two features out everything is going to be rosy you need to understand what your competition what your customers really need and what the marketplace is really requesting and be realistic with yourself and then realistic with your management team you as a product manager should be the expert you should understand the competition better than you know your senior managers now they may understand it because they've got a broader view but that doesn't mean that you shouldn't either you should have a broad product and marketing view and then when you do make an acquisition document the business case and there are plenty of of examples out there of how you can document a business case from an acquisition perspective and then you know really important that once the deal closes during that sort of quiet period go work like hell to make sure you've got the go to market you've got the sales you've got the skews you've got all the right presentation it's in the data sheet so when the deal closes you're ready to go sell sell sell sell and then the other thing is be ready for organization chaos and fallout because acquisitions are disruptive especially if they do overlap in terms of what your company has been doing itself and I will end there and thank you for your time hopefully this has been informative and I'll turn it back to Dan okay Bill thank you so much that was awesome that was jam packed with insights so um well that's it let's see if we have any questions here in our everyone said thank you so much for these more advanced topics cool okay well bill thank you for joining us before we leave um I just wanted to give all of our audience some more info on our upcoming courses and events so they have the resources to become a product manager our product management product leadership coding data analytics ux design and digital marketing courses are taught online and at 16 campuses around the world by top-notch product managers working at companies like google and facebook in addition to that product school also offers weekly events every wednesday and thursday at our 16 physical locations so uh if you're located near campus make sure you stop by one of our weekly events you can also find us on social media at product school and be sure to keep up with the latest product management content at the product blog at product school dot com thank you all for joining enjoy the rest of your day and i hope to see you next week bill have a great day thank you thank you for the opportunity appreciate it bye now