 Hello, everyone. I'm here today to talk about my journey transitioning from hardware to software product management. This is mostly some of my learnings and observations. I hope some of these learnings can be applied even if you are looking to move from software to hardware or change industries in other ways as well. But today I'm going to focus more on this on hardware to software transition just because that has been my personal experience. Speaking of myself, I'm a product manager at TumTac. Here I'm working on a new product that's designed to help homeowners better take care of their homes, specifically their home maintenance projects. Prior to TumTac, I was a product lead at Square, where I was focused on driving growth for the Square website. Before that, I've also worked at Intuit and Infineon, which is a semiconductor company as hardware PM. In my free time, I tend to read a lot about tech and tech strategy. I have published articles about Internet of Things and designing systems around IoT in various electronics journals. I'm a tinker at heart. Like I mentioned, I love programming home projects or reading about latest trends in technology and writing about it as well. Lastly, I live in the Bay Area in California. Awesome. Today's conversation is going to be focused on mainly three themes or ideas. First, I want to cover what the product development process looks like, and then want to talk a little bit about what are the skills that you would need to succeed as a PM in hardware or in software product management roles. Lastly, I want to spend time talking about making that transition, how I personally have made the transition, how I saw other people I knew make that transition from hardware to software. Like I said earlier, a lot of the principles can apply, even if you want to transition from software to hardware to take advantage of the semiconductor boom that's going on right now. So what I won't cover today, I need to call that out first. I will not be covering specifics of my role at any company that I worked at, whether it's Thumbtack or Square or Intuit. This is largely not applicable for our conversation today, but it's also I'm going to be sticking to more general terms on my observations in software, product management versus hardware. I also won't be covering how to become a PM, how to excel as a PM, how to ace the PM interviews, any of those things. The part who has a ton of resources around that that I would strongly recommend exploring if that is something that you're curious about, but I will also not be covering interview tips and tricks. The last thing is I don't intend to talk about the future of semiconductors or FinTech. That's something that I get questions about every once in a while, but I'm always happy to talk about it offline, but this presentation is more focused on hardware to software, product management and contrasting them. So here's the summary of our entire conversation. I want to give this mainly for two reasons. For folks who are kind of short on time, I want to give this takeaway. And for those who can stay and continue during this call, this is a good lens to have as you think through some of these things that I will be talking about going forward. But the key takeaway is that hardware is very similar to enterprise software, which is very different from consumer software. Often when people think of hardware versus software, there are a lot of products that kind of lie in a spectrum. And often it's transitioning from pure semiconductor style hardware to enterprise software is a lot closer than it is moving from, say, semiconductor to consumer software. So that's one of the main reasons I want to call that out. Now I want to cover the product development process as a PM. These are the different considerations that you would go through as a PM. And then I want to contrast them for what looks like for hardware versus software. So let's look at the product development process. I can compress it maybe at the risk of oversimplifying it into kind of two phases. There is the understanding of customer empathy and understanding customer needs. And then measuring that success, which is more of our customer facing side of the PM's job. And then there's engineering development or product development itself, which often involves designers, engineers, marketers, and various data scientists who have partnered with you on this. But the reason I picked engineering development is because engineering is such a critical portion of every PM's role. And that's also one that has a high overlap between hardware and software. So that's why I picked engineering development piece specifically. So on the customer empathy side, we want to understand as PM's, who are the customers? How do PM's learn more about their different needs? How is success defined? How do we prioritize products on the actual development side of it? How do the engineers structure their work? I'm going to cover a little bit about how do PM's partner with them? What are the key features of products that are released and how involved are the PM's? So these are kind of the two lenses that I will be using to contrast hardware versus software product management. So let's talk about the first one, customer empathy and metrics. Within the hardware, again, I want to caveat this by saying a lot of this changes based on whether you're in a consumer hardware role versus a enterprise software role. You might not, a lot of this might apply. I'm trying to draw more of an extreme here with like enterprise hardware versus consumer software to show the contrast here. So in the case of hardware, you're dealing with maybe hundreds of customers, maybe thousands of the most. These are often very high touch where you're directly interacting with your customers over email calls, even visits to their engineering facilities. In the hardware world, customers want specific features and capabilities because these are, again, in the hardware world, in most cases, you are selling like I mentioned enterprise hardware, you're selling to other businesses. And so there is a very specific expectation on what the product should do in terms of the features and capabilities. As a PM, you are also expected to have a high level of technical understanding of capabilities to understand how this works, what are the key trade-offs from an engineering standpoint that have led to this product behaving the way it has. Not to say that's not the case for software, but in the hardware world, I notice it's the expectation of technical understanding is higher. The metrics in hardware are focused more on functionality. You're looking at performance or yield. You also have a direct focus on your revenue. As a hardware PM, often you are focused on a revenue goal for your product. To contrast that with software, for consumer software especially, you have millions, maybe even billions of customers who would use your product. Because of that, your interactions with these customers tend to be very low-touch. You're mostly running AB tests, maybe some user tests. You're conducting surveys in some cases. You might do some analytics to understand or hypothesize customer behavior as opposed to having them literally tell you what they want. In the software world, customers want solutions and jobs to be done. They don't expect specific features. They just want their problem to be solved. Whereas, like you mentioned in the hardware world, it is a little more prescriptive in terms of what this product should be doing. PMs are expected to have a high level of intuition about customer problems and a high level of empathy. These are the key problems that customers are facing. This is the most impactful feature we can build to address one or more of those problems. Often the metrics in software product management focus on usage, adoption, engagement, retention. It's a lot of customer journey mapping focus metrics. The last point is there is an indirect focus on revenue, especially larger companies. Product management is somewhat abstracted from a revenue goal. Usually, PMs are focused on metrics that they can directly impact around engagement or adoption or retention, and less around we need to make X million dollars from this feature in this year. That's usually the case. Again, not always the case. I've been at companies and have interacted with folks at companies where they do know what their revenue goals are. They might still be thinking about metrics that are more tied to engagement or adoption of the product, but they do have a good level of awareness on how that ladders up to an actual dollar value. It's somewhat on the spectrum, but it's still a less direct focus than the hardware world where it's a very clear focus on revenue. Now talking about engineering development, between hardware and software, hardware has large products that often take months, maybe even years to actually release. Because of that, you have a consolidated product release. You have large teams with program management functions, often dozens of engineers, maybe even more working on a single product. Because of the high stakes here, you cannot launch a hardware chip and then if it doesn't work as intended, it's not easy for you to release a quick fix. You need to essentially recall those chips in many cases back and then ship the new products to your users who often might be selling to end users. Because of that, there is a much higher organization oversight in terms of how the decisions are being made, are the best decisions being made, and there is a push towards get it right as opposed to get it out quick. Again, I'm trying to compare and so I'm drawing more of a stark contrast here, but that's been my observation at different hardware companies as well. And often post release, there is more production monitoring and sales support that happens as well that engineers are very plugged into. In the software world, things are a lot more fluid because you can iterate on new releases. If you release something, you realize, oh, this is not working as intended. You can ship a quick fix to that or you can release the V2 of the product. And often the software world works in weeks. You have sprint cycles and the roadmap also tends to be more in quarters. You might have a vision for the team that maybe runs two or three years, but it's not a fleshed out roadmap. Unlike in hardware, it is very specific. This is what we're going to ship a year and two months from now and that's what you're going to do immediately after that. So it's a very detailed roadmap that you have in hardware, post and software. It tends to be more of a shorter time horizon because a lot of things could change as you release new features. You might find out that, oh, this is the direction that is engaging or not engaging with our users and so we want to change accordingly. There's less organizational oversight. Not to say that PMs can do whatever they want in software. There are still a lot of release reviews, status updates. There still are design reviews in many companies, but it's more to understand are you best solving the user need as opposed to are you building the specific feature that we need. And often post release for a software PM involves usage monitoring, scaling and also rolling out the features. All right. Now I want to talk a little bit about what skills you would need to succeed as PM. As I keep mentioning, this is more of a, for the sake of illustration, I'm going to compare enterprise hardware with consumer software. But there's a whole spectrum of where your product may lie that could impact what skills and how part development happens. So in hardware, you are playing the long game. It is hardware is a lot more like marathon whereas hardware is more, you know, you're building in sprints. And so in hardware, your focus is all the skills that help you succeed involve nurturing customer relationships, understanding the workings and the trends of the products that are specifically tied to like engineering or technical capabilities. You also want to prioritize perfection over speed. You, your ideal goals have zero bugs. And that is a very costly thing to have bugs in a hardware product. And so you want to be really intention about how you build and how you prioritize the features and how you evaluate testing and things like that. In the software world, you can always scale with iterative wins. And so the skills that make you succeed as a software PM are more focused on gathering insights, analyzing data, isolating and testing like the core hypothesis of the core solution, as opposed to kind of building a like we need to solve 10 problems. And this one product is going to solve those 10 problems. Often software PMs are focused on let me solve this one problem first and then move to second and the third. Whereas in hardware, because of the longer release cycles, you're not, you have to prioritize solving multiple problems for your users. Often software companies and software PMs prioritize speed over perfection. Facebook famously says move fast and break things. And that is very similar to how a lot of consumer software companies operate, where they want to get things out quickly and test and learn as opposed to getting it right, but taking a lot longer to do so. The things are uncommon. Of course, every PM needs to be good at understanding and translating the customer's needs into specific features or products. PMs need to be good at tying the product's success to the key business metrics, irrespective of whether that key business metric is a revenue goal or not. You're also expected to excel at partnering with stakeholders and to build a long-term vision for the product. Partnering with stakeholders is a key skill in product management irrespective of whether you're in hardware or software and being able to convince and evangelize people internally about the benefits of your solution or your hypothesis and why it should be invested in. All of that remains the same whether you're in hardware or software product management. Now I want to talk about making that switch. This is something that's more focused on folks who are curious about if they are in a hardware role and want to transition to software product management or vice versa. A lot of these ideas that I'm going to be talking about are from my observations and I've observed friends make those transitions as well. I want to share that this is more of my learnings as opposed to this is the best way to do so. You might notice that friends have taken different approaches to make this switch and I'm happy to share a few that I've noticed. The first one is working on transition products. I've mentioned this many times at this point now that the products can lie on a spectrum of how complex it is or how enterprise it is versus more of a consumer product. If you are in say enterprise hardware which is probably one in the spectrum, a good way to transition towards software is if you work on products that are in the middle in terms of the skill and the process. Enterprise software has a lot of features in common with say consumer software and so by the same time it does have a lot of the processes in the mindset being very similar to a hardware company. Conversely consumer hardware is very similar. You have hardware design and hardware product development but it is a faster process. It tends to be more short-term focused and often consumer hardware has a software element in it which means that you can hone both those hardware and software skills. Speaking of the benefits, there is a smooth learning curve because you potentially have a lot of skills in common and it's just about understanding what's changing. One thing I do want to call out is there may not be too many opportunities or products in the first place so job searching could be a little more complicated if you're limiting your search to transition products. Another thing I want to call out is there's very limited financial cost and less disruption to your lifestyle because you won't have to take a pay cut in most likelihood moving from a transition between products. You also are quite likely if you leverage your existing skill set and your interviews to maybe even get a compensation or salary bump but there is a risk of career pigeonholing that can often happen with some of these transitions just because of how rare they are. You might not be able to transition back or in a direction all too easily. Just something to call out here. The next one I want to talk about is stakeholder roles. So you as a PM would work with various cost-functional teams that may be part of your core team or may be outside depending on how your company is structured. Marketing, program management, business, corporate strategy, these are some of these roles that I personally know and people transition to and the reason that you do that is a lot of these roles can be product agnostic. If you are doing program management for a hardware company it may not be all that different in terms of like learning a completely new set of skills if you move to say a software company. There might be a lot that's in common. Same with marketing or best development as well. And so the benefits of this is there is it's easier recruiting and onboarding. Something I recommend personally is explore internal stakeholder roles before you explore external ones. Like talk to your PMMs to see if there are roles where your your skill that the PM might be a good fit. They're just for you to learn. And often companies have like six-month rotation programs where they allow someone to try out a new role for a short period of time. So that's something I would encourage exploring. You may even find out that these product agnostic or these some of these stakeholder roles are actually more interesting for you and for your preferences than product management. The other thing I want to call out is there might be you know there could be potential lifestyle disruptions especially if you take roles like this development or marketing where you might have more travel than you might do as a product manager so that's something to keep in mind. The other challenge that often comes with transitioning to a stakeholder role is often they require tenure and social capital like you need someone to be willing to take a risk on you being able to do a job. And this is especially the case if you're more senior. If you have 10 years of product management experience and you want to transition to say marketing it's going to be harder than if you do it you know a year or two after your you know early in your career. And so often you require a hiring manager or some senior leader to take a bet on you and often that also leads to less challenges on income limitations. You might be transitioning to a role you may be at the top of a salary ban and sometimes a promotion is not likely just because you don't have industry or role specific skills yet and so that might kind of limit your growth in the short term while you explore and learn this role assuming you make the transition. The third one is a career pivot. This is something this is probably the most common one I've seen a lot of people do largely because this doesn't require a lot of the you know the risk of oh if I get into marketing or if I get into program management or if I transition to a consumer hardware product from consumer from enterprise hardware I could get a pigeonholed into something. You have less of a risk you have a lot more flexibility which often leads to a higher likelihood of success in being able to make that transition. It also gives you total career flexibility depending on whether you get an MBA or an MS in product management or engineering or if you join a consulting firm you have a lot more flexibility to say maybe I'm not interested in this maybe my interest is in a to work in a social nonprofit and it gives you that opportunity to explore and find a role that makes the most sense for you. Often business schools like MBA programs or even masters in product management engineering especially there in good schools often come with a good income boost so if you feel kind of stuck in your career especially if you're early on your career an MBA or an MS can kind of bring you in at a higher level in a new industry so it gives you a little bit of boost there. One of the big challenges I think the most obvious one that a lot of you are aware of is you're essentially going to take a year or two years out of work so they could be the income loss as well as the cost of actually going through a program if you are not sponsored by your employer and there is a significant lifestyle disruption. You're transitioning from being a full-time employee at a company to a student sometimes you might be even doing an employee plus you might be doing a part-time MBA for example and often that leads to a lifestyle disruption for a year or two years or maybe even longer depending on the program and there's also a likelihood of having to relocate depending on whether you get a business school or a master's program at the city where you live in. One thing I do want to call out here I've had folks reach out in the past about whether it makes sense to do a part-time MBA to do so mainly because the employer is sponsoring them. My thought on this is it depends on the terms of the sponsorship if your goal is to transition out of your current role and you're tied to an employer for four years after you graduate that might make it a little harder so consider that as you're evaluating this option whether the risk of being kind of stuck with your current job for financial reasons is going to be a problem. So there you have it coming back I want to again call out like a lot of hardware is pretty similar to enterprise software you're building for a small number of users you are solving you're going very deep into understanding the technical aspects product you're really going deep into understanding the user's needs and their specific needs as well and you're often taking longer to release products in the enterprise software world just because often companies are not open to your own new features coming out every two weeks for their products and for the products that the company use by referring to enterprise software consumer software is very different but it's kind of like the other end of the spectrum and often there are ways to transition like I mentioned earlier you could transition by working on products that are kind of in the spectrum somewhere in the middle you could work on stakeholder roles or cost function roles and you can also do a career kind of pivot and just go to school again. So yes so that's that's about my journey and my observations that I've seen folks who have made the switch from hardware to software product management feel free to connect with me here's my LinkedIn I have just started using Substack haven't yet pretty much on that but thought I'd share if it's if someone's curious and you'll see my thoughts as I start writing about tech. All right that is it thank you all and looking forward to hearing any questions you might have and connecting going forward.