Hardware vs. Software Product Management
I started my product management career in the summer of 2015, shortly after earning my MBA. My first PM position was at a global hardware company for about 2 years. I have since joined the world of agile software development. This blog compares how the decision making process differs between the 2 worlds.
Hardware
As a hardware product manager, we are forced to make crucial unchangeable product related decisions extremely early on in the development process. Sometimes these decisions are made several years prior to when a customer will actually be using the product. From my experience, the hardware development cycle can take anywhere from about 12–18 months. This is mainly due to the long lead time required to source and test certain hardware components like memory, battery and screen display.
My responsibility was to release a rugged mobile computer in the enterprise marketplace. Due to the aggressive time schedule, we conducted limited market research. My team and I decided that Near Field Communication (NFC) was a nice to have feature rather than a must have. As a result, we were forced to make that decision within the first month or two of the development process — 12 months ahead of release. As the market continued to shift and change through the development process, we were getting more requests for NFC. You might be thinking, if it was so important, why didn’t you just add NFC to the product? Doesn’t your agile process allow for changes like this? You would think, but since hardware involves physical products that have defined shapes and sizes, it’s not so easy to make changes once specs are locked in. To implement NFC mid-development, it would require an additional antenna, a redesign of the electrical board to make room for the new antenna, additional testing, and potentially additional resources. Not only is this costly, but it impacts the product release schedule. Hardware product managers now need to be ready to answer these questions:
Sales: We need NFC to close this deal. I told them we can support it. Can we make it happen?
Project Manager: What is the incremental cost and the schedule impact?
Engineer: What else can we give up to make room for NFC?
VP Product: How much are our customers willing to pay for this additional feature?
C-Suite: What is the business case?
We ultimately decided to not implement NFC because of the incremental development cost and the lack of justification that it would increase our average selling price. Our customers wanted NFC but they were not willing to pay more for it. Looking back, it may have been the wrong decision but imagine how things would have turned out if we said yes to NFC from the beginning. The electrical board would be designed for multiple antennas, the incremental cost would have been significantly cheaper and it would have been part of the original value proposition. Being forced to make product feature decisions a year or so in advance is extremely challenging, stressful and unforgiving.
Software
On the other hand, the decision making process in agile software product management is less definitive. Software is all about being fast and managing change.
The time to market for a software-only product is light years faster than its fellow hardware sibling. This is mainly due to the infamous concept of Minimal Viable Product (MVP). How to define MVP is a discussion for another day, but the concept makes it completely acceptable for software PM’s to release functional yet extremely simple first product. We can continue to improve our product on the fly which eliminates the need to be perfect on day one. Since software is not confined by physical constraints, consumers expect their software solution to change, adapt and morph. Sure, hardware can change too, but it requires a completely new product redesign with a new product launch.
To manage the expectation of constant change, whenever I am asked to make a product decision (which feels like all the time), I ask myself one question:
Is this decision permanent or can it be changed in the future?
Most of the time, the answer is that it can be changed in the future. This makes every product decision much less scary. This does not mean that I can make decisions without proper research because if I make a series of bad yet changeable decisions, I am going to incur some serious technical debt. My decisions should still be backed by data, however, it is totally OK not to know everything. This is why the decision making process is so different:
The software decision making process is short term because we don’t need to know the market needs a few year from now. We just need to solve the customers pain points today.
The software decision making process is flexible because we don’t need the perfect solution today. As long as it’s functionally sound, we can afford to get away with a few UI/UX mistakes.
The software PM does not always have to be the final decision maker. Many times, the best decision is made when the development team or the design team is empower to think of an amazing solution. Other times, the software PM can resort to product testing to get immediate feedback.
Conclusion
Hardware product management has a lot of structure and it requires us to have incredible foresight into the needs and wants of the market. Every product decision seems so big because it’s hard to change them down the road. On the other hand, the perspective of a software product manager is short term and it requires us to be more accepting of ambiguity due of the high degree of flexibility.
