How to Write Requirements that Actually Lead to Better Products
On the surface, requirements seem simple. They are statements that outline the details of your customer’s problem, so your design or development team can come up with a solution.
But in practice, requirements get complicated. You want to include enough information so your team understands the problem, but not so much that they get mired in the details. You want to make sure you focus on the right requirements—the ones that are most important to as many of your customers as possible. And you want to make sure everyone—account managers, project managers, developers, executives—understands why and how you prioritize your requirements.
Requirements are a vital part of the planning process in any successful company and a central part of the Pragmatic Framework. Learn more about what requirements are, who is responsible for them, how to write a powerful product requirements document and more.
What are requirements?
A requirement is a statement designed for your developers that outlines:
-
- Who has a problem
- What the problem is
- How often the problem occurs
It’s equally important to understand what’s not part of a requirement—and that’s a solution. A requirement conveys the information your design and development team needs so they can understand the problem in the context of the market. From there, it’s their job to come up with innovative solutions.
Your company might use either the term “product requirements,” “market requirements” or both. A product requirement details a customer’s problem or a persona’s problem. Market requirements are a collection of these product requirements. However, some companies use these terms interchangeably, and some don’t differentiate between the two. If the documentation or terminology isn’t working for your organization, you may only need one requirements document regardless of what you call it.
A requirement conveys the information your design and development team needs so they can understand the problem in the context of the market.
Why requirements matter
Understanding requirements is crucial for keeping your current customers happy and creating a product that’s attractive to potential customers. Product requirements help you create better products or improve your products. More importantly, they move your products in the direction your target market wants so that they can help your business lead in your industry.
Done correctly, product requirements get your team on the same page. With solid product requirements, product managers make more proactive decisions, account managers are supportive, field engineers are responsive and development engineers are happy.
Who is responsible for requirements?
As you’re evaluating and implementing your requirements, you’ll ask yourself these three questions:
- What are we going to build?
- When do we need to be finished?
- How are we going to get it done?
Product managers have the primary responsibility for the first question. Product managers can take feedback from multiple customers and create a single set of requirements that outlines what you’ll build.
Project managers answer the second question. They can also develop an overarching schedule that encompasses software, hardware, services, documentation, promotion and sales.
Product architects and designers answer the third question and are responsible for analysis and design. The development team steps in to handle the design, coding and testing.
How to write a product requirements document
A product requirements document (PRD) is a collection of requirements you’ve identified as important for your product. In your PRD, you’ll spell out the details of your customer’s problem for your designer or developer. Your requirement includes the information your designer or developer needs to solve your customer’s problem innovatively.How the process fits into your business
To develop innovative products, you need to:- Find a problem—here’s where your PRD comes in
- Analyze it
- Design an innovative solution
- Code to the design
- Test the result
What traditional requirements look like
The Institute of Electrical and Electronics Engineers defines a requirement as a statement that identifies a capability, physical characteristic or quality factor that leads to a product or process problem. Typically, they fall into five types:- Functional – Capabilities the persona needs to perform the task or complete their goals
- Performance – Factors such as capacity, speed and concurrency
- Constraints – Conditions that limit the design
- Interface – Interaction with hardware and software
- Security – Meeting government mandates and customer privacy requirements
Communicating about requirements
Start by making sure your requirement is clearly conveying your persona’s problem before you share it with your design team. Give them the detail they need for context without overwhelming them. That way, they can answer many of the questions that arise without turning to the product manager for clarification. Keep in mind that your development team is your customer. Ask them how they want to receive the requirements and what tools they will use to solve the problem. Create ongoing opportunities for communication so you can discuss variables, priorities and responsibilities.Requirements that work
The best requirements tell a story so your designers can see the problem from the customer’s point of view and understand why they need a solution. You can frame your story in a use scenario like this: Persona has this problem with this frequency. For example, Sarah, a college student, needs to pay her tuition each semester using multiple credit cards. Ideally, along with the requirements, you’ll share names and contact information of two or three potential users your designers can contact with questions such as, “How are you solving the problem now, and how would you like to be able to solve it?”Documents for requirements
You need three documents to communicate information about your personas and their problems:- Business plan, which includes research, results, market definition, distribution strategy, distinctive competence and a financial plan. Be sure to update it yearly to compare your goals with your results.
- Product roadmap, which outlines your deliverables for the next 18 to 36 months or three to four product releases.
- Requirements, which state and prioritize your personas’ problems that you’ll address in the next release or version of your product.
Writing requirements as a virtual team
When a group of people create requirements together, start on a project together and work together, they’re more likely to succeed. But these days, it’s likely your team members are living in different cities and maybe other countries. They are working in different time zones and have different cultures. When in-person informal chats and regular meetings can’t happen, how can you create requirements where everyone is on the same page?
You can create virtual visits where you interview potential customers via video to find out what keeps them up at night, then share the outcomes.
You can then share all the results and identify clusters of problems with an online whiteboard. You can track your past and upcoming interviews with a shared Kanban or Trello board. Once you’ve gathered enough information, you can define your persona and their problem.
Make sure you include architecture, engineering and design as you define what needs to be done and you share your understanding.
For a closer look at writing requirements as an international team, check out our video featuring Johnathan Lucky, scrum master at DAZN.
Challenges of writing a product requirements document (PRD)
It’s crucial to write an effective PRD. But it’s not easy. Here are a few common roadblocks that can crop up.
Too much information
When you try to capture all of your customer insights in the PRD, it can become unreadable. You may need different versions of your PRD depending on the situation. For example, you need only the top-level, high-priority requirements for a product overview meeting. But you need more detailed information when you’re constructing design documents.
With good PRD design, you’ll link your requirements to customer insights, differentiate core requirements from other information, identify short-term and long-term requirements, and share the appropriate information with different audiences.
Losing track of customer insight
The insights you gain from your customers are valuable. Yet they are often stored in memory and forgotten, kept in notes that aren’t easy to access, buried in old PRDs or gone when employees leave the company without documenting the insight.
Ideally, you want your customer insights stored in a place where the product manager and other key team members can easily access them and sort through for the relevant information.
Not focusing on your developers
Developers are the audience for your PRD. So if you don’t keep that in mind when you’re creating and revising your PRD, you won’t provide them with the information they need.
Be prepared to address their questions, make modifications in the PRD when necessary, and highlight those modifications so developers can easily spot the newest changes.
Not listening to account managers
Communication breakdowns often lead to the perception that product managers aren’t listening to customers’ needs.
In good requirements management, you show account managers that you are discussing and considering their customer’s problems. That gives account managers confidence that you’re listening. You also can involve account managers in prioritizing requirements so they see what is getting immediate attention and what’s further down the list.
Moving too quickly
Often, developers start working on a project before the PRD is ready. This sequence can lead to uncertainty and poor communication.
You can steer clear of this problem by proactively developing and prioritizing requirements for future products.
Not sharing information
There’s often a gap between what customers want and what the development team can achieve. That’s understandable, but it can be disappointing.
The solution? Track and deliver critical information throughout the process, so everyone understands what’s included in the final version and why certain features might be delayed or omitted.
Our article, Managing Product Requirements: Where Did All My Customer Insights Go? can give you more information about the problems that can crop up when you’re creating your PRD.
When a group of people create requirements together, start on a project together and work together, they’re more likely to succeed.
How agile development affects requirements
With agile, you break a job into small chunks and deliver something in a short time, typically two to four weeks. Requirements that don’t fit in that period can get added to the next. Ideally, agile means you can respond to your market’s needs quickly. But it’s crucial that you develop agile requirements with your market in mind. Often, executives ask for new features or change their minds. So instead of responding to what your customers want, you’re responding to what executives are asking for.
To make requirements work with agile development, the product manager needs to serve as the representative of the customers, taking all of their requirements, aggregating them and prioritizing them.
With agile requirements, you need to include team members throughout the process. Have designers or developers be part of customer interviews. Get everyone’s input when you’re developing personas. Include representatives from all aspects of the process when you’re prioritizing.
Examples of a requirement
Here’s a simple requirement statement:
Vince needs to be able to use the handheld network tester while wearing heavy winter gloves.
In this case, Vince is the persona—a worker who needs to do his job outdoors in the winter.
The problem is that it’s challenging to use the handheld network tester with his gloves on. And the frequency when he faces this problem is every time the weather is cold enough to need gloves.
Learn more about writing requirements
Understanding how to develop strong requirements keeps your company aimed at the target that matters—finding innovative solutions for your customers and your market. Register for Pragmatic Institute’s Build course today to learn more about identifying requirements and how to write a product requirements document that will help your company lead in your industry.