Why We Need Product Managers

How many times have we seen this? A product with great design, clean lines, super finish – we are almost compelled to try it. But, no sooner have we tried it than we know the product falls flat on its face. How? Why?

Somewhere along the way, the product team seems to have lost sight of the vision that the product needs to be used by the target audience- and used with ease.
Recently, HelpScout released an article suggesting that the role of a product manager might be a superfluous one – even something that could be detrimental to the quality of a team’s output.

Theoretically speaking, they are right!

So, when do we get a great product on hand?

Usually, when the team is crystal-clear on the requirements, when it has the right skill mix, when they have figured out a way to work seamlessly on the design and engineering, when they know exactly what every single stakeholder wants, when their schedules sync up perfectly and so on – that’s when you can have a great product.

In the real world, though, a product development cycle has to cater to the needs of several stakeholders. Any team that has been through a typical product development cycle will tell you that balancing your stakeholder’s expectations and building a product that caters to their demands while sticking to the true purpose of the product can almost (physically) feel like stretching the product to its ends in all directions. One pleased stakeholder could mean you have a thoroughly pissed off another waiting at the other end.

How does a product team now ensure that they work on things that balance all the stakeholders’ requirements and not simply follow the person who is able to pull them in their direction most effectively?

Of course, they are many wrong ways to do something as there are many right ways.

All happy families resemble one another, each unhappy family is unhappy in its own way. – Leo Tolstoy

Here are some of the most common arguments mentioned in the article against a product manager’s role- which we seek to refute:

1. Having a product manager excludes other people on the team from taking ownership for the project

That might be true – but, only if the product manager repeatedly leaves gaps in his communication both ways. Oftentimes, a deliberate stonewalling effort to maintain control can frustrate his team. He could lose the most precious thing in the process- his team’s interest and loyalty leading to a lack of ownership among his team.

Most often, a product manager’s role is often seen as something of a wall (or, at least a curtain) between his star team, the customer, and other stakeholders. A common perception (stemming from a real problem) is that the engineers and designers of his team fail to see the big picture and have their roles watered down to simply implementing tasks assigned to them. In simpler terms, it prevents them from taking ownership of the complete project.

It is very important that techies take ownership of what they’re building and the customers they’re building it for. However, this does not translate into – I don’t need a product manager.

Can techies manage an entire project by themselves, yes they can. But that’s not what they were hired them do to.

At Exotel, we have seen first-hand that there are several simple practices that can beat this problem. Our product managers involve their teams in stakeholder meetings. They empower team members to come up with solutions for pressing pain points. They make sure that their teams always trusts the information coming from them as free-flowing- and not as something that’s passing in a trickle.

2. It could promote a “not my job” culture

In the absence of the product manager, it is perceived that everybody in the team contributes to every challenge and every aspect of the product. Everything becomes everybody’s job.

It could mean having a designer contribute to the engineer’s challenge. Or vice versa. While this is a great way to encourage cross-learning, this will definitely not count as great resource optimization.

Using an engineer’s skills to solve a pressing design issue will not only frustrate the engineer (and your designer), it is a criminal waste of his time and skills. Plus, you really haven’t thrown away the risk of a shoddy outcome.

Here, at Exotel, our earlier versions of the product have all been designed by engineers. At this point, when we would like our design to be overhauled by a professional designer, but we most definitely find it a nightmare at this stage.

One of the first things a good product manager does is to recognize his people’s core skills and correlate those skills to the product’s challenges. That means providing the designer every chance to come up with a great, clean design for the product and trusting him to do it well without unnecessary interruptions.

In other words,

when a product manager is running a project, it does not necessarily have to translate to “it’s not my job” for the others. It can translate to “I do my job better” for everyone.

3. A product manager shifts the focus to ‘ancillary’ tasks

Sure, there are things like planning and customer research that come before the real thing- which can sometimes be perceived as ‘non-core activities’ by engineers. But then, every task needs planning, even if you are on your own. With 10 other people working alongside, it becomes non-negotiable.

Also, it’s easy to forget that a developer will not be concerned about whether the design engineer’s schedule will sync up with his deliverables or not. And, he shouldn’t be- because that will be a sub-optimal use of his skills and time. That becomes the product manager’s job. In other words, the ancillary jobs are not superfluous, they are required and critical. The product manager takes the burden off the team’s shoulders to a large extent.

4. He slows down the project and adds overhead

Some would argue that a product manager can add overheads to the project with several hours being sucked into negotiating features, communicating back and forth with various stakeholders, making project plans, making and scrapping prototypes.

Here’s a scenario: We recently launched Exotel internationally. Our billing function was deemed complete by the techies, long before it was anywhere close to completion. However, while the billing function was done and dusted, other aspects like compliance, taxation, international laws, integration, were not factored in. This resulted in the product being incomplete.

An engineer tends to be unidirectional in his thinking. This allows him to get on with what he enjoys the best – coding. When you give an engineer a problem, the most logical way forward for him is to get down to solving it. The goal in this case is just problem solving.

Typically, a product manager’s goal is to look beyond the product’s current utility and focus on what will make the product great- now and years later. In a way, his constant focus on juggling the priorities of multiple stakeholders gives him the required perspective for the longevity of the product.

To sum up: The benefits of having a dedicated role to focus on holistic, long-term product-building capabilities will pay for itself. In most cases, it’s not very long before you begin to see the positives.

A product manager is a structured thinker and a persuasive communicator. He can make the product the hero while keeping the team together.

If he’s building a tech product, then it would be a bonus if he’s a techie. If you see your product as being valuable enough to survive the long haul, committing resources for this critical member of your team should become your highest priority.