If I had to predict the main challenges that would be raised in my first meeting with a new mentee seeking my help, it would probably be one of the following:

1. How to properly prioritize features and backlogs
2. How to properly manage sprints
3. How to properly manage customer requests and weigh them against internal stakeholders’ requests or the product roadmap
4. How to properly decide what should be on the product roadmap
5. How to manage chaos and continuous ‘urgent’ requests that are breaking the sprints

Or any variation of the above.

Of course, from time to time, the challenges that are brought up are a bit different, but for most of the cases – this is how the first session commences.

What’s common to all of the challenges above is the lack of a ‘uber’ guiding principle for prioritization. Additionally, the sense of ‘chaotic reality’ is being brought up almost every time.

Those two are, of course, tightly coupled, and I’ll explain why soon.

About three years ago, I published an article titled ‘The Universe You Operate In’. The goal of this post was to divide the ‘universe’ of product managers into layers which I called the ‘spheres of responsibility’. Each layer encompassed one or more product management ‘concepts’ that product managers would need to address and had its own depth.

Those layers would make a pyramid which looks like this:

In my original post I described each of the layers briefly, and I’m going to do so again now. In fact, you can treat this post as an updated incarnation of the original post where I’ll apply my new learnings since I posted it.

But before we do that, let’s complete the background story, because it’s important – 

When I first shared the pyramid concept, I hadn’t envisioned it becoming the cornerstone of my training for product managers. Yet, it quickly proved pivotal, guiding nearly all my initial mentoring sessions to reframe challenges from a broader, more accurate perspective.

The pyramid accelerated product managers’ growth, offering mentees a fresh lens to reinterpret their challenges and solutions.

And this is why I consider this post my most important to date and my main contribution to the product management world in general. That is – until today, as this post supersedes it. There is no need for you to read the original post (unless you’re curious), because I’ll explain it all here from scratch.

Let’s go.

The Product Spheres of Responsibility

As I noted above, I divided the realm of product management to ‘spheres’ or ‘layers’, where each such a layer encompasses an area of responsibility for product managers.

Each layer has its own depth, and on my site you can see that the navigation method is divided into similar layers, in case you wish to read articles which are related to a specific sphere.

Hence, I’m going to briefly discuss each of the layers now, but remember that if you wish to take a deeper dive into any of the layers – you can find more stuff on my site.

The Mission

At the top of the pyramid we have the company’s mission. In short, the company’s mission is how the company is going to make the world a better place using its products. The mission is determined by the founding team of the company, and in fact, once the company has received its first significant funding or revenues – it’d be very hard to change.

Therefore, as a product manager you have only one choice you can make – do you ‘connect’ to this mission and want to work in this company… or not? Once you made a decision to become part of this company you need to treat the mission as an axiom.

The North Star

Things are starting to get more interesting at this layer. 

You see, each company tracks many KPIs. Some of them are more important than others. But many claim, and so do I, that for each company (or business unit, if the company is big) there is one KPI which is the most important one. We call it the ‘north star’. There is a lot to discuss about this KPI, but we won’t do it now. You can read my post here if you wish to learn more. In short, though, the north star can tell you (if you selected it properly) whether your company (or business unit) is headed in the right direction or not.

A proper north star will fulfill the following three criteria:

1. It’d be a good leading indication for your revenue trend (meaning – if it’s heading up expect your revenues to increase as well and vice versa)
2. It’d be a good leading indicator for gaining/losing market share (meaning – if it’s heading up expect your market share to increase and vice versa)
3. It’d be a good indicator that the overall value that you deliver to your customers/users is increased/decreased (depending on its trend)

Again we can talk about it much more but we won’t do it now. Essentially though – the existence of the north star communicates to everyone in your organization what success means. It can also serve as an ultimate prioritization key for initiatives and big features (based on the evaluation of which of them will contribute more to the increase in the north star?).

The Product Strategy

There are many ways to define ‘product strategy’. I prefer (like always) a more direct and clear approach:

As I see it, the product strategy is the plan of how your product needs to be shaped in order to take the north star to the sky in the fastest manner possible.

The strategy typically spans a year and a half to two years into the future, taking many factors into account. Again, this is a huge topic and you’re welcome to read the trove of posts I’ve written on this topic on my site. 

From what I observed, though – a company (or a business unit) needs to take a different approach to strategy based on whether they are pre initial product market fit, or after.

