An excerpt from our newest title, Product Management for UX People by Christian Crumlish

We’ve just published our newest title, Product Management for UX People: From Designing to Thriving in a Product World, by christian crumlish. Below are the blurb and an excerpt of chapter 1, “What Exactly Does a Product Manager Do?,” so you can sample it for yourself. You can also check out the book site, which includes a table of contents, testimonials, and all the other good stuff you’d expect.

If you’d like to pick up a copy, you can purchase it directly from Rosenfeld Media and you’ll get a free copy of the ebook when you purchase the paperback.

OK, the blurb, followed by the excerpt; enjoy!

More and more, designers are grappling with product management — as a peer discipline, as the job title of a boss or teammate, and as a future career destination. But there is surprisingly little help for designers who seek to understand what it takes to manage products and services. In Product Management for UX People, Christian Crumlish plumbs the intersections and gaps between design and product management for both designers who want to work with product managers and designers who want to become product managers.

Chapter 1: What Exactly Does a Product Manager Do? (excerpt)

If you’re not sure what product managers do, you’re not alone. Quite a few hiring managers — not to mention entire businesses — are also confused about this job title and what exactly it means. It doesn’t help that there are a wide variety of legitimate approaches to product management that tend to emphasize one or another of the constituent proficiencies at the expense of the others.

As confusing as this may seem, there are multiple legitimate approaches to product management in practice today, because the work itself depends so heavily on context. That being said, every product manager has the same core responsibility: value.

Product Management Is Responsible for Value

The product manager is responsible for value, through the coordination and delivery of customer experiences, and for making sure that the experience being delivered to customers (and other stakeholders) provides enough value to be “hired” by the user and developed as a sustainable concern, ideally in service of a broader vision.

OK, but sustainable in what sense? It’s a broad goal. LinkedIn product lead and social change evangelist B. Pagels-Minor suggested at least one dimension of this: “Something the user values and repeatedly uses.” In addition to that, for a system of any kind, business or otherwise, to become sustainable, it needs to find repeatable cycles of inputs and outcomes that literally keep the system going. Some of the inputs, usually those related to people or money, need to be at least steady and consistent, if not growing, Whatever you’re building has to keep these cycles flowing.

So think of it this way: any sustaining value to the organization is derived by taking a fair share of the value created for the “customer” (or end user, subject, actor, protagonist).

Responsibility for value helps clarify a few roles that are often confused with product managers: project managers and product owners. Before digging into the building blocks of product management, let’s first get those different titles defined and distinguished.

A Product Manager Is Not a Project Manager

Product managers are frequently mixed up with project managers. Even people who know the difference will occasionally confuse them in speech. Abbreviations are no help, as both are commonly referred to as PMs with only context making the meaning clear. (Sometimes that context is “this company doesn’t have any project managers” or vice versa; other times, it’s based on the speaker, the team, and the conversation itself.)

To make things worse, project management can be one of the responsibilities of a product manager. PMs care a lot about schedules, know how to read a Gantt chart, strive to keep everything on track, and work to hold everyone to their commitments, but this should only be a sliver of their time and attention.

A project manager is a specialist whose subject matter knowledge helps them excel at understanding the fine points, but whose core expertise is keeping projects on track, on time, and on budget, not on defining the value of a product and driving the strategy to maximize that value.

Some project managers do become product managers and when they do, just as with UX designers, they must master a whole series of adjacent skills beyond “keeping the trains running on time.”

Product consultant and author Matt LeMay, co-founder of Sudden Compass, put it this way: “Product managers have both the opportunity and the responsibility to ask ‘why?’”

A Product Manager Is Not a Product Owner

There are core differences between a product manager and a product owner. Although companies often use the terms indiscriminately to mean the same thing or apply their own meaning, for this book, we’ll define them this way:

A product manager orchestrates the efforts of a cross-disciplinary team to ship software experiences as part of accomplishing strategic business goals.

A product owner is a person who shapes and guides the engineering team as they develop software. In this model, they are a bit like a very tactical product manager, but one who is primarily focused on the tracking tasks. This is an engineer-centric role invented in the absence of true product managers.

Originally, the product owner tended to be drawn from the company’s engineering pool, and some teams used a specialized scrum master role that required training and certification and focused on the project management dimensions of an Agile scrum development environment. Product owners from the engineering team were often a team lead but not always. However, today, there are many different real-world uses of this title in practice, including teams where the primary business stakeholder is called the product owner, or in some government contexts in which the “product owner” is the person ultimately responsible for what the team delivers, more akin to what most businesses would call a head of product or what some academic projects would call a primary investigator.

