Requirements Management – 7 Tips for Writing Winning Product Requirements

Published 03/02 courtesy of Bamboo Solutions Community

Of all the jobs I've held in my career, working as a product manager was one of my favorites. My stint as product manager occurred at AOL where I had ownership of a handful of Web-based consumer finance applications. The primary products I had responsibility for included a stock quote utility and a portfolio management tool. These were software products, and the tips I'll offer on requirements management and authoring requirements will probably be most relevant to those of you who work on software products. This post is intended for any product manager though, whether your product is laundry detergent or golf balls. If part of your job is deciding what features get added to a product, this post is for you.

Writing great product requirements is an art. That statement sounds a bit cliché, but it actually means a few things to me. Those things include:

Some product requirements are better than others, and by extension, some people are better at writing requirements than others. This has nothing to do with the product itself and whether or not the product manager has chosen the right feature set for the product. In this context, "better" requirements are those that actually make it into the product, meet the needs of customers and stakeholders, and most importantly are accepted by engineering or whoever it is that has to act on what you've written.
Writing great product requirements is not science, it's not formulaic or process driven, it's about the quality of the communication. Quality communication comes from listening to your stakeholders, deeply understanding what they want, and then effectively communicating these needs to the team that will fulfill them. At the end of the day, if your engineering team doesn't understand the needs of your customers as well as you do, your product will never be as good as it should be.
In my experience, the best product managers are "creative types", not the detail oriented folks that succeed as project managers. In my experience, it's a pretty common career ambition for project managers to become product managers. I've seen very few project managers make the leap successfully, it's just a different skill set.

Without further ado, I'll jump straight into a hard-earned list of tips for writing great product requirements. Glancing over my list, I can tell you that I didn't follow any of them when I wrote my first PRD. I learned each of these lessons in a painful PRD review or through a disappointing product release.

Tip #1 - Use Pictures

When I started in product management at AOL, we had no system for managing product requirements. In fact, there wasn't even a standard PRD template used across the organization. The template that I inherited from my predecessor was a miserable MS Word template that required manual numbering of requirements and nearly constant reformatting. It was ugly to look at, and made almost no accommodation for the inclusion of graphics. In fact, I believe that culturally the organization avoided use of images in requirements documents. The main reason for this is that one set of resources that would work from my requirements was a design team. Product managers who drafted their own user interfaces or design elements were perceived as overstepping their role. This is a danger, one that can usually be overcome by labels such as "FPO (For placement only)", "Concept Mock," etc. But you should be very sensitive to the feelings of ownership that your design leads have over look and feel.

I finally started adding pictures to my requirements at the suggestion of an engineering manager who often had trouble visualizing my written descriptions of user interfaces and user controls. Once I started, I would never go back. A picture is worth a thousand words, and takes a lot less time to read. If your requirements management system allows, include those images directly in the written requirement, not as appendix to your PRD. Use screenshots, or drawings or whatever images you can find that best capture the requirement in question.

Tip #2 - Have Some Fun, Mention Team Members by Name

I've seen a lot of PRDs that make for pretty boring reading. If you follow the textbook approach to requirements construction (e.g., ACTOR will be able to VERB/FUNCTION to achieve BENEFIT STATEMENT), you get a pretty damn dry document that no one will want to read. One of the things I started doing to combat boring PRDs was to include the names of product team members in my use cases.

I remember one particularly grueling set of requirements I had to write that were mostly math and formulas. Initially my use cases read something like "User receives a dividend payment for his position in Company X. The user position is incremented... blah, blah, blah." Just because I was bored by the text myself, I started using the names of various team members in my use cases. My revised text was much more readable... "Amy owns 100 shares of Microsoft stock. Microsoft declares a dividend of $4.50 per share"

Not only were my use cases much more readable, but team members began looking forward to finding their names in my PRDs. Team members that I knew had never actually read my PRDs began scouring them for the mere mention of their name. It works, try it.

Of course you have to be careful that your narrative doesn't become a distraction to the functionality. But when done correctly, this is a great way to make your PRDs more communicative and much more fun.

Tip #3 - Group Requirements Together by Function

I've seen requirements management systems and PRD templates that make it difficult to logically group requirements together in sections. Some of these requirements management tools try to order requirements by priority or level of effort or some other characteristic that is unrelated to work to be done. This can be really tough. It's worth breaking the PRD template or hacking the tool to keep requirements together that are related. If you have a dozen requirements related to reporting, keep them together. If your product has sections or modules, list the requirements for each section in a separate group. If the folks who have to fulfill your requirements have to jump around from section to section, they will inevitably miss something. Make it as easy on them as possible. If your tool simply will not permit this, add in references to make all that jumping around easier. (e.g., Requirement 3.1.1.8 - Printable Output for Users is related to requirement 10.1.7 - Summary Values)

Tip #4 - Spell Check, Use Correct Grammar, Avoid Acronyms & Internal Jargon

Spell check and grammar correction are nearly ubiquitous features of the tools we use to author product requirements. Still, I've seen plenty of PRDs in circulation with spelling errors and lousy grammar. It may sound ridiculous, but you will find that your product teams will get stuck on these errors and call them out during a PRD review. I can remember attending at least one PRD review that was completely derailed by the fact that the engineering manager insisted on identifying every grammatical defect of the document.

