Product Management Part 2: Mastering the Product Role
Product is the connector between business and technology. In addition to the roles and responsibilities of doing the core job, there are a few differentiating factors that can make a good product owner a great one.
As a continuance from my previous article, Product Management: Navigating the Product Role, there are key areas that a great product owner really understands:
Stakeholders
Stakeholders should be viewed as those benefiting and/or impacted by what you are building. There are set stakeholders identified, usually by the business, but as a product owner, you should be able to identify additional stakeholders to account for the full picture. That includes those who may be impacted, not just those who are benefitting from the product or experience. Communications teams could be a stakeholder, as they will help implement, train or announce what you are working on. Analytics could be a stakeholder, as the work could affect tracking or reporting. Teams who run tests (usually optimization or analytics teams) could be a stakeholder, as they may want to test and learn in the experience or functionality you are working on.
A user should always be a stakeholder, but may not be a formally identified stakeholder. I’ve always worked on incorporating anecdotal or formal user research to ensure I am understanding how the product is actually used. That could look like doing a side by side with an actual user in a sales channel, or looking at the analytics dashboard to see what the behavior looks like, or conducting user research, or replaying an experience to see how a user interacts with the experience. At times that has lead to working on features that no one else had thought of, but was something the user truly needed thanks to giving the user a seat at the table.
Having the proper and full list of stakeholders gives you a comprehensive view of all the needs and all the impacts and dependencies of the experience you are working on and will set you up for success in a product role.
Design
Design will likely be a big part of the working process, especially when you are working on front end products or experiences. It is a key part of the trifecta in the space: product, design, engineering. But understanding design, what they think of and what they ask about, will help you be a better product owner. While it may be a step in the process, you could bring design into more parts of the process to fully think through the impacts on the user experience. I think design is often overlooked, as they are brought in a bit late and may work in a silo. If you bring in designers earlier on, as more of a consultation than an actual design ask, you can understand the impacts to the front end experience better, you could simplify something visually that will improve the experience and it will make it easier for them to produce a seamless, cohesive, applicable design later in the process as well with the context they gain. By doing so, design will start to be aware of the impacts of their ideas and designs on the the front end code, and the engineers will also understand how their solutions may impact the user experience.
Experience
Experience in other areas helps you identify better with the stakeholders, so you can truly represent or identify with your stakeholders. I have experience in the MarTech product space, but I’ve also done marketing strategy (marketing), I’ve done analytics (data science), I’ve worked closely with a design team (design/ux), I’ve managed a budget (finance) so I can really speak the language of those respective teams and stakeholders. By having that experience, when I work on the tech stack that powers the marketing function, I can understand the needs of the teams and where they are coming from because I’ve been in their shoes before. Not only that, but the real differentiating factor here is to anticipate the needs or requirements from those areas that you’ve worked in before. That makes a truly successful product owner.
领英推荐
Details
Product owners need to be very detail oriented. As part of the Software Development Life Cycle (SDLC), a product owner documents the high level requirements (Epics) and has to break it down into smaller pieces (features, user stories), including the definition of done (acceptance criteria). By doing so, the product owner needs to not only document everything related to the high level requirements, but also understand all the little pieces that it will take to get that larger effort done and what ‘done’ looks like (including what it doesn’t look like). This requires the ability to think of all the details, break a big task into a bunch of smaller pieces, and the attention to detail to know when something is missing or not. Asking the right questions is a must in order to get into the proper level of detail.
Questions
Asking good questions is really foundational in being a good product owner, but asking the right questions at the right time in the right way can differentiate someone in this role. In order to really understand the stakeholders, what they are asking for, and get to the right level of detail, you do so by asking questions. No one is going to hand you the perfect requirements (if they do, please let me know because I want to meet these rare humans). You need to ask questions to be able to a) understand and b) uncover more, c) find the detail you need and d) uncover the impacts/dependencies that no one is thinking of. Some questions to start with:
What is the impact of getting this done?
Who does this impact?
Who is the user/customer?
How will this change the current experience?
Who will share/implement the change when it’s done?
Who needs to do the work?
How do I know the work is done?
Once you have the basics down, you can focus on the above areas to be really successful in your product role and thrive as a connector and translator between teams making a positive impact on your end user(s) experience.