Today we will travel to an ideal world and understand how an ideal company should structure its product organization. I know very few companies which are living up to this ideal structure, but nevertheless – discussing it will assist you on several levels.

For instance:

It will help you understand where you are positioned in terms of scope of responsibility in your organization
It will help you understand where do you want to go in terms of career building
It will help you work with the executive team or your superior to design and build a better product team structure in your company
It will help you get your priorities straight and make it easier on your to execute on your scope of responsibilities

It’s a lot of value packed in one post – so let’s get to it.

The Product Management Spheres of Responsibilities

Below is a layered pyramid of what I call ‘The Product Management Spheres of Responsibilities’. Yeah, I know it looks more like layers, but I prefer to address each layer as a ‘sphere’ because it encompasses a small universe with meaningful implications.

Anyway, this pyramid defines the ideal building blocks of the various responsibilities the product people in your group/business unit/company need to own.

Here it is:

Let’s go briefly over each of these areas of responsibilities and explain what they encompass:

Mission

The ‘Mission’ sphere is actually the company’s mission. Meaning – what the company is here to do. How is it gonna make the world a better place, or what’s the main value proposition of its existence. This sphere is most likely out of your hands, and dictated by the founders or the CEO of the company. From your perspective – this is an axiom that you must adhere to.

Leading KPI / North Star

Right after the company’s mission comes the leading KPI or the north star. Those performance indicators deserve a post of their own (and I promise to do one in the future). They are not exactly the same, but for the scope of this post – we’ll treat them the same way.

In our context – those are the metrics that best reflect whether the company is ‘healthy’ and progressing in the right direction. It could be the ‘gross revenues’, ‘monthly active users’ or whatever metric that encapsulates this information.

It’s not as trivial to come up with as it may first sound, and there may be challenges aligning all the internal stakeholders around it – but nevertheless – it’s crucial to define.

This is usually where the product people kick in. Usually the CPO or the VP product. But sometimes, especially if the organization is small and there is still no product executive – those will be dictated by the CEO.

If you are a product leader and you are joining a company where the leading KPI is not well defined, it’s your job to embark on a dialogue with your CEO and agree on such a metric, even if it’s temporary until the business dynamics are better known to everyone.

Product Strategy

I’ve already touched briefly in the past the basics of product strategy. You can read it here.

Generally speaking, though, it’s a plan of where the product needs to be a year or two from now in order to have the most positive impact on the leading KPI and how to get there.

As you can imagine by now – working on a good product strategy may turn out to be quite challenging if the leading KPI is not well defined.

Who is responsible for the product strategy? Usually the CPO, VP product or the head of product – depending on the company’s size and structure.

In big companies the product strategy may even be a division of its own and in such cases it will be dictated to you (annoying… I know).

Product Roadmap

The roadmap is a tactical deployment of features over a timeline, based on the product strategy. The roadmap is usually a bit shorter in terms of the time-frame it covers (e.g. – 1 or 1.5 years from now).

Since it involves actual features – this is almost always handed over to the product people to figure out and come up with a suggestion.

Depending on the company’s size – there could be several meaningful products that are being worked on concurrently, and each deserves a roadmap of its own.

Who is responsible for the roadmap? Usually the head of product, director of product and it could be even a senior product manager. Again, it all depends on the company’s size and structure.

Quarterly Plan

As the name implies – this is practically a ‘package’ of features that need to be delivered in the upcoming quarter. If the roadmap is well defined – then it should be easier to come up with the quarterly plan, though the resolution we’re looking at here is much more granular.

Meaning – the roadmap will only mention the important features, while the quarterly plan must also include all the features nobody wants to talk about (tech-debt, adding interfaces for other teams, annoying bugs, backlog items that have been postponed indefinitely and so forth).

Hence, the roadmap is usually ‘conflict-free’, clean and nice and the quarterly plan is where all the ‘tension’ and conflicts lie.

This is why product leaders would prefer to hand over the task of coming up with a quarterly plan to their subordinates.

I’ll devote a post in the future on how to properly approach the quarterly plan and we’ll drill down to the many challenges it encompasses.

