Product Feature Writeup Template
Every product person has their favorite one-pager format. I’ve been following the same format, roughly, since I started writing requirements in the late ’00s. I describe it as somewhere between a light one-pager and a fully formed PRD. This definitely isn’t detailed enough for a PRD, but I think it gets across functionality and dependencies better than some one-pagers I’ve seen, which has been helpful in my career in highly regulated industries. I thought I would share it, and the reasons behind the fields I include. I hope this helps some PMs be able to refine their thoughts and communicate their feature ideas!
What and Why
Feature Name/Working title — Obviously, this is the name of the thing you’re working on. If you have a marketing-type name, I recommend adding a more descriptive subtitle.
Business Justification — Describe in sentences WHY we are doing this work. What is the business problem we’re trying to solve? Add any relevant background info or statistics here too, like TAM or strategic goal links.
- What is the current state?
- What is the desired/future state?
- What is the work proposed for this phase (if applicable)?
Goals — What do we hope to change/achieve with this work? How will we know we’re successful? Example: increase conversion by x%.
Metrics — What metrics will we track for the feature? Specify events. Also a good practice to include how we will track the metrics. For example, in your product analytics or from a database report. Don’t forget adding the tracking/reporting as part of the work to be done!
Primary users/stakeholders — Personas (if you use them) or general notes about who the main “customer” of the feature is (either external customers or internal customers).
Timeline — We generally like to avoid time commitments, but this is a good place to add any regulatory or seasonality considerations (such as “needs to be finished before Open Enrollment begins in 10/1” or “should be done before summer vacation season starts on June 1”).
What the feature is/how it will solve the problem — This is the detailed description of what the proposed build looks like/feels like/behaves like. I generally use bullet points to specify functionality. This will be a bulk of the writeup and I encourage you to get as detailed as you need to be in order to communicate the build. You can (and should!) work with engineering and design when writing this part.
Use Cases — OK, hear me out. Use cases are phenomenal for thinking through edge cases or failure cases, which need to be accounted for during implementation. If you don’t think through these types of scenarios, you will have an “oh no” moment post-launch, I can almost guarantee you. You don’t need to use UML or follow a specific format, just focus on defining how a customer will achieve their objectives using the feature you just outlined above. You should include negative cases (what will happen if a customer enters invalid text? what happens if the download fails?) and empty/null cases (what does it look like for a new customer without any historical data?).
Non-Functional Requirements/Considerations
Security — Include security considerations! This could include things like permissions, database inputs, input validations, or PII data storage. If you aren’t sure how the feature you just defined could be exploited or manipulated, I encourage you to go talk to your application security folks! They can help review your spec and let you know, because threat modeling is part of their jobs.
Compliance — If this feature will impact or collect PHI, PII, PCI type data, you should check in with your compliance folks to understand if you need to address or add in any requirements for this. Similar to security, your compliance folks can review your spec and let you know what to include.
Reliability/Performance — Uptime requirements or performance considerations (example: make sure we can handle 2 tb data loads, we currently handle 100k transactions a day). If you don’t know this information, I encourage you to talk to your SREs or other infrastructure engineering folks!
Dependencies — Any related projects that could impact the build. For example, we need to upgrade the AWS account in order to build this, or we need to create a microservice to make this production-ready. It’s helpful to link this to those dependency tickets or writeups here, so everyone can read up on them.
Supporting Documentation
Mockups — I like to either embed or link to any related mockups. Links are easier because they will auto-refresh when you update the mockups, but if you have execs or sales folks reading your writeups, you can consider making this easy for them and embedding the mockup.
Tickets — I like to use a Jira macro to embed epics and stories that I’ve written so that there is a live connection to the work happening. This is especially helpful during and after the delivery phase of work.
