Software Product Management has exploded in the last few years. In this blog post, you’ll learn how product management differs in software, hardware, and services.
However, first, let’s try and define product management.
In the ultimate guide to product management, airfocus defines product management as:
Product management is the practice of defining the “what” and “why” for the solutions that companies build, solutions that are meant to solve customer problems.
Factoring in business goals, available resources and constraints, customer problems, metrics, market information, and technological capabilities. Product managers prioritize and make decisions that are meant to provide customer value and drive business impact.
In essence, a product manager’s responsibilities include discovering what to build and why to build it. A product manager continuously communicates with their team and gets them on board and excited to execute. Finally, product managers learn from user feedback and works with the team to iterate.
In my opinion, below are 10 product management skills to practice in 2021.
Lead by influence.
Building trust.
Customer research.
Ability to look at the bigger picture.
Understanding the sales process.
Communications skills.
Storytelling.
Understanding trade-offs.
Prioritization and sequencing.
Shipping that product.
What is software product management?
Let’s start off by defining what software product management is. Think about software products such as Google Maps, Slack, and Netflix.
In reality, the truth is there are a number of resources available that describe the role of the product manager and product management. Unfortunately, the role of a product manager has no defined roles and responsibilities. Hence, is open to interpretation depending on the industry and size of the organization.
Let’s look at a few authors who write about the role of software product management.
Marty Cagan
Marty Cagan explains in his blog post the architect role “The job of the product manager is first and foremost to discover a product that is valuable, usable and feasible. You’re wasting the rest of your team’s time, and your company’s money, if you can’t do this. But this doesn’t mean that you have to discover this product yourself.”
Martin Eriksson
Martin Eriksson defines product management as the intersection between business, technology, and user experience. You’ve likely seen this Venn diagram.
Elad Gill
According to Elad Gil, at a high level, a product manager (PM) is the single cross-functional owner directly responsible for the success of a product. Some pundits call PMs the “general manager of the product” or “CEO of the product.” In reality, a product manager is directly responsible individual for a product—they have all the responsibility for the product’s success but often lack the direct line reporting of the other functions.
Hiten Shah believes the #1 thing Product Managers own is documentation and Sachin Rekhi shares his top 10 deliverables of product managers.
What is hardware product management?
Let’s start off by defining what hardware product management is. Think about products such as Oculus, Spectacles by Snapchat, and iPhones. Hardware product management involves an additional element that requires tight integration between hardware and software.
Hardware is generally a much more complex process and therefore tends to be slower (than software product management).
When I started my career, I worked as a test engineer for a company that made full-flight simulators. No, not the desktop kind but the kind that commercial airline pilots train in. My role was at the intersection of tightly integrating the hardware and software.
Is it a software issue or hardware?
During an installation, I remember the pilot indicated a lag with a specific function with the aircraft simulator. We called the software engineer to come to take a look and within minutes the software engineer was able to deploy a hotfix. The pilot tested and was happy with the outcome.
Similarly, during a test flight, one of the functions of the aircraft worked intermittently. We called our software engineer who saw the function did not respond as expected. The software engineer reviewed the code and confirmed the code is appropriate. Tests in the test environment functioned appropriately. It must be a hardware issue.
As a test engineer, these were the words no test engineer wanted to hear.
My task was to review the hardware diagrams and recheck the wiring. I did, and the wiring was correct as per the hardware diagrams. I let my manager know.
My manager asked if I was sure.
At this point, we both knew the software engineer had given the green light that the software worked as expected.
The relationship between software and hardware is delicate
I began to understand the delicate nature of software and hardware/ test engineers working together and the tension between the two disciplines.
My manager asked me before we report the wiring is as expected, we should double-check each physical connection for improper wiring, as well anything that might need some work. We both started at opposite ends looking to meet in the middle.
As I inspected the wiring and circuit boards I notice one pin slightly bent and touching another pin. The circuit we tested worked but the bent pin was not up to standard. This was likely the cause. After some additional testing, we confirmed this as the cause.
We needed a new component to fix this. This meant we needed to create some paperwork that a specific part was faulty.
Introducing additional stakeholders
Next, we looped in procurement who first had the task of ordering a new replacement. It was a custom-built component with a three-week lead time.
Three-weeks?
Unfortunately, we did not keep any extra inventory of that particular component. So we began the wait.
At the same time procurement reviewed the chain of custody from receiving to installation in the simulator. Was it our fault once we received the component or was it a manufacturing default?
Luckily the component in question was not expensive. If it was, the finance team would definitely be involved. Luckily no budget conversations were necessary.
Once our component was delivered the component was inspected and installed. The function that was working intermittently now worked as designed.
Problem solved temporarily
Purchasing realized that this particular component was one that regularly failed and suggested we should keep some in stock for such situations. The extra stock order was approved and ordered to be kept in our stock warehouse.
Meanwhile, the design team who were working on the next generation of simulators had flagged this component as a potential redesign item.
I remember being invited to a design brief meeting where I was asked about the component and how we test it.
I asked the designer to walk me through the process of idea to implementation to feedback. One of the first things the designer mentioned was that it might take 2-3 years before this component goes into production on a customer simulator.
The designer told me first there is a design and review process. Then we have to look for competitive bids for manufacturing. Manufacturing can include investing in molds, setting up and moving machinery. Maybe new machines, training of people, quality control, and testing among other things.
Hardware is physical and physical takes time.
The release process
In my opinion, one of the most contentious differences between a software product manager and a hardware product manager is the release process.
In the software world, we are encouraged to iterate fast, ship fast, and build on user feedback.
Software teams
Ship fast and learn from feedback.
Break down the scope into smaller manageable parts.
Ability to roll back versions (with little or no cost).
Potential for using open source or 3rd party software.
Software teams optimize the path from idea to implementation to feedback to the point they can aim for a short cadence and begin “continuous development.”
Hardware teams
Releases are planned years in advance.
Components may not be easily broken into smaller parts.
Once in production difficult to roll back (can be expensive).
Additional stakeholders such as procurement, manufacturing, and inventory.
Hardware teams also try to optimize the path from idea to implementation to feedback. However, they work in a physical world that comes with its own constraints. Therefore, expect fewer releases.
In the hardware world, we are encouraged to move slower, work within rigid requirements, and need to work within the constraints of the physical world.
Have you ever wondered why your favorite hardware product only releases say once a year?
Well, now you know.
Software vs. Hardware Product Management
What is service product management?
Service product management is relatively new. Instead of working on a software or hardware product. Service product managers are focused on reducing friction, improving the customer experience, and strengthening the relationship.
Services is a very large industry and nuances apply. However, the skills a traditional product manager would use are very applicable to the services business.
They dig deep into customer research and identify opportunities from the sales process to delivery to optimize the experience.
Pradip Khakhar
Read also
Experience the new way of doing product management
