Is That on Me?

An ice-cream fallen on the ground

Let’s do a short one today guys. Today I’d like to touch on how I see the product manager’s accountability.

There is a lot of confusion out there as for what you are responsible for, what you are accountable for and where your ownership starts and ends.

 

I’ll try to make some order here while providing my personal perspective, which may not necessarily be the popular convention.

Let’s start with the definitions. I will take non-formal and more practical approach here:

Responsibility

Under responsibility falls:

  1. Your duties
  2. Your tasks
  3. Some business processes you own per your agreement with your boss

You are responsible for taking care of your duties on time. You are responsible for completing and delivering your tasks on time. You are responsible for overseeing the business processes assigned to you, making sure they take place and making sure to resolve any blockers.

We’ll get to specifics in a minute.

 

Accountability

Under accountability falls:

  1. Your decisions and their results
  2. Fixing bad outcomes

 

Hence, accountability is more about taking ownership of outcomes and how to deal with them, while responsibility is more about taking ownership of ongoing processes.

Here is a more formal paragraph about the difference between the two (taken from Eagle’s Flight here):

Responsibility focuses on defined roles, job descriptions, and processes that must be in place to achieve a goal. On the contrary, accountability is committed to the successful completion of tasks assigned to you and being willing to take responsibility for everything that happens as a result of the actions that were taken.

 

The responsibilities of a product manager

If you are not (yet) a product leader, but “merely” a product manager then most likely your responsibilities include:

  1. Attending dailys or taking any other active role in your agile processes
  2. Resolving priority conflicts
  3. Writing product specifications (PRDs), reviewing them and handing them over to the engineering
  4. Gathering market feedback, including meeting with customers
  5. Knowing the market you are operating in and the competitive landscape
  6. Orchestrating the product delivery process (see here) for the features you own
  7. Assisting with the quarterly planning

I guess we could always add more to this list, but I believe those are the major ones.

If you are also a product leader, then you can add to this list:

  1. Working on the roadmap
  2. Working on the product strategy
  3. Shaping up the north star and the major KPIs

 

What are you accountable for?

Given your responsibilities – there are many decisions you need to make each day and those decisions have consequences. You own your decisions and their consequences.

Hence, you are accountable for any results of the following decisions:

  1. Any priority decision you made and its consequences
  2. Any spec you’ve written, and specifically what you decided that it must include, and what you decided to omit.
  3. Any item that made it to the quarterly plan and any item you decided to de-prioritize
  4. Any item that made it to the roadmap and the stage when you decided it should be worked on
  5. The strategy you came up with and what that will happen if it was followed-through
  6. The north-star and the other KPIs you convinced everyone to follow and prioritize their own work according to
  7. Any market signals you’ve missed and not acted upon

I guess I missed a bullet or two – but again – I believe those are the major ones.

As you can see – your plate is full when it comes to responsibilities and accountability.

What happens when one of my decisions turns out to be wrong?

First – relax! It happens to everyone, no matter how experienced they are. Part of this job is to experiment, so by the nature of experiments – some will surely fail. But regardless of experiments – everyone makes mistakes.

That being said – true accountability means you need to fix this!

So make sure you identify your mistakes early on, by basing your observations on real data and market signals. Act immediately to solve those.

You released a feature that no one is using? Reach out to customers and check why. Did you misidentified the market need? Then kill the feature. Did you identify the market properly but the users didn’t understand how to use it? Make it simpler.

The thing to focus here is that you need to identify the error and come up with the remedy. Things will become worse if anyone else in your organization, or even worse – a customer – will complain and expose the error in front of everyone.

 

Sometimes, though – things are taking their time before it’s clear if a decision was right or not. In fact – the ‘higher’ your decision here – the more time it will probably take before you and everyone else will realize it was wrong.

For instance, focusing on the wrong KPIs or coming up with the wrong strategy may become an obvious mistake only after a few months. Therefore, if you are responsible for such decisions – make sure you check the market pulse and the health of your business very often!

But anyway – this post is not about how to perfect your decisions, but rather about understanding what you need in general when things go wrong.

 

What you don’t own

There is some good news! You don’t own everything.

Although some people in your organization will try to drop it on you – you need to push away accountability that doesn’t belong to you.

Yeah.. I know… it doesn’t sound too popular. All managers want people to have ‘total ownership’ or ‘total accountability’ but I don’t believe in this.

For example – let’s say you properly listened to your customers, wrote a very good & clear spec but then the development team takes twice the time they estimated that the feature will take – is it on you? I don’t think so (unless you surprise them with new requirements). Why? Because it’s totally out of your control and it’s not a consequence of any of your decisions.

It doesn’t mean you don’t care. Of course you do. I also encourage you to get out of the box and assist the development team in any way you can (remember guideline #1 – you are all in the same boat). However – don’t take on yourself the fallout of such occurrences. Because if you do – eventually it will stain your reputation, even though you made no bad call.

 

So when figuring out where the line is drawn – ask yourself – is there a better decision I could make that would result in better outcomes? If the answer is ‘yes’ – then you own part of the consequences and you’ll need to fix it and improve on that. However, if you are honest with yourself and the answer is ‘no’ – then you are not accountable. Again – you are still part of the team – so you need to do everything you can to help them recover – but you don’t own this mess.

 

That wraps up the post for today.

If you found this post/series useful – let me know in the comments. If you think others can benefit from it – feel free to share it with them.

Thank you, and until next time 🙂

Liked it? Why not share it?
Scroll to Top