But anyway – if you are a (senior) product manager, but not a product leader – this will probably be assigned to you.

Hands on

I put under the ‘hands on’ sphere all the daily stuff a product manager who is not a product leader usually needs to deal with. Specifically this includes:

Writing specs and PRDs
Orchestrating the product delivery process (see here) including sprints planning and dailys
Solving conflicts
Other hands on tasks

The sprint planning is extremely important with regard to the responsibility spheres since it supports the quarterly planning and needs to be aligned with it.

So yes, if you are a (senior) product manager – you will need to deal with all of that. Also if you are in a smaller company and the single product guy there. I devoted a post to this scenario here.

The relationship between the spheres

The spheres correlate and affect each other as you probably already understand.

Looking top-down the best would be to describe the relationship as ‘frames and aligns’.

E.g. –

The company’s mission frames and aligns the leading KPI and the north star.

The north star frames and aligns the product strategy.

The product strategy frames and aligns the roadmap…

And you get the drift… right?

Therefore, it would be very inefficient to work on a roadmap when there is no product strategy in place. Same goes for working on the quarterly plan with the lack of a roadmap. And so on….

We could also look at the relationships bottom-up. In that case it’d be the best to describe the relationship as ‘realizes and executes on’.

E.g. –

The hands-on aspects realizes and executes on the quarterly plan.

The quarterly plan realizes and executes on the product roadmap.

The product roadmap realizes and executes on the product strategy.

And so on…

So, to summarize – the pyramid looks something like this:

Great, but where do I fit in all of this?

That’s a good question and highly dependent on the size of your organization and how the product organization is structured.

If the company is small and you are the only product guy there – then congrats – you got the whole package. This is a big burden so make sure you follow the advice I provided in ‘Covering All Fronts’ (linked above).

If you arrive at a small company where there is already a VP product or a CPO, then most likely you’ll be in charge of the quarterly plan and everything below.

There are plenty of other configurations and it’d be impossible to cover them all here. I would say, though, that usually the line is drawn around the roadmap, and if you find yourself below this line, then I’d try to delicately push back and strive to take ownership of the roadmap at least (unless you are really junior).

The reason is that if the planning of the roadmap is not in your hands – then you are practically just an executor. You merely deliver others’ plans.

Where does it leave accountability if something fails? Sadly, on your side most of the cases. It’d be very challenging to blame the roadmap in case things go wrong. It will most likely fall on the execution.

Therefore, you should aim to own the roadmap of your products as well, and not just execute on your boss’ plans. You will also learn much more in such a scenario and it’d be very beneficial in terms of career planning.

Other product management responsibilities

In the world of product management there is a huge number of responsibilities product people are in charge of. However, most of them can fall under the ‘hands on’ part mentioned above.

There is one big aspect which is not covered directly under the pyramid I just presented and this is about managing other product people.

The management aspect is a responsibility by itself, and it can’t be attached to a specific sphere, because it depends on the structure of your company.

There are ‘heads of product’ who don’t manage anyone. Same goes to some of the VP products I’ve seen. But I’ve also seen senior product managers who manage junior product managers.

There are product management titles which correlate directly to management such as ‘director of product’ and ‘product lead’. Sadly, I saw companies mixing all the titles with the wrong spheres of responsibilities – so the bottom line is that titles don’t mean much, except on LinkedIn.

However, regardless of the title – the management of other product people is a huge responsibility by itself and it comes on top of your current sphere of responsibilities. So – if you are also a manager – the challenges are much bigger.

The good news is that if you are a product executive who is owning the leading KPIs and the product strategy, then you probably have enough capacity to manage other product managers. In fact – managing them should be the main part of your day2day job.

I honestly don’t see how working on a strategy and the KPIs can be a constant challenge that occupies your time long term, because those things – once they were agreed on – don’t change often, so it should leave you with enough free time on your hands. Use it to manage and mentor other product people.

That’s it for today.

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

Originally published by Nati Berkover on the Producteneurship blog on July 10, 2021