Is MVP a trap or are we abusing it too much?

Any development methodology has its own fallacies unless we appropriately use them. With MVP too, we have to be cautious not to fall into a trap of probably relying on it too much (or rather should I say abusing it). MVP (Minimum Viable Product) formulated by Eric Ries is an excellent way to build a product through an incremental process of build, measure and learn. Nevertheless, it does not entitle Product Managers to learn and validate every aspect of product requirements through MVP alone. When it gets difficult for a Product Manager to discover and comprehend customer requirements, the easy way is to put emphasis on MVP. If we start validating every requirement of a product, it will unnecessarily delay product development. There is always a necessity to strike a balance which I find missing. Further, in the case of enterprise products that have a direct effect on customer’s business, the customers will not be ready to validate every incremental version of the new product thoroughly. While building complex products for enterprise customers, it is always crucial for Product Managers to do extensive customer research for obtaining deeper customer insights and balance those findings with MVP without completely hiding under the veil of MVP and Agile.


Trap 1 (MVP is not one-size-fits-all): The efficacy of any development methodology (Agile or MVP) lay in realizing the true purpose of those development methodologies. Not knowing when to use those methodologies and how to use those methodologies will lead to utter chaos and inefficiency. Eric Reis devised MVP as a methodology because of uncertainty in markets, customer behaviors and their expectations leading to product failures. Because of uncertainty, Product Managers fail to build new products for right needs and for right customers. For eliminating uncertainties through validated learning, Product Manager could leverage MVP for incrementally building the new product in a cycle of build, measure and learn with a primary motivation to validate whether the new product is addressing the right needs, for right customers and as desired by those right customers. However, not every new product caters to uncertain markets. Certain products are conceived for predictable markets with predictable needs incorporating already a proven technology.

In a scenario where competitors are crawling everywhere and there are analysts to provide any information about the need addressed by the new product or about the market targeted by the new product, Product Manager should leverage those details to build better insights about customers and market. What makes certain insights more meaningful is the ability of Product Manager for always reading between the lines to understand what had worked and what had not worked. Product Manager would later augment those insights to define the necessity for MVP and identify what unknowns will be resolved through MVP. MVP cannot be an excuse for lack of insights about customers and markets, MVP should only complement already existing information to obtain better insights. Now, this leads to the second trap, how much to validate and learn?


Trap 2 (Validating too much for too long)
Validating too many hypotheses will unnecessarily delay the development cycles risking the possibility of any competitor with better knowledge of customers and market go past the new product. For every hypothesis, Product Manager should ponder whether it is essential to validate the hypothesis directly with customers or is it possible to validate it based on customer insights. Product Manager by virtue of interfacing with customers, being part of the industry for a longer period should have developed some insights about customers, markets, and technology. Such insights should be useful for conceiving the product. I am in favor of lean practices but not in favor validating every element of the new product with customers. The right balance is required to validate the most critical elements of the new product while maximizing validated learning and minimizing efforts. However, Product Managers often do the contrary.


Trap 3 (Maximum efforts, minimal learning): After optimizing the number of hypotheses to validate, Product Manager has to identify the most optimal ways to validate them. Building a minimal version of the new product might not always be the best answers for validating learning. Dropbox founders validated their idea by building a video because building a minimal product consumes time and any change in the expected behavior of customers requires Dropbox team to alter the product architecture making it costlier and time-consuming. Ideally, Product Manager should follow lean practices even for picking the number of hypotheses to validate, how to validate those hypotheses and how long to validate those hypotheses. Time should be a major consideration while adapting MVP methodology. In the words of Eric Reis

A minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

True to those words, MVP is about achieving maximum learning with most optimal efforts.


Trap 4 (Delivering with little value): Another trap is the risk of alienating customers especially when the new product addresses a need already addressed by competing products. In such scenarios, minimal version of the product that delivers the same value as existing products already in the market might not excite customers and Product Manager risks alienating customers even though there are explicit disclaimers that the product is a minimal version. MVP sometimes should provide a hint of what is in store for customers and it should excite customers just as a movie trailer captures the attention of its audience providing a sneak preview of the entire movie.

If the new product is another LinkedIn, Gmail or Salesforce, what could be the MVP version of the new product that might excite prospective customers? New Product, which might be a replica of an existing product, should deliver new value or deliver same value as the existing product in a unique way. Otherwise, the commercial success of the new product is questionable. Therefore, as part of MVP, Product Manager should validate the unique value delivered by the new product to verify whether it is a real differentiator. Doing so, MVP will provide a preview of the product differentiators that could excite early adapters. MVP while helping Product Manager validate the efficacy of the product in addressing a need uniquely should also excite prospective early adopters to buy the product.


Trap 5 (Not choosing right customers): Another crucial element for MVP is to choose the right set of customers. Always target customers who would be could be potential early adopters. In addition, the chosen set of customers should share the same passion for the new product as the Product Manager does. Few section of customers get excited about breakthrough products embracing new technology, few other customers want to be delighted with minimal intervention. The later set of customers hate when new the product uses their business environment as a trial ground.

MVP is a double-edged sword. While customers help Product Manager perform validated learning to pivot or preserve product development, customers will also throw feedback for further evolving the product. Product Manager is obliged to honor such requests after validating the fit with the overall strategy of the product. Therefore, it augurs well to focus on a specific target segment that are potential adopters of the new product ensuring that their needs are addressed and the product is out on the market as quickly as possible. Doing so, Product Manager can also avoid the problem of diverse feedback from MVP customers. In a B2B segment, I always prefer picking customers who can generate revenue in first two quarters of releasing the product. A certain section of customers do not generate immediate revenue but provides sufficient infrastructure to validate the product (early innovators).