Product owner activities likewise are often part of the work of
a product manager, to the extent that some businesses even treat
the product owner as an entry- or low-level product manager job title, but again this somewhat obscures the origin of the role from outside of the product management tradition.

Where Did Product Managers Come From?

So where did the tradition of a product manager come from? Why does everyone now seem to speak in terms of “products” at all in this digital age, and why are the people called upon to pull it all together called product managers?

The deep history of product management came from the 20th century concept of marketing, which emerged as an attempt to really understand a potential customer and to be more scientific about measuring the size of the market, the reach of a product, and so on.

(Some of this should sound familiar, as new generations rediscover these ideas and frame them in terms of research, humans, users, experience, experimentation, or analysis.)

The product metaphor itself is a bit double-edged in the internet age. The value it offers is to help focus and concretize the offering you are building to meet the needs of real people, or do jobs for them, or ease their journeys, and so on.

But the very real need to be specific and clear about what you are making (and what you are not) can easily hide the slippery nature of online products, which differ from their industrial counterparts in two major ways that both fall under the heading of “actually being a service”:

• In contrast to physical products in the old “packaged widget in
  a box on a shelf” sense, most software made these days is SaaS (software as a service), hosted in the cloud, accessible via the web and sometimes with native app clients, and resistant to some of the finite constraints of the manufacturing process (sunk costs, waterfall processes, and limited ability to make affordable changes once the product starts shipping).
• Online products also tend to be services, in the sense of working for or providing assistance to their users in an ongoing way (vs. the concrete experience of using an object or tool).

Regardless of the subtext of the word product and the mental frames that may get dragged along by its use, it has emerged as a way of talking about the product or service being built to meet the needs of real people in a valuable way.

A mid-20th century product manager would have usually been someone with a business background, if not a degree in business, and the earliest digital equivalents inherited some of that DNA.

Product Manager as Business Manager

Product management to this day is perceived by most people as
a business discipline or practice. Core to the role of the product manager is the responsibility for the business case, business strategy, and financial viability of a product.

Unfortunately, this stereotype can be negative: for example, the “suit,” the bean-counter, or the boss man who only cares about the bottom line. Yes, there are plenty of people with product titles out there living up to those clichés, but it doesn’t have to be that way. UX designers interested in product management can start by embracing the realities, necessities, and even the joy of business. It doesn’t have to be a dirty word.

When the product manager role first emerged in large software and other tech companies, it came with that business foundation and was often paired with technology or balanced by engineering and perhaps one or more other pillars (such as clinical expertise in a health enterprise, or editorial content in a media company, etc., depending on the nature of the business).

The equivalent role that emerged at Microsoft at the time was called program manager. Today, program management usually refers to a separate discipline dedicated to operational execution of complex programs, generally consisting of multiple ongoing interrelated projects.

These PMs nearly always had MBAs and at times rubbed seasoned engineers and designers the wrong way when “put in charge” directly out of school.

A number of business titles and roles have contributed to how product management is practiced today, and along the way, many people have done product management work under these titles, roles such as business analyst, product marketer, customer success specialist, and others. Execution-related business skills, such as project management, decision-making, strategic alignment, and leadership factor in there somewhere as well.

Sometimes the business aspect of the role is summarized with a saying, “The product manager is the CEO of the product,” but this really isn’t true. The only value of that expression is that in an extremely broad way it suggests that the PM has a business responsibility for their product that is central and critical. The buck stops with the product manager.

But the expression is frankly more misleading than helpful because CEOs control the budget, CEOs can hire or fire the team, and just about everybody reports ultimately to the CEO. Product managers have business responsibilities, sure, but they do not wield anything like CEO power.

Joff Redfern, a VP of Product at Atlassian (and formerly LinkedIn and Facebook) prefers to frame this aspect of the role as thinking like a general manager. It has some of the same limitations in terms of direct authority, but more closely matches the notion of one person with business-related responsibility for a coherent chunk of work.

Clement Kao of Product Manager HQ points out the GMs also have hiring and firing responsibilities, and he prefers to frame these operational and strategic leadership aspects as being “both coaches and janitors.”

Alongside this business-focused type of product manager, the turn of the millennium saw some managers and lead developers emerge from engineering departments and take on product management roles, sometimes, at first, in the absence of a true product practice, but more generally as a new career path open to engineering managers.

