Previous
¶ Requirement Management
¶ What it is
Requirement Management refers to the work needed to collect, analyse and work with new product requirements during the product's life. This is a constant task that any product team will have to deal with, as many stakeholders will have ideas and requests which need to be responded to.
¶ Why it is useful
Properly managing requirements means that there is a method to deal with the many voices that will give inputs to your product. We must ensure we follow the product vision and strategy and keep tactical suggestions from derailing us from the big picture. It also helps allocate resources correctly.
¶ When to use it
Requirements management will be needed throughout a product's life, as many stakeholders will constantly give inputs, feedback, and ideas.
¶ How is it done
- Tag by different sources: Putting all the requirements in the same place with corresponding tags of sources will help the product manager quickly sort out the requirements and understand the needs of different parties.
- Define priority: Always review and prioritise the requirements to ensure your team achieves the business objectives at full speed. For example, the source tags could be one of the elements to prioritise.
- Define resolution time: Resolution time for requirements are to be agreed upon with the reporters or the stakeholders in charge. On the other hand, it also must be feasible considering the production team's capacity.
- Plan product iteration: Product iterations aim to achieve each milestone and deliver the next release. These occur without disorder only when iterations are planned with practical and prioritised tasks.
¶ Do's & Don't
Do's
- Collect all requirements and take them through the due process for analysis.
- Make clear and consistent decisions on Go / No-Go criteria, and apply them equally to every incoming requirement.
- Remember your resource constraints and instead leave some buffer than over-estimating and over-promising your deliveries.
- Cluster requirements that speak to the same basic idea.
Don't
- Don’t just implement requirements because it comes from upper management. Apply the process similarly.
¶ Tools needed
- Doc Sheets
- Visure
- Ticket management software, e.g. Jira
¶ Example
¶ Useful Tips
¶ Requirement Sources
As the product goes live, more parties are familiar with it throughout its lifecycle. Besides, you are constantly making efforts to close feedback loops. There will be various sources of requirements coming in, no matter in which manner or from which channel. These include:
- From Operations
Operations may have two types of requirements: operational tools and product features.
- From Users/Customer Service
Suggestions and complaints form the essential parts of requirements that come from users, in addition to suggestions.
- From Data Analysis
Data analysis includes many aspects: Market analysis, defect report analysis, user analysis, etc. These can raise ideas that translate into requirements.
- From Management
Higher-level management may have their own opinion or business goal-specific requirements.
¶ Distinguish Wants & Needs
When facing all sources of requirements, be aware that some of them may not even be a requirement. The reason is that not everyone can design a solution for a need.
In many cases, people complain about what they have encountered and try to give a solution easily that could help the situation.
Therefore, you must ask:
Is this what he assumes he wants, or is this routed in a deep need/pain?
What is the underlying root cause? Are there other ways to access it?
To answer the questions, you must get the context of the so-called requirements, ask why they think they need this, and whether they have already tried all the existing features.
Three principles to keep in mind before you go on distinguishing wants and needs:
- All products must solve a real problem
- Problem analysis is the starting point of all products
- Solutions must be practical
Think about the questions below to find out what it is.
- What is the problem?
- What is the level of the problem?
- Is it a problem for an individual or an audience?
- Who would pay to solve this problem? How much?
- What if this problem never gets solved?
- Is this still a problem?
In reality, many people need to remember to analyse problems and are tired of doing things without thinking about why.
One should ask “Why?” before acting instead of saying, “Just do it”.
¶ Maslow's Hierarchy of Needs
From the bottom to the top of the hierarchy, there are five levels of needs:
- physiological needs (food and clothing)
- safety needs (job security)
- social needs (friendship)
- esteem needs
- self-actualisation needs
Maslow’s Motivation Model can be divided into Deficiency Needs and Growth Needs. The first four levels are usually called Deficiency Needs, while the highest is called Growth Needs.
This model can also be applied to product requirements and user needs we are trying to address. The more fundamental (down the pyramid) the needs are, the more critical they are to be met before moving up the hierarchy.
Only once the critical foundational needs are met does it make sense to invest in higher-order needs and features. They will not be appreciated if deficiencies make the user feel pessimistic about the base experience.
