Documentation for the Hardware Product Manager
Good documentation is always hard. It’s hard to write, and even harder to maintain. But, nothing communicates ideas from one to many in a scalable, repeatable way like good writing (anyone's who played the "telephone" game will understand this). It’s worth doing. But if you’re going to do it, you have to do it well.
I’ve struggled a lot with documenting business arguments and product requirements as a hardware-focused product manager. For a long time, I was shoving everything into one Product Requirements Document based on the Product Hunt template (which is a good point of reference!). But, there’s a tall stack of information in hardware. You have to get from the business case, to the physical product description and performance, to the software features and interactions. It’s too much information to live in one document, because any one person that were to read it would get bogged down in information not relevant to them. After all, your CEO doesn't need to know your battery life spec, and your engineer lead may not be interested in market trajectories.
To combat this, I’ve settled on a three-document approach. Each document is concise, focused on a particular audience with a clear goal. They are:
* Market Requirements Document (MRD)
* Product Requirements Document (PRD)
* Product Specification
Market Requirements Document (MRD)
The MRD is targeted at people who need to understand the opportunity you’re pursuing at a high level. This could be your CEO, other executives, your peers in product management, or particularly inquisitive engineers. Your goal is to make a coherent and persuasive argument for the product you’re working on.
Get ready to make some sweet charts in your MRD
Section headings I recommend:
- What Is It: A short, high-level description of the product. ie: “a wearable for the elderly that alarms when a fall is detected"
- User Need: A brief, user-focused description of the need. ie: “existing products are too complicated for senior ciizens to set up, use, and keep charged, defeating the purpose”
- Market Size: Do your research and figure out how big the market is. Break out your estimates of TAM, SAM, SOM.
- Competition and differentiation: Be upfront about the competitive landscape and how you will differentiate yourself. Maybe the market has overlooked rural seniors, or the simplicity of your product will set you apart.
- Pricing: How much will you charge for your thing? Roughly how much profit can you make per unit? Will a software subscription be part of the puzzle?
- Go-to-market plan and revenue projections: How will you spread the word about your thing and start selling? How much might you make in the first year or two?
If this document does its job, you’ll make a strong case for your plan and rally others to your cause.
Product Requirements Document (PRD)
The PRD is targeted at leaders in product development. Your goal is to communicate clearly the defining features of the thing you want to build.
Bridge the gap between your understanding and that of your engineers, and keep this from happening
Section headings I recommend:
- What Is It and User Need: recap the first two sections of your MRD. It’s okay to be a little briefer this time around. But, I’m of the opinion that everyone, from your company’s CEO to the engineers in the trenches, should understand why you’re building what you’re building.
- Product Nucleus: I take a cue from my time at Mindtribe, and make the body of my PRD a Product Nucleus. I make a prioritized, user-centric list of the key elements of the product. Or rather, I do a first draft. Then, I do two things. First, I schedule time to review my user and product research with the product development teams. We go through some of the interviews I’ve done, and then maybe demo competitive products. Second, I sit down with the team and ask them to prioritize the entries in the nucleus. This exercise gets everyone on the same page about product priorities.
- Major HW features: here is where I make an effort to sketch out items like rough product dimensions, user interactions, and U/I elements (buttons? touch-screen? etc.).
- Major SW features: I throw in any sketches or mockups of app pages/interactions
The PRD will certainly overlap with your MRD a bit, but that’s a good thing. Most importantly, if you’ve put this document together right, the people leading your product development efforts will be focused and well-aligned on what to make.
Product Specification
The product spec is targeted at engineers. This is where you’ll describe in gory detail the technical requirements of your product.
I consider this document optional. If you’ve done a good job with your PRD and working with your product development leads to define product priorities and high-level hardware/software descriptions, your technical leads might take it from here. But if you have very particular technical requirements in mind, or if you wear multiple hats leading technical efforts as well, or if you’re working with JDMs on some aspects of product development, then it might be a good idea to put one of these together.
Section headings I recommend:
- hardware block diagrams
- key electrical components
- hardware performance requirements (battery life, sleep/wake times, sensor accuracy, data transfer speeds, etc.)
- testing requirements (desired environmental and reliability specs, IP-ratings, etc.)
- and more!
Remember, brevity is the soul of wit. Keep each document to just a few pages long, capturing the key information. With that in mind, it really shouldn’t take too long to put these documents together. And once you have them, you have a great tool for spreading understanding about your work to all levels of your organization – from upper management to the engineers. And, as a product manager, there’s really nothing more important than clearly communicating your product vision and priorities.
