Jan 23
Hardware Product Management
I have been developing hardware my entire career, if we leave out the experiments of the geek kid (that I still am). It is enlightening to put into words the rules that became second nature to me.
Why should you take my words for professional advice? No particular reason really, I would not consider myself an expert, but I was fortunate to have a unique set of experiences, starting off in chip design, moving on to designing charging equipment for electric vehicles, and as a product manager of consumer electronics - smartphones and mobile accessories, to leading product teams, designing smart cameras and autonomous robots that stroll retail stores and report to AI-brains in the cloud. I hope you will find this worthy of seven precious earthly minutes.
Hardware Vs. Software, or is it?
Software eats the world. One can have a remarkable tech career, in cyber, gaming, consumer web, fintech, or other pure-software domains,
without ever bothering herself with the hurdles of the physical world — power consumption, overheating processors, or supply chain.
This could give the false impression that the reverse is also true and that hardware people are strangers to software, which in reality is never the case. Many hardware professionals, and hardware product managers, in particular, are dealing mostly with software, but also with the underlying hardware on which the software runs. If hardware is the body then the software is the soul, and just like in medicine, the best treatment is always a holistic one, that considers them both.
Be strategic, hardware is always a platform
Unlike software, hardware cannot change after the fact, in the hands of the customers. The hardware usually takes longer to design and it doesn’t duplicate with a click of a button. For the hardware product manager that means taking big bets — in the time gap, between the “design freeze” and the product launch, reality will change, company’s focus might also change, so the hardware conceived 6–12 months back, must stay relevant and “keep up” with these dynamics. Hardware must be relevant at the time it is installed, or put on the shelf to be sold, and it would better stay relevant throughout its intended life expectancy, wherever it serves its purpose.
Today’s hardware must be able to serve tomorrow’s business.
Hardware is always a platform, and as such it must contain some margins to run some extra code, to consume some extra power, and to support some additional features, that are not even on the radar today — making it so without adding cost that cannot be justified today — this is the real art, and probably a blog post of its own. Staying relevant also means that everything must be upgradable — every configurable component must be part of the upgrade chain; It is a common mistake to assume that some low-level components will never require changes and only the main controller, DSP, FPGA (the “smart” parts) will change, this might prove very painful, and require a physical upgrade sometime in the future. Whenever I explain this point, I envision the scene from “Apollo 13”, where the engineers on earth try to improvise with all the parts available to the crew on the spacecraft. Is your system improve-ready?
The software of tomorrow might need to run on a few different hardware products (your other, newer creations), for this you should make sure that today’s hardware is uniquely, digitally, identifiable, so that tomorrow’s software could read this information and decide how to run on every specific unit. Compatibility is a two-way street — hardware should be built to support changing software, and software should be designed to run on different hardware, for the software, that means — abstraction — keeping the code clean of any dreadful forks and if() statements, and building an abstraction layer that knows how to handle different hardware, while keeping the core logic agnostic to these peripheral changes; For example — the software can decide to take a picture, and it doesn’t matter how many mega-pixels are built into the underlying camera. A more advanced level of future-proofing is modularity — understanding what parts of the system are more likely to require a future upgrade, and designing the system to enable a painless change. Guestimating what will change is easier said than done, it requires a careful analysis of technology trends and a clear understanding of future use-cases on your company’s roadmap.
Some other attributes of your platform that require diligent planning are:
Instrumentation — today’s data could answer tomorrow’s questions — do you keep a local log, or collect all the relevant data? to be able to decide on the NextGen platform. The exception with hardware is that data about the environment, in which the system works, is also relevant, and very often available (through sensors).
Reliability/Repairability — is it possible to replace the parts that are more prone to wear and tear without breaking apart the entire system? does the system self-diagnose and self-report on potential issues? Should the system do something while idle, to make sure it will be ready to use when required?
Take advice from suppliers
Hardware is always a multi-organizational effort, if you build a system, your building blocks, the components, are the products of other companies- your suppliers. You can relate to this process as sourcing — have your system engineer make a list of technical requirements, and shop for components that meet the spec, when done — strike another task off your to-do list, good, but not great. [Banality alert] For the companies you buy from, you are a customer [alert -off], and these companies have many customers, which means that in their product management process they dig long and deep into the needs and pains of the likes of you. That also means that these vendors observe and learn how companies, similar to yours, use their products and deal with other issues, which just might be the impossible challenge you are facing today. You better treat every supplier as a partner to your journey, make your success their success, don’t be shy from sharing with them your “other problems”, and carefully listen to every piece of advice they give you. Vendors will never disclose confidential information of their other clients, but if they enjoy working with you, they just might help you with their intuition, and common sense, built upon their aggregated experience.
Never underestimate design
It doesn’t matter if you are in consumer electronics, or manage an under-the-hood, utility-only, never-to-be-looked-at, enterprise product. All human beings appreciate aesthetics, and involuntary judge your attention to details, and consequently — your professional standards, and your competence, by the looks of your products. It’s a take-it-or-leave-it kind of advice, I have seen some products in my life that deliver mind-blowing utility and look like a 3rd-grade science project, but somehow they are all in the homeland security and government sectors. If the company you work for is trying to make a name for itself, or even more — build a brand, do not underestimate industrial design, make it easier for your customers to show off their product choices.
“Simplicity is the ultimate sophistication”/Leonardo da Vinci, so while you manage the design, think of every person who will ever touch your product, in very practical terms — is your design “too symmetrical”? — can it be used (or installed) upside down? (I would hate to see a Jedi knight make this mistake..) is there ambiguity to resolve around interfaces? does your customization approach (e.g. colors, or plug types) create a supply-chain nightmare? Can one check that the product works before investing hours in installation? Make it easy, keep it simple — delivering an easy-to-use product is a wonderful opportunity to shine.
Just one other piece of advice on this subject — it is likely you’ll be using the services of external mechanical engineering, and/or Industrial design studio — only work with partners experienced in wrapping electronics, and in serial production processes, they will solve, upfront, some problems you don’t even think of right now, while other types of designers will only create new challenges for you to solve. If your mechanical design partner doesn’t obsess over manufacturing tolerances, you should raise the issue at your next meeting.
There’s always a funnel
If you’ve ever been to a product management lecture and thought oh gosh… another software product management advice that I can’t use, I am telling you, buddy, you should listen more carefully. Every existing product management advice is applicable in hardware, some just require extra creativity — you can A/B test, you should iterate, create an MVP, survey, interview, create (3D-printed) mockups, confirm the hypothesis, keep a backlog of ideas, work in sprints, fall in love with the problem, work backward, base your decisions on data, provide context to your developers and let them lead, there is always a funnel — find it!
TLDR
Be strategic — By the time your product is out, the world has changed. Better together — your suppliers will provide the components, but also their attention, experience, and advice — if you are willing to take it. Aesthetics matter — but only if your product will be used by human beings, skip this point if your customers are all robots. And last — do apply every software product management concept — there are all relevant.
So much more to be said, in general, and about the current state of events (e.g. chip supply shortage), if you want me to write more about it, please like this post and share it.
BTW, there is an opening in my team, in Tel Aviv, for someone who wants to do just that https://tinyurl.com/productrax (last I heard, FOMO is a thing..)
Doron
