Skip to main content

Surviving as a Business Analyst in a Product-Centric world

According to the IIBA, “a Business Analyst (BA) enables change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.”

However, Business Analysts (BA) are often viewed as simply requirement recording machines. Agile methodologies have allowed the BA role to evolve, by limiting the focus on documentation. However, the next step in the evolution of Business Analysts is to don a product management hat to develop stable, scalable and innovative solutions. Here I outline a guide to help analysts create more elegant, effective, creative and expansive solutions using a product-centric approach by keeping the user and business as the core focus.

What If

As usual, you want to start with identifying the needs of your users by articulating and framing the need statements. If you are working on a new product, outline “what if” statements, which test the status quo, such as for e.g. “what if our customers can access their medical records on the go.” These questions enable you to think outside of your constraints and leave you open to all possibilities. Put together multiple statements with your team and consider these your hypotheses. Make sure you involve your stakeholders from the beginning, so you don’t have to convince them for approvals later. With each statement, ask yourself:

  1. Does this help you maximize the impact?
  2. Does the situation work in multiple contexts?

You can use this worksheet to complete your “What If” statements.

Make First, Document Second

Make first, document second may sound counter-intuitive, especially if you are a seasoned BA who is coming from waterfall background; but you don’t have to document anything at the moment. Once you are done with your “what if” statements, create prototypes that will validate your hypotheses. Prototyping is a great way to make your idea tangible. You can get quick feedback from your end-users to help you with capturing acceptance criteria and use-cases. It can also help you get buy-in from stakeholders, who would be convinced by working software. Your prototype doesn’t have to be a finished product. It can range from an image, wire frame, digital mock-up or storyboard that would help you communicate your idea to the end-user.


Advertisement

Just make sure you observe how your end-users are getting engaged with it and what questions it generates. You can use this worksheet to guide you with capturing the necessary data. Capturing this data will help you immensely with your requirements documentation as well since it will be insight driven and you can determine possible use cases as you observe their interactions with the prototype. You can capture your learning on Typeform, Google Forms or Murals. Some of the tools that can come handy for prototyping are POP, Proto.io, or Sketch.

Go Out of the Building

We usually are sitting in front of our screens, playing around with the current systems, creating diagrams and defining processes. This may be effective when we know what we need. Going out of the building is a metaphor used to test your hypothesis with actual users to understand their pain points and get a perspective of the environment your solution will be used in. Connect with your users and ask them, if they would use your product/service and give them your prototype to play around with. Keep a close eye on them while they are playing with your product. Remember you are just validating your hypothesis, so don’t be biased towards it.

Refine and Prioritize

Once you know you have the pain points and solution defined, take a step back and assess the merits of your solutions by questioning the impact of it and what resources would it require to be implemented. This would allow you to get a sense of direction and have a product roadmap by the end. You can connect each concept and feature with a specific set of goals that the solution would achieve for your organization by answering the following three questions:

  1. Viability: If it addresses the long-term strategic goal of the business.
  2. Desirability: If it provides value to the end user.
  3. Feasibility: If it will be viable to develop and what resources would be required.

This worksheet will help you prioritize, refine and put solutions in perspective.

Once you have these questions answered, you will be able to start from the top and implement these features one by one. Our job as business analysts doesn’t end in the solution phase. We need to be engaged continuously in the process to assess the usage of the solution and how it is impacting the business.