As a first-time Product Manager at an enterprise software startup, I find myself spending a lot of time doing research and creating requirements documents for our product. One of the biggest challenges early on was to build a mental distinction between a concept document and a requirement document. The concept document describes the general direction for the product or feature set whereas the requirements document is much more specific — this is a document to be handed off to the engineering team. Over the course of drafting several extensive ones, I have learned that the best requirements documents have three characteristics.
1. Show as much interaction between features as possible. Even though you may miss some interactions, showing them in a format helps the engineering team work through the details. For example, we recently built a campaign reporting tool that contains a funnel. Impressions, engagements, and conversions. Engagements and conversions change depending on the goal selected by the user. When I worked on requirements for our reporting tool, I drafted a paragraph detailing the differences. I thought it would suffice. Instead, it led to confusion. The paragraph I wrote was delivered in an easily digestible way. When I wrote the specs for the second time, I provided a Google Spreadsheet that documented the different goal types and how the funnel changed. Even though the words were the same, the format changed how quickly the requirement was understood.
2. When building products, engineering and product teams rarely have the answers to all questions that might arise. Product teams especially may not be able to flag all potential challenges for the engineering team before delivering requirements. Instead of using the uncertainty as a roadblock or using it to justify additional research, a strong Product Manager will flag any potential problems when working with the engineering team for the first time on the particular product or feature. This almost guarantees that whoever is building the technical requirements for the product will have to spend less time researching. At the very least, it shows that the PM thought about the question ahead of time and tried to address it.
3. Show functionality over design if needed. A strong PM has a deep understanding of the user and should be able to wireframe a UI/UX in the process of drafting requirements. If the problem is too complex or the timeframe short, PMs should focus on drafting the “what” instead of the “how”. In these situations, PMs should work with their design team to go through UI/UX.
Concept documents do not have to meet these three characteristics. In fact, they have the flexibility to leave questions open ended and have a well thought out user interface and user experience. Requirements documents on the other hands are much more functionality documents. They exist to guide the design and development teams in the iterative process required to create a product.