Not every customer is very vocal about sharing feedback. The right way to perform validating learning is to observe customers using the new product. Never really rely on what customers actually say, what they often say is not what they actually intend. For true validated learning, rely on customer behaviors, body language, and usage patterns. There is a cultural aspect to feedback sharing, not every culture embrace the quality of calling spade a spade. Therefore, I loathe feedback forms, user group interviews etc.


We often follow a herd mentality and blindly adopt the widely used development methodologies. Instead, we should understand the true purpose of any methodologies and adapt it for the value they deliver and not for its popularity or for its wider acceptance among the fraternity. I appreciate your thoughts or rather contrary views on MVP traps specifically for enterprise products.

The focus of this blog is to specifically highlight the MVP challenges for enterprise products. In my previous blog post – Moving target of customers’ needs – A unendorsed challenge of building enterprise products, I have explicitly highlighted the challenges of MVP in building enterprise products. 


Should Product Manager prioritize defects?

I have seen many debates on Quora and other related forums regarding how Product Managers should prioritize defects against product requirements. Now my belief is that both are different and I am a firm believer in ‘Engineering owns quality’. Even though quality precedes everything, Product Manager does not pitch defects against product requirements. No product is defect free and every requirement added to the product begets more defects. Product Manager would collaborate with engineering team to determine the tolerance level for the overall open defects or defects open rate. Accordingly, allocate a window in each release for resolving defects avoiding any conflict with product requirements. Ultimately, it is the responsibility of engineering team to prioritize and resolve defects within that window. Engineering team should have complete authority over prioritization of defects and resolve them within the guidelines of quality SLAs (Service Level Agreements) even it is a severity defect affecting customers’ business. Product Manager will be encroaching into their space, if (s)he starts prioritizing defects.

I would definitely loathe if my engineering team is busy fixing defects at the cost of evolving the product. As I had said earlier, both engineering team and Product Manager should agree on the tolerance level for defects, if occasionally the defect rate goes higher because of certain unforeseen reasons, I would urge Product Manager to make more room for resolving defects probably at the expense of not addressing few requirements. However, if it happens too often, then the problem is addressed by identifying the actual root cause. What is causing more defects and what is causing the decline in quality should be ascertained to improve quality in a long run instead of continuing fixing defects at the expense of evolving the product. It is as important to continuously evolve the product as it is to maintain the quality of the product. There cannot be any trade-off between them.

Moving target of customers’ needs – A unendorsed challenge of building enterprise products

The primary emphasis on building a great product is to discover a right problem and getting married to it. However, customers’ needs and problems are increasingly becoming moving targets. The needs and problems evolve, so do the solutions to address them (i.e. the outcome too evolves) triggering an uncertainty of which needs or problems to address and what outcomes to deliver. It is a challenge that has primarily gone unendorsed or not consciously realized until now. The biggest mistake that Product Managers commit while building new product is to freeze needs and problems at a specific point in time and start building products for those static needs. Nevertheless, Enterprise products address hard problems and building such products consume around 12 – 24 months. With technology evolving much faster than ever, market dynamics changing too fast, and human race undergoing more changes than before, new needs or problems emerge, prevalent needs or problems extinct, and solutions embracing technology advancements to address needs or problems come in various shapes and forms. Primarily, Product Manager cannot taste success building a product for static needs. Product Manager should learn to hit a moving target anticipating how needs or problems change as a function of time in future. Agile methodologies and MVP (Minimum Viable Product) address those fallacies by reducing development cycles and incrementally validating whether the product is addressing right needs or right problems and delivering right outcomes. However, MVP seldom works for enterprise products.


Why MVP and agile methodologies could not address those problems of dynamic needs?

Enterprise products affect real businesses of customers, they might either help customers increase revenues, manage costs or streamline operations. The fundamental truth is enterprise products affect business in some form and hence they should be robust and resilient with zero-tolerance for failures while addressing a real business problem that is at the top of customers’ priority list. Therefore, delivering something quick, validating it and incrementally evolving the product does not augur well for enterprise products. Enterprise customers seek a complete solution. There is also a necessity for shrouding development efforts of certain enterprise products in secrecy to introduce an element of surprise and euphoria during launch. Then, how do Product Managers validate enterprise products causing minimal interruption to its targeted customers? Through maintaining a subtle balance between using MVP and relying on customer insights and experiments. Product Manager shall use MVP at the initial stages of product development to validate whether there is a real problem, whether the new product is addressing the real problem, and whether the new product is targeting the right customer segment. The problem with that approach is MVP does not consider time as one of its parameters. While constructing a hypothesis and validating assumptions using MVP, Product Manager has to validate assumptions across time space ensuring whether needs or problems persist across the duration of the product lifecycle and identify how they evolve. The appropriate approach is to understand the causal effect between needs, problems and corresponding factors that cause them. MVP framework for such analysis is:


