To build a great product, you need design and you need engineering. Somewhere along the way, and especially as companies grow, another mysterious role enters the fray: the Product Manager.

Conventional wisdom says that as a product becomes more complex, you need someone strategizing, coming up with plans and executing on them—someone who can step back and organize the process around a bigger vision. They also ensure everything gets done on time, on budget, and without drama.

But the Product Manager role introduces a couple disadvantages. It seemingly takes ownership away from the people doing the work. Designers and engineers become cogs executing a plan when they should be empowered to solve customer pain. Product Managers also add overhead to every project, albeit unintentionally.

You may not need a Product Manager. At Help Scout, we don’t have any dedicated Product Managers. Instead, the goal is for designers and engineers to manage their own work. It may not ultimately scale, but we love how it distributes authority amongst the team.

When running a project isn’t a manager’s job, it’s everyone’s job

With a Product Manager in the mix, it’s easy for “not my job” syndrome to creep in. People doing the work suddenly get someone to lean on for all stages of project planning, including ancillary tasks—writing specs, doing customer research, organizing to-dos—and it gets pretty easy for them to say anything other than pure execution is “not their job.”

A magical thing happens when there’s no Product Manager. All of the project planning and ancillary tasks become “everyone’s job.” Designers and engineers have to work together to understand customer pain and come up with a delightful solution.

By being forced to think a problem through front to back, the team can do better work.

These “chores” become empowering, rather than a burden, because they give people a sense of ownership and responsibility that didn’t previously exist.

The efficiency argument

Some argue that dedicated Product Managers are needed for efficiency. Separation of duties reduces context switching and allows you to better align high-value work with high-value (cost-wise) people. The problem is that this argument doesn’t account for communication overhead, a huge velocity killer on product teams.

If a 3-person team can produce Y output, why can’t a 15-person team produce an output equal to 5*Y? The answer is overhead. It’s extremely expensive to keep 15 people on the same page. The reality is that the 15-person team’s output is only 2-3x that of the 3-person team.

Adding even one more person to a team creates overhead. It also reduces the amount of ownership on the shoulders of each person doing the work. In order for product teams to move quickly, communication overhead must be low, meaning the number of people must be at a minimum. Ownership of the project must also be distributed, which is in conflict with the whole “manager” concept, where a single person “owns” the project.

So what’s the ideal team size? A mentor of mine named David Cancel has some great thoughts on this. I tend to agree with him, that three people is the ideal team size. Communication overhead is virtually zero in a three-person team that has all the tools they need to do great work. Four or five people has some overhead, and anything over five is going to cost you.

Keep the product team close to the customer

Managers often put an unnecessary layer between customers and the people building a solution. It works like a game of Telephone. The more layers between customers and designers/engineers, the more skewed the message is by the time it gets to the people that need it.

Empathy doesn’t travel well in a game of Telephone, and people doing the work need to be able to feel the customer’s pain.

On the other hand, magic happens when designers and engineers feel the pain and are given the autonomy to solve it how they see fit. When the outcome is on their shoulders instead of on a “manager,” they are capable of doing their best work.

Splitting the Product Manager role

splitting the product manager role

To be clear, the work of a product manager is critical. But our goal is to distribute that work rather than hire for a dedicated role.

For product management to be everyone’s job, designers and engineers have to take on more responsibility. We’ve found it’s pretty easy to split up the work.

Designers are responsible for being the voice of the customer from initial concept through to final deployment. Only a fraction of their work is pushing pixels around.

A designer does customer research, written specs, wireframes, working prototypes and testing alongside engineers. They also run any beta period themselves so that they can hear customer feedback firsthand. Lastly, the designer has the final say on launch. Not every designer on our team does this sort of work, but we have a couple people who are great at it.

Engineers have more ownership without a product manager as well. They write their own technical documentation, coordinate the work and timelines with any other engineers on the project and are responsible for communicating about their progress.

While many product teams seem to revolve around engineers and giving them the most autonomy, I’ve seen this have a negative impact on the customer experience.

At Help Scout designers have the final say because they are in closest proximity to customer pain and the people working to solve it.

As a company grows, product development gets slower, takes more people and requires more effort. We often misunderstand those challenges and insert Product Managers to make the process more efficient.

I’d argue that this role exacerbates the problem instead of solving it. At scale, things move slower: that’s a fundamental reality. The key to maintaining the highest possible velocity is giving the designers and engineers ownership over the work.

Update on May 9, 2016

I've had some great discussions with folks in the product management community over the last week. Since we don't currently allow comments on the blog, I wanted to share a few clarifications:

  1. It's not my intent to claim this is the only way to do things, only that this is what currently works for us. There are many great cases for product managers and some of the smartest folks I know are in the field. I'd encourage you to read links like this one, this one and this one.

  2. You could make the case that I'm describing more of a "project manager" instead of a product manager. The role of a product manager seems to vary a great deal across organizations. My description is narrow and can be more closely aligned with a project manager depending on the organization. Most dedicated PMs do a lot more than what I've described here and some of my comments unfairly downplay their contributions.

  3. The reason we've been able to get by without this dedicated role has a lot to do with our leadership already being focused on product management. This is arguably the strongest common thread between the founders and other product leaders in our company. I acknowledge that in other companies this is likely not the case; therefore a dedicated role makes a lot more sense.

Nick Francis

About the author: Nick Francis is a co-founder at Help Scout.