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.

How to push collaborative innovation

During IPMA event, I had a chance to interact with Head of Product Management, Wipro and I asked him how service organization could enforce collaborative innovation. He was quick to point out a top-down approach.

Top-down approach is that every BU by default would have certain sales target and he wants to strictly enforce that certain percentage of the revenues had to come from either new solutions/new markets. Even if the overallsales target is achieved and X% of sales revenue is not contributed by either new solutions/new markets then the target is to be missed. Such approach will ensure that the BU heads will persuaded to push for collaborative innovation and they will bring in required process to capture the value arrived out of collaborative innovation. However from the conversation, I could not sense that there is no deliberate attempt to spur the collaborative innovation from bottom-up.

I sincerely feel that there should be some equal focus on the bottom-up approach too for the success of collaborative innovation. As stated in previous blog article, engineers are more focused on their individual component that they often fail to relate their component with every other component in the entire end-to-end solution. We have to facilitate them to think how their components work in relation to other component in the overall solution. Such thinking is also called as Systems thinking and it will help foster a mental map that will provide a holistic view of how each component is related to the entire system or rather solution in our case. System thinking will act as stimulus for collaborative innovation as the engineers would have the urge to understand every component in relation to every other component in the system. But the biggest challenge is to inculcate systems thinking in the minds of engineers.