Discovery of needs is a continuous activity that would span across 365*24*7 and there is never an end to the process. While discovering needs, I would insist to focus on quantity and not on authenticity or veracity of the needs. I don’t mind digging my way through maze to find the most valuable needs to incorporate in the product, but I hate or rather dread to encounter competition spotting a need that was missed by the team. So I always advocate collating as many needs as possible from various entities (Engineering, Sales, BDMs, and Account Managers etc) as they could possibly perceive and understand.
In the initial section of this document, I had elaborated about need vs requirement. I would prefer to document the needs as it is in the product backlog tool. As I indicated in my definition of need vs requirement, the requirement is outlined from engineering perspective while need is outlined from customer perspective. Therefore the ideal location to translate need into requirement and record it is in PRD. The appropriate timeframe to translate the need into requirements is while drafting the PRD. The methodology to store the needs could be the prerogative of the Product Manager. There are lots of tools to store the needs. For convenience, let me assume that Product Manager uses excel.
While discovering needs and recording them in the product backlog tool is a continuous activity, Product Manager periodically gets into the below mentioned sequence of linear activities before the start of each release
- Needs triage
- Categorize needs
- Refine needs
- Draft the PRD
- Prioritize requirements
- Organize product backlog
The entire sequence of activities has to be planned in such a way that on the 1st day of the development work for next release, the Product Manager should clearly outline the list of prioritized requirements for the upcoming release. I repeatedly insist that the list should be actionable and well-articulated, so development team does not get into repeated cycles of requirement clarification. The primary purpose of development team is to either build or evolve products. Product Manager will plan his activities meticulously to let the development team focus on what they do best. The worst thing that could happen is development team hanging on Product Manager for requirements clarifications, decision making etc.
I derived the title for this section from ‘Bugs triage’. It is similar to bugs triage conducted by engineering team. Product Manager has to analyze each need and categorize the need. The entire purpose of needs triage is to identify the subset of needs that is worth prioritizing for the upcoming release.
The outcome of needs triage is to filter them under one of the possible categories
- Discarded – The needs under this category are not worth pursuing further for one of the following reasons
- Duplicate – Already tracked through another need or rather combined with another need
- Product currently has the capability to address the need – In addition to discarding the need, there is a necessity to educate the requested customer(s) how their need could be addressed using existing product capabilities
- Does not align with overall purpose of the product
- Not feasible – The need could not be addressed by the product, the decision is taken after careful evaluation with engineering team. Even before handing over the requirements to engineering in the form of PRD, there can be little informal discussions around the needs.
- Age out – The need exists in product backlog for a long time and no customer seems to be interested in it and it does not even fall under ‘Parked for future’ category, so the need ages out. Discarded automatically after existing in the backlog for a certain time period, the time frame should be defined by the Product Manager depending on the nature of the product.
- Parked for future – As the heading implies, the need is reserved for future triage
- Existence of dependent need or infra – The need could only be addressed after addressing a dependent need or providing support for dependent infrastructure.
- Ahead of its time – There would be always a reason for Steve Jobs introduce iPhone first and iPad latter. Some suggest that iPhone is introduced earlier to validate the touch behavior of the users. Irrespective of the reason, not only products but also every individual requirement has to be validated for its timing. If the timing is not right, the requirement has to be parked for later prioritization.
- To be prioritized – The needs under this category will be converted into requirements added to PRD and will prioritized for the upcoming release. The requirements under this category will undergo the prioritization process explained earlier.
Once the list of ‘To be prioritized needs’ are derived. Ensure each of the need has sufficient information to be translated into a requirement. In addition, categorize the need into i) tactical, ii) strategic or iii) disruptor. For more clarity and inputs, please refer to ‘Categorizing requirements’ section
Draft the PRD
Remember the tenets of requirements, Product Manager has to ensure that each requirement has ‘WHAT’ and ‘WHY’, most importantly ‘CONTEXT’ as well. Product Manager has to strive to make each requirement as detailed as possible and ensure that the requirements are actionable as well. Immediately after drafting all the requirements in the PRD, share the PRD with engineering team to facilitate further discussions on the each of the requirements.
Prioritize the requirements
Drafting requirements and deriving solution to address those requirements does not happen in linear fashion, while discussing the requirements with engineering based on their inputs certain requirements take even better shape. Exactly for those reasons, Product Manager has to complete the exercise of drafting the PRD at least 3-4 weeks before the start of the development and use remaining 3-4 weeks for brainstorming with engineering and rest of the stakeholders for crystalizing and refining each of the requirements. After all the requirements are refined, Product Manager has to derive the prioritized list of requirements for the upcoming release.
Entire set of needs under product backlog are classified into 3 broader categories
If I use excel for maintaining product backlog, I maintain 3 tabs for each of the above categories. Under the open category, I would classify entire needs as identified below and use color codes for differentiation. Next time Product Manager attempts to triage, (s)he need not triage all the needs, instead triage the needs color coded in RED and ORANGE
|Not Triaged Needs|
|Parked for Future Needs|
Completed category would have all the needs incorporated into the product along with the release numbering. I use this list as a reference to identify the list of needs incorporated in each release or identify the release in which a specific need was addressed.
Ongoing category would have all the needs addressed in the ongoing release. After finalizing the list of needs to be addressed in the ongoing release, I will move the contents of previous release from ongoing to completed category and update the release number in which those needs are addressed. Later move the prioritized list of needs in the ongoing release from open category to ongoing category.