First-time Product Owner/Manager (Guide 2022)

You are a new or first-time Product Owner, Project Manager, or Product Manager? A new position can indeed be very stressful, especially if it is your first time working in this role. Let’s get you ready for this and see what you can expect from your first 1-2 Weeks and further on.

The title of this guide (First-time Product Owner/Manager (Guide 2022)) suggests already, that it is primarily aiming for people who have probably not worked deep in project management before.
It’s most likely you have previously worked as a business analyst or so-called requirements engineer, or UX designer, or else as a software developer.

No worries! Let’s find out on how you can best get through your First-time Product Owner/Manager in 2022
What to watch out for, what not to do, and how to settle into your new role.

IS THE SCRUM GUIDE THE ANSWER FOR FIRST-TIME PRODUCT OWNERS/MANAGERS?

I’ve done a lot of research on the topic of getting started as a product owner.
Unfortunately, almost all posts and contributions recommend to first internalize the Scrum Guide and learn all the PSPO content. That’s all well and good, and it should be done as preparation.
(Assumed you work with Scrum – very few “Scrum Teams” really work exactly according to this methodology).
However, when you sit in your first team meetings, you realize that empathy, individual concepts, and adapted methods are more in demand than bare theory.
People are dynamic, emotional, and complicated – THAT is not told to you in the Scrum Guide.

Let’s see how it works in real life, and how you can quickly get into your role.
The term product owner comes from the agile framework scrum, but nowadays it is equated with project manager or even product manager in almost all aspects of software development.

This may not always make sense, but it shouldn’t matter to us, because just having a title on a piece of paper doesn’t define our day-to-day professional lives.

Many of us have probably worked in something called scrumban – a mixture of scrum and kanban.

You probably won’t know what to expect in your new team until you start your job.
What you do with it then is crucial for success or failure.

The 2 Scenarios you start in

1. You join a new team, or the team is under construction.
   In this case, you have “the freedom” to design your process the way you want it. You can use the techniques that make the most sense to you and help shape the culture within the team.
   
2. You join an existing team, replacing the current product owner.
   This case is daunting for many first-time product owners.
   You don’t know exactly what is expected of you, you measure yourself against the work of your predecessor, you orient yourself on his processes, without knowing if they were successful or if they performed badly.

In any case, at first, you appear as something like the coordinator, I don’t want to say the boss, even if the scrum guide clearly defines that the product owner is equal to the developer, in reality, it is usually different, and he is first perceived as an authority in the team.

It is expected that you coordinate, distribute tasks, and communicate your vision.

What is the best way to start?

1. Get an overview (or overviews)
2. Craft a strategy
3. Establish consistent communication
4. Master your tools
5. Measure success
6. Ask!

3. Establish consistent communication

This is an important topic that ties in with the idea of team-autonomy and efficiency.
You should consider how you communicate with the team.
This also depends on whether you are a remote team or work on-site in the office.

Depending on how your company is structured, you will have or get some extra tasks as you grow into the product owner role.
This generally leads to your calendar starting to burst at the seams, and you need to figure out a good way to stay as close to the team as possible while still managing your other tasks.

A few practical tips from my experience as a product owner, agile coach, product manager, or whatever you want to call it, that will make your workday easier and help you work effectively.

• No meetings before 10.00
  → The simple reason for this is that I like to start my day productive, and besides my key tasks, I try to prepare for all meetings I have on my calendar for that day.
  On the one hand, this has the big advantage that you can start immediately in meetings, and directly determine a requirement for the outcome of the meeting, which (hopefully) leads to the meeting staying in the timebox for which it was intended.
  On the other hand, we know from experience that meetings often last longer, it is sometimes not so easy to just counter your boss and end a meeting.
  
• Always structure team meetings with an agenda, which you send out beforehand.
  This has the advantage that you can let your developers prepare something.
  Too often I’ve seen people come to meetings simply because they’ve been invited, but they don’t know what the meeting is about. This is of course useless and unproductive.
  Therefore, tell people exactly what you expect from them in the meeting and what the outcome of the meeting will be.
  
• People who have nothing to contribute to the meeting should be able to leave without feeling guilty aka, keep meetings as small as possible.
  How often do you see people sitting in meetings, or sitting there yourself, bored out of their minds, hoping it will be over in a minute because the manager, XY is presenting the team’s OKRS from Honolulu, which doesn’t affect you one bit and which, if you were listening, you will forget as you walk out the door.

Todo: think about how you want to hold meetings and communicate this to your colleagues, they will appreciate knowing exactly what to expect and what to expect when you invite them to an appointment.

Measuring success is not only good for you and how you look in front of your boss, but also for your team to see where you can improve, and as motivation to see what you have accomplished in the last iteration.

As I described in the previous point, you should know tools and methods to serve facts on the table.
Reporting is one method here.

Depending on the project you develop differently, and therefore different OKRs, KPIs, or whatever you want to call it are useful for you.
You can measure velocity if you are working with scrum, cycle-time if it is kanban, and and and.
I will create a separate article for this, especially with values, on which you should optimize.

You can also measure success with praise.
Not every team member is as interested in the numbers you analyze for the project as you are.
For many, if you praise them for their work, it means they are successful.
Appreciate every part of the team’s work, because they are spending their limited time to make your project a success.
Over the time you will find our who in your team needs how much attention and appreciation for their work.
Emphaty will become one of the most important skills to drive over the finish line.