If your company hasn’t achieved initial product-market fit, then the strategy will most likely focus on how to attain it as quickly as possible.

If your company has passed this stage then usually the product strategy would focus on growth and gaining market share as fast as possible.

Product Roadmap

While the product strategy aims deep into the future, the product roadmap is more down to earth, and usually focused on the next 12 months.

The roadmap needs to serve the strategy and it’s therefore focused on high level capabilities that need to be developed in the coming quarters. Hence – high level capabilities over a timeline.

I do cover it on my site, though from my personal experience the product roadmap is vastly overrated, and it’s one of the easiest things to design. I’m saying this because if your product strategy is solid – then you already know what should be on your roadmap. 

The Quarterly Plan

Unlike the roadmap, and definitely unlike the strategy – the quarterly plan is in the very small details. As its name suggests – it looks only one quarter ahead, and it needs to contain everything that it’s going to take time from your dev team (or any other workforce which is assigned to you).

This is why I consider the quarterly plan as the most daunting product management task.

It’s very hard to do right, and even if you do it right nobody will be happy when you’re done.

Anyway – if you are not sure you are doing it right – I have a post on it under ‘quarterly planning’ on my site.

Hands on

We’ve reached the bottom layer of the pyramid – the ‘hands-on’ aspects of product management. Here I include:

1. Writing PRDs (specs)
2. Managing & planning sprints
3. Interviewing customers
4. Managing day-2-day priorities
5. Orchestrating the product delivery process

And more.

Many product managers mistakenly believe that this is their sole job. I mean, as a product manager you definitely need to do this, but it’s only part of your job.

I devote a great portion of my posts on covering the hands-on layer and I also offer a crash-course on this. You can find it all on my site.

Anyway – this is the pyramid. Now let’s see what it gives us.

The value of the framework

What I like about this pyramid, is what I found over the years to be very true:

Each layer in this pyramid frames and aligns the layer below it.

Here are some questions that proves that:

1. If you don’t have a north star – how do you expect to develop a strong product strategy? After all – you can’t tell what ‘success’ means to your organization.
2. If you don’t have a product strategy what do you base your roadmap on? From my experience, with a lack of strategy you just dump a few big features your customers asked for and convince your manager that it’s a great roadmap. Your manager will probably approve it because they can’t tell themselves what’s the big plan..
3. If you don’t have a roadmap – how do you decide what you should work on in the next quarter? Again, from my experience, with a lack of a roadmap you revert, again, to tactical initiatives your management declared on a day before. They will probably change their mind right after you’re done with your plan (because everything is tactical and opportunistic)… but hey.. You got a plan. 
4. And if you don’t have a quarterly plan – how do you decide what gets into your next sprint? Let me tell you what I see – whomever shouting the loudest or of higher rank gets their items into the sprint. Right?

If your product team makes an effort and builds this pyramid properly then a lot of magical things will happen:

1. Everyone understands ‘what’s the plan’ and where the ship is sailing to.
2. You are not spending your time on tasks that have little impact.
3. Your company chooses the ‘opportunities’ to tackle much more carefully and in light of whether they serve the strategy. Resulting in much less noise in your day to day.
4. Sprint planning becomes trivial, the quarterly planning becomes much more bearable and the roadmap, as I noted above, becomes much easier to build.
5. The chaos that was haunting the corridors slowly dissolves.

This is why I call this framework the CAF Product Framework. The ‘CAF’ stands for clarity, alignment and focus – which is what you get for properly applying it in your organization or business unit.

Sounds like an utopia?

Well, it definitely sounds good. Is it achievable? Definitely. I applied it successfully in the business units I was leading as a product leader and many of my mentees managed to apply it successfully in their companies.

Still skeptical? Don’t think that you can make this change on your own?

If you’re tired of chaos, working on futile features, and struggling with sprint planning, embracing this framework isn’t optional – it’s necessary for a strategic future..

Yes, it takes some convincing. Yes, you might make slow progress on that. However, you’re not alone.

You have your manager, who might feel the same and might join forces with you on that.

You can also read my articles that cover this challenge and how to tackle it more deeply (here, here and here).

And you can also reach out to me. I’ll make a best attempt to find the time to talk to you.

Good luck!

—

If you have any feedback on this post – feel free to reach out let me know what it is. I’d be delighted to hear from you.

If you think your friends/peers can enjoy this newsletter as well – invite them to subscribe on this page.