How should I approach a Product Owner interview test?

Question

I have an interview this week for a PO position and they have set a hypothetical practical exercise where one of their clients is experiencing a problem with their mobiles app and for the candidate to present a suitable solution to improve user experience given various technical constraints. Might you have any advice on how the problem could be approached, such as tools, exercises, deliverables, check-lists, etc?

Ordinarily I would list and prioritize the biggest pain points and business risks, and then work with the team to brainstorm possible solutions and work through each to determine our collective, best approach. From there I'd work through technical feasibility and implementation which would naturally initiate development once we are all happy to go ahead. I think it's safe to say that they are looking for more rigor in the approach and I'm wondering what evidence they may be looking for candidates to demonstrate.

Answer 1

If CodeGnome's comment were a post I'd +1.

Focus on how you are going to understand the customer needs, not the technical solution. Three point/suggestions:

1. Watch Simon Sinek's "Start with Why" TED Talk: This is the mindset a good Product Owner should always be in. You need to understand the "why" of your company to be able to deliver value to your customers.

2. The PO decides "What", while the Dev Team decides "How". The PO's job is to figure out what the end solution needs to be. They don't need to dive into the technical details. Knowing it is valuable; however few dev teams want to be told how to do their job. A good tool here is Jeff Patton's User Story Mapping book.

3. Use Agile Collaboration Frameworks (a.k.a. Innovation Games), by Conteneo. Prune the Product Tree and Buy a Feature are key tools I coach Product Owners on using with their customers and stakeholders. Cities like San Jose can use these tools to build a budget with their community as do many leading Enterprise Software and "Big Business" companies such as Adobe and Transamerica. Do a little reading on how the games work to understand them.

Answer 2

TL;DR

In general, a Product Owner should focus on process, not on technical solutions. Your role on a Scrum Team is to represent the stakeholders or users, and to drive the development of the product, rather than to manage implementation details.

The Product Backlog it a set of high-level deliverables, not a set of specification documents. Don't get caught in the trap of treating user stories or Product Backlog Items as specification documents, or attempting to drive implementation-level details which are the responsibility of the Development Team.

Focus on Process

The Product Owner's job is to work with stakeholders to gather requirements, and with the team to refine user stories. Whether in an interview or in an active role, I'd focus on the methodologies used to gather requirements and build consensus; leave the technical solution alone unless you're specifically being hired for your UX expertise.

Example Process: Theme Screening

For example, you might talk about how you would use a tool like Theme Screening to quickly build consensus about what Product Backlog Items (PBIs) should be prioritized for the project. Consider the following:

In this example, stakeholders should be able to easily compare the relative merits of the Baseline, Embiggening, and Ensmallening themes/epics against one another. Given the right selection criteria, your stakeholders should quickly develop consensus around spending available project resources on the highly-ranked Embiggening theme, and on all the user stories that collectively compose it.

Later on, you will refine whether your Baseline or Ensmallening themes are more important by repeating this process as the project progresses and the Cone of Uncertainty narrows. Stakeholder input should be just as iterative as the product development itself, so this type of ranking process should be an expected practice when a project needs to establish relative rankings for its deliverables.