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


Appreciate your thoughts or opinions

This site uses Akismet to reduce spam. Learn how your comment data is processed.