On Feature Ownership

As a program manager (PM, for short), I had and continue to have the pleasure of working on a number of features across a range of products. The scope and feature direction can change fairly frequently, and it’s our (PM’s) core responsibility to re-adjust and make sure that we design and develop a solution that helps our customers be more productive, efficient, and successful.

In Ben Horowitz’s 15 year old post, he states that good PMs are “mini-CEOs” of features and product segments. And before we go into deep off-track conversation on this, I know that there is a note that says the post might no longer be relevant - the concept is still very much ingrained in the overall PM track. In on itself, the idea of “mini-CEO” is not the most productive to carry forward in one’s career, as I learned. It creates the image of an “omnipotent PM” that has absolute ownership over a product or a feature. The reality is quite different, and it might take some time to realize it.

Scoping #

Like with any feature plan, let’s scope the conversation around this subject, specifically around an idea mentioned in my last sentence - that of ownership. It’s quite often that we hear “They own Feature X”. Our eye (and ear) will instantly catch the word “own”. It implies that there is a single person who has a feature signed to their name. They are the ultimate decision maker around it. This idea very quickly omits the fact that the feature (or the larger product) is, in fact, not made through one single decision maker. I like to think that in a functional team, a feature of a product segment is always the result of collaboration between several people - engineers, designers, sales, content developers and other managers. A single person doesn’t truly own the feature. The implied ownership creates the burden that one, as the owner, has to be the one to always make the calls and be the one that takes care of the success of a project (and by proxy, take the credit for it).

Changing view #

Let’s look at this from a different perspective - as a PM, one’s job is to bring the best ideas from within the team and company to the table, and build something that empowers their users. In this scenario, a PM doesn’t need to force their own ideas to be the ones that need to be implemented, and neither are they expected to be the ones that are always right about every call made on a feature (over time, it’s possible to get better at distinguishing good ideas from negligible or negative ones). The underlying mission is to continuously grow and learn, and the best way to foster this mindset is to detach one from the illusion of ownership when it comes to product or its features and instead re-focus on driving it.

Drive instead of own #

It’s a topic inspired by my good friend Philipp Cannons. What would driving a feature really mean in a product world? When a PM drives a product or a feature, they are not doing so from a figurative throne - they are, instead, collaborating and getting the right people in the process to get things done in a way that solves customer problems. Driving a feature means that one is free to give up their ideas being the only way and be more open to input from various channels (we all usually work with people smarter than us). When a PM drives a feature, this also reduces the friction of re-shuffling features around - when you own something, and it’s given to someone else, it’s a different feeling compared to when you are driving an effort, and are now driving an alternative effort instead.

It’s all in the details #

Now, one could argue that this is just semantics - at the end of the day, what does it matter whether a PM owns or drives a feature, as long as they get to the same result? In my team, I want to empower everyone to feel as if they are part of the feature success and not just me. I want to make sure that the team feels like they are free to express disagreements and provide better ideas for the direction I might be proposing - all this is much easier done in the context of everyone being treated equally, where there is no “owner” or “mini-CEO” and instead a coordinator that aggregates inputs and helps produce an optimal output.