In my post on product prioritization, I listed 6 popular frameworks that product managers can use to focus teams on the most important tasks. While these frameworks are often associated with software development efforts, they shouldn’t be restricted to that. In fact, they are useful for both software and hardware product management during product discovery. Though, when it comes to dealing with bugs that occur during hardware product development, many of these frameworks do not easily apply.
Hardware Product Development Process Overview
Before discussing prioritization of hardware features and bugs, here’s a high-level primer on Hardware Product Development Process.
The development phases – prototype, EVT, DVT, and sometimes PVT stages can take on multiple iterations depending on the hardware complexity. For instance, at the prototype phase, a product can go through P1, P2, P3, P4 prototype builds before moving on to EVT – EVT1, EVT2, and so on. The riskiest items should always be evaluated as early as possible for feasibility.
Triple Constraint Triangle
In project management, there’s a classic triangle (also known as Triple Constraint or Iron Triangle) that is used to visualize the constraints as well as analyze how making optimizations on one area of the project jeopardizes another. For any project, it’s nearly impossible to optimize for all three constraints and one has to pick two.
This classic triangle doesn’t quite capture the impact to customer experience for any of these constraints. As a product manager, I err towards exceeding or at the very least, meeting customer expectations with great quality products. As such, I have come to prefer this version of the Triple Constraint for prioritization analyses:
With Quality as the central theme, the idealistic criteria for the project is as follows:
- not exceed cost/budget
- delivered on time/schedule
- meet agreed-upon scope/requirements – no scope creep!
The Iron Triangle is about balancing each constraint to realize a successful project outcome. I have never worked on a project that has met all 3 criteria on the first attempt. If you are the unicorn who has, please reach out as I’d love some of your good luck to rub off on me 😁
When issues arise, it is important to assess risk and resolution from the lens of the customer experience. As a product manager in hardware, keeping these constraints in mind is quite instrumental for product prioritization efforts.
Product Prioritization Framework for Hardware
As a product goes through the various stages of the Product Development Process, the expectation is that the product will reach a shippable-level of stability. Along the way, at the EVT/DVT stages, reliability testing and beta trials often uncover new problems that attempt to throw any one of those constraints off balance. When this happens, the hardware product manager must work closely with the program manager and engineering lead to assess risks, provide mitigation paths, and propose solutions – all without compromising customer quality.
Here’s a flowchart of how I analyze issues as they arise. It’s not exhaustive and doesn’t account for every nuance or dependency. Nonetheless, It’s helpful as a high-level reference guide:
When an issue arises, I get as much information and facts as possible from the appropriate teams to aid my understanding of the various implications of the issue. I also assess the impact to the customer experience, the business, as well as the priority relative to the product requirements document (PRD). After gathering as much information as available, I focus on what must absolutely be resolved and where concessions are acceptable.
Must Resolve
An issue must be resolved if it:
- impacts the core functionality of the product, rendering it unusable
- is a P0 requirement such that the product will not ship without this feature
Implications:
- Schedule: When a significant issue surfaces, you’re always going to lose time and need additional builds for validation efforts. The amount of time lost depends on the team’s ability to swiftly identify all relevant information, triage issues, test and integrate proposed solutions. From a business perspective, each day without a resolution implies GTM and revenue-generation delays. Furthermore, delays not only impact your business but that of your supply chain partners as well. For a MUST RESOLVE issue, it’s all hands on deck until the fire is put out.
- Cost: There are financial costs that aren’t accounted for in the budget resulting in the business having to pull finances from elsewhere. There are also opportunity costs that are incurred when the team spends much of their time resolving this highest priority issue.
Re-evaluate or De-scope
For an issue that doesn’t impact customer experience or core functionality, it is necessary to re-assess expectations and scope of requirement.
For example, let’s say back in 2015, the PRD for a connected device stated 5G support as a P0 requirement. Then, the feature was implemented and deemed relatively stable throughout the early build phases. However, during beta testing, significant instabilities were reported not just on 5G but the overall connectivity of the device. Assuming the reasons are due to the nascence of 5G at the time, we may decide to de-scope 5G for this version of the product. The justification for this could be the lack of awareness and broad use-case for this technology. We de-scope it with conviction that there is little-to-no impact to the customer experience.
Implications:
Here, the main takeaway is that time-to-market is of the essence. In other words, it is better to launch without this feature than to launch late or not at all.
When re-evaluating or de-scoping a feature, you can decide to :
- add this feature to the roadmap with plans to launch at a later time
- remove the feature completely from the roadmap upon further research
- do something else as it pertains to your company strategy
Other things to note
Press & Influencer Reviews
In hardware product development, press reviews and influencer marketing are a huge part of the Go-to-Market (GTM) Launch Plan. Many prospective customers flock to these channels for review assessment when making a purchase decision. When making priority calls, it is important to think about how a particular issue or resolution decision might influence press reviews. Work with your marketing and launch teams to come up with an appropriate strategy and ensure alignment.
Post-Ramp Qualification (PRQ)
After ramp/MP start, PRQ is used to validate new designs or alternate component/material sources. Sometimes it’s done opportunistically to take advantage of cheaper components or materials. Other times, it is necessitated by a new design to resolve some problems that surfaced during reliability testing. If the issues do not threaten the customer experience and time is of the essence, then punting a resolution to a PRQ might be the right course of action.
Prioritization is a required skill for both software and hardware product managers. If you struggle with prioritization, chances are your product lack a clear strategy. As I mentioned in my post, prioritization begins with strategy. If you’re a product leader, it is your role to ensure a product strategy exists. If you’re not a product leader, this is a growth opportunity for you to establish one and garner buy-in.
Remember, there is no one-size-fits-all approach for prioritization. Different companies require different frameworks. Within the same company, frameworks might differ per team or per product. Whichever you choose, make sure your team and stakeholders are aware and aligned.
The ultimate goal with any prioritization framework is to ensure teams are working on the most important initiatives that deliver value for the customer and the business.
Liked the post and think someone else will? Please share 😃
I’m making small bets, hosting a podcast, and sharing learnings on Twitter.