The fundamental premise is to understand what is causing the need while validating the existence of a real problem or need and bundle the findings with customer insights to understand how the need or problem manifests in future. Understanding causal-effect of the need and its corresponding triggers along with customer insights should provide required clarity about the relevance of the need or how the need evolves in future. Customer insights are essential to comprehend what has caused the present to diverge from the past and use that as a reference to anticipate what will cause future to diverge from the present. Building customer insights are one of the key foundational pieces for building great products that enterprise customers want. Product Manager has to build customer insights through experiments and observing customers in their natural habitat, immersing in their business, assimilating their business process, problems and challenges and not just listen to what they say but to read between the lines to understand what they did not say. There is a dire need for restoring the lost art of gathering customer insights. MVP bundled with customer insights and experiments are required for validating any assumptions related to the new product and building a visual map of how customers’ needs or problems evolve and what new outcomes they might desire. Product Manager should learn to hit a moving target anticipating how needs or problems change as a function of time in future. How do you hit a moving target with an arrow, we notice the rate at which the target is moving, how long does it take for an arrow to hit the target and accordingly predict the possible position of the target when the arrow is released. Product Manager should do something similar not just to understand needs and problems of today but also to predict the needs and problems while the new product hits the market. Doing so, the new product will hit the bull’s eye when it hits the market.

Why does moving targets of needs and problems affect enterprise segment alone?

A unique challenge that Product Managers encounter with enterprise products alone and it is not applicable for consumer products is that enterprise customers’ are resistant to frequent product upgrades because of CAPEX (Capital Expense) and OPEX (Operating Expense), they tend to use a product for a longer period of 3-5 years (especially on premise products). On the contrary, business models of most consumer products rely on frequent product upgrades. There is no benefit in stacking all the value in a single product and making customers stick to a consumer product for 3-5 years. The duration for moving target of needs or problems of enterprise customers just shifts from product launch to eclipse the entire duration of product life cycle.


Product Manager should anticipate customers’ needs or problems as a function of time across the entire duration of product life cycle. Customer insights combined with extensive knowledge of how markets evolve, how technologies evolve, and how customers’ behaviors change should provide an estimation of how customers’ needs or problems change as a function of time and what new outcomes are possible. For certain enterprise products, addressing customers’ needs or problems as they evolve is not entirely possible without building a product architecture or a platform that can scale. I was once managing an HW product used by ISPs (Internet Service Providers) for defining policies of their internet users. During the launch of the product, internet speeds offered to each user was low. However, the internet speeds offered to each user raised exponentially far exceeding our predictions and the product could not meet the new requirement resulting in the early retirement of the product (or rather the product has to retire prematurely). In the enterprise segment, we tend to face a similar problem with complex SW products as well and refactoring the architecture can help but it will be costlier. Even so, refactoring the entire HW or product architecture takes time and there is a risk of not being able to address evolving needs or problems in a timely manner. When the only thing that is certain about future is uncertainty, a question that stares at every Product Manager is how to anticipate what needs will prevail and what new needs will emerge. In most cases, needs will be static, but the scale required varies. Another question that stares at every Product Manager is how much to scale and when?


Please keep watching this space as I revert back to further to continue the conversation on this topic. Meanwhile, I would like to understand whether you agree with above challenges. If so, please share your thoughts in the comments section below or drop me a note at If we are not reaching an agreement on this topic than any further conversations will be futile, looking forward to hearing your thoughts or opinions.

Pragmatic Guide for GREAT Product Roadmapping

I consolidate all my recent blog articles related to preparation of product roadmap into a PDF document and uploaded it to Slideshare. Please take a look and let me know your feedback.

The eBook could be directly downloaded by SlideShare

How to avoid customers from hijacking the product roadmap

I have talked about prioritizing requirements to list them in chronological order in product roadmap. Product Manager diligently prepares the product roadmap to reflect the product growth strategy. Nevertheless nothing works as per the plan. First roadblock that every PM face is some unexpected product requirement requests from their customers and that product requirement will be total deviation from the items planned in the roadmap.

I bet every Product Manager would face this situation on every day basis. So how do Product Managers stop their customers from hijacking the product roadmap? Before Product Manager definitely puts his/her foot down and say NO irrespective of revenue contributing potential of the customer, I shall suggest Product Manager to follow the following steps (aka decision tree) to mitigate the situation in a way that it is win-win for both Customer and Product Manager.

The entire exercise might not be required if the business model is to entertain customizations or handle specific customer requirements for additional $$$.

Step 1: Understand the requirement – WHY?

It does not suffice if Product Manager just knows what the requirement is. (S)He needs to have a broader understanding of why customer has asked for the requirement. Unless Product Manager gets a grasp of the underlying reason or cause behind the product requirement, (s)he will not be able to make informed decisions in the subsequent steps.

Also please take a look at my blog on ‘Understanding customer requirements’.

Step 2: Validate the requirement

Is the requirement valid? In certain cases (mostly in B2B environment) because of lack of product awareness or technology, customer raises product requirement that is either invalid or not feasible within the scope of the product. If the requirement is invalid we should definitely make attempts to immediately communicate the information back to the customer with appropriate reasoning.

Step 3: Understand the business criticality

Understand the potential business impact to the customer because of not fulfilling the product requirement. Is the requirement has any potential revenue impact or is it just to enhance the usability of the product or is it just nice to have a feature. In case of revenue impact, the stakes for delivering the product requirement goes HIGHER.

Step 4: Identify alternate (optimal) mechanisms to accomplish the requirement using existing infra of the product

In the initial step, I suggested to look for the actual reasons behind the requirements ie Product Manager needs to understand the WHY part of the requirement in addition to WHAT part of the requirement. Having known the WHY part, Product Manager needs to figure out whether there is any alternate optimal mechanisms to address the WHY using existing product infra. If yes, communicate the alternate mechanisms to the customer provided Product Manager gets convinced that the alternate mechanism is actually the optimal way of addressing WHY.

