The Life of the Product Owner
Life is a funny thing; I fell into a product manager role several years ago and, in the process, inherited the role of product owner (PO). As of late, I have found myself providing guidance on what it means to be a product owner to various organizations of different sizes and products. The common theme seems to be around what it takes to tackle this role.
There are lots of different articles out there about being a product owner; some things in this blog post may overlap, and some may not. My intent is to share knowledge (i.e., show battle scars) from my past experiences.
If you have found yourself with a newly minted role of “product owner”, you need that role in your company, and/or have inherited one and don’t know where to start, this blog post is for you. If you are not new to the role, please comment on the post and add your own thoughts and personal experiences…I promise you it is time well spent and only enhances the journey of others.
Defining “Product Owner”
Caveat: I could take an entire blog post talking about who should own the role of product owner vs. it being a position (with the PO title).
Here is my condensed stance: The PO is a role. If you have a product management team, this role is often filled by the lead product manager (PM) (i.e., the one responsible for a product). If you don’t have product management, this role is often filled by the person with the most customer knowledge, vision, and ability/authority to make decisions.
The standard “Product Owner” definition is “the one who is accountable for maximizing the value of the product resulting from the work of the Scrum Team.” The “Product Manager” definition is a “person who is responsible for the product’s strategy, roadmap, features, and success through its lifecycle.”
From a true Scrum standpoint, the PO is more tactical and the PM is more strategic. If you don’t have a PM, the PO is responsible for the strategic and tactical product work. In this blog post, I assume that there is no PM in the picture.
What to Know as a New Product Owner
When I first started out as a product manager, one of my mentors told me (repeatedly) that the role of the PO is to “prioritize the backlog and say what “done” looks like. When defining a PO in a pinch, I still repeat these words to this day. When you dive deeper though, there are a few more things that the PO should know to be successful. So, in addition to “prioritize the backlog and say what done looks like,” here are four things that can help guide you as a new PO or give you an idea of the value the PO brings:
Acceptance. This one may seem like a no-brainer, but it’s important. The PO is critical to a project or product. They need to know what the role is, embrace it, and charge forward. I have seen this role be assigned to people with little to no interest (or time) and, in turn, don’t fully accept it. This can be disastrous.
As a PO, people will be looking to you for decisions. This goes hand in hand with “prioritizing the backlog and saying what done looks like.” You are the person. Be ready because lots of questions will be coming your way. You are a key decision maker, maybe THE decision maker. When decisions aren’t made, people will make guesses or assumptions. Often, these will be wrong. Wrong costs time and money.
In short, accept that this is your role, embrace it, and keep your focus looking forward while having a steady foot in the present.
Time. Make no mistake, serving as a PO is a time commitment. The PO’s involvement should be seen throughout the entire Software Development Lifecycle (SDLC): Discovery, Detailed Design, Development, Quality Assurance (QA), and Release. The time that the PO puts in pays dividends. It also works in reverse. Without the proper time commitment, the delivery team and product will suffer. This may result in costly rework, missed deadlines, and/or product delivery that does not meet the needs of the market/end user.
A few key areas during the SDLC to help you know what needs your attention:
- Discovery. The PO works in the trenches with the architect, UX designer, and project manager (and product manager if the PO is not one and the same). This is a collaborative effort to define the user goals and scope (i.e., what done looks like). The design and requirements process can vary from team to team, but the PO should be reviewing and approving those artifacts. This phase may also include user testing, which should involve the PO.
Time commitment. Plan to spend more time here. The amount of time will vary depending on how much Discovery needs to be done. A single feature? Maybe a day to two days. A new product could take weeks or months. One thing to keep in mind: this time investment is worth it. You will spend less time in the future phases because of it. From a cost perspective, it is less expensive to iterate in Discovery (design) than it is to do in code.
- Detailed Design/Development. Not every development team does Detailed Design. Because of this, I have lumped these two activities together. Engineers will have questions; the PO is the perfect person to ask those questions too. Often, the engineer may not have several days to wait; they may only have hours. If they wait, things could get delayed, or they will make the decision to get it out the door, and it may not be what you want. Know when the development team is working on your items, be prepared for questions, and make time to answer them.
Time commitment. Even if you were thorough in your discovery/design process, you will still have questions in this phase. Depending on the size of the scope, this could be an hour to a few hours. The less time you spend on Discovery, the more time you will spend in this area.
- Quality Assurance (QA). QA is like development. They will have questions on how something is supposed to work. When these questions come up, they may be asking you. If the requirements and/or design are not clear, they will ask you. If something changes in development and is not tracked, they will probably ask you about the correct implementation.
QA should also not be the only ones testing the feature/product. The PO is in a great position to test. They understand the business objectives and the use cases. Work with QA on the best way to document anything you find while testing. Some QA folks may want you to send everything to them to deconflict what they have already written up; others may ask you to enter the bugs directly into your backlog tool.
Time commitment. Plan on testing your feature and product. Take notes and snag screenshots of things you find that must be addressed. This will help you communicate the changes to the team (development, design, QA). Time will vary depending on the scope and time spent in the other areas.
- Release. As the PO, you could be asked to describe the features being released for a release email, marketing, or training materials. You may be the one who needs to send out release emails to users. User feedback is typically collected via a variety of channels. If you don’t have a Product Manager (or if you are the PM), tracking the feedback and moving things back into the SDLC process could also be within your area of responsibility.
Time Commitment. Release is the second largest time commitment in the SDLC. Depending on your involvement with marketing, sales, and end users, it could even be more. If you have great access to users, this is a wonderful opportunity to assess product-market fit, an area worth spending extra time on. Depending on the size of the scope and the different areas you are involved in, this could take a day or weeks.
Tradeoffs. The product owner will eat, sleep, and breathe tradeoffs. There are two main tradeoffs to be aware of: business tradeoffs and technical tradeoffs.
- Business tradeoffs: there is not enough time in the day to get everything done. Often, the PO may have a list of 10 critical things, but when it comes down to placing those in a project plan (considering resources, complexity, and level of effort), maybe half of them can be accomplished. Knowing which items have priority and the most business value will be important. A prioritized backlog can help you make these decisions, so can RICE scoring.
- Technical tradeoffs: the architect or development lead will probably ask you questions about different ways to implement aspects of your feature(s). Questions could look like, “Hey, we could implement this part of the feature in three different ways. Which way should we implement it?” Chances are the engineer is also providing you with their recommendation, but it may not align with the user’s goals. Great questions to ask as you are trying to decide which direction to take include:
- If options were not provided, ask to know what your options are.
- What is the cost (time and budget) for each option?
- Which option most aligns with the user goals? Is there anything within those options that will change the expected outcome of those goals?
- If the options presented do not meet the user goal needs, work with the architect so they understand the intent and see if there is another option that could be leveraged.
Regardless of the tradeoff, it is up to you to work with your teams to make the decision.
Alignment. Finally, alignment. If you didn’t notice from the above, the PO plays a key role in understanding the user needs/market, communicating those needs with the team building the product (product, UX, development, QA), and providing direction during that process. Some POs could even be the ones communicating the overall product vision (if you do not have a Product Manager).
Teams do their best when they know the direction they are headed, their objectives, and when change needs to happen. The PO is the guide and final stop (in most cases).
Keep open channels of communication with your teams, set the vision and direction early, work to maintain touchpoints through the entire process, and don’t be afraid to course-correct teams if needed. Lastly, if the direction is clear, your team will have your back, advising you if something needs your attention before you even notice it does.
The life of a product owner is full of constant learnings, and it can be a very fulfilling and chaotic role. Hopefully, this provides you with some guidance, confirms some things for you, or spurs some additional thoughts that can be shared.
