Requirement vs Need

I have been constantly using both the terms ‘requirement’ and ‘need’ interchangeably in all my blog pots. Since i am in the process of publishing series of blog posts related to product roadmap and requirements play a vital role in it, I thought of making myself clear on my definition of a need and requirement

  • Need – Any customer business challenge or pain point or an outcome is called a need. The need could be either untold (understood by the Product Manager without explicitly mentioned by the customer) or unmet (no product has addressed it) or underserved (existing product is only addressing it partially). Need is primarily defined from the perspective of a customer. Typically MRD captures a need.

PS: I am not a big fan of MRDs and I have never prepared one

Business challenge or pain point could be used interchangeably. Existence of challenge or pain point would be the single most compelling reason for customers to buy a product that solves the pain point in most optimal and economical way while delivering best possible experience. Identifying and anticipating business challenges or pain point is critical for evolving the product. Outcome can be termed as a business solution derived to address the business challenge or pain point.

  • Requirement – The need when translated into a form understandable by the engineering team is called a requirement. The PRD would never contain a need. It would only contain requirements.

Context of requirements

Every need when translated into requirement has 3 facets

  • What is the requirement? – Focusing on outcome
  • Why customer need those changes – Focusing on customer pain points
  • How to address those changes? – Focusing on solution

While translating need into requirement and recording them in the PRD, Product Manager has to focus on the first two aspects leaving the last one to engineering team. However in addition to those 3 facets, there is another additional facet that is relevant today called context to formulate the right solution. Context highlights the exact environment in which the customer operates. Accordingly engineering team can build a solution that exactly fits customer environment. Product Manager can also use the context to pro-actively figure out any constraints. Constraints highlight the limitations of the customer environment that might hamper the solution to work properly.

For sake of illustration, let me take an example of connected car wherein the car updates the vital statistics over internet for diagnostic purpose. The purpose of pro-active diagnostics through connected car is to anticipate the failure based on set of critical parameters going off the threshold marks and also to inform probable causes of the failure. The data could be possibly used to auto rectify the defect. Otherwise send a team to address the failure without any delay.

I have drafted the requirement but what about context? User personas and user stories are probably one way of communicating the context but if personas or user stories are used, they had to be exhaustive to cover all possible scenarios. The context is a car participating in a rally traveling at an average of 100 miles/hour in remote terrain. Accordingly Product Manager can figure out the list of parameters to diagnose. Does the data is sufficient to formulate the solution, obviously NOT. So where does the problem rests, being aware of the constraints. The success of the solution hangs on reliable connectivity to continuously connect the car with base station while traveling at an average of 100 miles/hour and to relay the diagnostic data in real time. Product Manager has to anticipate whether there is sufficient infrastructure to ensure success of the solution, otherwise Product Manager need to defer the solution until either the infra is ready or alternate measures for reliable connectivity is introduced.