The definition of a ‘product manager’ and that of a ‘product driven organization’ has really evolved over the last few years. In a knowledge share session organized by Blume Ventures, Kaushik Subramanian, product leader (previously at Facebook), tried to resolve this question by discussing the building blocks of a high functioning product team for a group of early stage founders and CPOs.
Decision-making is the single most important function of a product manager. While it is easy to fall into the trap of outputs, such as metrics and shipping velocity, those are lagging indicators of the decisions made. High quality decision making as an input will always result in good outcomes. Hence, everything that makes a product manager’s job of either 1) making decisions easy or 2) freeing up time to make decisions contributes to building an empowered product team.
PM as a title is often different from PM as a role and that depends on the type and stage of the company. For example, at a pre-seed stage, a PM’s job is often a combination of project, program and product management. All is fair in love and pre-Series A!
Post Series A is when the PM role can become a ‘high leverage’ role. Ideally, you should be thinking of staffing a team around the PM in order to increase PM leverage.
You need to examine how much time your product team is spending on the core job, otherwise it is a waste of both time and resources. A good way to solve this problem is to staff up your program management team. Ideally, one program manager supports two PMs, even though accountability remains with the PM.
Now that we have the do’s and don’ts out of the way, there are differences between the PM title and the person who is actually doing the job, which often manifests itself in several ways as below. It’s important for founders to identify which archetype their company falls in:
Founder is the PM
Here, the founder is the chief decision maker. They tell what should be built and shipped. Roadmaps would focus on new potential ideas instead of problems, which are hardly discussed after the initial product requirement document is set. This approach suits early stage companies. It makes sense for the founders to drive every move instead of handing over the ownership to a product team, which can be risky. Doing so would essentially mean that you are giving up the most important task of building the company even before it gets validation from the market.
Customer is the PM
In this case, your customers become the key drivers that determine what you do next. They are the sounding board for your solutions-in-making, and would propose and dispose as they think is right. Intuition hardly has any role to play here. It doesn’t have to be all customers, but only a few that become your reference point. Every request from this group, even if unreasonable, is your guiding light. The sales team becomes the primary messaging channel between you and the customers. Companies often go through this phase around the time they’re trying to hone in on PMF. This for a long time becomes a dangerous approach.
No one is PM
This arguably is the most dangerous case to have. Here, everyone works in silos: technical teams will limit themselves to shipping features, business teams will focus on just business outcomes, and so on. There’s no overlap or communication between the various teams. This is often the case when technology is not core to the company. For example, a grocery delivery app may have a product team concentrating on making the app and a business team driving business for the app.
Ultimately, where you place this role depends on what leads to the best outcomes. No approach is incorrect, but ideally the solutions should be rooted in a problem. Your approach to do this could be product led, where technology solves problems and the process brings in revenue at some point. Or it could be business or sales led, where you either combine tech and margins or maximize distribution and depth in your customer base.
A common problem that arises after a product team gets built is what titles to award. It makes little sense to waste time over titles, and makes more sense instead to define roles better. Ideally, this should be a three-tiered machinery:
The Head of Product defines company-wide vision and sets the guidelines for the team.
Manager of the PM is tasked with the execution of the said vision, allocating resources as they should be and checking in on progress.
Product Managers form the components responsible for realizing the vision. They make the everyday decisions that move the needle.
This isn’t set in stone. Most companies adapt these roles according to immediate goals. But however these relationships shift, it’s important that there is no information transmission loss. In many cases, accountability suffers when there are multiple levels of discussions. To counter that, the product managers should closely communicate with the engineering manager, who is then responsible for execution by his team. In this entire picture, program/project managers only come in to take care of processes.
It’s also a good idea to encourage lurking. People from one product team should have the liberty to sit in meetings of another and throw questions and suggestions at them. This helps build a collaborative roadmap as opposed to an isolated one.
Product management is a craft perfected over the years. Domain knowledge may play a role in some niche spaces, but in most cases, you would be looking at someone who gets excited at the prospect of solving hard problems and is able to build a product that users love (irrespective of the domain).
Disha is tasked with building compelling narratives for Blume. Prior to this role, she was a journalist with Economic Times, where she extensively wrote on food tech, gaming, and consumer tech. She has also worked with LinkedIn,…