In case of no alternate mechanism to address the requirement, let us proceed with next steps.

Step 5: Is the requirement generic or customized

Is product requirement custom or generic? Understand whether the requirement is customized to the requested customer or it can be generalized for broader segment of customers. In case of generic, Product Manager could not have discovered the need and it is good that some customer had brought this to his/her attention. Product Manager now adds the requirement to the requirements backlog, the timeline to deliver could be figured out depending on the business criticality and requirements prioritization process. In fact, I have talked in detail about how to prioritize requirements in in my earlier blog. If the delivery timeline conflicts with the expectations of the customer, then Product Manager has to negotiate – move to step 7.

Step 6: Understand other additional requirements of customer

We have reached this step because the product requirement is customized. In case of customized product requirement, please do not look at the requirement in isolation. Take a look at other requirements from that customer, also take a look at the requirements available in the roadmap and figure out how many of them would be applicable to the requested customer.

Step 7: Negotiate

Identify possibilities to trade the customer requirement with any of the generic requirement(s) already available in the product roadmap. Even if the customer requirement is critical, as long as Product Manager is able to compensate with other requirements that matter most to the customer, it would definitely be a WIN-WIN situation. If someone insists there is nothing to compensate and there is no product requirement in the roadmap that would suit the customer, then I could only think 2 possibilities (i) our understanding of the customer is flawed (ii) customer does not actually belong to the target customer. Please note that it is worthy to forego a sale rather than selling to a wrong customer, this topic definitely needs more attention.

Final Thoughts

Earning the trust and credibility of the customer is mandatory to engage in a meaningful conversation and to communicate the NO for any product requirement request in a convincing manner.

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

Prioritizing product requirements in alignment with product objectives

In all my earlier blogs, I was focusing on discovering and anticipating needs and who can help Product Manager discover those needs. After Product Manager collate all possible needs and start drafting requirements, there will not be dearth of product requirements but the next challenge is to prioritize those requirements. Product roadmap is a reflection of the product strategy and rightly so, product strategy should provide guidelines on what requirements to prioritize and it should also provide justification on why those requirements have to be prioritized.

Identifying Product objectives (aka Goals)

Product vision is the foundation for any product. Product vision encompasses everything related to the product – who are the customers, what does the product do, what is the competitive edge of the product, what is the unfair advantage that product has over competitors and finally what are the product objectives (how does the product help accomplish organizational goals). Rightly so, product vision provides guidance for every decision making related to the product – How sales should sell the product, how engineers should build the product, how marketing should promote the product and how Product Manager should draft the product strategy. Product strategy outlines the path to accomplishing product objectives abiding by guidelines laid by product vision. Let me revisit the product vision again and dissect it. At a high level, product vision embodies the following:

  • What needs to address?
  • Which customer segments to target?
  • What is the USP of the product? How effectively does the product will address the needs?
  • How the value is captured?

A little deeper look will reveal that product vision has 2 broad categories

  1. Product purpose
  2. Product objectives

Product Vision

Product Purpose (Customer Centric) Product Objectives (Organization Centric)
·        What needs to address?·        Which customer segments to target?

·        What is the USP of the product? How effectively does the product will address the needs?

·        How the value is captured?-   Increase in profits

–   Expansion into new markets

–   Opportunity to cross sell other products etc


Product purpose and Product objectives do change as the customer needs evolve, organization growth objectives change and product traverses through various stages of the product life cycle (launch, maturity and decline). Understand from your CEO or VP Product Management, how the product should contribute to overall organizational goals, accordingly Product Manager has to formulate product objectives. Product Manager would later perform thorough analysis of customer, market, competition and technology to understand what kind of augmented needs are valued most by customers and how effectively do those needs has to be addressed to achieve product objectives. In short, product prioritization process is all about identifying the set of requirements that fits within the framework of product purpose and yet has the potential to collectively accomplish product objectives.

Identifying attributes

When Product Manager starts prioritizing requirements, there should be an effective mechanism to understand how each requirement contributes to both product purpose and objectives. So we identify attributes (related to both purpose and objectives) that can help measure how each requirement is contributing to the overall product vision.

Attributes of product purpose

Product addresses lots of needs, but there should be some primary needs that focus on the key pain points of the customers. I call them as core services and rest of them are allied services. List some of the core services as attributes. For the sake of discussions, let me assume a fictitious B2B IoT product targeted for retail stores that help in following

  • Insight – Provides insights on how customers are accessing the store
  • Generate revenue – Notifies customers through smartphone about the availability of goods that might interest them based on the behavioral pattern
  • Cut costs – Eliminates the need for sales person by flashing all information about goods on his/her smartphone
  • Operations – Aid in ordering of goods that are brought together (replicate Amazon model)
  • USP – Does the requirement contribute to enhancing the USP? In case of the fictitious product, the USP could be as simple as ‘easy to use’, ‘easy to maintain’, ‘compatible with all mobile devices’, ‘mobile payment to avoid long queues’ etc

Pick relevant attributes that represent the augmented needs and assign weights in accordance with how customers value them. Efficacy of product prioritization process lay in effectively picking the attributes that are valued most by the target customers. Existences of those attributes in the product should provide compelling reasons for target customers to buy the product.

Attributes of product objectives

