Product managers have a lot on their plate. They oversee current initiatives, conduct discovery for upcoming initiatives, work on long-term strategic planning, manage stakeholders, and so on.
It’s even worse if there’s no separate project manager or scrum master, making the product manager responsible for the delivery aspect on top of their typical responsibilities. As a result, PMs are often overloaded and don’t have time to focus on what’s truly important.
To add insult to injury, this is not even how healthy product teams should function. In an ideal scenario, product teams should self-organize and require minimal oversight from a product manager. But properly implementing this approach is an omnipresent problem.
However, during my journey, I discovered one repeatable approach that, in the long run, both boosts the team’s agency and offloads PM from day-to-day activities. In this guide, I’ll introduce you to the concept of a feature owner.
There’s an omnipresent ownership problem in product development. On the one hand, we’d like to build product teams with high agency and ownership over their work. But if it’s everyone, it’s no one.
And with everyone (thus no one) taking ownership over initiatives, it rarely gets fully taken care of. As a result, it’s common for product managers to step up and oversee a feature to ensure it gets done with high quality and on time. They take up mental ownership to make things happen, even if it’s not technically their responsibility.
But having mental ownership over too many things at once is both very taxing and doesn’t empower the rest of the team. We must find better solutions.
One of the best solutions for the ownership problem is to have dedicated a feature owner for everything your team does.
The general idea is to have one person accountable for making things happen within the team regarding a given initiative. Although it’s still the whole team’s responsibility to discover and ship the right solution, the feature owner takes the mental ownership of ensuring that it goes smoothly and resolving any blockers or issues.
The feature owner is mainly an internal role. That means the product manager is still accountable for communicating and aligning with stakeholders within the company.
Here’s how the feature owner’s accountability compares to that of the product manager and the rest of the product team:
The exact scope of responsibilities for the feature owner role depends on the specific context, team maturity, type of initiative, etc.
Here is an example of how it looked in some of my cases:
Ideally, you should designate a feature owner as soon as you know the initiative will take place. The sooner you establish such a person, the more holistic an experience they will have and the fewer “handoffs” will be needed.
Some of the accountabilities of a feature owner at this stage might include ensuring that:
The engagement of a feature owner at a discovery phase depends heavily on the role and the team’s maturity.
If you are just starting with the concept and the team is relatively immature, focus on making sure that:
A more mature feature owner can also take up additional accountability for outcomes, such as guiding the team to ensure it’s making smart decisions and that the whole discovery process is done healthily — basically, wearing a product manager’s hat.
During the development phase, the feature owner is accountable for timely delivery. This includes activities like:
In this case, we could say that a feature owner wears a project manager’s hat to some extent.
The job of a feature owner shouldn’t end on the release day. There are usually at least a few additional steps the team must take care of after the release.
These might include:
There are countless things to address at every stage of product development. But just to be clear, I don’t suggest a feature owner should do it all. It’s the team’s responsibility; the feature owner is just the person who makes sure the team gets things done.
Let your feature owners discover their own path to success. Some might decide to do everything on their own. Others will wear the “coach” hat and bombard the team with questions. Others might lean a bit into micromanagement.
Let your feature owners see what’s working and what’s not, learn from each other, and find the best approach for a given team. Coach them as needed, but let them learn to walk on their own.
Establishing feature owners is the best team ownership tactic I have discovered so far. Here are some reasons why:
Additional accountability over an initiative forces people to go out of their comfort zone. A developer that usually focuses on code and technical feasibility suddenly has to worry about communication, discovery, designs, data, etc.
Not only do they usually learn a lot along the way, but it also helps them see the bigger picture of product development. Not to mention, it speeds up the team’s maturing process tremendously.
With a feature owner on board, product and project managers don’t have to oversee the whole process. They can leave more breathing room for the team because they know someone on the development team has mental ownership over the initiative and will escalate as needed.
That builds a sense of ownership within the team. There’s a big difference between a product manager pinging everyone in the team to ensure things get done versus a peer member of the team doing this.
With feature owners on board, product managers have more mental capacity to focus on more strategic, high-level activities. This helps unlock their growth and capabilities.
When they don’t have to spend half their workday overseeing “business as usual,” they can zoom out and invest more time assessing the product and competition and ensuring the team captures the most impactful opportunities.
I’ve implemented the feature owner role at three different companies. Here are a few tips I picked up along the way:
Building ownership in product teams is hard. If something is everyone’s, it is no one’s, so it often ends up being the product manager’s accountability. That’s an ownership trap.
Combating that ownership trap is one of the highest-return investments a product manager can make, and a feature owner is a powerful tactic to do so.
While it’s by no means perfect — and, to be sure, I am still learning how to implement the concepts most effectively in my teams — for now, it’s one of the most powerful team tactics to boost team ownership and free up the product manager to focus on higher-level strategic tasks. I strongly encourage you to give it a shot.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
