Managing product requirements
Product requirements management is an essential part of the software development process. It has a direct impact on the success of the project.
Smart requirements management ensures the project reaches its targets and all the necessary requirements end up in the final product release. On the contrary, inefficient or lack of management puts the project at risk and can lead to the failure of the final product to match the defined requirements and meet the stakeholders’ expectations.
This guide shapes the basic concept of efficient product requirements management. It explains why it is important and what techniques and methods of product requirements management are used in software development.
In this guide:
- The basics of product requirements management.
- Key techniques to document product requirements.
- Methods to prioritize product requirements.
The basics of product requirements management.
In general terms, product requirements management is the process of creating, documenting, prioritizing and communicating project requirements and their changes to relevant stakeholders.
Effective management of product requirements sits in the core of successful project realization for a number of reasons.
Reasons why product requirements management is important:
- Optimized cost and time of project implementation.
Most project managers, design and development teams work under conditions of time and budget constraints. They are expected to deliver functional prototypes and final products with the best time to market ratio and stay within the set cost limits.
Read: Tech team augmentation – best practices and tips for business
Smart requirements management is focused on helping teams work in this environment. Product managers use documentation and prioritization techniques to make sure each version of the product has just the right set of features for a certain iteration stage. Therefore, product requirements management helps save money and time on unnecessary modifications and additional iterations.
- Reduced misunderstanding between stakeholders.
Product requirements management is focused on keeping the transparency of the project development process. Documentation allows communicating requirements between a client and teams. In turn, efficient communication between project stakeholders helps minimize the mistakes during the transition from project strategy to project implementation.
- Ensured transfer of all necessary features into the final product.
As mentioned earlier, product requirements management implies strategic feature prioritization. Therefore, it ensures the right features are implemented at the right product iteration stage. Furthermore, every project manager uses requirements management techniques and methods to deliver a final product with all the necessary features confirmed by the stakeholders.
Key techniques to document product requirements.
Writing and documenting product requirements helps keep all the stakeholders updated on the course of project implementation and ensure control over and transparency at every stage of design and development. Here are three important techniques to document product requirements.
1. Jobs-to-be-done
Jobs-to-be-done (JTBD) framework is focused on solving a problem. It describes a project requirement based on the situation, the motivation for the job to be done and the desired outcome. Therefore, it is abstracting from the doer – persona. This is how a typical JTBD scheme looks:
When [situation], I want to [motivation], so I can [desired outcome].
For example, here we describe how a booking system is supposed to find a proper hotel option for any customer.
When [searching for a hotel to book], I want to [see the options at the best price] so that I can [quickly find a hotel within my price range].
Quick tips for the jobs-to-be-done framework
- Initially, determine and document first-tier jobs (problems to solve), then find less important jobs that enable first-tier jobs implementation.
- Analyze motivations – the benefits from solving a problem. Then, find out how similar problems are currently solved and try to discover a better solution.
- Build job stories – complete jobs users expect to be done and the goals they pursue.
- Build the flow according to the scheme using the determined situations, motivations and expected outcomes.
2. User stories
User stories framework is a great technique used to document requirements for the systems used by certain groups – personas. If you can determine personas for your project, you can write user stories focused on the needs, characteristics, expectations and goals of certain user segments. This is how a typical user story looks:
As a [type of user], I want [action/goal], so that to [outcome].
If we adjust the previous example of a booking system oriented on certain user groups – activity-focused travelers – we have the following user story.
As an [avid traveler], I want to [see hotel options within the walking distance from the major city sights], so that to [book the most relevant option for my travel activities plan].
Quick tips for user stories framework
- Study users to better understand their preferences, habits, behavior.
- Identify user groups based on their goals.
- Create user stories focused on user needs and expectations.
- Build the flow according to the scheme using the determined user groups and their goals.
3. Clickable prototype
This is not a typical requirements documentation technique. Clickable prototypes are easy instruments to demonstrate the functionality of the product when the backend and logics are not too complex. Then, it’s helpful to use visual documentation.
Clickable prototype gives the best visibility into the future project functionality – features, user flows, high-level user interactions. This instrument is useful for presenting a project idea and allows stakeholders to collaborate on allocating project requirements. Also, clickable prototypes are convenient for communicating product requirements.
The tools which allow creating easily clickable prototypes are abundant. However, they all require a certain level of technical knowledge and skills.
Quick tips for visual documentation
- Choose the right tool depending on the type of system that is supposed to be built (web, mobile app, chatbot, etc.)
- Collect the content necessary to demonstrate how the desired features work – preliminary images, text, form layout, etc.
- Arrange all the elements and configure the functionality in the tool according to the way the features should work.
- Use the clickable prototype to communicate requirements to the stakeholders and teams, collaborate on the requirements, get initial user feedback.
Methods to prioritize product requirements.
In order to optimize time to market ratio and get user feedback as soon as possible, it’s important to use iterative development approach. In this agile process, requirements prioritization is utterly important.
Prioritization of product requirements scope allows to elaborate the tactics for product implementation and arrange the features for development and release in the most reasonable sequence. Clever prioritization enables to roll out a fully-functional product prototype with the set of essential features first and then to grow a product at further iteration stages using real-life testing data (or user feedback).
Here are 4 ubiquitous methods used to prioritize requirements in software development.
MoSCoW method
MosCoW is the acronym for Must, Should, Could, Won’t. This method allows stakeholders to prioritize requirements using their gut feeling. Thus, stakeholders rate feature according to their belief of what is more or less important and assign a related attribute to each requirement.
MoSCoW prioritization method allows to define Must have requirements absolutely necessary for the project’s launch, determine Should have and Could have functionality, and decide upon the Won’t have features. As a result, this method helps launch the first version of the product once its core functionality (Must) is ready and continue iterations based on the real data coming from the testing of this version.
Kano model
Kano model dates back to the 80’s but finds its relevance in software development today. It’s a simple and versatile method to prioritize product requirements based on the concepts of “less is more” and primarily focusing on customer’s (user’s) needs.
According to the Kano model, we assign three attributes to product requirements:
- Basics – essential features necessary for the product to work and reflect the primary needs of customers (users).
- Satisfiers – the features the product can go without, which however are favorably received by the users and positively affect user satisfaction.
- Delighters – additional features that literally cause the user’s delight. These features are not expected to be in the product, however, once discovered, significantly boost the product’s competitiveness.
Based on the attributes in the Kano model, it’s easy to prioritize the requirements and develop the tactics for product development.
User stories mapping method
User stories mapping takes into consideration both business needs and optimized development flow at defining priorities. In many cases, it’s important to prioritize requirements in accordance with their technical dependencies and sequence.
This method allows to arrange requirements and determine product releases graphically. To build a prioritization matrix, we arrange user stories or tasks along the vertical axis depending on their criticality, starting from the most important at the top and following downwards to less important tasks. Horizontally, we arrange user stories of the same criticality according to their usage sequence and dependency.
As a result, we map all user stories in one table. Then, all we need is to draw a line to define which package of user stories should be delivered in the first version of the product, which goes to the second version and so on depending on the number of product iterations.
Financial model
Financial model is a more complex method to prioritize requirements. Often, it is used in the projects where we focus on improving and upgrading existing products and target financial performance growth.
Originally, it is based on the financial goals of the project and, therefore, requires a thorough analysis and understanding of both short-term and long-term project objectives and expectations from returns.
To prioritize product requirements according to the financial model, we need to determine and calculate different financial goals and expected returns.
- New revenue. Does the feature generate new income from the use of the product?
- Incremental revenue. Does the feature generate additional income from existing users if they choose to upgrade and use this feature?
- Retained revenue. Does the feature allow to save income thanks to retaining users?
- Saved cost. Does the feature enable improved operational efficiency that leads to saved cost?
Defining these goals allows to estimate the return from developing certain features, and most importantly, can help determine which features bring the biggest return in the shortest time possible. Using these calculations, we can prioritize the features from the most beneficial and rewarding in terms of ROI to the least ones.
This list of requirement prioritization methods is not exclusive. In fact, there are dozens of different models and tactics that can contribute to building a smart product development strategy. However, these particular methods are, possibly, the most ubiquitous when it comes to the agile process.
Moreover, depending on the iterations, the requirements stack is constantly changing in agile development. This is why efficient up-to-date product requirement management is essential for the success of the project. It covers digital product analytics, requirements analysis, documentation, prioritization, communication and changes management.
In the next articles, we’ll explain how to manage changing software project requirements and later discuss the difference between managing time and budget projects and the projects with changing requirements.
