Scorecard technique had mostly helped me to eliminate all possible mistakes committed during prioritizing requirements, however not everyone does follow scorecard technique. So I thought it would be appropriate to list down all possible blunders that could be committed by the Product Manager while prioritizing requirements.
- Prioritizing product requirements purely based on revenue potential
It is always nice to focus on requirements that have higher revenue generating potential as revenue is possibly one of the most important reasons for existence of the product. Ironically, Product Managers are also evaluated primarily on the revenue generated rather than on the strategic activities that can possibly have positive implications on the long term. Guess it is a different topic for discussions. Now coming back to our original topic, Product Manager should not get too much obsessed with revenues losing sight of the long term objectives. Without revenues, management would cut down the resources and Product Manager would be left with no resources to evolve the product. The ideal scenario for a Product Manager is to adeptly balance both short term and long term priorities while ensuring steady flow of revenue.
- Prioritizing product requirements of customer with loud voice
Customer with loud voice often have their way through escalation or making noises at right place to right people. It is always easy for Product Manager to succumb to the pressures, but it might not end with just one request and the trend might continue. If the product requirements of such customer are reasonable then there is no trouble, but prioritizing a requirement just because someone is exerting pressure is not an ideal scenario. It is better to nip such requests in the bud without yielding to the pressure outlining the implications of acknowledging such requirements to the management. In a latter blog post, I will outlined some actionable points on how to say ‘NO’ to customers hijacking the product roadmap in a convincing manner without antagonizing them.
- Prioritizing product requirements concurring with engineering team
Product Manager can have two possible types of engineering team (i) Sluggish and (ii) Motivated. Either way it would be trouble managing them.
They always look for reason to turn down high effort requirements and probably enjoy basking themselves committing to low effort requirements. They are mostly risk averse. Product Manager should primarily be ruthless while dealing with sluggish team.
They are enamored by the technology and mostly look forward to do stuff that is cool. They enjoy being challenged by complex problems. Their aspiration is around technology and not around customers. Product Managers should always stay on top of them to guide and steer their efforts in appropriate direction that adds lot of value to customers.
You cease to exist as a Product Manager if you let engineer take a decision on prioritizing the requirement for simple reasons that you are either lazy or could not grasp technical nuances to understand what value is rendered by the requirement to customer business environment and how the requirement is aligned with overall product purpose. Product Manager is a gatekeeper of the product and (s)he should be aware of every change made to the product.
- Prioritizing product requirements because you (Product Manager) felt that those requirements add value to the customer
Being a hands-on Product Manager is a nice quality and I do insist on Product Managers getting their hands dirty with the product, so Product Manager can independently evaluate the product gaps when trying to understand the customer needs without troubling development team. Such hands-on quality will also allow Product Manager to independently identify product gaps, however the requirements has to be judiciously prioritized after gaining a thorough understanding of what kind of value could be rendered by those requirements to customers.
Product Manager should step aside for a while and move to other side of the fence to evaluate whether the requirement would be valued by customers and try to estimate the amount of value rendered to the customer. There should not be any bias towards the requirement identified by the Product Manager while prioritizing the entire gamut of product requirements for each release.
- Prioritizing product requirements of the user instead of the buyer
User and buyer are two different entities in case of B2B product. In most cases, Product Manager would talk to both buyer and user. While buyer can throw light about his/her potential business challenges, user can throw light about his/her experiences using the product and how the product could be further improved. I am not advocating that Product Manager should only prioritize buyer needs over user needs, even though buyer needs gain relatively higher priority as those needs directly impact the customer business. I would rather insist that Product Manager should appropriately recognize the role of the entity communicating the need and prioritize the need at the face value of it by determining whether the need is merely enhancing the usability of the product or addressing any critical business challenges.
- Prioritizing requirements without a common theme
Theme is a unifying factor for majority of the product requirements prioritized in each release. Why do we need a theme or unifying factor for each release? Each person might have their own views on the need for themes, some outline that themes help in better prioritization. At least, I opine that themes help in better marketing of the product release. If the product requirements are cluttered across multiple areas such as usability, performance, stability etc., it would be tough to construct a unified message to indicate the value delivered by each release. I have earlier talked about identifying product objectives and attributes, later measure how each requirement is performing against those attributes. Using such methodology will ensure that majority of the features can be grouped under one or two product attributes and those attributes can provide some unifying theme for the entire release. I basically derive the theme from the list of prioritized features.
Certain experts do recommend to list down themes and start prioritizing requirements based on themes. Alternately list down all the prioritized requirements and categorize them into themes, later deliver requirements of 1 or 2 themes in each release. Honestly there is no right or wrong approach. Even the scorecard methodology that I had outlined in the previous section will let the Product Manager indirectly prioritize requirements based on themes through assigning more weights to specific product attributes.
- Prioritizing requirements yielding to the pressures of sales team
Sales Manager is one of the stake holders that can communicate product requirements because they interface with customers regularly and keep tab of their expansion plans. While communicating product requirements, Sales Manager attach revenue figures to aid Product Manager better prioritize the requirements. In most cases, the revenue figure would be most optimistic and it might not often reflect the real potential. Least in some cases, the revenue would not realize even after delivering the requirements. Yet Product Manager has to gamble especially if the revenues are drying, however (s)he can go for calculated gamble instead of purely relying on the data provided by the sales manager.
- Does customer has compelling reasons to buy our product?
- Is customer evaluating any competition?
- What is the past history of the customer? Do they consistently buy our product or just get their job done under the veil of promising revenue opportunities?
In a different scenario, Sales Manager will close certain deals promising few requirements on roadmap even though roadmap is a plan and not a commitment. In such cases, Product Manager would add exceptions to provide a commitment to customers. Product Manager should not allow Sales managers to make the promise. Instead Product Manager should analyze all the customer requirements and after careful evaluation of already planned activities should make the promise to the customer. Basically Product Manager should be confident enough to make the commitment.