A great Product Owner can have a significant impact on the success of a project. For that reason here at TangoCode we place a lot of value on learning from our Product Owners. We determine which of their actions help the team improve performance and which can hinder a team. The better we can prepare our client and Product Owners for their role during a project the more value they can get out of their project, and delivering value is a core priority for us.
To help better prepare new Product Owners we recently interviewed one of our current Product Owners, Mark Weissman. Mark is the Director of Product Strategy for Plan & Spend at Aprimo and the Product Owner for both of our projects with Aprimo. He has been a great P.O. and has, in turn, maximized the value in his projects.
Question 1: How much time (hrs) do you spend on PO activities during the average week?
Mark: I typically spend an average of between 6 and 10 hours a week on PO activities directly related to the product, although beyond that there are also many other related things I am working on like supporting product marketing, sales and helping our customers.
Question 2: Do you have a schedule that you follow each week to stay on top of the project (excluding team meetings), if so how does that schedule look? Ex. Time spent testing or getting users to test, time to review stories, etc.
Mark: I don’t have a strict schedule that I follow each week, although the majority of my story reviews occur one or two days before our refinement meetings, and then most of my testing happens on the last two days of the sprint when they come my way for acceptance testing. I always try to be as responsive as possible around those times of the week because I want to set the team up for success and not hold anything up. My communications with users about testing new features are usually the day or two after our deployments, every two weeks.
Question 3: How are you getting valuable user feedback back from the product every sprint and how do you get that feedback into the next sprint cycle?
Mark: It all starts with making sure that you deliver something of value in every sprint. Even if some of it is just a building block for a later sprint – or it could certainly be a full-fledged feature – you are then able to present users with something they can use and collect feedback from them. It’s always important to have an idea of what you think comes next to keep building on the past accomplishments, but taking that feedback you get and re-thinking or re-shaping your original vision, or sometimes even making a diverging path to adapt to that feedback.
Question 4: How do you control the scope of the project?
Mark: It’s controlled by having both a near-term and a long-term vision, and then properly breaking down the components of the near-term vision into stories that the design, development and QA team can tackle without a lot of risks because the scope is well understood. You can always put in placeholders for items that you know will go beyond the scope and the team may (or may not) choose to address them later.
Question 5: What is your strategy for effectively communicating with the team?
Mark: I always want to communicate at a level and cadence that makes sense for the audience and optimized for the fact that I’m a remote Product Owner, and members of the team are also dispersed themselves. This means several calls a week, but also ad-hoc conversations using Slack and through the comments in JIRA. My rule around deciding which route to take usually centers around the question “Would I want to refer back to this decision or thought process later?”. Then I would make sure it’s posted to JIRA, even if it had started more informally in Slack. If it’s a design review, refinement, sprint review or sprint planning meeting, then, of course, I want to have a conference call and Google Meet session for that.
Question 6: How do you manage the balance of responsibilities between your project and those you have at your company?
Mark: Always a tough challenge, but planning out your day and week and focusing on the typical weekly schedule (that I mentioned earlier) helps a lot. Sometimes things come up unrelated to this project where I have to ask the team to be a bit flexible, but then again that also happens the other way around.
Question 7: What change(s) have you made while working with the TC team, since the start of the project that has yielded the most benefits?
Mark: The most significant positive changes that have occurred have been around acceptance criteria for stories. First, review to make sure the acceptance criteria is well-developed, well-written and meets the goals of the story. Second, performing my PO acceptance testing from the lens of a user who is looking at the most recent features/enhancements and is understanding what value it brings to them, as well as for our company and does it achieve the goals of the feature and the overall sprint. We’ve also started instilling “sprint themes” at times recently, so the team understands the most important overall thing we are trying to achieve in the sprint.
Question 8: Where do you feel the team best supports your role of PO, and where do you think your role could be supported better?
Mark: The whole team right now does a great job of understanding the PO’s role. You always want to get the most out of the team without asking them to take any shortcuts, and we seem to work well together in that respect. We also honestly assess each situation and communicate proactively instead of reactively. One area that could be supported better is utilizing some time from a BA role to do more of the formal use case and acceptance criteria analysis and documentation.
Question 9: How do you ensure that the stories created by the Scrum Master/BA support your vision as PO?
Mark: We almost always decide together what stories we want to create, and if they appear to be getting too large then we’ll ensure that they are broken down in a way that makes sense. I also review the backlog every few weeks to make sure that the stories present there to support the vision I have as the PO.
Question 10: Any other tips or advice you have for other Product Owners.
Mark: Get to know your team and understand their working style!