Under ideal circumstances, the product team cares about your product, has bought into your vision and is eager to work with you to deploy the features you've identified as important. However most of us end up working in less than ideal circumstances. In many cases, every new feature that is accepted means more work for the team. The more requirements they can kill, the less work they have to do. It's also common for members of the product team to disagree with you on feature priority and how features are implemented. In these less than ideal circumstances, the product team will latch onto any defect of your document to filibuster your requirements and undermine your credibility. Take the time to scrub your text, don't give them anything to ding in your document.

On a related note, I encourage you to avoid acronyms and internal jargon whenever possible. If you know up front that your document will be riddled with acronyms and obscure terms not everyone will know, a nice touch is to create a section for definitions. A little chart including term and definition will help ensure everyone knows what you're talking about.

Tip #5 - Write At Least Two Requirements That Will Be Rejected or Deferred

Yeah I know, this sounds pretty manipulative. I'm barely comfortable writing it. But as a practice, it is useful. Again, if you're working under ideal circumstances, the product team is a group of individuals who love your product as much as you do and will do whatever is necessary to help you improve it. If that's your situation, feel free to skip this suggestion.

For those few of you still with me, you know that the product team doesn't come to a PRD review just to hear you tell them what to do. At best the product team wants to believe that they have contributed to your vision of the product. At worst the product team is motivated to reject complex functionality that will be difficult to build. In either case, they are going to want to see their input reflected in future versions of your document. They will not be bought in on a release definition until the PRD includes something from them.

There's also something magical that happens when a product manager surrenders a requirement to the team. Being able to say, "Now that I've heard your feedback, I realize this is too aggressive - I will strike it," will buy you an amazing amount of goodwill. Including a couple of straw men will also give you something to negotiate with when the product team is attacking key requirements you must have. "Hey, I was willing to give up 5.1.1.2, I need you to work with me on 7.2.1.7 Deal?"

Tip #6 - Tell Them What You Need, Not How to Deliver It

One of the cardinal sins of authoring product requirements is to specify the technology or method used to fulfill the requirement. It's hard to avoid, especially if you actually have expertise in a particular area. When product managers come from engineering, project management, or design they often have strong opinions about how a requirement should be executed. Even if you really do know the best way, even if you're right, do not write it in your PRD!

If your requirement reads, "Write a JavaScript query to do X" or "store user values in a SQL database" you are headed for trouble. Now that you're a product manager, your job is to decide what gets done, not how it gets done. The truth is your legacy expertise is probably out of date anyhow, so shut up and let the current experts figure it out.

Feel free to write your requirement in a manner that suggests a particular implementation. Add conditions and restraints that ensure your preferred method of delivery is likely to be the only answer. But whatever you do, don't tell other people how to do their job.

Tip #7 - Load Up on Appendices

Any good PRD template or requirements gathering tool will provide you with virtually unlimited opportunities to add appendices. By the time you've finished anguishing over all of your requirements, you may not feel especially motivated to tack on ten more pages of exhibits. Do it anyway, it might just save your butt.

What should go in the appendix? I recommend loading up on data that supports the requirements you've written. Chances are that before your PRD gets baselined, someone is going to challenge or question either the content or the priority of your requirements. Having supporting data at your fingertips can help you quickly quash these challenges. Include customer verbatims, pathing data from Google Analytics, sales data, screenshots of competitive products, anything you can think of. The more information you can provide, the more likely it is that stakeholders and the product team will share your vision for the product.

I hope that you found something useful in these tips that will help you write more effective requirements. I hope you will add your own suggestions as comments to this post. Finally, I hope you enjoy your time as a product manager, it truly is one of the best jobs around, despite the headaches.

Do you know what all of these tips have in common? These are all things you can do quite easily if you are using the best requirements management solution in the market, BambooRM. BambooRM is a SaaS solution for requirements management. This is a tool developed by folks with many years of practical experience in gathering and managing requirements. We know it has everything you need, because we've been there. Try it free today!

Sharepoint Answers

Requirements Management – 7 Tips for Writing Winning Product Requirements

Recent SharePoint Questions

More Articles By

Develop Mobile Applications for SharePoint with Mobile Entree - CMSWire

Bamboos Year in Review: Marc OBrien Introduces the Bamboo Online Applications Division

Working with the Admin Links on your SharePoint Blog

More Articles Under "News from Around the Web"

Guest Blog by H3 Solutions Jason Hall - Mobile Entrée, Taking a Look Under the Hood

SharePoint on Your SmartPhone, Android Moves to Laptops, Best Practices Conference Speakers List

Announcing the Best Practices Conference Speakers List!

Most Viewed Content

Sharepoint Answers

Requirements Management – 7 Tips for Writing Winning Product Requirements

Share This Article

Recent SharePoint Questions

More Articles By

Develop Mobile Applications for SharePoint with Mobile Entree - CMSWire

Bamboos Year in Review: Marc OBrien Introduces the Bamboo Online Applications Division

Working with the Admin Links on your SharePoint Blog

More Articles Under "News from Around the Web"

Guest Blog by H3 Solutions Jason Hall - Mobile Entrée, Taking a Look Under the Hood

SharePoint on Your SmartPhone, Android Moves to Laptops, Best Practices Conference Speakers List

Announcing the Best Practices Conference Speakers List!

Most Viewed Content