All Product Owners have one shared goal: create a successful product. But while designers plan the experience and interface of the product, developers build the product, and testers ensure the quality of the product, the role of the Product Owner is much less easily defined. It’s a role that’s multifaceted, deeply integrated with the team it serves, and comes with a constantly shifting array of responsibilities.
As a new Product Owner, I wanted to know what those people thought made a great PO, and how I could use my role to facilitate theirs. So I asked engineers and designers from around the office at TAB, and here are three things that they said great POs do.
Understand the User
You can’t build a great product without knowing who you’re building it for. Jason Turner, Lead Designer at TAB, says that the difference between successful and unsuccessful products is that successful products get out to an audience early, experiment, and fail fast. They work hard to find out what problem they’re solving, and who for. Unsuccessful products are often someone’s big dreams, opinion-driven and not backed up with data.
A good product will not only keep the user’s interests at its core, but will also try to understand what’s in their heads. To consider how people approach and try to solve problems requires a level of empathy that affects both the design and build of the product. Even when building a backend product with no User Interface, TAB Backend Engineer Andrew McCafferty says that, "If I can think of something that could go catastrophically wrong, I’ll think of it in terms of how this is going to impact a person."
Having empathy for the user also allows a great Product Owner to define value. In these cases, Ben Pitman, Tech Lead, points out that unfortunately sometimes value isn’t measured at all, and only cost is tracked. When this happens, it’s not unheard of for measures to be taken that optimise towards creating more cost rather than value. Aligning stakeholders towards creating value is really important, and for this reason understanding the user can be converted into big wins for the business.
Elevate the Team
Many people assume that the day-to-day role of a Product Owner involves writing user stories, attending meetings, and managing the product backlog. But it is more than that, it also means being at the centre of a team who, when it comes down to it, need you to help support them, enabling them to perform at their best by showing that you care, and creating the right environment needed to perform to their highest ability.
A big part of this is to understand the blockers and waste that could impede each story, and to remove as much of it as possible. Ensuring that stories have met a clear Definition of Ready, the working agreement amongst the team of what readiness looks like, before they are picked up by development can reduce inefficiencies, such as context switching. "The cost of context switching can be so high. In my previous job before TAB I was being interrupted so much, I couldn’t even bring myself to start coding," says Ben. "It’s partly because developers care so much and want to deliver good quality, so helping set up a team that achieves the balance of very short feedback loops while also optimising uninterrupted time is often very difficult and requires good understanding of both sides."
And don’t forget that talented designers and engineers are not just building your product, they’re also managing their careers. As they move up in seniority that means taking on more responsibility, such as managing other designers or engineers and supporting their teams in other ways. Jon Hocking, Lead iOS Engineer, points out that this increased responsibility can at times result in more context switching and reduced efficiency. "It’s really helpful when a Product Owner can take a step back and be able to help the team use their time more efficiently rather than just expecting them to know," he says. Caring deeply enough about people to understand their goals and help manage their daily tasks will allow them to do the things only they can do, like share their working knowledge. Not only will they have more capacity to produce high quality work, but they’ll also be investing in the individuals who are coming up behind them and increasing the overall strength of the team.
Tell the Story
Ultimately the Product Owner owns the "why" of a product-- a subject that Simon Sinek wrote an entire book about: Start With Why. This takes more than knowing why a particular product is being built, it also means being able to communicate this and bring stakeholders on the journey with you. "Your product has got to be fulfilling a need and has got to have a clear outcome. The team has to get behind that outcome, and if they don’t it doesn’t matter what kind of cool technology you’re using," says Paul Coletti, Lead Test Engineer. "If they don’t believe in the product, you’re probably going to find you’re moving quite slowly."
Great Product Owners will also use the "why" as a tool. After spending a year, or more, on the same product, Jon points out that it’s easy for an engineer to get caught up in the individual stories he or she is working on. This can result in that person going through the dip-- when motivation, and possibly also productivity, drops. "The more POs that can help engineers find a way to put their own stamp on what they’re working on, the more motivated they’ll be," he says. That’s where it helps to retell the story and zoom back out beyond the individual user stories to the bigger picture, the vision of the product as a whole. This can help get more members of the team involved in key product decisions, thereby increasing morale and creating a sense of shared ownership for the product. The team may also have additional ideas for quick wins or different ways of doing things, such as using native components, that will enhance user experience and be quicker to build.
It’s having clear sight of the whole-- the whole user, the whole team, and the whole story-- and working with them all effectively, that makes a Product Owner truly great.