Defining product requirements so everyone loves their job!

Every tech project ever..

Yes, this article is for you

Think back to the last time you were part of a project that didn’t go well because of poorly defined product requirements. You wanted to throw something at one or more persons but resisted because they weren’t worth the jail time. Much has been said to establish the need for great product requirements. But how do you know when your product manager or owner has got it right?

Elements of an amazing requirements document

Context / Value Proposition

What is the value proposition here? What is being changed or improved and why will the end user care? Even if the requirement is obvious, it needs to be clearly specified in writing as it will be referenced later. A product owner needs to communicate this effectively for the entire team to be onboard before any code is written. This is not a justification for the feature request but instead will help set the stage for advanced discussions.

For instance, a feature set is being developed to enable the user to perform a new activity. The owner wrote the context and began discussions with stakeholders. The team found a way to tweak existing features to bring the user to the same end goal! Having a clear context will lead to advanced discussions and can often save a lot of time for all stakeholders.

Defining Features

Welcome to the world of agile. A surefire way to annoy a dev team is to provide loosely defined features that changed over time. What may appear well-defined actually did not even qualify as a feature definition. Sample these three definitions below that have the same end goal of purchasing an item:

1. The user shall be able to add an item to cart and then check out in order to purchase the item

2. The user shall be able to click two buttons (Add to Cart and Checkout) and proceed to the next page in order to purchase the item

3. The user shall be able to click an add to cart button and notice the item was added to their cart. They shall be able to click the cart button to review items they want to purchase. Then they shall be able to click a proceed to checkout button and be directed to a payment page where they shall enter credit card details to purchase the item.

All stakeholders would love to receive the clear level of detail provided in (iii) instead of (i). It removes scope for ambiguity and again leads to advanced discussions.

What is needed v/s How to build it

There is a fine line between the What and the How. The product requirements must specify the What in as much detail as possible (what the feature will do, what the user will do with it, etc) but not How it should be built. That’s what the engineers and project managers are here for..don’t tell them how to do it!

In the above example in (iii) above, I focused on some of the How to provide a base for discussions with the engineering team. The How is never set in stone — engineering must have flexibility to build the product. It must be considered a success if it can deliver towards the What.

In summary, it is crucial to define each feature at the level of interaction design and provide clear use cases. Product owners must be very clear on what each feature is and what the user experience should be like, while leaving maximum flexibility on how to build it.

Prioritizing Features

As features are being defined, it is crucial to trace each one back to the business or operational objective being accomplished. Doing this will serve three massive goals:

1. Prioritizing all the features in an order that brings most value to the company (e.g. building a new feature v/s solving a bug in existing feature)

2. Identifying feature dependencies (e.g. makes no sense to build a payment page without first having functionality to add item to cart).

3. When a requirement needs to be cut or pushed to later release (as is often the case), the value it brings is my reference point. This way, the overall impact of any delay or unexpected issue during development is minimized.

Without clearly mapping requirements to overarching objectives, you’re left with a set of randomly prioritized features, lack of clarity on dependencies and the worst — when issues are encountered midway during the development cycle, changing priorities can leave team members feeling frustrated and lacking direction.

Wireframes & UI Mockups

Folks are still divided over the right timing to begin wire-framing and whether it is worth including mockups during an early draft of product requirements. Proponents argue that every mockup helps solidify the concept and provides direction to the team. Opponents feel that they are a waste of time early on and can limit the team’s thinking while starting out.

I recommend combining the best of both arguments. Having a basic wireframe in place for each major feature set while starting out. This will begin discussions with UI and UX teams who will gladly point out whether the idea is completely stupid or somewhat achievable. This way, stakeholders don’t need to stress about every single button while starting out but they have some idea on the lay of the land.

Proper Test Acceptance Criteria

When product requirements are published, the associated acceptance criteria are referred to by multiple individuals during the dev process. Ideally, a formal QA process is followed to ensure there were no issues. Often production environment bugs are not due to limitations in the technology stack but instead attributed to poor initial test acceptance criteria.

You can’t assume a feature will work the same way on all browsers, all operating systems and all devices. Test it! For e.g. if a feature bug is discovered on Firefox whereas the Chrome version works fine, but 36% of your users browse with Firefox, you’re getting set up for two different user experiences without even realizing that. The problem is exacerbated if you have feature dependencies.

The last thing you want is a supposedly successful on-time release with wonderful new functionality that doesn’t work properly for a subset of users due to poor initial testing. Blame games ensue. When defining requirements, placing in robust initial testing criteria will make everyone successful and love their jobs without sweating the small stuff.

The Awesome Future

Product requirements are referred to well after the project is over, sometimes even years down the line. The effect of having great product requirements each time around is compounded over over consecutive releases.

Imagine a world where the product owner got requirements right the first time. All the internal stakeholders enjoyed working on this project and all went smoothly. Ultimately, the customer was given a product that didn’t have bugs and fell in love with it. Now imagine this occurring each time! Well not quite but just how awesome would it be over the long run if each set of product requirements was stellar and every single issue associated with poor product requirements was always avoided.

Being a stickler about great product requirements each time may seem trivial but over the long run its positive effects are compounded over several years and successive launches.

Summary

Product requirements are the lifebloood of any project and are referred to at every point in not only the current lifecycle but also in the future. Excellent requirements will make everyone love their job and directly impact the team’s productivity. However, the value does not just end there.

Ultimately, getting your product requirements right will lead to the company shipping and implementing solutions that beat competitors and win the industry. You’re loved by customers and you reduce the number of customer support requests and negative reviews you receive. Boom!

Further Reading

If you’re interested in learning more about writing great product requirements, I recommend the following sources:

  1. How to write a good PRD, Silicon Valley Product Group

2. Product Requirements template, Aha! Product Management blog

3. Creating a lean mean requirements machine, Atlassian Agile blog


Thank you for reading my article. I would love to hear from you. What are your best practices and thoughts on product requirements? Please comment and share this article and be sure to connect with me on LinkedIn or Twitter.


About Me: I strive to write more words than memes. I have worked in roles ranging from engineering, product management and sales. I pursed a Master of Engineering Management at Dartmouth College and currently operate in a hybrid Sales Engineer & Product Manager role at a SaaS company in the San Francisco Bay Area.