Who got there first? Who’s responsibility was to bring the picnic blanket? Who should have paid attention to the weather reports?
Just like a trip to the beach, the overlap of the roles of Product Owner, Product Manager and Business Analyst often results in the blurring of responsibilities in the Software Development Lifecycle (SDLC), which can be just as unpleasant as sand in your picnic food.
The overlap of the three roles becomes clearer when accountability and responsibilities are better understood. Delivering working software to a customer is complex and can be stressful. When you hear creaks and groans like these you know action is needed:
“That’s a delivery issue!”,
“That should have been done at requirements stage!”,
“That’s not my problem!”.
It might feel like your colleague’s ‘slopy shoulders’* or just maybe there needs to be some clarity over where the boundaries and overlaps of those responsibilities are when it comes to getting a software product delivered to a customer.
Being bang on-trend, I decided to ask the amazing chatbot from OpenAI - ChatGPT how AI thought each role differed from one another and how the different roles overlapped one another (highlights my own):
I don’t disagree with these generated definitions by a non-human - all these roles have at least some effect along the entirety of the SDLC process - but as pointed out by our ChatGPT friend above, ‘all three roles may be involved in gathering and analysing requirements for a product’. So for this discussion, I want to focus specifically on the first section of the SDLC process, what goes in – the requirements - rather than the latter stage of building and delivering what’s been requested (another kettle of fish!).
The Journey from the Customer’s Head to the Product Backlog – from the Vague to the Concrete
Requirements are the ideas, theories, and ‘the why’ of a product, and I want to discuss how these three roles influence the journey from the theoretical to where they become clear and understood items listed in the Product Backlog, ready for development.
In my own experience, working as a Product Manager alongside Business Analysts and Product Owners, there is indeed a lot of overlap in who does what, but more in the sense of a pipeline, or conveyor belt, as a software feature/request is progressed along its path from being an idea to being set of details ready for action. Each role has more or less responsibility at different stages in this journey, where each are either Responsible, Accountable, Consulted, or Informed (just as in a RACI analysis), as shown in the diagram below:
The image above shows the roles as they overlap through the requirement journey:
- The Product Manager is initially a front-facing interaction zone with the customer, as well as listening to the wider audience, trends, and other influences on the entire product/business. They either create, influence or deeply understand the overall product vision, strategy and high level roadmap. In the development pipeline, their work is very much involved in what goes into the pipe at the very beginning, matching these up to the overall product vision, strategy and roadmap, then handing these over to or working with the Business Analyst to refine further. The Product Manager needs to have a full view of the entire development process so she can respond to emergencies and queries and be able to clearly summarise the outcomes to the customer at the end. The Product Manager interacts with the Product Owner, negotiating with them on what gets developed and when, relying on their knowledge of the current backlog and team capacity.
- The Business Analyst will take the lead on the details of the requirements coming in, working out all the elements with all the relevant stakeholders for the request. They may produce a Product Requirements Document (PRD), or in a less formal and waterfall-ish manner, just enough documentation and user stories to convey understanding to the development team. They will initially work with the Product Owner to understand feasibility and viability, and eventually with the dev team to build out the user stories and estimates once items have been accepted into the backlog. They may be involved again during any user acceptance testing (UAT), to make sure the team is delivering what the customer actually needs.
- The Product Owner is responsible for the product (or team) backlog, decides what should be done and when, and ‘owns’ the development process from now on - the Product Manager is merely a (sometimes noisy and irritating!) influence at this stage. This is where the input requests – the theories - now become concrete items to be delivered. The Product Owner will work with the development team to figure out the estimates of how long it’ll take to build and deliver and then plan the work out into Sprints. As work continues in the development team, they will liaise closely with the Delivery Lead or Scrum Master who irons out impediments for the development team so that delivery targets can be achieved.
Understanding the overlap of responsibilities, you can see how each team member compliments one another when it comes to making sense of what the customer is asking for and where it fits into the greater scheme of things, working out what is needed in order to make that happen, and then actively planning and estimating its development.
So why did the Product Manager, Product Owner and Business Analyst go to the beach?
Finally, I gave the awesome ChatGPT a chance to finish the title for me:
* As we’re all part of the same team, of course we’d all be there for each other! 😉