Did you just land a dream job as a Product Owner? Are you waking up each morning thinking about how to plan for a successful start?
In this post, I'll give you some practical advice on what questions to focus on, some tricks that can speed up your integration, and my two cents on approaching this role.
I've worked with companies in various geographies and different company sizes, from startups to Fortune 500 companies, and want to share some of the good practices I picked up along the way that will give you a jump-start in your new role.
With that said, let's jump right into the practicalities.
Table of contents
Ask Your Superior to Introduce You to the Company Employees
Controlling the narrative about yourself can save you a great deal of time. Starting with authority within the new company instead of spending time building it can make a huge difference.
Internal marketing and positioning yourself are critical as there is no second chance for a first impression. This can make a crucial difference in how your stakeholders perceive and interact with you. You must be, at all times, aware of which responsibility belongs to the product owner in the team and use that knowledge to make a statement about your product owner position.
Sometimes our Superiors are busy and forget that sharing your story and why they have hired you can save time. This is especially true if your Superior is a trusted and likable person.
Practical advice:
- Ask your Superior if there is a practice of introducing new employees. Have a pre-prepared picture and a few paragraphs about yourself and your role.
- Here's an example: “Let's welcome Zoe to the company. We believe her experience can help us move our webshop in a new direction and can establish double digits growth in the years to come.” This clearly portrays a metric of your past success and the expectation towards you within the company.
Build Relationships
Being a Product Owner is all about relationships. It's about understanding the whole ecosystem, user needs, team capabilities, technical debt, and strategy of the company. It's about becoming a domain expert and making sound decisions based on user data and needs. To do so, start by talking to the relevant people in the company.
Practical advice:
- Learn who the company's domain expert is so that you can consult on the topic and schedule a 40-minute meeting with them. Use some of the time to bond and the rest to talk about relevant resources you can learn from. This can be dashboards, relevant research done in the past, books they recommend, Twitter/LinkedIn accounts they follow, etc.
- Schedule a series of 20-minute one-to-one meeting sessions with each team member (with a 10-minute break after each to make notes and sort your impressions). Learn about the person, not their tech stack or their responsibilities, but make it a purely person-to-person talk. Consider naming the event "coffee-talk." You want to learn about their education, their motivations, what they like about the company, and their superhero story.
- Schedule two 20-minute coffee talks with your Scrum master. Use the first meeting to get to know them on a personal level. The second meeting can be a reflection meeting. During the reflection meeting, share some of your initial impressions and ask if they find them relevant. You can also ask them to clarify some of the personal dynamics within the company. If there's a Product Manager on the team, schedule a meeting with them as well.
- At the end of the week, schedule a meeting with your Superior to get some insights about the metrics you will be measured against and the short-term goals they have envisioned.
Understand the Tooling
Another important thing when joining a company as a Product Owner is to understand the toolings the company heavily relies on. This is also one of the primary product owner roles and responsibilities.
For example, the team might be using a tool like Confluence as a single point of truth. To prosper in your role, you must learn how the team uses such tools. If you're unacquainted with these tools or are a bit rusty, there are some things you can do to get up to speed.
Practical advice:
- Ask your Superior to set up a meeting between you and the Scrum Master or some other relevant team member to inform you about the tooling within the company. The meeting can be hands-on during which the team-mate will guide you through the tools and how they are used.
- If you think the team should be using a certain tool, discuss it openly. Instead of saying, "Why aren't you using Google analytics?”, say, "Are you using some analytics tool for acquiring quantitative user data?”
- If the team is using a certain tool like Matomo, for example, but you think that Google Analytics is better, take a moment to compare the two tools and see which one is a better fit for the team.
- Most companies will be using Confluence or similar Collaborative Knowledge Workspace (maybe Notion). Once you get the equipment, create a personal Workspace where you can experiment with the different plugins they are using. Copy some pages you like from the company workspace into yours and play around to learn how to set them up yourself in the future.
Understand the Process
Usually, Scrum will be the keyword you have seen on the job ad, but the additional flavors are what matters now. Schedule another 80-minute meeting with your Scrum Master to discuss:
- The Process: Is your team part of a Scaled Scrum setup, and if so, what are the rules? Which other teams do we have high dependencies with? Are there any team metrics? What is the User Story style used so far? How is the estimation done? Are there any existing roadmaps for our team or for the related teams? Is there anything that should be improved within the process with you onboard?
- Dev practices: How is the branching organized? Are there unit tests? Is there CI/CD? Is there specific team expertise that makes certain people have to work on certain tasks? How long is the waiting time for code reviews? Is there any known technical debt?
- QA practices: How is the QA developer process organized? How many environments are there? Is the testing process embedded in the development process, or is it following it? Are there any ideas on how to improve it that you should know? What is the code coverage? Where did we have the most bugs in the past few Sprints, and why? How can I run the AQA tests myself?
- KPIs: Are there OKRs? What are the KPIs measured so far? What is tooling for metrics? What are the trends of the KPIs so far?
Understand the Customer Lifecycle and Needs
To understand the customer lifestyle, ask if you could work alongside a Customer Support person for a day or so. Besides knowing where to get the qualitative data, customer support agents can give you the much-needed qualitative data which can make a big difference in understanding the trends.
Use Your Fresh Eyes
Listen carefully. Think about everything you would do differently. Be careful which of your impressions you are going to share early on. Take notes in a document that you can review at a later time and enrich it with new data and insights—something like a personal diary with topics you find relevant. A fresh eyes perspective is important for the organization but presenting yourself in a positive light is critical. So, once you feel settled and have established good relationships, start probing those questions one by one.
Make a Shareholders Map
Understanding your Stakeholders and establishing good communication channels with them is critical.
Ask them openly:
- How do they prefer to communicate?
- What are their short-term expectations from you?
- What metrics are important to them?
- What is important to them in the long run?
Maybe do not explicitly ask but think: what small win can you deliver to kick off your collaboration in the right direction?
Enroll and Introduce
Join the relevant communities of practice, such as Slack channels, Yummer, or another group communication channel. Introduce yourself everywhere. Be polite but noticeable. People need to remember there is a new person in town they can ask for help.
When I joined the TeamViewer Platform team, I learned there are many more Stakeholders than I thought initially just by attending community and practice meetings and introducing myself.
To Sum Up: Enjoy the Ride
All in all, one of the best product owner tips I can think of is to try to leave out the stress of the unknown and enjoy your new experience.
Imagine how nice it would be to watch your favorite movie for the first time. Doing some things for the first time can bring unique joy. Embrace the unknown and enjoy the ride!
You may notice I did not write much about going through the backlogs and refining PBIs. I did not mention anything about the Scrum Ceremonies. That's because you'll be just a passive member in those first few weeks.
Being a Product Owner is mostly about managing expectations. Nobody expects you to deliver in the first week, so use it wisely to understand how to navigate within the company first.
But what happens after the first few weeks in your new role?
You should start with small wins!
Nobody expects you to make tectonic changes right off the bat. Listen carefully to people's problems and help them overcome these problems by delivering small wins. By doing so, you can establish the first tokens of trust, which are essential for your growth and success within the company.
As my philosophy professor liked to say:
"Just go out and play!"
