Product management isn’t about the features.

In most companies, product discussions are about features. But features are bricks in a wall, a means to an end. What matters is what you build with them.

Talk about product with almost any company, and the questions are going to be: what are you building? How is it going to look like? When are you going to ship it? 

I'm going to argue here that talking about features isn't helpful. Any company has an infinite number of features it could build. If your process is to pick in this bottomless bag what to do next, you'll be condemned to work on hypes, on the latest thing the CEO thought about in the shower, or that thing that important customer mentioned last time you talked to them. In short: random garbage. 

Features are only good if they help you reach an objective. If the company you're building were a house, individual features would be bricks: they are useful not for their own sake but insofar as they contribute to the overall project. Features are a means to an end. The end is an objective, and this is what we should be talking about.

Implicit objectives

Objectives exist in any organization, but more often than not, they are implicit, kept in someone’s brain. It usually goes something like this: 

1. A manager of an app thinks that they should grow their user base. They figure that translating the app to Spanish could allow them to get there

2. They communicate that the app is going to be translated into Spanish

3. Translating the app to Spanish becomes the goal for the product team

Translating an app is a valid idea to grow the user base, by increasing its obtainable market, but it’s not the only way to get there. However, if the objective isn’t clear, no one will ever be able to find a better way to get to it.

In short, if objectives aren’t clear, prioritization becomes impossible. Prioritization is about identifying what is the highest priority right now — that much should be obvious. You do this by comparing different features and determining which ones will have the biggest impact and are the simplest to implement. But you can only do this analysis if you know what your objective is. You cannot establish relative priorities for features serving different objectives.

Taking the above app example, growing the user base might be one objective, for which a Spanish translation might be helpful. Another objective might be increasing the revenue per user. There, candidate features may be introducing a premium tier, removing some features from the free tier, or adding features valuable to enterprise clients, for instance. 

With a clear objective in mind, the product team can identify and prioritize features that would allow reaching it. A Spanish translation may be a great way to grow the user base, but might be costly. In the case of an app with a lot of drop-off during sign-up, simplifying the onboarding may be a better way to get there, and this is therefore what the company should be focusing on.

But if the objective isn’t clear, you might end up comparing features serving different objectives. For instance, you might have to choose whether to translate the app to Spanish or introduce enterprise features. And how do you go about that? You cannot compare their relative impact, since they are serving independent objectives, and you will therefore end up picking at random.

One more time: you cannot establish relative priorities for features serving different objectives. 

Not having clear objectives will lead to the team running left and right, putting out fires, and making minor improvements while not making any tangible progress towards what’s important for the company's future. You will be wasting time while keeping busy. 

How to solve it

An efficient product organization will not focus on features but objectives. The first step towards this is making the objectives clear for everyone.

This is the goal of management and strategy: get the whole company aligned on what they want to achieve. 

“Management and strategy should get the whole company aligned on what they want to achieve”

With clear objectives, the duty of the product team becomes finding features that are going to help the company get there. 

On a day-to-day basis, the objectives will keep you from wasting time since you will be able to ask yourself, for whatever you are working on, “Is this going to get us to our objective?” If the answer is no, you should be ruthless in dropping whatever it is — or, if you cannot, reflecting on whether your objectives are well defined.

I’ve written about OKRs in the past and they are a great tool, but they are just that: a tool. OKRs will help you track your objectives and improve them, but having OKRs is not the same as having objectives. For example, one company I worked with had rolled out OKRs company-wide; however, the company would then always prioritize whatever its most important clients were asking for, making the OKRs useless. 

How to check if your objectives are good

There are three tests to check whether the objectives you’re working with are valid: 

1. A competitor might have different ones

2. They are actionable

3. They don’t change all the time

Let’s go through them one by one.

1. A competitor might have different objectives than you

This one may sound counterintuitive, but it is, in fact, pretty straightforward. If all of your competitors share the same objectives, it means that they are self-evident, and therefore not helpful. An extreme case would be a company whose objective is to “generate profit.” Sure. Sure it is, but so is the case for every other company in the world, so it isn’t very meaningful. 

When asked what her company would look like in the future, I once heard a bank executive answer that it would be “connected, and close to the people.” Could you imagine someone saying the opposite? That they would like their bank to be “not connected, and far from the people”? No, of course not, so that statement is entirely pointless. 

For a traditional bank, a good objective might be to increase the proportion of accounts created through its app: that would show their willingness to transform to reach their users where they are. A digital-native neobank like Revolut would have completely different objectives, on the other hand. 

2. Objectives should be actionable

The goal of an objective is to steer your company and allow anyone to understand how their work squares with its mission. For that to be possible, the objectives should be actionable.

Take the example of the lousy objective again, “generate profit.” While yes, it is what the company is ultimately all about, you cannot go to a product manager and say, “Hey, this quarter, I’d like you to generate some profit.” It is much too broad, and it would immediately disqualify any strategic project that may not generate profit instantly. 

On the other hand, for a bank, increasing the proportion of accounts created through its app shows a clear strategic vision to go towards mobile banking in the hope that it will generate revenue in the future. Will it increase profits in the very next quarter? That’s doubtful at best. But it doesn’t mean it’s not something the bank shouldn’t tackle with very high priority. 

3. Objectives shouldn’t change all the time

Finally, your objectives should stay (relatively) stable over time. Now I know what you’re going to think: “whoa, we’re talking about startups, things change, you need to be able to react!” Sure, I agree with that: you may set an objective and realize halfway through implementing it that it was misplaced. In that case, you should scrap it and refocus on something else.

However, if every one of your objectives gets scrapped, it means that you have a problem: probably an absence of strategy. 

Going from objectives to features

Without objectives, you cannot have a product team. The best you can hope for is some project managers who instruct the team to follow management’s latest whim. With objectives, however, you’re set to create a functioning product organization. 

Individual product managers can be assigned objectives or sub-objectives in their respective teams: the team responsible for the onboarding in the example bank’s mobile app, for instance, can be tasked with increasing the app’s conversion rate. With such a clear objective in mind, product managers can get to work: collaborating with designers, user researchers, engineers, etc., they can come up with ideas for features that might accomplish this. 

PMs can then prioritize these features, my tool of choice for this being ICE. But I cannot stress this point enough: if you don’t have objectives, no prioritization is possible. For example, how can a product manager prioritize improving the conversion rate of an app vs. increasing the scalability of a back-end component if they don’t know what the objective is? They cannot.

So, managers who are reading this: please state your objectives clearly, and make sure they are good ones. Your product team will thank you.