Pragmatic Viewpoint : Understanding your direct/indirect stakeholders and different sources of requirements
I have read articles about types or sources of requirements and came across categories like functional requirements, usability requirements, technical requirements etc. This is one viewpoint and a much needed one. I feel, we also need to look at the types or sources of requirements in a broader fashion and then drill down into these types.
When gathering requirements for an internal product or an application, there are multiple sources that need to be considered and features need to be prioritized appropriately.
The four sources of requirements are as mentioned below.
1 — Customer and Partner expectations
There is a certain way customers and partners want to engage. They are looking for multiple types of quotes to select from, different ways to buy, implement and consume.
Even if officially, customers and partners do not provide requirements for an internal application, it is important to keep them in mind all the time. We shouldn’t design something for internal sellers that does not align with how customers want to quote, buy, pay and consume.
Customer obsession should always be ON.
2 — Company Leadership Priorities
Executive Leadership team always has a vision. It is critical to design internal systems and tools according to where company is headed and not just based on today’s requirements. Design should be scalable to align to the leadership’s vision on go-to-market strategy.
3 — Internal user pain points and requests
Now coming to the most important and obvious source. These are the real users for whom we are building the application. Internal tools need to be built to increase productivity for internal users, so all sales teams can sell faster, smarter and bigger!
When building a net-new application, journey maps, user research and interviews help.
When transforming an existing application, additional step of documenting pain points is necessary. Also, understanding the “Why” behind pain points helps get to the right design.
4 — Internal Operations/Finance/Engineering team’s requirements
At times, there are requirements originated due to internal processes, legal compliance, audit expectations from internal Ops teams. Also, Finance team needs set of data points in order to report company’s revenue accurately every quarter, so they feed requirements. Examples of the internal applications where Finance team weighs in heavily are — Sales Goal setting, Sales Forecasting, Bookings Reporting, Revenue Reporting and others. Furthermore, Cisco sells across multiple architectures (Security, Collaboration, Data Center, IoT etc.), so product engineering teams come into the picture as well.
Requirements from these internal teams need to be incorporated and become another source.
I have visually represented above sources here -
Once features from all sources are documented, next step is to prioritize them and also tag H,M,L effort/complexity. This is called as Value-Complexity metrics.
Occasionally, requirements from different stakeholders clash. For example — leadership might want to see certain data points in reports for better decision making but that might become time consuming data entry for sellers, negatively impacting their productivity. That’s where there is a need to creatively find ways to automate workflows and get what all four types of stakeholders are looking for. Yes, it is going to be hard but hard is not impossible! Balancing expectations of all stakeholders is challenging and fun.
Thank you for reading. Feel free to comment if you feel I have missed any important aspect in this article. Happy to learn!
Cheers!
Jyotsna