Product manager identifies similar attributes for product objectives as well.

  • Revenue – Does the requirement directly contribute to increase in revenue
  • Customer – Does the requirement is applicable to all possible target segments or to only a section of target segment. It is an essential attribute if the focus is on expanding market
  • Competition – Does the requirement provides competitive edge or merely puts the product on par with competition
  • Cross sell – Does the requirement facilitate sale of other products
  • Stickiness – Does the requirement increase the switch over costs or create a stickiness factor facilitating recurring revenues

I have dropped down all possible attributes that I could imagine. I suppose it would be ideal to stick with utmost 3 attributes in purpose and utmost 2 attributes in objectives, otherwise the weights would be thinly scattered and it might be difficult to effectively prioritize the requirements.

Scorecard technique – Brainstorming

Every product would have a distributed team of Product Managers, each managing different components of a product or separate target markets or combination of both. The process of adding weights combined with brainstorming exercise would ensure that the respective Product Managers have done due diligence in evaluating each of their requirements, so relative prioritization could be done lot better.

There is no better option than brainstorming to discuss, debate, and argue on the ability of each of the requirement to contribute to product objectives. Brainstorming session when done effectively provide revelations that was not comprehended before by the Product Manager or rather by any other participant. How many times have we felt ‘Oh GOD, I never thought about it’! Brainstorming would help to identify such facets never thought earlier when done effectively. Efficacy of brainstorming sessions lies in the following

  • Each participant should challenge and be willing to be challenged.
  • Each participant should build upon the thoughts of other to add better clarity to ‘WHAT’ and ‘WHY’ of each requirement.
  • There should be a commonality of purpose, vision and direction among all the participants
  • Each participant should engage in dialogue. In dialogue participants aim for collective good and not for win of any specific participant
  • The session should be skillfully facilitated by one of the Product Manager

Much of what I had described above was borrowed from a book called ‘The Fifth Discipline’ by Peter M Senge, the book offers lots of tips for effective and efficient brainstorming session.

The process might be chaotic, exhausting and mostly Product Manager might feel tired about justifying each need. Yet such process adds pluralism ensuring healthy discussions and debates among divergent minds leaving no room for human errors in prioritizing requirements. The exercise is also an attempt to prove everyone that product requirements prioritization exercise is driven by a process backed with data and does not happen as per whims and fancies of the Product Manager.

It is also on opportunity to introduce BIG PICTURE to the engineering team:

  • What are the lists of product requirements?
  • Which segment of customers need those product requirements?
  • Why do the customers need each of those product requirements? What specific business challenges or pain points would be addressed by each of those product requirements?

I often insist that engineering should inculcate system thinking to have a holistic view of how each component in the product inter-operate to deliver value to customers. Engineering should be aware of the customers using the product and what are the essential needs for which the product is used. Unless engineering imbibe those details, I could only foresee lots of friction between what they should develop and what they develop. Including them early in the prioritization process is one way to reduce the friction even though I insist that during on boarding process of every engineer into the product team, (s)he has to undergo detailed training on (i) what is the product, (iii) who uses the product, (ii) why the customers are using the product, in addition to the regular agenda of (iii) how the product is built.

Involving engineering early in the process helps them obtain the bigger picture to avoid any ambiguity during development, estimate efforts required to address the requirements and most importantly Product Manager tries to instill a sense ownership highlighting that their comments are valuable to evolve the product. Making engineering realize that delivering right product is the priority and not delivering product right. Constantly attribute success of the product to their efforts and make them realize that they are entitled to demand more details from their Product Manager on why certain features are prioritized and for whom as much as Product Manager has every right to ruthlessly demand more from engineering team.

End of the brainstorming session, scorecard would be completed with appropriate weights for each of the requirements for all possible attributes. Further every stakeholder would be on the same page with regard to prioritization process. Remember, I was talking about inclusive approach to product requirements prioritization process under discovering needs section so every stakeholder would feel they are valued and they have better clarity on how requirements are prioritized. Guess there is no better technique than brainstorming to achieve an inclusive approach.

Why I don’t use scorecard methodology?

Wonderful… we got a scorecard that can let Product Manager pick the ‘top X’ requirements. But wait, did I ever say I will be using scorecard methodology to prioritize features. With all due respect, scorecard is an excellent methodology that helps Product Manager to ponder and diligently assess how each product requirement can help achieve product objectives. Yet, I do not rely blindly on scorecard methodology or any methodology. I merely use them as reference to understand the relative importance of each requirement under a specific category to make effective prioritization decisions. Let me assume for a moment that the primary product objective is to generate more revenues, so obviously revenue attribute would carry relatively higher weights along with other attributes corresponding to the product needs that are valued most by customers and can either directly or indirectly contribute to increase in revenues. If we apply scorecard, undeniably all the features that contribute to increase in revenue will be prioritized and Product Manager would have done a fantastic job.

Nevertheless did I not discuss in length about being market focus – delivering requirements that might excite customers, generate demand, attack growth. I also discussed about imbibing new technology to stay ahead of the curve and ensure the competitiveness of the product. Focusing on them (WoW requirements, new technology) will fetch revenue in long run in addition to allowing the product elude strategic inflection point. Customers will be glad to have those value adders but they would never ask for them explicitly. Scorecard methodology will not be able to strike a balance between short term and long term requirements.

For those exact reasons, I have earlier attempted to categorize the requirements as i) tactical, ii) strategic and iii) disruptor. In addition to avoid prioritization conflicts between requirements in each of those categories, I strongly advocated the need to allocate a portion of product roadmap for strategic and disruptor. In spite of all the categorization, I am still not convinced with using scorecard technique for prioritization of requirements within each category. Prioritization is more of an art than science, so employing pure scientific methodology might be disastrous. Even though I use scorecard techniques to ensure that I have done my due diligence in understanding how each requirement contributes to both product purpose and objectives, I firmly believe that common sense prevails over scorecard methodology.

