 Hi everyone. Today I'm going to be talking about the hardware versus software product management roles. What does product management look like when you're in the hardware space versus the software space and kind of contrast them. My name is Ruben. I'm a product manager at Square. And I have also been in the hardware space for a few years as a product manager as well. So let's get started. First things about me. Like I mentioned earlier, I'm a product manager at Square. I am the PM for the Square website. So the entire public web. Prior to this, I was a product manager at Intuit. I was part of the QuickBooks family and I was the PM for contractor payments, which is one of the products within QuickBooks. Before that, I had taken a small break to go to business school and I was a PM in the hardware space. I was working at Cypress Semiconductor, which got acquired by Infineon prior to my time at Intuit. My first job was actually in Russian banking, but I realized pretty quickly that I really enjoy working in tech. That was something I did during undergrad. I'm an engineer and I really enjoyed that part of my... I just enjoy working on technical solutions and solving problems using the power of technology. So I made that switch fairly early on back into the tech space. And I definitely enjoy every bit of it. I'm glad I made that transition. I do love... Like I mentioned earlier, I do love learning and writing about tech. I actually have published articles about IoT design in various leading journals because I really enjoy just kind of absorbing tech. I am a tinker at heart as well. I really... I spend quite a bit of time on the weekends just working on different gadgets like coding on Raspberry Pi and just little home automation projects. I definitely enjoy that. So that's a little bit about myself. During a conversation today, I'm going to be covering the different stages of the life of a PM and kind of contrasting them for hardware versus software. I'm going to... The first two topics, product development and stakeholders are going to be focusing more on the life of the PM. And the second group of topics, which is skills to succeed and how to make the switch, will be more focused on how to... What do you need if you are looking to make that switch from hardware to software or software to hardware? What skills you need and how do you actually more tactically kind of make that switch? There are a few things I won't be covering today. I won't be able to cover the specifics of my role at Square or Intuit. Honestly, it's not even relevant for what I'm going to be covering during the rest of our conversation today. I also won't be covering how to become a PM. That's the question that is addressed through a lot of other events that are organized for product school. And I'm sure there are a lot of better resources out there that you can get to actually know how to become a PM and introducing the basics of product management. I also won't be covering interviewing tips and tricks. I'm happy to do that offline, but I don't think I had the time to actually cover that today. The last thing is I frequently get asked this question, you know, what's interesting in semiconductor space or in the fintech space? Well, what would that look like, you know, a few years from now? Again, I really enjoy these kind of conversations. I'm happy to do that offline for anyone who's interested. So today I'm going to give you the key takeaway, you know, the summary of our conversation up front for two reasons. One, if you're kind of short on time, this summary should help you just kind of think through what is the trade-off and, you know, what is the key difference between hardware or software space. But for those who are kind of who those are willing to stay longer, this also helps you kind of have a lens with which to look at some of the other content that I will be covering later on and just contrast the hardware with the software product management. So here's my key takeaway. Hardware is has a lot in common is actually quite similar to enterprise software. But enterprise software is kind of very different from consumer software. So I see this somewhat as a spectrum. On the one hand, you have enterprise hardware products. If you're selling servers, for example, that's the extreme end of that spectrum. And the other end is the consumer software, you know, if you're, for example, you are a PM working on Messenger on Facebook, for example, that's a pure consumer software play. In the middle, you have enterprise software. You have consumer hardware. For example, if you're making iPhones, you PM for, you know, hardware product that actually sells as a consumer product, then you have, you know, they kind of fall somewhere in the middle. Culturally speaking, enterprise software is a lot similar to hardware. In terms of, you know, how, how do you think about the product enhancements? How do you think about your, you know, how do you work with stakeholders? How does the process look, etc. So that's, that's kind of the, the high level, the takeaway for this for our conversation. I'll be going into more depth as we go through the next few slides. So the first thing I want to cover is the product development process itself. I'm going to cover the, the day in the life of a PM and in two aspects of it. So I'm going to cover customers, you know, what do your customers look like? How do you actually go about building that empathy? And what are the key metrics that you use to evaluate your product success, either in the hardware side and also going to contrast that with what it is in the software side. The second aspect I'm going to cover is the actual engineering development part of the product development for two reasons. As a PM, you spend a lot more time working with engineers than you would with many other functions within the company. The second reason is there's also a lot that's common between hardware and software when it comes to, you know, you, in both cases, you actually work with engineers. And so it's a lot easier to contrast it. So I'm going to quickly cover how do the engineers kind of structure their work, how do PMs partner with these, you know, with your engineering teams and with engineers to ship products. How are the products and the features released? And lastly, how involved are you when it comes to, you know, what is your role as a PM in the product development process with engineers as well as later on. Once the product is shipped or ready to ship. Speaking of customer empathy, I think it's important for me to call out here that when I say hardware was software, I'm going to be taking kind of an extreme lens here. I'm going to be comparing enterprise hardware, you know, for example, if you're working on servers, just an example, versus more of the consumer software space. Like I mentioned earlier, you may find that, you know, there may be things that kind of fall along that spectrum. But just to kind of give you a real clear difference and going to take these extremes now. You may still find that some of these things, you know, apply if you've kind of fall somewhere in the middle, if you're, for example, hardware PM for the iPhone, for example. On the hardware side, you have dozens or hundreds of customers, not much more than that. It's not to say that you only ship to these customers or you only have, you know, hundreds of products that you release. You may have millions of products that you release. You may even have billions of, you know, you may be shipping billions of chips. For example, if you understand the conductor space, but what's interesting is that in hardware space, you're, you kind of have a small group of customers that control and that define, you know, 80% of what your product should look like. They are, you know, they are outsizing their influence for what you ship. And this might be even for some of the more consumer focused products where you may find out that, you know, some of these customers that may buy millions of units from you. Have an outsize a control in terms of what gets shipped and how it gets shipped and what gets prioritized. Whereas in the software side, you actually have, you know, you might have millions or even billions of customers and no single customer or not even a small group of customers, you know, actually get to control and tell you, you know, have influence over, you know, what would you ship. Because of the fact that in the hardware space you have a small group of customers that you really need to be intentional about, you have high touch interaction. So you have emails, you know, you have calls, you may even visit them. You may, you know, add their locations. On the software side, usually lower touch interactions, you may be running a few tests, you may be doing a few studies and surveys with, you know, the millions of customers that you have. You may do a sampling and interview a few of them, but it's in general a fairly low touch approach. On the hardware side, your customers also are a lot more clear about what they want in terms of the features they want to see for your products. On the software side, on the other hand, it's less clear. They usually want a solution to the problem that they are facing and not as much. I want this button to look this way and to do this one function for me. That's what I mean by features versus solutions. And so as a PM, you are also, and I'm going to skip the technical understanding part, actually go into metrics and the revenue, because as a PM, since your customers are more particular about what features you want in the hardware space, for example, your metrics also focus a lot more on the functionality itself and the features that you're looking at. Your metrics are judging the performance of the product in terms of what is the speed, what is the bill of materials, what is the battery performance. You're also looking at yield and the cost aspect of it. And so there's a lot more of a direct focus on revenue. If you're able to improve your bill of materials, you're able to reduce costs and increase profitability. If you're able to make a product that ships a certain number of millions of units, then as a PM, you spend a lot more time thinking about the revenue itself. You're actually connected to the revenue. On the software side, it's usually abstracted a little, you know, one level away from a pure focus on revenue or cost. What I mean by that is a lot of your metrics focus on usage. You're either focused on adoption or retention on customer satisfaction. And even in terms of, you know, how it ties to revenue, usually your key metrics of focus and adoption, increasing lifetime value, increasing cost, reducing customer acquisition costs, etc. Not really focused on revenue, even though these directly contribute to revenue. There's just that one kind of level of abstraction that happens in the software space. There's some more extreme examples to kind of contrast it. You may find that not all of the supplies if you're, for example, working enterprise software. There's also another key call out here is that in the hardware space, there is a high level of technical understanding that is expected from PMs. I mean, it's even at the very early stages of Europe, where when I was starting out as a PM in the hardware space. There's a high level of understanding that they expect you to have of the technical implementation of that product. What does it look like for, for example, if you're making, you know, chips, I was a PM for random access memories, which are memory products. You actually need to understand for say a smartwatch, what is the exact technical capability that you need for a RAM chip. On the software side, it's a lot more creative. There's a lot more focus on how do you solve the customer problems. And as a PM, you build a lot more of that intuition about what does it look like to solve the customer problem. And not as much of what does it look like to ship a specific product or to have a particular feature set. Next, I'm going to cover the engineering development side of it. This is this might be actually more clearly defined around hardware versus software lines. What I mean by that is even if you are, for example, in the enterprise software space, you might find out that there is you, your engineering development methodology is actually more in line with what software looks like and very different from hardware in terms of development. Usually you have consolidated product releases in the hardware space versus software space is usually I trade apart releases. What I mean by that is in the hardware space, I just, you know, I'm going to give you specific examples that might kind of help you understand what I mean by this. I worked on memory products that took over a year. Sometimes they took, you know, your and many months to actually ship a product. And so you're actually dealing with a much longer timeframe and you, you only get to release every, you know, few quarters or maybe even a few years. And because of that, you have larger code teams because these are massive projects that, you know, spread out over many years. You may have to give you an example as a PM I've probably had, you know, some products. I've had teams of maybe 30 or 40 engineers, maybe even more, if you, you know, consider some of the engineers that may kind of work in phases on the product. And yeah, yeah, actually, before I go into the hardware, let me go a little more down the hard before going to software space. I'm sorry. Let me go down the hardware points here. You have longer development cycles. As a PM you also have to build a long term plan. What I mean by that is you have to think about what the product is going to look like two years from now and prioritize accordingly. There is very little scope for you to reprioritize and, you know, kind of change course midway through because it's a much more, it's a much bigger ship that you're sailing there. And because of this, like I mentioned earlier, because you don't get to do repeated power releases, there's a much higher level of quality and oversight that that you would have as a PM hardware space, you would have more executive reviews, more presentations to your EVPs or even your CEOs. And there's a much higher bar for, you know, you cannot have any bugs as you ship. It's got to be a perfect product. To give you some examples, you know, you give you a personal example. I've shipped a product and you know had a bug that was discovered. And usually in those cases, you're dealing with having to do a recall because it's not, you know, something that you can just fix quickly over a weekend and have it go out there and impact, you know, and benefit customers. You might actually have to withdraw the products that have the ships that have been shipped and, you know, re issue new chips to your customer. So it's a much bigger cost when it comes to quality control. And so because of that you have a lot more oversight. The last thing is, you also have, you know, post release, you're doing a lot more focused work on production monitoring, making sure the chips are, you know, the yield is good. There's no sudden cost increases. And you're also doing a lot a lot of sales support. You're working with your field engineers to make sure customers are happy with the product and it's, you know, performing as it was intended when you started working on it. So on the software side, it's kind of like you're building a ship while it sails. You have I trade as part of releases. You have smaller teams usually, you know, you don't really need a program manager to actually monitor these massive projects and shipping, because it's a lot more creative. So you, you know, might have a team of six or 10 engineers and you work and work with them to actually ship enhancements to your product. You have shorter development cycles, which probably is just weeks. It might be like a two week sprint, for example. You also have a shorter term roadmap, because you can constantly change and update your prioritization based on, you know, what you ship and how customers are adopting to that. That allows you to not have to plan a roadmap that's, you know, two years or three years down the line or maybe even longer time period, because a lot of things can be changed and updated based on that based on, you know, how your product is doing currently. There's less organizational aside, because like I mentioned earlier, there is no, you know, you make a you have a bug in your product. It's fairly easy to fix it in the software side. And so you might still have release reviews and you might have status updates that you might have to share with your leadership, but it's usually just to make sure that you are kind of going at a big picture level, you're going right direction. Post release as a PM you spend a lot of time monitoring usage, scaling your product, making sure that rollout is going smooth and there's no, you know, bugs that, you know, as you as you scale. So that's kind of the engineering development side of the product and process itself. After this, I'm going to go into the stakeholders. I'm just going to briefly cover the stakeholders, because I've, you know, I want to spend a lot of my time focusing on the, the transition how to make that switch. Yeah, so on the hardware side, you can see that, you know, engineering is fairly common. They might go by different, you know, they might have different organizations of engineers, we might have design was some engineers was the product engineers. Whereas on the software side might be more front end with the back end, you know, like platform engineers, for example, product marketing is still fairly common your relationship with product marketing is very similar to hardware and software space. Interesting thing is you might actually on the hardware space you might be working a lot more with financial analysts because like I said you are actually looking at more revenue versus costs improvements on the software side since it's abstract a little bit. And since you're dealing with, you know, millions and even billions of users, the skill set is very different for analytics and so you might actually be dealing data scientists who might be, you know, combing through millions of data points, billions of data points to actually give you key insights and, you know, you might partner with them differently. From a customer facing front. I've seen that hardware side you might have sales and field engineers working with you closely as a PM. Whereas in the software front you might have more kind of user researchers partnering with you there, you know, a lot more focused on what the customer experience is and they are parking with you on that. Similarly, on the software space you have experienced designers who think a lot about you know what the experience should look like for your customers. On hardware space that role is often done by applications engineers who are thinking about, you know, what, what, how do chips look for the smartwatch or for connected devices or for, you know, IOT sensors, for example, how do we design, you know, at chips to actually address those needs. So they are focusing a lot more on the customer experience side of things. Cool. Now we are in the later part of our conversation. I'm going to be covering what are the skills that you need to succeed in hardware versus software space and also how to make that transition. The first key call out is there's a lot that's in common between hardware versus software PM. It should not feel like you're kind of moving between different jobs. Or different industries altogether. You are irrespective of whether you're in the hardware and software space. Your job is to be your product's biggest proponent, right? You're supposed to, you know, as in terms of skill set, as a PM, you are spending a lot of time thinking about what your customers needs are, how to translate them into products and into features. You are tying your product success to what your key business metrics are and you partner with stakeholders to build a long-term vision for the product. All of that stays exactly the same whether you're in the hardware or the software space. Where it changes this in the hardware space, you are kind of playing the long game. Like I mentioned earlier, product development cycles take a lot longer. And so you spend a lot more time and this is where, you know, your skills would differ. You spend time nurturing customer relationships. You have to have a good eye for understanding complex technical implementations and understand technical trends. Like I mentioned earlier, even at a very early level in your career, you might actually be thinking about, you know, what does the smart, again, taking an example, what does an autonomous car, what are they going to need for autonomous driving? And, you know, how do you actually connect that to what chips you're making? Or, you know, you might, if you're a product manager for, say, for example, servers, you might be thinking about what does the internet look like two years from now, technically, you know, from a technological perspective and how does that transfer into your product needs? As a hardware product manager, you are, you should be spending a lot of time to prioritize perfection or speed. You really want to make sure that there are no bugs before the designs are handed off to production engineers and who actually, you know, go and build it out in silicon. On the software side, you might, you know, a quick summary of what your skill is, you should be able to scale that iterative wins. There's a lot more of a short-term focus of being able to make iterative improvements, focusing on tomorrow rather than, you know, two years from now, for example. In terms of the skill set, like I mentioned earlier, there's a lot of, it's a much bigger customer base you're dealing with on the software side. And so being able to gather insights by combing through, you know, billions of data points and getting those key insights is very important. Also, being able to isolate and test the core solution, what I mean by that is you might get a lot of signals if you're dealing with large data points. Being able to pull the key insights and the key solution and then being able to test that and get those learnings iteratively is a key skill set you need in the software space. The last one, like I mentioned on the hardware side, it's a lot about prioritizing speed or perfection. You want to be able to keep testing, keep releasing, and so your skills are going to differ accordingly because you are expected to move faster as a software product manager. Cool. The last thing I'm going to cover today, and I'm going to go a little more in-depth with each of these, is how do you actually make the switch? I know a lot of you are considering making the switch, and that's why you're on our call today. And so I'm going to talk about how to make the switch. A lot of the interest I've gotten is making a switch from hardware to software. That's something that I myself, that's a switch that I've made in my prior experience. And so I'd probably be focusing a little more on that, but a lot of these concepts apply in respect to if the direction you're going, even if you're going from software to hardware, for example. So one of the most common ways I've seen folks make that switch is what I call transition products. What I mean by that is you work on products that are kind of in the middle in terms of the skills, in terms of the process for product development. I've seen enterprise software and consumer hardware kind of fall in this transition product space. So like I mentioned, if you think of this as a spectrum from enterprise hardware to consumer software, you want to try different products that kind of fall in the middle that help you make that switch easily. Some of the benefits of making this switch is that you have a much smoother learning curve because a lot of things will stay common. So for example, just give an example, if you're moving from say Intel to Apple, you'll find a lot of things that are common in terms of the process. And then I say Apple, I mean the hardware side of Apple, you find a lot of things that are common. There is very little financial cost to this. In fact, if you play cards right, you'll probably go with the hike and you'll be able to make that transition. It's also the least disruptive to your lifestyle. You're not having to like learn complete new skills and have to change how your lifestyle works as you make this transition. Some of the challenges with this one, you of course have to apply for jobs. So there's job search overhead, you know, preparing a resume, interviewing and going through the mental ups and downs of the interview process or job search process. There are also maybe limited opportunities. You may not find too many companies that are kind of in the middle. You may not find too many roles that are in the enterprise software space. For example, you might find over a thousand PM roles if you open up Google's career portal today. Just in terms of the size of the opportunity, you might find fewer opportunities in enterprise software, for example. You also may run the risk of kind of getting pigeonholed into a specific segment. Again, just to give an example, you might be working on enterprise software for payroll for large businesses that have over 2,000 customers or 5,000 customers. That might be a very, very specific niche that you might run the risk of getting pigeonholed into if you get into that and spend too many years in that space. So that's again pros and cons. If that is something that you're really excited about, there is no harm in that. It's just, you know, the trade-offs that you need to keep in mind as you think about these options. The second thing I've seen is stakeholder roles. What I mean by that is you transition to roles from product management that are more kind of product agnostic. So marketing, program management, business development, corporate finance, corporate strategy. These are roles that you could easily transition from hardware to software space when it's easier, I mean more easily than a PM making the transition between these different industries. They're more product agnostic. Usually I've seen a lot of people are able to make these transitions internally within their company. It's much harder if you're, you know, product manager and you want to get into business development in a completely different company. You might find that harder, but if you're willing to do that within your company, you might have a much easier time recruiting. You might just be, you know, having a conversation with your, for example, with your marketing manager and, you know, see their interesting opportunities that you might be kind of able to flex into. Easier onboarding. You have a ton of social capital in the company, since it's a company that you're already working at. And you also would be able to build cross-functional skills and experience. What I mean by that is, you know, a lot of your work as a product manager benefits from having prior experience in marketing or having prior experience in corporate strategy. It just kind of helps you build those skills that you can then take over, transition over to product management whenever you make that switch. The last benefit of this is also reversible. You can decide, you know, two weeks into your new marketing role that, you know what, you actually did enjoy product management and you actually want to go back to it. It's fairly user-versed that versus, you know, some of the other options out there to make that switch. One of the big challenges with this is it requires certain amount of, you know, certain tenure and it requires you to have a certain level of social capital within your company. You cannot, you know, if you joined your current company two weeks ago, you cannot be able to make that switch as easily. It also requires you to have relationships within your company and, you know, be able to make that switch. I also want to call out that one of the big challenges with this is that there might be potential lifestyle disruptions. For example, if you get into this development, you might have to, you know, travel more often or you might have to work different hours. If you're in marketing, for example, you might have to work with folks in different countries and so you might have, you know, there might be some lifestyle disruptions that you might face. The last challenge that also is something important to keep in mind is you might have income and growth limitations. What I mean by that is you might find out that, you know, you might be at the highest income bands for, you know, if you're moving from, say, product management to product marketing or program management. In general, I've noticed that product managers are on the side, you know, the higher side, you know, for the same level, you might find pms or the higher level compensation compared to some of these other roles that I've talked about. And so you might be at the top of the band and you might also be limited in terms of your growth opportunities because you might not, you know, for example, if you move from a senior product manager to senior marketing manager, you might not be able to make it to the next level, which, you know, for example, might be staff marketing manager. Just because a skill set of that level would require a certain level of experience in the marketing domain itself. And so you might face some growth limitations in this. But if you're looking at this more of a short term switch, you know, for like a year or two years and then you're able to make the transition out into product management again, then this makes sense as a kind of a middle ground for you to be able to switch industries more easily and then switch into product management. The, the last option and which is I've seen a lot of people take I myself have, you know, followed this path is to kind of do a full career pivot or career reset. What I mean by that is you either go back to school, get, you know, get a master's program, get an MBA or a master's in program, product management or engineering. Another option is you could join a consulting firm, but often I've seen consulting firms are only they also often require MBAs to be able to make the switch. So if, for example, you, you know, already have an MBA, then you might be and you're looking to make the switch from hardware or software or software, consulting firms might offer you some of these interesting roles that help you make that transition. You might be, you know, doing copy charges specifically for certain industries and so you can build those skill sets to make a transition. The benefit of doing this, you know, kind of career reset is that you have a very high likelihood of success. You go to a good master's program in, you know, engineering product management or business administration. You're almost guaranteed to be able to make the switch very easily. You know, you have a ton of opportunities out there. A ton of companies have recruit from these, you know, top programs and they, you know, give you the opportunity to make that switch very easily. There's also a lot more of a career flexibility. You could, you know, go into your business school program and find out, you know what, I want to be doing private equity. You can do that. It's a total career reset that you get. It's going to use your clean slate. In a lot of cases I've seen there's also a sharp income boost, especially for MBAs, but also for a lot of the master's programs. Just because, you know, they respect, again, this is assuming that you go to a good, a top-ranked school and you're able to make that switch. They usually bring you in at a much higher level than you were initially. So you would see a sharp income boost. A key call out here is that to really take advantage of this, you want to be going to a top business school or top engineering school because that makes a big difference. You don't want to be going to a low-ranked school and then face a lot of limited opportunities. And then you also have a lot of these challenges. You will have, irrespective of which kind of school you go into, you might still end up having significant lifestyle disruptions. If you have kids, it might involve relocation. If you're going full-time to school, it might involve significant financial implications. You might even have no income for a year or two years if you're doing it full-time. If you're doing it part-time as well, you would have significant lifestyle disruption where you might have to put another 20 hours, a week on your education for this. It's also still going to have a job search overhead that's going to come here because you're going to have to go through the process of finding a job, even though it might be easier at school just because they might have career boards and job boards and all those things. But yeah, these are the three common ways I've seen folks be able to make that switch from hardware to software or even from software to hardware if that's something you're looking to do. I'm happy to talk about this offline and if you're interested in these options. Yeah, that's about making the switch. I'm going to quickly summarize. Like I said earlier, hardware has a lot. It's kind of a spectrum. Hardware versus software. It's not as black or white. You might find enterprise software often falls kind of in the middle of the spectrum. In fact, there's a lot more in common with hardware than it is with software. And so if you are looking at just doing hardware to software, enterprise software might be a much easier transition for a lot of people based on the skills that you have. The last thing is, you know, happy to connect. I have my LinkedIn profile here. I have just joined Substack maybe a couple of weeks ago. So I've actually been writing on this, but I intend to be writing on Substack as well about this, about, you know, the hardware with software. About product management, about tech trends, things that I generally enjoy kind of reading and writing about. So yeah, happy to connect with all of you offline and all the best with it as you make this transition. And thank you for, thank you for joining this conversation today. Thank you for being here. I'm happy to connect. All right, thank you.