Requirement Gathering is an interesting process and the most important one as a PM.
It is the time to socialize with the product through people which makes it interesting and without the right details building the product is not possible which makes it important.
There are lot of templates available all over the internet, so I am not creating any new template in this post – I use Jira templates and sometimes even reuse my co-worker’s template if it fits the purpose of the project (Collaborate, Learn, Implement, and Repeat), there is a lot to learn for people around you.
When gathering requirements there are a lot moving pieces and you need to get your ducks in a row and the road that will lead you in your path is “Collaboration”.
Here is the method I have been practicing:
Draft the Goal
It is a good practice to draft out the objectives & goals before diving in the details. You should discuss the draft internally with the product folks in your team. It will only help build a strong narrative and help in building out the next steps. Setting the right goals which align with the overall business needs and mission is imperative. It has made me more aware of the value that I am helping bringing in the business and why it is important/ not so important to continue with the idea.
At this stage the project is just a simple/complex idea that needs to be discussed with some colleagues, PMs, business managers or if you have access to connect top-level management/leaders. I am lucky to connect with everyone.
Knowing the stakeholders
This must not be news to you, however I am not just talking about top level leadership stakeholders I am talking about actual users of the product or feature you are building.
They can be the direct customers, or even internal employees. They are the ones with whom you will collaborate the most to get the details of the functions, business numbers, reviews, approvals and validation on the project.
They can act as your advisors or test buddies during and even after the requirement gathering phase.
Once you understand your stakeholders and align their needs with your goal you will be able to focus better on the product.
The best practice I like to follow is weekly catch up with stakeholders, a group call works better for me as a regular practice (weekly/bi-weekly).
Business Impact
Often or not while the focus from the "Impact of Work" gets lost in the crowd. However it is very important to keep the focus on the goal that aligns with the business's top-line goals. Now that I know the stakeholders,
I try to understand what their key purpose is or focus in their line of function cause then it gets easier to draft the questions and get around to the impact on business.
Collaborate with the data teams such as the sales, analytics, and performance and business teams as they have the most information on the revenue impact on business
This helps me shape the data with the goals I setup at the ideation step.
Advice: PM's who are not friendly with numbers such as me should take up a Business Analytics course, there are many online. I will soon be enrolling too!
Minutes
Every meeting is important and the time you spend in the meeting is invaluable, ensure you make your notes and send it out after the meeting as an email to every participant and missed participant. If meeting is online and is a very important one, record it if possible. You can add your point of views at the end of the minutes email for talking points for the next one! But do not miss this! It is to be treated as mining Gold for future use :)
Building Blocks
If the project is large then I ensure that I am aware of each block or what we can call "Dependency" that helps build and deliver. In such cases I require support from other teams for e.g. when planning to setup a new CRM for an organization which will be used by multiple functions such as marketing, sales, operations, data analytics and probably even more. So I not only need to know the person responsible for that "Dependency", I should also understand their goals and align them to the business goals with the stakeholders.
This is the most difficult yet crucial part of Requirement Gathering where you learn about:
The blockers which will give you better understanding of the project you are building
How to align functions of the business with the business
It is not something that will go very easy, there have been times when my projects has gone on a stand-by as there were other important on-going/new projects. At such times it will be better to reassess your objectives and redefine the course of work.
Deeper Understanding of Timelines and their Repercussions if missed
When I am the owner of the project at large it is very important for me to know when I will be able to see, touch and feel. So I corroborate with each dependency owner to get to the final timelines along with my internal team. It is important to keep the channel of collaboration on with each stakeholder on always as these days it doesn't take too long for variables in a business to change.
The process of requirement gathering doesn't end once it's all documented, it is continuous process to identify and catch any changes that might have any adverse or altering impact on the overall goal with business.
It's also important to find out the consequences if deadlines are missed and here is how to get and what to do with the data:
It is easier to know the consequences if you have drafted the goals well
If not then you should gather the data about business requirements that can help identify the impact if we do not deliver in time and align them with the overall project and business goal.
Once you have this data you need to call it out in the meetings with the stakeholders
This might lead to a change and make it easier to re-prioritize (if needed) with awareness.
UI/UX Overview
Before you get to the engineering side of the product, it is best to get the look of the product ready and discussed. It's common to draft completely different use cases for different devices/languages/platforms/OS.
Conduct feedback/user testing meeting with the stakeholders to help validate the requirements and user flow. It will help fasten the process of understanding what your idea looks like and keep an open mind with the feedback from the group.
Document the feedback and the updates you make post feedback round, if possible maintain versions of your document, (love the feature on Confluence for this).
Once the UI/UX is ready and confirmed by the stakeholders, it will further help in collaborating with the engineering/tech team and will make the conversation simple and fast on either side.
Crisis
There are many kinds of crisis with a product e.g. Data Compliance, Legal Issues, Regulations Issues. When building a new product or feature it should non-negotiable to discuss and call out any such crisis and its plan to overcome or resolve.
Crisis is to be considered as the best "Marketing" event - you can consider this as unwanted yet an opportunity to gain trust from your customers or colleagues/stakeholders. Awareness and preparedness are the key survival tools to be ready for crisis. Imagine if there is any crisis and you might need to pivot your project towards the new business goals.
Here are some minimal steps that guide me to keep a check:
Know all kinds of audience who will be using/affected by your product/feature
Identify and document how it might affect them
Build a plan to resolve the crisis
Simulate the crisis so it gets yourself and the team you are collaborating with trained for crisis management
I know it is tough to know what crisis might happen, but learning and practicing for it can be quite helpful at that time when you need to cease that opportunity and make the best of it.
Summary
Well these are top-level overview on how I collaborate for requirement gathering and it has helped in working on in business goal-oriented projects. I got the experience of working with many interesting teams and it helped me learn a lot about the product and the business and how it all connects despite of the different point of views and ways of working across different functions within the business.
Comments