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. 

What’s wrong with the Product Requirement Documents (PRDs)?

PRD is the most commonly used mechanism for product managers to describe product requirements for a release. PRDs forms the basis of requirements for both Waterfall and now even with Agile software development processes. However, there are some fundamental challenges with the PRD model and I’m sure if you take a step back and analyze the pros and cons of the PRDs...you will find commonality between your thoughts and what I have shared below.  Not sure who invented PRDs but I’m sure this person/organization didn’t have just the word document as the fundamental way to define products.  So, lets start with the challenges first :

Take Time to Write

Product Managers spend considerable amount time on the document.  During this time your product teams are in waiting mode and management is anxious to figure out what’s next. So, cycles are wasted and engineering management cannot plan for what’s next from a staffing, budget , platform perspectives until this document is firmed up.

User Experience is an after thought

This is the biggest challenge with the PRD. They are a bulleted list of requirements ...very verbose but cannot describe the user experience. User experience is the most important element of a requirement...experience does not only imply the UI. It's every touch point the user has with the product. 

Static in nature

PRDs are static documents. However, development is a dynamic process...in fact, agile development is used today to help give structure to this dynamic nature of software development. On the other hand , the most crucial document that is used for software development is static.
 

Error prone scoping Analysis

Engineer cannot actually provide the scope of the work until he really understands the requirements, gets a chance of putting a high level prototype or design document . However, we hardly give this "must needed"  time and force the engineering team to come up with the estimates to help identify the next spot on the roadmap . Thus, what you get usually are high level estimates with a significant error margin in them and off course very conservative.  PMs are still not done.  Then, the next round of discussions start around the negotiations. Give and Take...

What you ask for is not what you get ?

We all have lived through this. What is specified in the word form in the document is different then what you get? Why is this? Because requirements are subject to interpretations ...PRDs cannot capture the entire context of the requirement.

Cycles after cycles are wasted

The ping pong game between engineering and product management on requirements is a waste of time and crucial product release cycles are wasted. It causes frustration, results in lack of trust, results in throw away work. PRDs usually start with the complete wish list from a PM and ends up with what should have been there from day one prioritized as the right feature set for the release. This is a significant waste.

Cross functional teams have no clue what’s in the release

Even though PRDs exist but honestly the only teams that read it are usually the engineering staff. As a result, cross functional teams are in dark and they all wait for the final PRD and some kind of a dev milestone to understand what is in this release. So, they are in dark and cannot plan for future deliverables.

Too long to read and it changes...

Hardly a few engineers read the entire PRD which takes time and by the time you read it usually changes . Infact, the change is constant since you are going and forth from a market perspective but also adjusting based on all the discussions.

Management is left in dark

Executive team usually gets a few bullets on a power point to help illustrate what the next release would look like. These bullets form the basis of budget approvals, decisions and pretty much the “Go/No Go” decisions for the project.

Do not describe the requirements but end up describing the solutions

In order to be precise and to make sure what you ask for is what you get product managers end up identifying the solutions to the team instead of the requirements. PRDs suffer from this common problem.

Cannot be validated

There is no way to validate the PRD and the assumptions associated with the requirements. It’s not something you can put in front of the customer ans ask for feedback or lead them to discover new requirements.

This list can go on and on...but I’m sure you will find a connection between your process and these data points . On the positive front...PRDs in its true form are a useful document when you know the exact set of requirements and can clearly / very clearly articulate it and expect little to NO changes to it as you move through the release. Usually, this is true with waterfall development models or shorter releases.  This is hardly the case in the software world we live in these days. 

So, what’s the solution...

Solution lies with the startups and entrepreneurs who have built companies from scratch. This will be a topic for my next blog...but here is the hint. What do startups do differently? What do Entrepreneurs focus on initially when they have limited availability of everything ...money, cycles, resources etc?