Product Manager as Marketing Manager

Another antecedent of today’s product manager roles lies in the concept of a marketing manager or even a product marketing

manager, which is the historic origin of the role in 20th century business practices. Interestingly, the obsession with customer needs that is inherent in product management derives from this fundamental DNA. The obsessions today with addressing markets and achieving product-market fit are other elements of continuity with the marketing orientation of early product management.

Both roles still exist as distinct positions in many organizations. This dichotomy can potentially lead to turf or coordination issues when the product manager wants to approach product/marketing issues from a product-centric point of view and the product marketing manager wants to approach these same issues from a marketing-centric framework.

The article “Product Marketing Manager vs. Product Manager: Where Do You Draw the Line?” (www.productplan.com/learn/ product-manager-vs-product-marketing-manager/) does a nice job of delineating these roles and making a case for them being separate, boiling down the essence to this:

• Product management’s role is strategic oversight.
• Product marketing’s role is message creation.

Product Manager as Engineering Manager

Given that the context of all of this is software and technology, science and engineering, on some level any product manager in the internet age is a technical product manager, at least in the eyes of people who don’t work in tech. (In practice, roles defined as technical product managers almost always require a computer science or analytical or subject matter expertise with the specific technical approach of the business.)

Engineers with big-picture skills (such as technical design and architecture), a vision for the purpose and value of what the team is building, and the ability to debate pros and cons with other stakeholders to make the case for a specific direction, may find they have greater leverage and ability to steer the ship as product managers.

The influx of engineer-trained PMs into the field started rebalancing the mix of skills expected from product people, with the business sense still a core orientation and now coupled with a deep mastery of the technical issues involved in software development.

When the role is literally advertised as a “technical product manager” or at an engineering-led company such as Google or any of its many imitators, the job application will include several technical interviews involving puzzles and problem-solving questions very similar to the ones presented to programmers, without necessarily requiring them to write any code.

Questions involving sorting, efficiency, algorithmic complexity, etc. reflect product cultures that are heavily centered on engineering skill sets, experience, and frames of reference.

Google is famous both for making product managers “earn” engineering resources and buy in. There’s no guarantee that producing a spec means anyone will build it for you. But Google is also famous for cultivating and empowering product managers. The Associate Product Manager program with its structured training and rotation that Marissa Mayer pioneered there has been widely imitated at other aspiring tech giants.

But again, the type of product manager favored in shops with Google or Google-adjacent cultures tends to be highly technical, hence
these brain-teaser type interview sessions that really only make sense as a filter for programming-capable minds and not so much as the far-fetched notion that the PM will routinely debate the “big-O complexity” of several competing algorithmic approaches.

And to be fair, nowadays most decent places that pose challenges like these encourage them to collaborate with you and help you along with your thinking. (If a role like that is your goal and you aren’t a computer scientist, there are books to help you cram. More about choosing your career path in Chapter 2, “Do You Want to Be a Product Manager?”)

At Yahoo, the product organization was a peer to and equally as powerful as the engineering organization. From the beginning, Yahoo’s websites were planned and built by people called producers (adopting terminology from media and broadcasting).

Over several years, these jobs gained in complexity and ultimately diverged into two distinct roles, one focused on planning and directing what got built (product managers) and the other doing the actual building (front-end engineers). It actually took some time for the front-end developers to be accepted as peers in the engineering organization, given prejudices at the time against HTML markup and the other front-end languages, but the significance here is that the product role, at least at one of the 90s era internet tech companies (“dot coms”), shared a common ancestor with a programming job.

Fast forward to today, and the role is still a highly technical one. A strong UX practitioner is going to take a serious interest in the technology they are designing with and for, just as an artist takes pains to understand their materials, but at the same time the designer is empowered to explore possibilities without constantly bringing to mind the apparent limitations of the existing technical stack and codebase.

Product managers (and not just “technical” product managers), by contrast, must delve even more deeply into the substance and properties and limitations of the technologies being worked with and never really have the luxury of putting those factors to one side. (PMs also spend much more time working directly with engineers than most UX designers do, which creates further pressure to demonstrate a thorough command of the technical factors that figure into any difficult decision.)

The new hybrid eng/biz type product model still left a lot to be desired as practiced, as most companies still follow waterfall and command-and-control software development lifecycle practices, but in the first decade or so of the millennium a few influential practitioners studying what worked well in Silicon Valley started articulating a fresh model of “lean” and “agile” and “fully empowered” product management.