Successful Product Owner (PO) and Business Analyst (BA)

Some of things in the role of PO and BA are quite common. This blog is generic to both roles. Well, it is important to understand the two key questions about the BA role.

What does a BA analyse?

A BA analyses a business requirement to determine how it can best (from a perspective of quality, cost, time) be implemented into the available suite of software applications or products. The business requirement could be around a new feature, upgrading an existing feature, deprecating part or whole of the existing feature, decommissioning a legacy system or related to migration of the application.

Who does he analyse for?

He analyses the above primarily for 2 set of stakeholders.

  • What it means to the end user?

    The requirement may come in different ways (may be just 1 line, 1 paragraph, 1 page or even non-written but out of a conversation). The BA has to analyse how this requirement or change in requirement would impact the application which in turn would impact the end user. Empathy and ability to put himself into end user shoes is important.

  • What it means to the IT team (software development team)?

    The development team is usually more tech savvy and less business savvy. They want to know what it means to them in terms of grass root level implementation. As a developer or technical lead, I would look forward to know what exactly I need to do step by step in the software or application’s components that will meet the business requirement. So, the BA has to slice and dice the end user impact into such a fine grained way so that development team can understand it as actionable pieces of work. And of-course, while slicing and dicing, he also needs to translate and transpose business stuff into technology enabled delivery vehicles. In other words, the BA has to act as a bridge between both worlds (the business and technology).

Essential attributes for success:


  • Ability to slice and dice (INVEST principles are very useful)
  • Ability to drive workshops to dissect, deduce and elaborate requirements
  • Analytical mind to understand what it means to the end user, how the customer or end user would act/feel/behave while using the application
  • Top to bottom approach –ability to deduce detailed requirement(s) or use case from very short brief
  • Write acceptance criteria and cover all possible boundary conditions (permutations and combinations where/how each AC may fail)
  • What-if approach – What data user may use and what if he uses incorrect data which may be correct from his perspective
  • Research skills – Need to identify and understand existing capability to ensure nothing is overlooked or broken as a result of the change
  • Organisation – Must be able to work with other teams to determine dependencies and timings of inter-related changes, as well as determine the logical order of small pieces of work building to a whole
  • Ability to analyse a problem, develop solutions and evaluate various options for benefits and drawbacks
  • Ability to plan, execute and document scenarios for acceptance testing
  • Articulation skills – comprehending something in mind is one thing however articulating the same on paper in such a way that others can understand it well is another thing which comes from experience (write user story in such a way that development team could understand it well with minimum ambiguity)
  • Do an impact assessment to a degree that lays the ground for the technical folks to think further
  • Prioritisation of user stories (both in terms of sequencing of stories and also from business value perspective)
  • At times, designing mock-UI and wire-frames also part of BA’s responsibility. If yes, then s/he should have good command over tools like Microsoft visio, lucid charts etc. to draw UI screens. This also needs good imagination.
  • Use of tools such as JIRA, confluence, Rally and so on.


  • A good communicator – the BA/PO has to spend a lot of time talking and listening with different sets of people.
  • Calm and patient – BA/PO will be dealing with diverse stakeholders from different background, he must have patience to actively listen everyone and constructively respond
  • Collaboration with development team
  • Self-organising, balancing time and availability in the mid of constantly changing priorities
  • Empathy to put himself into customer’s shoes
  • Reacting quickly to change in priorities or solution approach
    Being able to justify the complexity of seemingly simple changes (the devil is in the details!)


  • Paralysis by analysis – loaded with massive information that too scattered
  • Work in the twin worlds of business and technology
  • Volatile requirements
  • Explaining cost of delay to stakeholders

Author: Vinay A.

Agile specialist, expert in full spectrum of end to end project deliveries, Innovator and lateral thinker to solve routine corporate problems

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: