I've been reading Cliff Gilley's writings for several years now, starting with the The Clever PM1 all the way to some thought provoking discussions on Quora. What's keeping me engaged with what Cliff have to say is his non-compromising, buzzword-free approach to product management; seeking the core reasons behind what is product management as a profession, what are we doing and why we do it. I'm a fan.
Over time I lost track of Cliff's writing, especially with me being less present on social media, until my RSS reader pushed me a new blog post by him over at the Gartner Blog Network called 'Product Managers Must Become “Masters of Product”2'.
In his article, Cliff writes about how historically product managers were urged to become 'jacks of all trades' and in order to evolve they will need to become 'masters of product'. Part of that transition will include detachment from 'doing other people's jobs' and push stakeholders (marketing, sales, customer support etc) into using their own resources to gain autonomy. By doing that, product managers will be able to focus on "understanding the customer and their motivations2".
Cliff's words really hit home for me. During my time at my current workplace3 and transitioning from a place where I was a 'jack of all trades', I was met with strong autonomous teams that needed a different approach to product management. I showed up to my first day at work equipped with all the tools to handle the ambiguity and chaos that is a startup environment and encountered well-structured teams with processes that were established over decades. Here's my journey and take on evolving from 'jack of all trades' into an aspiring 'master of product' and what value one brings to the organization.
above: Your typical 'masters of product' training. photo by Thao Le Hoang on Unsplash
a master of product is a master of context
While teams in the organization have different levels of control over their resources and freedom to self-build, they also need to make sure that their expertise and efforts are in line with the customer and the organizational goals. Working with autonomous teams, I found that giving the members of the team context into their daily work improves the teams' outputs and reduces waste in the form of unnecessary iterations, backtracks and time.
Context is different depending on the person or team it's delivered to: The sales team may be interested in customer segmentation and how it contributes to solving problems for their clients. They may also be interested in what is currently being developed in engineering so they can retain existing clients by giving them an outlook into the roadmap. That's not to say that the sales team's leadership isn't capable of procuring cross-functional information themselves, but when information is processed and framed it opens up cognitive space to ask follow up questions and gain even more context instead of worrying about obtaining the information in the first place.
Being a master of context means first and foremost owning the product's 'why' and having a good grasp on who is the target audience, what are their pain points and how does the product provide solutions to these pain points while maintaining a sustainable competitive advantage. Armed with the understanding of the 'why' the master of context can then learn how each stakeholder's effort contributes to the business goals and effectively communicate it.
As Cliff mentions in his article, there is a fine line between communicating context and handing stakeholders the 'what should be built' on a silver platter: To me, the question of 'what' is owned cross-functionally between the product manager and the expert level stakeholder. Designers, engineers, sales team members, architects and other professionals should be empowered to have the foresight to envision how their capabilities can be translated into success metrics and how those roll up into business goals.
working as a master of context across the organization
One key argument in 'masters of product' is that product managers should "focus on doing their core jobs so well that the other reliant organizations in the company can take their outputs and run with them" to a point where the product manager isn't the automatic go-to person to prioritize issues and resolve trade-offs.
As a person who heard plenty of 'we're doing this because is what product wants' in my professional life, one of my responsibilities as a product manager is to advocate for the customer and more importantly, instill customer-centric thinking in stakeholders. In a customer-led organization, the goal is changing the terminology to 'we're doing this because as a customer I could achieve...". Getting stakeholders into a customer-first mindset requires finesse as each stakeholder has business goals to pursue and as a 'master of context' I want to view their goals through the customer's prism.
Transitioning into a scenario where teams are set up for autonomy require two key components from a product management standpoint: The first is relinquishing some control over outputs in favor of providing the team with more agency on the 'how': When a product manager acts as a 'master of context', they need to provide just enough 'why' and a facilitate a productive discussion on the 'what' that will enable the team to be creative about the 'how'.
The second component is the PM using the extra bandwidth and mental capacity created by not having to be in the drivers' seat, and use them to break organizational silos and build better communication channels cross-functionally. Once the communication infrastructure is created and teams are feeding each other information, the product manager can then refine their ability to improve product discovery, diving deeper into the voice of the consumer, vetting hypothesis and fleshing out additional context to drive the product roadmap.