From BA, QA or developer to Product Owner: what to learn?

Working as a BA, QA or developer and want to become a Product Owner?

This is an illustrative situation. Linh is a QA on a spa booking app. Minh is a BA at a software company. Tu is a backend developer. All three want to become Product Owners (POs), and all three hear the same question when they ask to move: “Tell me about a product decision you were responsible for.”

Each of them has plenty to talk about. Linh caught serious bugs before release. Minh wrote hundreds of user stories (short descriptions of a need from the user's point of view) that developers understood at first read. Tu redesigned part of the system so it ran much faster. But on reflection, all three realise their stories are about doing the requirements right, not about choosing which requirements were worth doing.

Some entry-level PO job ads ask for 0 to 2 years as a BA or an equivalent role. If you work as a BA, QA or developer, you are already close to product work. But being close only becomes PO experience once you add the missing part.

This article is for people coming from BA, QA or development. If you are coming from design, “From Designer to Product Owner” is written for you. Here you will find a table of strengths and blind spots for each background, a way to build PO experience inside your current job, and a way to tell that story on a CV without overclaiming.

• From Designer to Product Owner

Why is the move to PO hard even from inside a product team?

Because the measure changes. In your current role, your work is judged on correctness: the document is complete and clear, bugs are found, the code runs well. As a PO, the question becomes whether the work the team just did was worth doing, and whether it created the change you expected.

The Scrum Guide 2020 says the PO is accountable for maximising the value of the product resulting from the Scrum Team's work, and for managing the Product Backlog (the ordered list of work for the product). The PO is one person, not a committee. The PO may delegate backlog work, but remains accountable. This is a key difference from BA, QA and development: you do not just contribute to the decision, you answer for it.

In one sentence, the shift is from “do the requirements right” to “choose the work worth doing and own the result”. It sounds simple, but it is hard for a few reasons:

• You are used to someone choosing for you. Work reaches you after someone has already decided it is needed. The choosing happens before you see it.
• Being close to the PO is not the same as doing the PO's job. Sharing meetings and reading the same backlog gives a feeling of understanding the role, but you have not yet had to do the hardest part: choosing and owning the outcome.
• Old strengths turn into blind spots. What made you good in your old role can pull you back into that role once you are a PO.
• Your company may not give you decision rights yet. You need a way to practise deciding without taking over from the current PO.

Scrum.org lists several misconceptions about the PO role, including seeing the PO as just a story writer or a gatekeeper. In this article's view, those two are the nearest traps for BAs and QAs respectively. For developers, the trap is deciding how the work is done on the team's behalf. If the line between PO, PM and BA in your company is unclear, read the comparison of the three roles first, then come back.

• How PO, PM and BA differ

From BA to PO: what carries over and what to add?

A BA is used to clarifying requirements with many parties and rewriting them into something the team can build from. That is a good base for managing a backlog. What to add is the nerve to propose cuts and to choose. For Minh in the opening, a first decision story could start from a request that keeps coming back.

Acceptance criteria (AC) are the conditions that show a story was done right. BAs are used to writing AC, so you start ahead here. What changes is the first question: instead of “have I captured everything”, ask “what changes if we build this, and is it worth doing first”.

• Saying no to stakeholders without losing goodwill

From QA or tester to PO: what carries over and what to add?

A QA looks at the product as a user and thinks about where it can break. Both habits help a PO write testable AC and face fewer surprises after release. What to add is accepting risk selectively and measuring results, not only defects.

One question helps a QA change perspective: “If this feature worked perfectly and nobody used it, would we call it a success?”. The answer is no, and that is exactly the part a PO has to answer for.

• Working with developers when you cannot code

From developer to PO: what carries over and what to add?

A developer understands the system, the data and the technical cost. You spot cheaper options early and talk to Developers naturally. Here “Developers” is the Scrum Guide's term for the people in the Scrum Team who create the usable Increment each sprint, not only those who write code. What to add is stepping back from how the work is done.

Mountain Goat Software draws the line clearly: the PO decides what to build and why, while Developers decide how to build it and how much to take into a sprint. For a former developer this is a hard line to hold, because you know how and may see a faster way. Offer your technical view as a suggestion, then let the team choose. For Tu in the opening, a good problem to take on could be a manual operational step repeated every day, because Tu understands how much time it costs and whether it can be removed.

How can you get PO experience inside your current job?

You do not need to wait for an appointment. The approach this article suggests is to take full ownership of one small problem and follow it through four steps. The key point: you do this with your current PO or manager, not instead of them. They still decide the backlog order. Your part is to bring a problem that is well understood, backed by evidence, and measurable.

Step 1: take a small problem. Look inside your own work. A BA may notice a request that keeps coming back. A QA may notice bug reports that are not bugs but users failing to find a feature. A developer may notice a manual operational step repeated every day. Do not pick something large like “rebuild the whole payment flow”. Pick something small enough that the build fits in about one sprint, or that you can test manually.

Step 2: talk to the people who face it. Meet or call 3 to 5 people. Ask about the last time it happened, what they did, and how long it took. Avoid asking “would you like feature X”, because that question tends to get a polite answer rather than the truth.

Step 3: write a one-page document. State the problem in one sentence, the evidence you have, two or three options with the cost of each, your recommended option, and how you will measure it. Give it to your PO, one person who builds and one person who tests. The questions they ask are the most valuable part of the learning.

Step 4: measure and tell it. Record the measure before the change, then measure again after a fixed period. Note anything other than your change that could have moved the number. Finally, write the whole thing up as a short story using the template below.

• The one-page requirements document
• What to ask in user interviews
• Measuring a feature after launch

Example: a QA follows one small problem end to end

Back to Linh, the QA on the spa booking app “Hen Xinh”. This is an illustrative example: the name and all numbers are assumptions, there to show the method.

Step 1. Linh notices many bug reports from support with the same content: salon staff “cannot change an appointment time”. On checking, the feature works. The “Change time” button sits inside a three-dot menu that many people miss. Linh counts the last three weeks of tickets: about 12 per week on changing times, on average (assumed number). Linh talks to the PO before doing anything else.

Step 2. Linh calls 4 salon staff. All 4 describe the same thing: when a customer asks to move a booking, they open the appointment details and look for a button there. When they cannot find it, they cancel and create a new booking, or call support.

Step 3. Linh's one-page document has three options. One: send salons a how-to guide, almost no build effort, but new staff may still stumble. Two: move the “Change time” button onto the appointment details screen, which a developer estimates at 1 to 2 days. Three: allow drag and drop on the weekly calendar, several days of work and a risk of double bookings. Linh recommends option two, plus sending the guide in the meantime. The PO agrees and schedules it for the next sprint, which falls in weeks 4 and 5 of Linh's plan.

Step 4. In week 6 Linh takes the first measure, then keeps measuring until two full weeks after release, slightly past the six-week mark. Two weeks after release, tickets on changing times average about 4 per week (assumed number). Linh also checks the number of appointments in those two weeks and finds it similar to the previous three, so the drop is unlikely to come from quieter salons. Linh still notes clearly: only two weeks measured, not yet known whether it holds after a month.

When you tell this story on a CV or in an interview, the wording decides whether you can defend it. The table compares an easy line with a defensible one.

The defensible line sounds more modest but holds up better under follow-up questions. Interviewers may want to know whether you noticed a problem, found evidence, weighed options and measured the result. Linh's story has all four, even though Linh was not the final decision maker.

Templates: a six-week plan and the story of one decision

Use these two templates together. The first is for doing the work, the second for telling it. Copy them and fill them in for your own situation. If the work is not scheduled into a sprint, use week 5 for a manual test or a how-to guide, then measure as usual.

Problem I am taking on: [one sentence: who faces what, and when]
Person who agreed I can follow it: [PO or manager's name]
Time I can give each week: [hours]

Week 1: Collect existing evidence (tickets, messages, data). Record the before measure: [measure, period]. Get agreement from [name].
Week 2: Talk to 3 to 5 people who face the problem. Ask about the last time it happened, what they did, how long it took.
Week 3: Write a one-page document: problem, evidence, 2 to 3 options with costs, recommended option, how to measure. Send it to the PO, one person who builds and one person who tests.
Week 4: Revise the document based on their questions. Agree the smallest scope and the done criteria with the PO.
Week 5: Follow the work through build, test and release in the scheduled sprint (the sprint may start in week 4), or run a manual test. Note anything that comes up.
Week 6: Take the first measure after release. Compare with the before measure. Note anything else that could have moved the number. Draft the story using the one-decision template.
After week 6: Keep measuring until [chosen measurement period] is over, then update the story with the final number.

When to stop early: [e.g. the PO decides not to do it, or the problem goes away]. If you stop, still write down what you learned.

Context: [product, users, my role at the time]
Problem: [who faced what, and when]
Evidence: [data, how many people I spoke to, what they said]
Options considered:
1. [option] - cost: [effort, time, risk]
2. [option] - cost: [...]
3. [option] - cost: [...]
Decision: [chosen option and why]
What I did: [work I did directly]
What others did or decided: [who, what]
Result: [before measure] -> [after measure], over [period]
What I am unsure about: [other factors, short measurement period]
If I did it again, I would: [one thing I would change]

When you use the second template to prepare for interviews, ask yourself two likely questions in advance: “What would you have done if the PO had said no?” and “How do you know the result came from this change?”. Answer honestly, even when the answer is “I am not sure yet, and this is how I would check”.

Common mistakes when moving from BA, QA or developer to PO

• Waiting to be appointed before starting. Without a decision story, the new title is hard to reach. One small problem followed all the way through gives you a story to tell, which theory alone cannot give.
• Taking over from the current PO. Going straight to stakeholders with promises, or reordering the backlog yourself, can quickly cost you trust. Bring evidence and options to the PO, and let the PO decide.
• Choosing a problem that is too big. A big problem runs for months and depends on many people, so you rarely get to the point of measuring the result.
• Measuring by work completed. “Ticket closed” or “released” is output, not a result. Measure what changed for users or for operations.
• Overclaiming your part. Claiming the whole team's work, or quoting a number without its measurement period, shows up at the second interview question.
• Dropping your old strengths entirely. You do not need to forget how to write AC, think about failures or estimate cost. Just put them after the question “is this worth doing”.

• The first 30 days as a Product Owner

Summary

• Moving to PO means going from “do the requirements right” to “choose the work worth doing and own the result”.
• BAs bring the ability to clarify requirements and need to practise proposing cuts and choosing a priority order. QAs bring a risk mindset and need to practise measuring results and accepting risk selectively. Developers bring technical understanding and need to practise letting the team decide how.
• Build experience with one small problem: take it on with your PO's or manager's agreement, talk to the people who face it, write a one-page document, measure and tell the story.
• On a CV, keep your real title, separate what you did from what others decided, and give numbers with their measurement period and what is still uncertain.
• Once you have the PO role, “The first 30 days as a Product Owner” helps you through the first month.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

• Get new articles by email

Frequently asked questions

What does a BA, QA or developer need to learn to become a Product Owner?

The gap is similar for all three: choosing which work is worth doing first, talking to users directly, measuring results after release and owning that choice. Existing strengths such as clarifying requirements, thinking about risk or understanding technical cost still help, as long as they do not replace making the decision.

How can I get Product Owner experience without the PO title?

Take one small problem in your current job once your PO or manager agrees, talk to the people who face it, write a one-page document with options and their costs, then measure the result and tell the story. For a small problem, one such round can fit in about six weeks, with measuring continuing after that.

How do I put PO experience on my CV if I have not been a PO?

Keep your real job title, then describe one piece of work you followed from problem to result, separating what you did from what others decided. Give any number with the period it covers and what you are unsure about, so you can defend it when asked.

Sources to check

• Scrum Guide 2020: Product Owner
• Scrum.org: What is a Product Owner?
• Mountain Goat Software: Product Owner Role and Responsibilities

Related articles

• PO vs PM vs BA: what is the difference?: How PO, PM and BA really differ, how the lines move between outsourcing firms, product companies and startups in Vietnam, and how to read a job description to see which role it actually is.
• Your first 30 days as a Product Owner: what to do each week: A four-week plan for a new PO: listen and map, understand users and metrics, own a small slice of the backlog, then make a first decision and agree expectations with your manager.
• Can you be a Product Owner without coding?: A PO does not need to write code, but does need enough technical literacy to ask good questions, respect the Developers' ownership of “how”, and talk about trade-offs clearly.
• Product Owner interview questions: answer with real situations: The kinds of questions in a PO interview, how to answer with a concrete situation, what to do when you do not know, and what to ask the interviewer.