top of page
  • Writer's pictureSteven Timbers

Business Analyst to Product Owner

Through my career I have had some differing titles within Product / Project work; Business Analyst (BA), BA/Tester, Proxy-PO.

Ultimately I have landed in the Product space as a Product Owner and for me its a job I love.

I wanted to share some of the strengths from each that I have pulled into my PO role and some red flags to look out for that you aren’t being used to your full potential as a PO.

Business Analyst


Naturally one of the biggest strengths a BA is being able to be analytical in your approach to extract the most amount of detail. If you have spent time in this space you will have built-up a number of tried and tested methods in detailing requirements and also in running workshops.

A lot of this transfers nicely over to the Product Owner role. One of the methods I now use most frequently is interviewing techniques. Admittedly this does differ slightly to Product interviews but the key concept is the same > get the information out of the persons head!

Red Flags

When starting out as a fully-fledged PO I spent a lot of my time writing out comprehensive user stories pages long in JIRA, where a button is positioned on a page, etc. This is great for a BA but not good practice for a PO.

A PO needs to aim for ‘understood’; the detail doesn’t need to be exhaustive it just needs to be understood by the full team. Yes you will need to detail some things but the more you can collaborate with the team and get all to input in the story the better. Spend your time else-where e.g. talking to customers.

Extra: As a BA you can end up with the mindset of detailing requirements with the Development team in mind. A Product Owner needs to shift focus and be the voice of the customer. Don’t restrict your vision early on because the ask might be difficult.

Test Analyst (Manual)


A lot of detail is required to fully test out an application. You are thinking of all the ways a user would functionally use the application… you are also thinking of ways they might not use it, those ever comical edge case scenarios! This approach is a great way to think when applying into the PO role. It really allows you to think like a user and the logical steps they would take. It can highlight where there are too many steps and where some are just too complicated, helping you to produce better UX.

Red Flags

Test analysts tend to live in the realms of edge cases and ways to break the system. If you are asked to detail all of these by your Dev or QA team this is a red flag. As PO you should be more focused on the main scenarios a user would take and the high value this will deliver. Make sure you prioritise these first.



As a Proxy-PO you are basically doing the same role as the Product Owner. You are gathering the customers needs, defining the backlog, working with the team to produce increments. You can transfer all skills you have as a Proxy-PO over to the full PO role.

Red Flags

As a Proxy-PO you are not the decision maker. This seriously undermines the role of a Product Owner. If you are titled PO and aren’t allowed to make decisions that guide the products direction then you need to be having conversations to change this. Only when you are the decision maker can you really incite change for your product.

End Note

There are many strengths you can take from any role you have previously held into the Product Owner role, however be mindful of what a PO truly is so that you can be effective in your position. Don’t let old habits creep in (easier said than done) and become an effective story teller!

3 views0 comments
bottom of page