1. How will this requirement or decision impact the user?
In a high-pressure environment, in which decisions need to be taken fast, it is easy to fall into the trap of not considering, in enough detail, the impact a product decision may have on our potential and actual users. Sometimes, due to budgetary, time or technical constraints, product teams make conscious decisions that are not optimal for users. This is ok, as long as we understand the impact beforehand. The BA plays a critical role in keeping the user at the center of the product, by:
Asking the right question at the right moment to the right stakeholder
For example, before deciding on a technical solution, a BA may ask an implementation subject matter expert (SME): Let’s say we implement the database using approach A. After a user submits a form, how many seconds will data validation take in the back-end?
Another example, at a backlog refinement meeting, the BA may ask the Product Owner and the User Representative: By providing users with a feature to download the list of purchases in Excel, will this satisfy the requirement of having a list of purchases that is sortable and can be filtered?
Proposing and organizing user research or testing, whenever required or possible
User research is useful to get to know users better and have more information when making product decisions.
User testing is great to assess users’ responses to specific requirements or designs.
User research or testing are time-consuming. Depending on the relevance of the decisions to be made and their level of uncertainty, the product team might decide to do it or not. The business analyst plays a key role in analyzing when user research or testing would be beneficial for the product.
2. Are we overlooking any stakeholders?
To avoid product re-work or push-back, it is very important that we invite the relevant stakeholders to the meetings and activities in which they can provide value. The biggest challenge here is that the stakeholder list is never static. Therefore, Business Analysts should frequently conduct Stakeholder Analysis to update the Stakeholder List and Map.
Organizational changes might be one of the sources of new stakeholders. We should be aware of things like staff changes, the opening of new offices, or internal departmental restructuring.
Also, as a product evolves, different stakeholders need to be considered. For instance, the stakeholders involved in a product’s discovery activities can differ a lot from the ones involved in going-to-production activities. In product teams working iteratively, where discovery and implementation can happen at the same time, the BA’s communication and planning skills are critical assets to ensure a smooth product development cycle.
Furthermore, external factors also determine which stakeholders you should involve. A new regulation might cause you to include the company’s lawyer in requirements elicitation, or a new marketing campaign launched by your main competitor might trigger you to schedule a brainstorming session with the Marketing team.
Sometimes, asking yourself or a team member a simple question like “Shall we invite someone else to this meeting?” will help identify new relevant stakeholders, as explained above.
Yes, some people would say BAs ask a lot of questions. Questions that lead to other questions. They unveil things that might alter the product plan. They might point out our own shortcomings. But at the end, every question not asked is potentially a missed opportunity to improve.