In addition, prioritization of strategic and disruptor features is done after evaluating the degree of uncertainty and amount of efforts required to build product increment to eliminate uncertainty. Attributes and weights do not work in this situation. Little gut feeling and thorough analysis of the amount of efforts required to eliminate uncertainty, extent of risk and amount of efforts required to deliver product increments (apply lean techniques) plays a vital role in selecting requirements under strategic and disruptor category.

How to prioritize smaller features

I call them as low hanging requirement that will deliver reasonable value to customers and does not take too much effort to deliver them. Those requirements are not deal breakers but definitely good to have. When the small features are pitted against bigger ones, they would never find space in the roadmap. In OS, I could recollect the concepts of starvation wherein OS would employ aging technique to avoid any low priority process from resource starvation. I would be glad to employ such aging techniques; nevertheless I am not heading in that direction. Product Manager has to negotiate with engineering team to prioritize such features without impacting the original set. The efforts are little less in delivering those features and the risk to overall development would be minimal, engineering team can deliver those features by optimizing their development and test cycles.

Roles, responsibilities, authority, hierarchy etc nothing would help Product Manager to have his way as much as personal relationship does. The relationship between engineering team and Product Manager should be symbiotic in nature. Product Manager has to offer something before asking for favors. Among many other things that Product Manager can do to let engineering focus on what they do best in most optimal way is to

  • Add lot more clarity to the requirements (ensure it is actionable)
  • Freeze the requirements and clarify on all the open items before start of the development
  • Do not let engineering team wait on Product Manager for prioritization decisions.
  • Remove any obstacles or deviations that is clogging the development or test activities

I always believe in the principle ‘Do it right the 1st time’. The above activities of Product Manager would definitely aid engineering team to head in that direction and facilitate them to do ‘Deliver more (features) with less (resources)’.

Prioritizing defects vs requirements

I have seen some debate on how to prioritize defects against product requirements. Now my belief is that both are different and quality precedes everything. Yet Product Manager does not pit defects against product requirements. No product is defect free and every requirement added to the product begets defects. Product Manager would collaborate with engineering team to determine the tolerance level for the overall open defects or defects open rate and accordingly allocate a window open in each release for resolving defects avoiding any conflict with product requirements. Ultimately it is the responsibility of engineering team to prioritize and resolve defects within that window. I firmly believe that engineering team owns ‘Product Quality’ and they should have complete authority to mark the severity of the defects and resolve them within the guidelines of quality SLA. Product manager will be encroaching into the engineering space, if (s)he starts prioritizing the defects.

Collaborative discovery of customer needs – Who can participate?

As a Product Manager, one of the constant fears that I have is: Competition identifying a need before I or my peers do – Honestly, I don’t feel bad about it. Such situation can only testify that the discovery process is not rock solid and there are gaps. It gives one more reason for Product Managers to believe that they should think beyond themselves to expand their sources that can help them discover needs. Product Managers are always outnumbered in an organization by Engineering, Sales, Account Manager, BDMs etc. One best piece of advice that I received from my manager is that stacking more Product Managers is not feasible and it is not the right solution too. Instead Product Manager has to scale with existing stake holders to perform his/ her activities.

Impact: Collaborate effectively with all the stake holders to discover needs

[PS: Please read my earlier blog post on the need to discover customer needs]

Product Manager is not a lone entity while (s)he is exclusively responsible for discovering needs, corroborating needs and sometimes synthesizing inputs from various disparate sources to formulate a need. It might sound cliché, the fact is Product Manager does not have authority to demand that every stake holder has to discover need and Product Manager cannot set goals for discovery of needs. What I have mostly seen is that when Product Manager walks that extra mile to facilitate Sales Manager close the deal, help Account Manager maintain better relations with their customers, and aid Development team to build products faster, the entire stakeholder too walk that extra mile in assisting the Product Manager.

To better know how each stakeholder can help Product Manager in discovering needs and what kinds of needs can they discover, I have provided some illustrations and it would provide some idea on the kind of needs that each stakeholder can discover

Needs from support team

  • Product/ Non-product enhancements (Usability/ Features/ Documentation etc)

