Ever since I became a product manager at Chef in January, I’ve observed a fair amount of confusion and uncertainty in our industry about the role of product management. Although this is my first job as a product manager, I now have enough of a grasp of the responsibilities that I can offer a succinct explanation of the role (so if you’re reading this, dad, you now know what the heck I do.)
Broadly speaking, the VP of Product holds the overall product vision and vision of the company in the marketplace. Product managers that report to him or her are then accountable for building the right product, compatible with the product vision, to meet the company’s current business objectives. Business objectives could be to grow market, reduce cost-of-goods-sold, reduce churn, capture a market or niche, and so on. These areas of accountability boil down to some key responsibilities:
- Create and own the product roadmap
- Manage engineering teams’ backlogs
- Meet regularly with customers to listen to their feedback, communicate the roadmap, and review product direction
Obviously, there’s a lot to unpack in these three bullet points. Moreover, a product manager rarely has direct authority over the people he or she is trying to manage. Even if they do, they will be far more effective if they use that authority rarely, and instead develop trust with their engineering teams to guide and influence them. In the words of Deep Nishar, former SVP of Product and User Experience at LinkedIn: “A great product manager has the brain of an engineer, the art of a designer, and the speech of a diplomat.”
Creating and Managing a Product Roadmap
I’ve been following Intercom’s excellent series of articles on product management, and one of the topics they addressed recently is Where Do Product Roadmaps Come From? In general, items make it onto a product roadmap from three areas:
- Customer feature requests
- Bugs and quality improvements we know we need to make
- Ideas we have for solving customer problems
No product roadmap should be dominated by any single category. In fact, part of a product manager’s job is saying “no” more often than “yes”. That will invariably make stakeholders — customers, customer support, customer engineering, marketing — unhappy at various points in time, but there are always far more good ideas to implement than resources available. It is a core responsibility of a product manager to not only try and achieve a fine balance amongst the types of items on a roadmap, but to push back against idea creep that will distract the team from the small number of achievable goals for the quarter.
At Chef we’re on a journey to building our products iteratively, with fast customer feedback coming from frequent releases. This means that the resolution of a product roadmap becomes increasingly poor the further out you go. I know what we’re building this quarter; and next quarter is reasonably baked, but the quarter after that is hazy. Anything beyond that? Well, who knows. As such, we’ve stopped publishing year-long roadmaps because they become meaningless very quickly, and no roadmap should represent hard-and-fast customer commitments beyond the current quarter or two.
Models of Accountability
As I mentioned previously, it’s rare that a product manager has direct authority over engineers on his/her team. Product management typically reports up to the CEO, while engineers report to a VP of Engineering, or a CTO, who is either peer to or reports to the CEO.
This doesn’t mean that there shouldn’t be a clear model for who is accountable for doing what between the two groups. For this, I turn again to another excellent Intercom post, Lessons Learned from Scaling a Product Team.
I found the post a little “blamey” in the way it words the roles and responsibilities (“if X is screwed up, it’s on Y person.”) Let me reword the post in a way that’s a bit more positive:
- The product manager is responsible for specifying the right thing to solve the customer problem and to measure the outcomes. They must fully understand the domain to the best of their ability.
- The UX designer is responsible for ensuring that the design addresses the customer problem. They are responsible for conducting user research and interviews as part of the product development process.
- The engineering lead is responsible for delivering what was designed, and on schedule. The engineering lead is also responsible for making sure that their team is executing primarily customer value-creating stories, and not spending too much time on non-value-creating stories.
- Engineers themselves are responsible for writing high-quality, well-tested code.
This leads me to another big area of confusion in our industry: how does a product manager differ from a project manager? In short:
- A product manager is responsible for determining what to build.
- A project manager is responsible for determining on what schedule that thing can and will be built.
These roles can overlap, especially in a smaller company, but they are distinct. Product management is much more domain-and-customer-focused. Project management can be done even without a lot of domain knowledge and expertise.
Other Responsibilities of Product Management
A product manager must be a domain expert in their product area. This is why it makes it somewhat difficult to hire product managers for Chef: you need to find operations or DevOps people who want to give up their technical jobs to do more business stuff. In my work, I am constantly learning not only about how our customers use our products, but also how they do their jobs. As such, I also do the following:
- Attend a variety of conferences and meetups to speak with our users and to keep a pulse on changes in the sector at large;
- Read market research (Gartner, Forrester, 451, etc.) and articles about the industry and our competitors;
- Perform competitive reviews of our competitors’ products, and develop a perspective on them;
- Speak and write about our products, views on the industry and how we build product;
- Regularly meet with a variety of people inside Chef to ensure alignment across sales, marketing, engineering, business development, professional services, and product.
Chef also has no separate product marketing arm, so I spend a fair bit of time building sales collateral and demo material for our field teams. (Did I mention that time management and prioritization are an important skill in this role?) I’ll have more to say about what product marketing does, and how it’s distinct from product management, in another post.
Being a product manager has been an intensely rewarding but also challenging experience, especially as Chef grows as an organization. I was employee number 60 or so, and now we’re well over 200 people, so you can imagine how much the company has changed. As befitting a company with such explosive growth, some of our processes and practices have not kept up with the pace of change. It’s been a struggle to mature our software development practice while meeting the expectations of our customers. Introducing a product organization is part of addressing those scaling problems.
In the end, though, being a product manager is a perfect fit for my aptitudes and interests, and I’d recommend the job to anyone with a technical background who wants to learn more about how companies and products are built.