What is a Product Owner?
A Product Owner (PO) is one of the key members of an Agile development team. The primary responsibilities of a PO is to define the stories, maintain the product backlog and define the length and workload within a sprint.
This role is often combined with that of the Product Manager (PM) but in organisations that clearly delineate between the two it is important to not get confused. The Product Owner is responsible for the sprints and the backlog whereas the Product Manager is responsible for understanding the user needs and creating the product road-map (The PM focuses on the ‘what’ and the ‘why’, the PO focuses on the ‘who’ and ‘how’ – both come together to discuss the ‘when’)
Product Owner salary – A Product Owner is a highly skilled and challenging role. As such it commands a high salary. Those in the UK can expect to pick-up an average of £60,000 working as a Product Owner. For our American readers you can expect to command a much higher salary, the average Product Owner in the USA picks up around $100,000.
With such [relatively] high wages the competition for each role can be fierce. That is why in this post we are going to look at applying for PO jobs, in particular how to handle the interview portion of the application.
Product Owner Interview Tips
Lean heavily on your experience. This applies even if you have never held a PO position before. A Product Owner is responsible for numerous things but primarily ensuring that the right activities are being worked on at the right time (managing the product backlog). You don’t need to have held a PO title previously to have participated in similar activities. Perhaps you have worked in a role before where you had to choose which features to deploy at which time? Or maybe you have instituted changes to processes when there were multiple options available? When answering questions lean heavily into these experiences.
Talk about how important quality is to a firm. Working in a agile fashion is great for pushing out product updates quickly, but often it can result in quality taking a back-seat. Hiring managers will want to see how you balance the need for frequent and rapid deployments with the need to product a high quality product.
Know your audience. You should always research the organisation you are interviewing for. But what people don’t think to do is also research the interviewer and the hiring manager (if these are different persons). You want to impress the person making the hiring decision so you should research them specifically trying to understand what makes them tick and what they are looking for in a new employee.
Pepper your answers with technical terms. Agile deployment has a number of technical terms, processes, systems, tools etc. For example when answering a question you can talk about how your team uses JIRA for defect tracking. Or you might talk about how you used Selenium for automated browser testing. These little things show the interviewer that you are well versed in the area and are not just full of fluff.
How Best To Answer Product Owner Interview Questions
Unless the question you are asked is a straight ‘up or down / yes or no’ style question then you are going to need to learn to describe, expand and elaborate on your answers. The best way of doing this is to follow the B-STAR technique for answering interview questions.
Answers using this method follow the below structure:
B – Belief – What are your thoughts and feelings with regard to the subject matter? – As a Product Owner you should have your own set of processes and management techniques that you tailor to each situation.
S – Situation – What was going on? Briefly explain the scenario that was taking place. – Try not to spend too much time describing the situation. The bulk of your answer needs to be about you and what you did so keep the situation simple to understand and even simpler to describe. Try to make sure the scenario directly relates to one of the responsibilities in the job you are applying for.
T – Task – What was your role in the action? Most of the time it is best that you are taking an active rather than passive role in the encounter – You are going for a Product Owner role (presumably if you are reading this) so the situation you describe should have you involved with overseeing and managing the delivery of a product going to launch.
A – Activity (or action) – What did you do? Detail the steps you took and why you took them. – This should take up the bulk of your time answering the question.
R – Result – How did everything end up? Try to use figures if possible (e.g. 99% of issues were resolved in first instance, End user feedback scores went from 4.3 to 4.8, etc.).
Remember though that the B-STAR technique is descriptive not prescriptive. You do not need to follow this flow strictly, go with what is best for your answers and that will allow you to put your point across and show your experience the best.
What You Should Not Do When Answering Product Owner Questions
Do not avoid the question.
Do not describe a failure (unless specifically asked).
Do not downplay the situation.
Do not overhype the situation.
Do not say you have no experience with the subject matter.
Do not reject the premise of the question.
Do not have a passive role in the situation.
Do not give a one-sentence answer.
Do not overly describe the scenario and miss the action.
Product Owner Interview Question & Answers
“I believe that it’s incredibly difficult to overcome a bad first impression. Because of this I always strive to never make one. That’s why for important meetings, or interviews like this, I make a clear plan of what I want to get from the meeting and outline the steps I need to take to achieve that goal.
So when I received the call about scheduling this interview the first thing I did was research your offices. As you are based in an area of town I am not familiar with I drove by here after work one evening just to make sure I knew the way. I also checked Google Maps to see what the traffic would be like at this time. Nothing worse than being late sitting in traffic after all.
I actually have a contact who works in your finance department, Claire, we were colleagues in the place I am currently working. I reached out to her to see if there was anything she could tell me about the interview process. We had spoken before about the company as a whole and how she talks about the company is one of the reasons I applied.
Following our chat I went through all of my work achievements and made sure they fully encompassed everything I have accomplished in my career.
I’m glad I took the time to prepare as I did because there was a lot of traffic so it was good I knew to expect that. Also talking with Claire helped jog my memory on a project we both worked on a few years back delivering a piece of financial software that I believe your company is in the process of deploying.”
“As Product Owner at X company it was my responsibility to prioritise the backlog of tasks. The way things worked in our organisation was that any stakeholder could raise an item to add to the backlog, then as a team we would discuss in which order it would be best that they were worked and deployed.
Ultimately however the final decision on priority lay with myself.
As you can imagine with so many different areas of the business raises items, each with their own agendas and goals the backlog meetings would often end with a lot of disagreement
One such occasion we had two business areas both asking us to deploy a change to our product and both were asking for the change to be deployed in the next sprint. Unfortunately we only had the dev resource to implement the one change in this cycle.
The backlog call became heated between the two representing colleagues and I was forced to cut the meeting short to let cooler heads prevail.
After the meeting I sat with both colleagues to further understand the urgency behind both changes. Asking them to describe the benefits of the change and also the drawbacks of waiting until the next cycle.
Once I had this information in hand it was clear to me which change would be most beneficial to the business. I invited both colleagues into a meeting where I had compiled the information into a presentation deck with a few charts showing the resources available within the product team and the relative benefits of each change.
Explaining it this way allowed both colleagues to fully appreciate the restrictions that were on my team and also the comparative benefits of each change.
Both colleagues left the meeting happy with the outcome and both changes were pushed into production in the next 2 sprints”
Tell me about a time you were late delivering a piece of work
“I was given the task of producing a spec delivery report for a very important potential client. This was on top of my regular workload but I was happy to pick it up as the client would bring a lot of business to our firm if we were able to secure the contract.
During the week that I had to complete the report a number of unforeseen events happened; my work laptop died, the office I worked in flooded and someone stole my car. It really was one of those weeks!
I knew that I wasn’t going to be able to meet the deadline so I looked at the piece of work that I had been given and the reasons why the firm wanted it. From my conversation with the firm I knew they were more interested in the capacity my team could deliver within each sprint rather than the specifics of the product itself.
So I focused my efforts so that I was working only on the capacity portion of the report. I communicated this with the client and with my colleagues. Everyone seemed largely happy with this and I delivered the report in 2 stages, the first at the agreed upon date and the full report just 2 business days later.
Luckily this delay did not upset the clients and we did bring them onboard. After this fiasco I petitioned the firm to provision VPN access on personal devices (with the relevant security software added) so that if this confluence of events were to repeat I would suffer no downtime…except for the time spent wondering where my car was.”
“I believe that bad news is best delivered in person and discretely, where it is responsible to do so. I don’t particularly relish giving bad news (I suppose not many do) so I often try to resolve the situation in advance so the bad news never needs to be given.
Obviously though that isn’t possible all of the time. For example in a previous role I managed a team of developers working in a agile fashion when word came down from senior management that we were offshoring a large part of our process and this meant layoffs of nearly 40% of the department.
I tried to go to bat for my team and show how our quality and production scores were the highest around and unlikely to be replicated using our offshore colleagues, but the decision had been made and was purely cost driven.
It was my job to determine which members of my team would be let go and which would stay.
We had all joined the department together on the same contract so there was no element of seniority that needed to be accounted for. Instead I devised a balanced scorecard type of approach, ranking each team member against the department’s relevant KPIs (quality, production, skills).
Once I had my list I booked one-on-ones with all of my team members as close together as possible, starting with the colleagues who would be staying. With the colleagues who were being let go I got straight to the point and told them the company would be terminating their contract. I allowed them to ask any questions they wanted and informed them that I would be around for any help they needed in looking for a new role.
During the meetings 2 of the colleagues I wanted to keep informed me that they were planning to leave soon anyway and suggested that they would leave now instead freeing up room for other colleagues to stay.
In the end I had to tell 6 members of my team that they were being let go. They were all understanding of the situation and were grateful that I offered to help them look for new roles.
Going forward if I were to be in the same position I would have gone to the meetings with some open positions that I would recommend the colleagues apply for”
Have You Ever Needed To Change Someone’s Mind?
“We had two options for a supplier; supplier A who we had used before and supplier B who we had not used but who were cheaper. As my target was to reduce costs for our department I thought that we should go with supplier B.
I approached my other colleagues, informally over coffee, to understand more about their concerns with supplier B. Learning that the principal worry was that supplier B was an unknown quantity whereas with supplier A we knew the quality to expect. It was then that I came up with a solution to quell any worries.
I approached supplier B and negotiated for them to provide sample products and also to agree to a trial/probationary contract that could be ended fairly easily should the quality not be up to scratch. Once I had this proposal in hand I went back to my colleagues who were now in agreement that supplier B was the correct option for the company.
With all colleagues in agreement we pitched the idea to the director together, ultimately we went with supplier B and enjoyed a high quality product for a lower price”
“In my current role I use Microsoft Projects extensively for scheduling tasks when working with certain clients. A few months ago I learned that one of our newer clients used Primavera as their preferred PM tool.
Even though the new firm were content that we continue to use Microsoft Projects I thought it would be best to upskill myself on Primavera so that I at least could understand what the client was used to versus what we would be providing.
I started by following some courses on LinkedIn and eventually I asked my employer if they would support me in attaining the certification – which they did.
I passed the qualification on the first go and was able to successfully amend our MS Project reports so that they more closely resembled what the client was used to”
How would you characterize your role as Product Owner? Are you a facilitator, a coach, a manager, a visionary, a tactician, a coordinator, or a “driver?”
What is the purpose of being agile in the first place?
To what extent is the Product Owner a “product manager”?
When was the last time you told a stakeholder “No”? How did you approach this situation, and what was the reason for it?
What “labels” come to your mind when you think of your role as Product Owner?
How do you collaborate with the other Scrum Team members?
What roles would you deem necessary for a cross-functional Scrum Team delivering software?
In what Scrum events shall the Product Owner be participating?
How do you know that you are a good Product Owner?
How do you include user research in the product discovery process?
How would you design a process to handle product ideas from stakeholders and other members of the organization?
At what stage do you involve the Scrum Team in the product discovery process?
How do you determine whether an idea is a worthwhile investment?
How do you avoid misallocating resources on features or products that no one wants?
During which stages are Product Owners participating in planning activities?
Your organization has recently decided to become agile and product-driven. How do you educate your stakeholders about the implications?
How do you organize the collaboration with stakeholders and improve it over time?
How do you communicate with uncooperative stakeholders?
In your opinion, how often should product roadmaps be planned?
Who shall participate in the product roadmap planning?
How much of your time do you spend talking with customers and researching industry trends?
How much time should you spend on Product Backlog refinement?
How would you organize the “refining” process of Product Backlog items?
At what level do you include other team members in the refinement process?
How do you handle bugs and technical debt when many valuable new features are competing for resources?
What shall a good user story look like? What is it structure?
When would you remove a feature?
Do you recommend that a Product Owner shall assign work items to individual members of the Scrum Team?
Tell me about a time you worked well as part of a teamInterview Question: Tell me about a time you worked well as part of a team – Answer Tips
Interview Question: How does your current (or previous) role fit into the organisation’s wider goals? – Answer Tips
Interview Question: Tell me about a time when you have had to make a decision using only limited information? – Answer Tips
Do you have any questions for us?10 Questions To Ask At The End Of An Interview (And 6 That You Shouldn’t!)