YouTube changed the VIEWS variable to 64 bit to accommodate more than 2 billion views as ‘Gangnam Style‘ video by PSY was viewed more than 2 billion times (source: Every product is initially created with certain scale parameters assuming it would suffice, however as time progresses and customer business grows, product might soon start hitting the limitations on certain critical scale parameters. Customer would raise a panic button immediately after hitting the limitation but support team can pro-actively raise an alarm through monitoring the critical parameters of the product. Support team will use support cases or other methodologies available to monitor and track the critical parameters of the product. When the critical scale parameters reach a threshold level, support team should immediately alert Product Manager to increase the value of the affected scale parameters.

Support team is also equipped to analyze the support cases and understand the trends to figure out the most common issues faced by the customers, such analysis can help Product Manager understand the list of needs that is not optimally solved by the product. Any improvements can lead to better customer satisfaction thereby triggering higher retention rate leading to more up-sell or cross-sell opportunities. Increasing trend of support cases on a specific feature could also throw lot more possibilities to ponder upon the following

  1. The feature might be buggy – Wakeup call for engineering team to immediately address those issues, while Product Manager can plan for interim release to avoid further customer dissatisfaction
  2. The feature is not intuitive – The feature might be working properly but customers are increasingly finding it difficult to operate. Either the feature is not intuitive (usability constraints) or documentation is not clear. From the perspective of HW product, documentation often plays a key role
  3. The feature is incomplete – The customer needs are not fully met, wakeup call for Product Manager as the customer needs are not properly analyzed. Product Manager needs to take quick remedial action to bridge the gap between customer needs and product capabilities ASAP.
  • New use-cases/ solutions

There are classic examples of customers using the product quite distinct from its intended use. Every product has few innovative customers who are always step ahead of the product team in implementing either new use cases independently through innovative changes in configuration or new solutions through successfully aligning the product with other products. Those innovative customers whom I would comfortably refer to as Innovators or Visionaries as explained by Geoffrey Moore in his book “Crossing the Chasm” do dare to exploit the complete functionalities of the product to resolve the challenges faced by them. Such customers constantly pose technical challenges and help Product Managers build better products which eventually puts us ahead of the competition. Personally it is good to have such customers and my opinion is that they are worth more than a million dollar customer.

Support engineers when consciously look out for such unique use-cases or solutions through the aid of support cases can help Product Manager identify innovative customers and capture their innovations. Product Manager can later use the data to enhance the product that can supplement those innovations or draw plans for new product offering for new ways of positioning the product (aka demand generation)

  • New product requirements

Customers ask about non-existing features through support probably because of lack of understanding of the entire functionality of the product. Product Manager could use those inputs to understand new product requirements; this set of requirements will predominantly be incremental extensions of existing product capabilities.

Sometimes support system is the single window for customers to vents their ire on lack of any features that should have been available in the product by default. In B2C, customers do not think twice to raise their concerns through social media. If your support system does not have the facility to track the digital foot print for such messages, comfortably fall back on ‘Google Alerts’ to track.

Needs from engineering team

Engineering teams are masters of technology while product managers are presumably masters of problem space. Closer ties between the two entities triggering frequent discussion (not necessarily structured, probably unstructured discussions over coffee, lunch or in corridors) can create wonders. When engineering teams are kept informed of the problem spaces, they can evaluate how advances in technology (probably new components in case of HW products, new algorithms) can address the customer pain points in a much better way. For instance in case of VoIP products, engineering/ folks can suggest alternate mechanisms to increase voice/video quality, reduce latency and BW required etc. For same reasons, it is always better to let engineering team provide outside view of the world. Engineering team has to be updated with details about competition, customers, wins & loses, what differentiates our product from the rest.

To further illustrate the importance of working with engineering team, while I was working on new virtualized product I was interfacing a lot with engineering team to understand more about virtualization and how the performance could be improved. I did earlier talk about increasing the adaption rate of new technology. I saw performance as one of the primary roadblock for customers from adopting virtualized product. Engineering team did throw lots of ideas on how to improve performance and in fact they did introduce me to docker technology. Docker technology is gaining ground and engineering team did keep me informed on how it work and the potential advantages over virtualization. I could leverage the technical details provided by the engineering team to understand how docker can help provide better value to customers. End of the day, underlying technology does not make much difference to customer as much as the value rendered by each of those technologies does.

Most would advise Product Manager to hang out with customers, sales, and account teams. I would rather insist to hang out with engineering team as well provided if you are in same location as them to build better products. When Product Manager is close to engineering team, it is better to leverage the opportunity to facilitate more frequent exchange of thoughts, ideas, problems etc. I could only say that MAGIC would be created out of such interactions and if there is distributed Product Management team, I would prefer to hand over the responsibility of building the product to the Product Manager closer to the engineering team. Such interaction might not often enable Engineering team to communicate new needs, but they can deliver solutions that can amaze customers and create a WOW feeling.

Needs from sales

No one interfaces closely with customer as much as Sales Manager does. Sales Manager can provide specific details on how each customer is using the product and they also help discover needs of individual customer. Sometimes Sales Manager can also help understand the gaps with competitor that is haunting the product in closing deals. In addition, Product Manager can also seek Sales Manager input on the below items to get better knowledge about the product

  • Why is customer happy with our product?
  • Why is customer whining?
  • What deals did the product lose? Is there any trend?
  • Is the product losing to any other product in the adjacency space?

Another big source is RFP that most often neglected by Product Manager to identify product needs. In case of B2B segment, RFPs mostly precede sales and the RFP would contain more details about customer needs. RFP would also validate the ability of the product to handle future needs of the customer. Analyzing multiple RFPs provides the direction in which customer businesses are evolving, look out for patterns of new needs and record them.

Ideally spot star Sales Manager to better know about customer needs. Star Sales Manager sell more not because the product is in demand or the product is great or that (s)he is lucky. They sell more because of the deeper understanding of the customer and the product combined with ability to position the product effectively at the intersection of problem and solution. Working with such Sales Manager is really a boon to understand more customer needs, further such Sales Manager are always on lookout for opportunities to generate the demand for the product. They equally look up to the Product Manager to share or contemplate new use-cases providing additional compelling reasons for customers to invest on the product.

Needs from BDMs

BDMs can mostly help discover strategic needs that can push the growth of the product. While talking about discovering needs, I stressed on the importance of pondering on the following topics:

  • Attacking growth – If it is a growing market, there should be conscious effort to identify who is contributing to the growth and lay plans to capture it?
  • Capitalizing white space (aka demand generation) – Probably same product but new use-case and new target segment, Product Manager has to look out for such possibility. Otherwise Product Manager has to spot customers trying to use the product differently from its intended use and check if the variations of the product could be built to generate additional demand for the product.
  • Is there any product in the adjoining segment that has the potential to make the current product irrelevant (what Mobiles did to Pager, what Smartphones did to Camera and Navigation Devices)

BDMs do definitely play a greater role in helping Product Manager ponder over the above topics. BDMs by the virtue of their responsibility to identify new markets for the product and put the product on growth trajectory will gain better knowledge about the market, trends etc. While interactions with Sales Manager(s) boil down to specific customer needs, interactions with BDMs will mostly be centered on discovering market needs.

BDMs role might not be just restricted to help discovering strategic needs, they can also play a greater role while the market is on cusp of technology change. During discussions around inflection point, I did mention that Product Manager should also focus on accelerating the technology shift triggering the migration of customers from old to new technology. BDMs can help identify factors which when accomplished can trigger the acceleration of technology shift. The factors could be improvement in performance of new technology or identification of wide spread applications of new technology.

Basic tenets of collaborative discovery

In all the above cases, Product Manager do not blindly accept the needs and record them rather he opens a dialogue with the respective stakeholders to understand more about the need (WHAT part of the need) and develop a complete awareness of how unmet/underserved/latent need is impacting the customers (WHY part of the need). Without the complete grasp of what and why of the need, it might be extremely difficult for Product Manager to convert the need into requirements and appropriately prioritize it. In certain cases, the stakeholders can merely provide some hints on the needs and they might not be equipped to provide complete details. Incomplete information is still fine and Product Manager might have to build upon those hints. The stakeholders should neither be discouraged to share any kind of information about the customer needs, pain points etc. nor be penalized or reprimanded for sharing incomplete needs. The basic premise is that any information on customer need is worthy unless thoroughly corroborated. Product Manager should also follow inclusive approach while prioritizing requirements thoroughly communicating the yard sticks used for prioritization to the entire team of need discoverers for allaying any fears of unbiasedness in prioritizing the requirements.

Needs from confluence of multiple minds

Needs are not always discovered by a single entity, certain needs emerge at the confluence of multiple minds. Especially in case of emerging technologies such as IoT, Virtualization, Big Data etc. where the problem space is not clearly defined as technology is evolving and the applications of the technology is also evolving; culmination of engineering, domain experts, Product Managers is essential to synthesize divergent thoughts into a concrete need. Unlike in the earlier scenarios, I am focusing on structured methodology (like brainstorming) because each entity has lots of thoughts and they are worthless individually. The focus of the brainstorming session is not to pick the best idea, instead Product Manager has to effectively moderate to facilitate a freewheeling conversation among all the participants to put on table all the divergent thoughts including their assumptions, later participants would built upon other thoughts to provide a shape to a new product need. The scenario is akin to each one holding a partial solution to a riddle. Product Manager has to identify and bring together all the entities holding the partial solution to solve the riddle. To ensure success of this entire exercise, Product has 2 challenges

  • Identify the right set of participants
  • Facilitate effective participation from all the participants

Importance of ‘WHY’

‘WHY’ does not essentially mean that Product Manager fires a barge of questions either during brainstorming or while collating needs from various stakeholders, ‘WHY’ should not sound like an interrogation. The power of ‘WHY’ lay in enabling other person to ponder, to reason out their findings. Primarily ‘WHY’ should also let the other person break their assumptions. Every person has certain set of assumptions and it guides their thinking process. Higher the assumption, more the limitations exists in expanding the thought process of an individual. Because of the limitation or inability to question the status quo, retailers thought people will never buy clothes without touching. Execs at Nokia and BB thought mobile users will always be comfortable with QWERTY. ‘WHY’ is critical when Product Manager has to think beyond the existing needs of customers and anticipate how new technology could impact them. ‘WHY’ would dug out all the assumptions related to customer behavior and ‘WHAT IF’ hypothetical analysis could be used to understand what changes in technology or product would trigger change in customer behavior. The examples that I had highlighted is related to disruptor technology as ‘WHY’ makes much larger impact, nevertheless ‘WHY’ is essential for critical understanding of tactical and strategic requirements as well.

Ability of Product Manager to facilitate collaboration

Honestly, there will never be a dearth of stakeholders discovering or contemplating needs based on their role and experience. Product Manager has to facilitate an environment for free flow of needs and also information related to product (drawbacks, needs, limitations etc) from every stake holder to Product Manager. Even if any of the need sounds dumb, Product Manager should not duck it away, (s)he should explain the reasons for discarding and elaborate the yardsticks used to measure the value of a need.

To check whether Product Manager could create a collaborative atmosphere, Product Manager(s) should try answering the following questions with YES/NO

  • Are you approachable?
  • Are you enthusiastic about listening to ideas that resolves customer problems?
  • Are you eager to know about the new business challenges of customers?
  • Are you interested to keep yourself abreast with latest technology advancement surrounding your product? Also eager to know about the kind of implications that new technology can have on the product?
  • Do you have list of blogs or analyst data on your reading list as everyday task?
  • Do you feel spending time with engineering is your primary responsibility?
  • Do you feel bad about bad dragging engineering team into all your calls with customers?

If the answer to all the above questions is emphatic YES, then Product Manager is desperate to fill his/her head with information. Such Product Manager would never forego any opportunity to learn and (s)he would naturally facilitate an atmosphere to collaborate.

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.

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