Managing product requirement backlog

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.

Record needs

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

  1. Needs triage
  2. Categorize needs
  3. Refine needs
  4. Draft the PRD
  5. Prioritize requirements
  6. 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.

Product requirement backlog

Needs triage

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.

Categorize needs

The outcome of needs triage is to filter them under one of the possible categories

  1. 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.
  1. 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.
  1. 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.

Refine needs

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.

Organize backlog

Entire set of needs under product backlog are classified into 3 broader categories

  • Open
  • Completed
  • Ongoing

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

Triaged Needs
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.

Categorizing requirements backlog

Building new product – My experience (Part II – Drafting requirements)

This blog is a 2nd part in a series of blog post on ‘New product development – My experiences’. The focus of this blog is purely on new product requirements

Requirements gathering – PRD

Once new product development is approved, next plan is to draft the detailed product requirements in the form of PRD. PRD should start with justification for new product – So borrow details from business case 🙂

  • Why customers need new product(s)?
  • How does the customer requirements will evolve in future?
    • Very critical to laying a foundation for flexible product architecture or platform
  • What are the key value propositions valued most by customer?
  • What are targeted vectors of differentiation?

The above responses would help Product Manager to outline broader requirements for new product architecture. IMO, Product Managers should be aware of the product architecture and in any new product development should play a key role in finalizing the architecture. While architect team would design the architecture, Product Managers should act as a guiding force in deriving the architecture.

Elaborate ‘Defining attributes’ of the new product

PM has to elaborate in PRD about the defining attributes mentioned during business review. The defining attributes of the product should act as guiding principle for the engineering team and other stake holders involved in the product development. PRD will focus on 2 primary aspects

  1. ‘What’ are the features that constitute new products
  2. ‘Why’ those features are required – The actual purpose and how customer might use those features

Engineering will later focus on ‘How’ to develop those features. While developing the features, defining attributes (such as simplicity, ease of use, reliability or higher performance) would determine how those features are built. For the same reasons, it is critical to determine the defining attributes of the product and list them in the early sections of the PRD before formulating the feature requirements. Defining attributes would also determine the choice of components procured from vendors, so it is vital that every stake holder involved in the development of the products shares a common understanding of the defining attributes.

Drafting requirements and framing MVP list

Next level is to go deeper into specific capabilities of the product. At least in my scenario, the focus is on the extension of existing product line. So I have put my attention on 4 important things

  • Do any of the existing functionalities have to be eliminated?
  • Is there a need to bring-in any new functionality or new technology to align with customer value proposition and differentiation?
  • Do any of the existing functionalities have to be altered to increase the scope or make it better usable?
  • Synergies between old and new products

Add granular feature requirements in PRD and list the priorities for each of those features as it helps in decision making while determining the trade-off between release timelines and product features. We do always have conflicting priorities such as early TTM of product packed with lots of features. So here comes the topic of minimum viable product that could still fetch revenues forecasted in RoI calculations while targeting early TTM. All features that constitute minimum viable product should be tagged appropriately in the PRD.

Deriving synergies between old and new products

It is also imperative to list down the synergies between old and new products. If the new product is an extension of the existing product line and even though it might be built on a totally new platform, Product Managers should outline if there needs to be any synergies between old and new products. Essentially, the majority of the target customers for new product would be the existing customers of older products and it is imperative to take their inputs/requirements/needs into consideration. All the existing customers invariably will look for easy migration from existing devices to newer devices keeping the switching costs really low. Moreover none of the customers would be willing to invest heavily in learning the new product, so the learning curve should be minimal. Product Manager has to capture those requirements in the PRD and later during product planning phase development team would outline how the synergies could be derived.

Finally, ‘Whole product approach’

The last section of the PRD would talk about ‘Whole product approach’. Whole product approach focuses on elements (both tangible and intangible) enabling the core products sell better. PRD should list high level plans for the following

  • Technical support
  • Partner training
  • Product documentation
  • Compliance requirements
  • Sales or distribution channel support

In addition GTM plans (collaterals, PR, launch plans) would also be listed in the PRD. Ironically, ‘Whole Product Approach’ is given least importance in comparison with the actual product. As part of the ‘Whole Product Approach’ we might also have to consider ‘Product Ecosystem’. ‘Product Ecosystem’, according to me is a culmination of multiple players contributing jointly to the success of the ecosystem and the conduciveness of the ecosystem is essential to success of all the players of the ecosystem. However the value rendered by each of the players to the ecosystem will not be identical.

From the perspective of ecosystem, products would be broadly classified under 2 categories

  1. Products that drive the ecosystem – Products that are at the center of the ecosystem and it is instrumental in creating the entire ecosystem

For instance Smartphone OS (iOS, Android) that created an entire eco-system of apps

  1. Products that thrive on the ecosystem – Products that are at the periphery of the ecosystem and significantly contributes to the strengthening of the ecosystem

Even though apps thrive on the ecosystem, their existence strengthens the ecosystem
Both are complementary, existence of apps is critical to success of the apps ecosystem and stronger app ecosystem contributes to the success of apps

If the new product belongs to category (i), then PRD should outline the initiatives to create such an ecosystem. In case of product belonging to category (ii), we need to outline the dependency in the PRD, outline the plan to monitor the evolution of the ecosystem under ‘Monitor Plan’ and outline the risks associated in the ‘Product Planning Phase’. Both ‘Monitor Plan’ and ‘Product Planning Phase’ are elaborated in subsequent blog posts.

Importance of PRD

For me, PRD is a BIBLE to product development and it should act as one stop reference guide for engineers to build the new product. The requirements in the PRD should be exhaustive, but the focus should be only on ‘What’ and ‘Why’ as stated earlier. I will drop a scenario

  1. What – Smartphone requires front camera
  2. Why – For selfie, video calls etc

Probably PRD would not define the specifications for the camera, however ‘What’ and ‘Why’ would set the scope of the feature and it should tickle creative minds of the engineers to formulate the ‘How’. Doing so, the product developed would be aligned to meet the exact purpose. Just like movie scripts enables the actors to visualize the movie, PRD should provide such visualization of the new product.

I recently came across this article (http://www.actuationconsulting.com/actionable-product-teams-requirements/) and was appalled to find that only ~15% of the Product Managers provide right level of details and actionable requirement. Providing right level of details for all the product requirements is one of the single most important responsibility of PM, unless the requirements are actionable and unambiguous, the final product might not be the same as the product envisioned during business review.

PMs should truly demonstrate technical leadership

While drafting PRD, discussing requirements, finalizing product architecture or formulating platform strategy, PM has to demonstrate superior technical leadership, great depth of market/competitive knowledge to quickly gain the trust of the development team. Otherwise it is tough to reach consensus on the vision of the new product and the development team might not believe in the vision of the Product Manager and the product. Even though it is a cliché, I have to re-iterate that PM has no real authority or power. So mutual respect, trust and admiration is the key to influence other stake holders and sell the vision of the new product. Mutual respect, trust and admiration are not formed by our position or authority but by our actions, thoughts and deeds. It might take some time to forge such relationship but once built it will only fuel more product success stories.

Final Word:  Every single feature of the product should have the requirements originated from the PRD and it should have the approval of PM. I am not trying to ascertain the authority of the Product Manager, I am only insisting that Product Manager alone would have absolute clarity on what set of features would facilitate new product to make $$$.