Collecting Requirements from Multiple Stakeholders
Hello 👋,
I’m Pratik and welcome to my product management musings where I write about my product management experiences.
As a product manager, you are either building something new i.e. building new software, or a business line that has had no precedence at your company. You could be managing a product/business line that has been running for some time.
If you are managing the latter, then you will often be at the crossroads to decide what to build next?
Managing a product roadmap in an operational business is complicated.
Urgent Attention: You must work on the requirements that need urgent attention today and you cannot stall your business needs.
Plugging Features: You cannot start plugging new features basis your judgment. Your engineering will question you for that.
Prioritizing Backlog: You cannot build a roadmap basis a backlog, whether it’s product or tech. Your companies priorities could have / must have shifted to deprioritize them.
So what do you do?
There are 5 pillars in collecting requirements for a roadmap. A roadmap that should start 2 months from today with a 6-month horizon for a business that’s in operation.
Scraping through your backlog.
Scrap through the data generated on your platform to make inferences.
Understanding market demand and needs.
Keeping track of peers and competition.
Speaking to your stakeholders and collecting requirements from them
We will elaborate on “how you should collect requirements from various stakeholders.”
Becoming the WISH Collector
In an operational business, your stakeholders are taking care of a business function. They could range from your sales, operations, engineering to customer service.
The business function owners will have a better understanding of the gaps because they are working close to the ground. They will have needs and wants to optimize or bring efficiency in their part of the business.
Your job is to collect these requirements from your business function stakeholders. These requirements will form one pillar of the foundation.
When you are announcing collecting requirements, you must have the following guidelines in place.
Name it a WISHLIST: You must call it a wishlist. Because you want a list that consists of things that people wish they had. This will help you get some good ideas.
Keep a TIMEFRAME: You must inform the timeframe of the execution of the WISHLIST (Ex: next fiscal? Next quarter?)
Provide an FAQ: Your FAQ must consist of
Purpose of this wishlist
Submission Types
Deadline to complete the activity
Who can contribute? (this should be available to everyone in your company.)
Some don’ts
No Forms: Don’t give a google form to them. It reduces transparency. Use an open collaborative tool.
No Guidelines: Don’t give guidelines on what to write and how to write. Give the stakeholders freedom to express themselves.
No Blank Sheet: Don’t share a blank sheet. Blank sheets give anxiety. Submit your own WISHLIST before you open it up for your stakeholders. It will reduce their anxiety.
All you need are two pieces of information, the name of the stakeholder and their wish.
What next? Do we wait?
Once your mail gets delivered
Speak to your stakeholder: Make individual calls to the stakeholders and explain the importance of this activity. You will need to wear the hat of a relationship manager.
In a large setting, you can speak to your function heads and explain to them the importance. In a small setting, you must speak to all your stakeholders.
Conduct Followups: You must conduct follow-ups with your stakeholders and remind them of the importance. You will have to operate like sales.
You must tell them that you are working for them and you are there to build things so that they can do their work better.
This entire process of collecting requirements should not exceed 2 weeks. Get your manager’s support to do this, else this project would become a complete failure.
What to expect from the wishlist?
The deadline has approached, and people have filled the wishlist. What do you reckon the WISHLIST will consist of?
Wishes that are more like bugs and gaps in your current product/process
Small wish that seems like a task
Large wish that is more like a product
Wishes that are similar with different narration.
Wishes that seem like process improvements and not technology upgrades
Wishes that look similar but are different
Wishes that look improbable to build in the next 6 months
Wishes that have no relevance to the company’s vision
Hey, it’s a wish. It’s unorganized.
How big should the list be?
You can assume a 1:1 ratio. It means that in an organization setting of 100, you should expect over 100 entries. We have observed that the average entry per person is around 1.25.
So what do you do from here?
Understand every submitted wish.
Speak to the stakeholder to understand abstract wishes. Elaborate them with your comments.
Make mind-notes of the wishes and categorize them into various business functions.
This will take some time if the wishlist is long. You will be speaking to stakeholders elaborating their wishes to expand the context of the wish.
The collection of wishlists from your stakeholders could take between 1 to 3 weeks. You could do it quicker, but then you will not get meaningful wishes. You must give time to your stakeholders.
In the next series, we will talk about organizing a wishlist.
Feedback
Hey, you made it here! If you liked the content
You can follow me on linkedin . twitter
💬Do take out the time to leave a comment, share, and subscribe to the newsletter.