Every good recruiter knows how important it is for candidates to have a deep understanding about the job they’re applying for, and exactly what skills are needed – but these two roles within the industry seem to cause much confusion.
It’s not just candidates who find the boundaries a little blurred. We often hear the terms used interchangeably; we get lots of job specs for a Product Owner listing all the skillsets for a Business Analyst, and vice versa – and businesses often call in BAs to do a PO’s job, when in reality the roles are quite different.
So I’d like to try and clear up some of the common misconceptions about these roles.
Both obviously demand core skills such as problem solving, good communication, and critical thinking and soft skills like relationship building and self-management.
While a Business Analyst is project and tactical focused, a Product Owner may be more business strategy and customer focused (although you might have a business savvy BA, or a technical PO, depending on what kind of backgrounds they’ve come from).
Product Owner (PO)
The Scrum definition of the PO role (where the function originated) is “the person responsible for maximizing the value of the product and the work of the development team”.
The PO has to know what the business objectives are and why the product has to be a certain way to achieve business goals.
They are the member of an Agile team who works with product management and other stakeholders to define items in the product backlog.
They’ll be responsible for business strategy, customer focus, competitive analysis, business priorities, business engagement, issue escalation, backlog refinement, iteration planning
- They must have a clear vision of where the product needs to go;
- They are responsible for helping the development team understand the needs of the business;
- They make budgetary decisions about the product.
Business Analysts (BA)
The BA, on the other hand, will be writing functional requirements for developers rather than having anything to do with the commercial business strategy.
They’ll understand the structure, policies, and operations of an organisation, and recommend solutions that enable an organisation to achieve its goals.
- They understand how the client’s business operates;
- They design and deliver solutions which help the client solve problems;
- They are the informational bridge between business and technical teams.
Where the confusion comes about is because the role of the BA overlaps with the PO in a number of areas.
Having a PO as the information bridge between the business community and the development team is the customary set up, but sometimes a BA ends up in this position, which is sometimes not as effective.
Other areas where the boundaries are blurred include:
- Tactical focus
- Story gathering
- Story writing
- Benefit analysis
- Backlog refinements
- User acceptance testing
With people being the primary drivers of a project’s success or failure, it’s crucial that clients understand precisely what they need – and that’s what we’re here for.
To establish what role a client needs to fill we might ask ‘What’s the problem you’re trying to solve?’
- Is it understanding who their customers are and relaying that to internal development?
- Or is it being able to elicit requirements from stakeholders in order for developers to build it?
- Where do the pain points lie?
We can also help candidates clarify their strengths in this area (and by the way, there’s no reason why a BA couldn’t move into a PO role if that’s what they want and vice versa).
When considering a PO role, we might suggest candidates ask themselves:
- Am I involved in business strategy?
- Do I need to understand who the customer is?
- Am I doing things like market analysis?
Or for a BA role:
- Do I need to be able to write technical, functional requirements for developers?
- Am I working on internal business processes?
- Am I the bridge between business and technical communications?
So before you consider hiring or job seeking, read up on the differences and similarities – and our team is always happy to chat. Say hello at email@example.com.
Other similar news
Advice on hiring product managers for...
Thinking back to 18-24 months ago, if a client called up with a ‘Product Manager role for Internal Tools’, I’d have sighed slightly. Product roles for internal tools were viewed...
My favourite product management events
Here at Futureheads, we enjoy any excuse to exercise the old grey matter by attending various industry events in London and beyond. I wanted to share with you some of...
FFS Bede McCarthy
Being part of the Product team here at Futureheads means I get to spend a lot of time talking to people who have interesting stories to tell about their careers, the...