3 simple steps to ace the start of your new product role

Lately, I’ve had discussions with other product people around our roles at our respective companies. One common theme always surfaces. The role and responsibilities of product people can be vastly different in different companies. This is especially true in a non-mature market such as New Zealand.

First of all, different companies may interchangeably use different names for the same product role. A role with product-focused responsibilities, like product strategy & roadmap, might be called Product Manager, Product Owner, or if you want to be fancy Digital Experience Owner. Similarly, a role with more delivery-focused responsibilities, like software releases & backlog management, might be called a Product Owner, Programme Manager or Delivery/Release Manager.

Hence why it’s always quite tricky to pin an exact definition of what a Product Person (I’m using this term to be neutral of whether we’re talking about a PO, a PM, a DEO, or any other acronyms you wanna throw out there) does. The responsibilities of a Product Person would largely depend on your team set up and where the product is within the product lifecycle. I think as a Product Person you have to look at your team setting and ask yourself, how can I bring the most value to this team?

For my team, communication is one of the key areas that we need to improve. This is because my team is remote and there had also been a few personnel changes, while also dealing with a complicated re-platforming project. Consequently, the activities I focus on as the Product Person in the team revolve around writing clear documentation & user stories, and team harmony. This is a stark contrast to what I was accustomed to. During the early stage of the product lifecycle, my responsibilities revolved around customer research and product validation. It’s just that currently, the product and team I’m managing is in the stage where fostering communication is what’s needed from me the most.

As you see, depending on where your team is in its maturity, your main focus may be different. Especially if you are in a small product team like I am.

What I find to be similar after talking to other people and in my 5+ years of being in the product space are the 3 helpful steps one should take when starting in a new product role.

1. Set a 1:1 with people

Boring! I know.

While it doesn’t sound as cool as things like “set your product vision” or “conduct market analysis”, I would argue that this is one of the most, if not the most, important initiative you can do when starting in a new product role and/or team.

As a Product Person you’ll be working closely with different teams and stakeholders. Each one of them would have different goals and perspectives on things. Catching up on a 1:1 basis at the start of your tenure helps build rapport and trust which will definitely assist you down the line. Trust me. I’ve gotten A LOT of help from my successive Tech Leads because of that initial rapport we built at the start.

2. Map your product ecosystem

I’ve been guilty of jumping into the product too fast in the past. Just hit the green light and go! Do this, this, that, and that. This came to bite me in the middle of our delivery timeline as I became overwhelmed with information and got lost in some of the technical conversations.

Pause. Step back. Understand the product and its ecosystem first. What tech stack is the product built with? Is there any limitation? Who are the stakeholders you have to consult with? Illustrate this based on your understanding if there isn’t any existing document. Very often than not, there won’t be any.

This will not only help you understand the playing field, it will also provide you with a point of reference later on.

3. Find or define a responsibility matrix within your team

Everyone knows what’s everyone doing right? Designers design, Engineers write code and Testers test. Nope. It’s not that straight forward during the actual product development process.

Who will make the final call if there was a conflict between the technical and UI designs? How involved should the Product Person be with QA processes or release management? Sure, if you have a mature product team these points will already be clear. However, 90% of the time, I would bet that there are no clear guidelines on who is responsible for what.

My go-to tool to achieve role clarity is the RACI matrix. This matrix gives the team a snapshot of who is involved in each of the product development activities and to what extent. Together with the team, you can discuss and agree to the assignments of each team member.

What the? Where is the essential Product stuff? No roadmap? No customer research? No vision?

All those things are important as well. Critical actually. Although depending on your company and which stage the product is in, those shiny product artifacts might not be as relevant (yet) or at least they have been well established by the business.

The 3 recommendations here are perhaps more on the uncustomary side, especially how they’re not really “product management’ activities per se. However, they would be relevant and helpful regardless of what circumstances your product and team are in.

Do you have any other must-do recommendations? I’d love to hear about it. Let’s chat.