How to Write Product Requirements That’ll Wow Your Boss(es)

I’m a Product Management Intern — I just wrote a list of Requirements for the first time, here are my findings, struggles, and recommendations to others.

Recently, I was tasked with writing product requirements as a follow up to my PR FAQ. Requirements are a very important step in the development process because this is what your team will use to make sure what parts of the project are doable and make sure that the timeline will offer you enough time to make this happen.

For my first requirements document, I wrote the functional and visual requirements for a camera in a social media app. Requirements will probably be the most meticulous and tedious task you will have to master while being a product manager. It’s an entire skill that needs to be learned and understood. It took me four drafts just to get it through my head what requirements are exactly.

Whether you learn through definitions or hands-on, writing requirements is going to be a lot of trial and error. So less of figuring out what to do and more figuring out what not to do. But that’s completely fine, because you’re learning.

So, what are requirements?

In a very basic sense, requirements are a very specific set of needs or wants that will be included in a project or product. Using requirements are how your team members will collect all the information needed to build or design a product. The requirements of any product need to be specific enough so that if anyone was to come and try to start making mock ups of your descriptions, they could do it with ease.

There are two types of requirements to help with specificity and force you to think critically about what you’re doing. There are Functional Requirements and Visual Requirements. Functional requirements are limited to only how a user or customer will interact with a new feature, or the functions of this new feature. Functional requirements will often look like “Tapping directly on the downward arrow will trigger a drop down menu” while Visual requirements will look more like “Pictures are displayed in rectangular form”.

Starting my own requirements, I didn’t look for very many resources because I thought it was self explanatory. I watched a couple YouTube videos and read one article and thought I understood. I made my first draft and quickly became less and less confident and more confused. My first draft was very short compared to the others that I was using to go off of.

My boss(es) lent me multiple resources and gave me some pointers and prompts to make my information more well put and better laid out. I realized that I was combining the visual and functional requirements into the same points in order to condense more information into the same sentence. Don’t do that. Organize your thoughts and separate visual and functional information. And if anything, be too specific.

After taking those pointers and prompts into account, I started on my second draft. I made two different mistakes this time.

My diction was much too casual — what I was good at in the PR FAQ, was stopping my progress in my requirements. It’s only a couple of instances but it was enough to throw off the focus while reading it through. I used “camera” where I should’ve used “capture”, I used “you” and second person point of view where I should’ve used “user” and third person point of view. Always be conscious of the language you use and what context you’re using it in, but if you need to, write everything how you would normally and then go back through to places you can be more specific.

When creating requirements, you are creating a new process of events. You’re changing a process or a feature and making it better. So when you write this new process, don’t mention the old one. Don’t say “Instead of ___, this feature will be introduced”. All you need to say is what the feature will look like and what it will behave like.

This is my latest draft of my requirements. I won’t say my final draft only because there are still things I can improve on and projects change all the time. A week after you finish your requirements, you might have to go back in and tweak some things because a feature may be taken out for times’ sake, or it just wasn’t going to work, or someone else recommended a better way than what you had originally. And that’s alright. Everyone involved with the project is learning and just trying their best.

The Visual and Functional Requirements are separate, there’s language specific to this project, and the points and subpoints are descriptive enough so that anybody could pick this up and understand it. I did not expect everything to stay the same as it started as, content-wise. Lots of small features or behaviors changed since I started writing this and I have had to implement them. Aspects will continue to change that I will need to stay on top of and pay attention to so I can change them within the requirements.

Requirements are a big and, admittedly, scary thing to learn about for people who have never heard of the word in this context. Despite the fear of new concepts, learning how to correctly list out these requirements is a necessary step to take in this process because it allows everyone on your team to come to the same page. Essentially, requirements are very long and detailed outlines of the entire project you are working on — it brings up problems that you hadn’t considered and allows others to ask questions that will force you to think critically and it’s all a part of the learning curve.

I’m a Product Management Intern at Dark Matter Digital — a strategic product studio that specializes in helping companies create and test new software verticals.

I’m also a sophomore at Drexel University, where I study film and video production.

Follow along with my journey of being a first time Junior PM in my blog series, which you can find on the Dark Matter Digital publication.

See ya!