Prioritization of Requirements - Right product that delivers maximum value

Prioritization of Requirements - Right product that delivers maximum value

This is one of the most important decision a product manager has to make in order to define the release and develop a roadmap.  Even though this is a key decision...very few  PMs spend time on this process .

The most common way to prioritize requirements is by adding a suffix with every requirement that states it’s a must have, should have and nice to have. So, what's wrong with us method of prioritization.  Must have in PM's definition implies that we wont ship the product, should have if we have time in the release and nice to have is essentially relying on some unknown factors influenced by super natural powers to get the requirement into a release.  Natural reaction on the first look at this list is for the engineering teams to eliminate should haves and nice to haves. Why do teams do that? If you recall in my previous blog on what's wrong with PRDs I highlighted that engineering cannot cost the release by reading a few lines/paragraphs. So, the natural reaction is reduce the risk by eliminating what' s not really important to the Product Managers to begin with.  Should have's and nice to have's are gone in the very first discussion or prior to that. Then what remains are the must haves and the "dance" starts.  Engineering is asked to provide scoping analysis of the high items  and the process of elimination starts.  An engineering lead I'm friends with started a presentation with a nursery rhyme as part of his discussion with the product managers:

• You put your right foot in,

• You put your right foot out,

• You put your right foot in.

• And you shake it all about.

• You do the Hokey-Pokey,

• And you turn yourself around.

• That's what it's all about!

After all this is...what remains is a set of requirements that for legacy Enterprise products are usually the "me too" or "customer escalation" or " a specific customer request" or a "catch up" or "close gap" or a "tactical feature" to deliver the release. At times, innovative requirements/features do get it but this is based on perception of the PM and no hard data and thus starts the costly gamble for the product team/business.  You may or may not get lucky with these innovative requirements.  Similar issues, exists with all the other forms of prioritization - p1, p2 p3/ 1,2,3/ voting etc.

So, what's the alternative…

Let's revisit the core responsibility of a product manager again . Product Managers have to define a right product that provides maximum value to the customers while reducing the complexity and meeting the time to market needs of the business and customers.   With this key definition firmed up...lets look at the prioritization process from this perspective in the diagram below. Always, keep this definition in sight ...

1. Business Strategy - What is the strategic direction of your business?

2. Product Strategy - > How will you support the business strategy?

3. Business Opp. Assessment -> What Problems?, For Who? Competitive/Substitutes/Threats?, Why us?,  Why now?, Market size?,  Risks? & Critical Marquee Themes ?

4. Customer Validation (Ideas or themes)/ Internal customer facing teams validation

5. Brainstorming (three key stakeholders - Product Management -> market needs/problems , Product Designer -> Understand the persona & required user interaction , Architect-> Determines the feasibility)
6. Iterate through steps 4-5-6 UNTIL you define a right "minimal" product which has a blend of form (UI) & requirements and that provides maximum value to the customers while reducing the complexity and meeting the your business and time to market needs.

Scoping analysis does help prioritize the requirements.  But, this could be done via a gut level feasibility analysis and not the formal scoping effort.   There are a few big issues with the scoping analysis method where engineering teams are asked to go into vacuum and come back with estimates.

 1 - You waste time and valuable engineering cycles

2 - You are asking for validation of the features from the engineering team which is not what engineers are supposed to do.  PMs have to put the right set of requirements from a customers / market and industry perspective.

3 - Create unnecessary stress between development and the PM team. No one likes the dance we do ...why do it if you can avoid it in the first place.

The steps outlined above are meant to gather the right data for you to help define the product. Some product managers like to go one level deep with this analysis and actually come up with some mathematical model to use.  There is no harm in doing this as long as you stick to the fundamentals outlined above. So, how do you go about adding  more granularity to this process. Well, add one more step

7. Assign weights based on key factors (weight/factor).  Use a very simple formula  that works for you and you can justify.  But, this is after you go through the 6 step funnel process to identify the right product that customers want to use.