It\u2019s no secret that product management is often a misunderstood and misused role. Many companies restrict PMs to narrow, stereotypical jobs, hindering their potential impact. Without strong role models, some PMs fall victim to these product management myths and perpetuate them to new hires.<\/p>\n\n\n\n
Here are six wrong ways to think about the product managers, and an alternative that I like. <\/p>\n\n\n\n
This old chestnut is fading away, but I still come across PMs who believe it\u2019s their job to tell the developers and designers what to do, and to control their time and quality of outputs. First, that\u2019s not a CEO, that\u2019s a 1920s assembly-line manager. Second, while a product manager is indeed a leadership role, the PM certainly should not<\/em> try to manage the team. Good products are built through intense interdisciplinary collaboration. Having the PM call all the shots will result in weak product ideas, low team commitment (they\u2019re there just to deliver), and a huge workload for the PM; not to mention that engineers and designers will resent a PM trying to manage them. <\/p>\n\n\n\n Better model: The Trio\/Triad leadership model<\/a>. <\/p>\n\n\n\n This stereotype is typical of companies who adopted Scrum before they discovered Product Management (very common in Europe and Asia). A product owner has become a full-time role rather than a Scrum \u201chat\u201d. The PO is there to serve the team and to maximize delivery. She translates the roadmap (created by others) into product backlogs, user stories, and epics. She\u2019s expected to participate in all the ceremonies, but not to develop user and market expertise (that\u2019s the job of the Strategist \u2014 see below). It\u2019s a very laborious and joyless role that contributes to output, but rarely to outcomes. <\/p>\n\n\n\n Better alternatives: full-featured PM<\/a> that works closely with the team, but with far less Agile dev overhead, which leaves time to focus on the users, market, and business. <\/p>\n\n\n\n This is the missing half of the PO, a mid-level PM solely responsible for thinking of the \u201cbig picture\u201d, looking at the users, business and market, talking to managers and stakeholders (see the Facilitator<\/em> below) and devising the perfect roadmap. However no PM, senior has she may be, can do a good job without having tactical understanding of the software and the team. Handing off features to someone else to figure out the \u201csmall details\u201d has never worked. Product development requires many iterations and changes. Splitting the decisions across two people makes everything slower and less effective. <\/p>\n\n\n\n Better model: PMs at all levels should do both outbound (customer\/market-facing) and inbound (team\/product-facing) work. They should think both tactically and strategically<\/a>. With seniority, the strategic, operational, and political parts grow, but being in the details and knowing the people that do the work is a must-have for any PM no matter her rank. <\/p>\n\n\n\n This person\u2019s job is to run between managers, stakeholders, and team, collect everyone\u2019s product ideas, then mediate some compromise. In practice good products are never \u201cdiscovered\u201d through consensus, so this is a massive waste of PM talent. The facilitator PM is powerless to make decisions, even if she understands the users, market, product and the business very well. Her ability to create a positive impact is very limited. <\/p>\n\n\n\n Better model: Facilitate agreed-upon outcome goals<\/em> with managers and stakeholders, then empower each part of the org to find ways to achieve these goals (see the GIST model<\/a>, explained in detail in my book Evidence-Guided<\/a>).<\/p>\n\n\n\n Whether it\u2019s OKR, OST, SAFe, GIST, or the various Agile and launch processes, PMs are often expected to make it all happen. Managing the processes-of-the-day, ones they had no part in choosing, creates a ton of work for PMs (Jira tickets anyone?). Accumulation of frameworks and methodologies can easily overwhelm and distract the product org, and especially the PMs. Ultimately \u2014and I\u2019m saying this as someone who creates frameworks for a living \u2014 implementing a process is output<\/em>, and one that doesn\u2019t necessarily lead to outcomes. <\/p>\n\n\n\n Better alternative: It\u2019s much better if PMs, and more broadly, product trios, are charged with achieving better product development outcomes<\/a>, while being allowed to be flexible in how to implement the processes. <\/p>\n\n\nThe Product Owner<\/h3>\n\n\n\n
The Strategist<\/h2>\n\n\n\n
The Facilitator<\/h3>\n\n\n\n
The Process Manager<\/h3>\n\n\n\n