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.

The need for periodic introspection of target market – Part I

As the old adages goes, change is the only constant and change is inevitable. But high-tech industry is undergoing so many changes at a rate faster than anyone can ever fathom. We are witnessing rise and decline of technology giants in a short span of a decade. Moreover the intensity of changes that we are experiencing in the last 2 decades (at least since mid 90’s) is much larger than changes that occurred in the previous 5 decades. The belief was further reinforced after I read an article titled ‘Bye Bye BlackBerry. How Long Will Apple Last?’ The article was also raising doubts on the longevity of Apple in retaining its supremacy. Coincidentally there was another article in Forbes that was speculating about the possible disappearance of Google and Facebook in 5 years.

Even though the thought that Google and Facebook will disappear and Apple will lose its supremacy is unbelievable and daunting, I decided to have an open view that anything might possible and start contemplating possible ways to arrest the decline of any technology giant. So the blog posting is to share some of my thought process on those lines. The decline of all the technology giants is directly correlated to the decline of their respective flagship product(s), so let us focus on how to arrest the decline of their flagship product(s). Rather than saying decline, I would prefer to use the term ‘Inflection point’. Let us discuss how we can ensure that the product does not hit the ‘Inflection Point’. There are several stalwarts who have done a thorough research on this topics and authored great books. Some of my favorites are ‘Innovators Dilemma’ and ‘Innovators Solution’ by Clayton M. Christensen and ‘Only Paranoid Survives’ by Andrew Groove. I am not an expert or genius to talk anything beyond what those gentlemen have already elaborated in their books, I am just trying to use some of their concepts and focus on the very basic concepts of product marketing/product management.

Every product is conceived to either solve the pain points or enrich the experience of target market. So every organization has to constantly re-invent and consistently raise the bar of innovation to ensure that their products(s) is aligned to the changing needs of our target market.

In rapidly changing high-tech industry, there is an imperative need to constantly introspect to check whether a product is still relevant to its target market vis-à-vis competition. One significant reason for any product to get into sunset mode is that the product has lost relevance in target market. With that intention, I have basically arrived at a few set of questions (presented below) to help us validate how a product is positioned to serve its target market. Candid and honest response is critical to validate relevance of the product in its target market.

1.      Is the target market still bigger enough to satisfy the growth requirements?
2.      Are the requirements / product preferences of target market still remaining same?
3.      Is competitor offering better value proposition by raising the bar of innovation?
4.      Is our product getting commoditized?
5.      Can the target market be served by any alternate product?
6.      Is the target market over served?
7.      Can the product satisfy any unmet needs of adjacent market?

I will elaborate on each of the above questions in my subsequent blog post. I will also attempt to address whether answering each of the above questions would suffice to arrest the decline of any product.

 

Attacking White Space – Identifying Growth Opportunities

This post is continuation of my previous post ‘Attacking White Spaces’. IMHO, this is the least risky among all the three options as we will be focusing more on growth in existing market. As an initial step, I would definitely suggest taking the help of analyst or research firms such as Gartner, Light Reading etc to predict the market growth of your product. For instance, Standalone DPI market is predicted to reach 2$ billion by 2015. Now the real exercise is identifying the source of demand. Firstly we have to identify whether the additional growth is concentrated in a particular geographical region or it is equally distributed. We have to later evaluate our presence in those parts of the world where there is additional growth. By presence, I am referring to the presence of BDMs, Account team, Sales team. Most importantly sales teams connect in those parts of the world are more important as they do the actual selling.

Secondly we have to indentify which market segment(s) (higher-education, service provider and enterprise) will contribute to the overall growth. We have to later evaluate whether our product(s) is positioned to capture those market segment(s). If not, we have to take a quick decision whether to foray into those segment(s). Simultaneously we also have to evaluate our capabilities and competencies to effectively tackle the challenges posed by the new market segment(s).

Finally, we have to drill down our focus to understand how the DPI requirements would take shape in future. We have to make a possible assessment of what customer might require in 2-3 years from now. Here, the inputs obtained from different organization silos are critical in this phase to precisely understand the customer pain points and how their future needs or demands might take shape. To do so, we have to firstly understand the factors that drive the need for DPI and evaluate how those factors can change. We should also think of new factors that might drive the need for DPI. Evaluating all those factors should provide us an approximation of new features/solutions that customer might require in the future. We have to later evaluate the competencies and capabilities of our engineering team to deliver those new features/solutions. We might also have to align with 3rd party vendors to deliver additional solutions. In such cases we have to evaluate the capability of the organization to derive a long standing partnership with those 3rd party vendors.

In the first two cases, we have to factor all the assumptions that were made to forecast growth and later do some due diligence to validate those assumptions. For instance, analyst would have predicted that much of the growth will be contributed by the additional demand for standalone DPI product by service providers in African region. The primary task is to identify the assumptions behind such prediction and later validate those assumptions for their existence. This can be a parallel task done by a group of people as to be wary of such predictions and not to base our product revenue forecast purely on those predictions. We also have to be aware of all the factors (both external and internal to the target customers) that can positively/negatively influence those assumptions. In Telecom sector, regulation/economic growth of the region can be a probable external factor and cash flow of the target customer can be an internal factor as the industry is subjected to huge OPEX and CAPEX.

In forthcoming weeks, i will focus on the following aspects of ‘Attacking White Spaces’:
• Capabilities to create new market – Demand generation
• Unserved vs Overserved market segments