Sample Chapter: Product Management for UX People

This is a sample chapter from Christian Crumlish’s book Product Management for UX People: From Designing to Thriving in a Product World. 2022, Rosenfeld Media.

Chapter 1: What Exactly Does a Product Manager Do?

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.

From the Trenches…

What We Talk About When We Talk About Value

The first person who taught me to focus on “value” as the lodestar of product management was Jay Zaveri, who was my chief product officer at the time, at a start-up called CloudOn, and now runs a product incubator at Social Capital, a VC firm in Palo Alto.

I checked back with him because when people ask what defines value, it’s hard to avoid circularity of the “you know it when you see it variety.” Some people emphasize value to the whole system vs. monetary value, or value that accrues to the owner of the organization alone. However, Jay put it this way: “Value is something special that a person or customer experiences that never existed in the same way for them in the past—it’s a product that is useful, usable, and desirable. Value fulfills a deep need, desire, or want for the customer that they did not even know existed. It’s apparent when something is technologically differentiated (‘cheaper, faster, better’), abundantly available (‘accessible in a way that was only available to few before’), and changes human behavior (in a way that is beneficial to the person or customer).”

When asked who gets this value, he said, “I think people get confused by adding financial metrics as value metrics. Some of those are necessary, but not sufficient, and some are pure garbage. No true value is created by just financial and growth metrics; in fact, we now know there are serious unintended consequences if you are focused only on them. Nothing beats staying focused on true value to your customer—everyone wins!”

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.)

Note: In this book, PM means Product Manager

Forget PrM or ProM, too, as potential abbreviations—still no distinguishing characters. And I haven’t met anyone yet who wants to go around calling them ProjMs and ProdMs, or PjMs and PdMs for that matter. In this book, PM stands for product manager.

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.

From the Trenches…

MBA Not Required

A couple of years ago, I was part of a team led by Matte Scheinker that was charged with raising the product bar at AOL, which had newly spun off from its disappointing Time/Warner merger and was playing catch-up with a decade-old style of web development. One of the things we did was review and update the HR ladders for product managers and UX designers, indicating what level of accomplishment was required across a series of criteria to be hired at or promoted to each level—from associate to VP (with an individual-contributor track leading to principal, at the director level for designers).

The old grid required the product managers to have an MBA. We removed this. The HR department asked if we could make it “MBA preferred,” but we said that this wasn’t the case. If anything, we were MBA-neutral. An MBA might help make a PM better at the business side of the role, or it might not. The time spent getting the MBA yielded one set of experiences and contacts, and the equivalent time spent working yielded another. By itself, the degree didn’t tell us much; however, we didn’t penalize anyone for having an MBA!

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 market- ing 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.

Note: The Technical PM Interview

• I still fondly recall a day I spent on the Google campus being interviewed and taken to lunch by a sequence of 11 white men of varying ages and hair colors and degrees of athleticism or geekiness. Many of the interviews were a lot of fun and, to be honest, I’ve always liked puzzles, although not so much under pressure with big bucks at stake. They rotate these questions over time so that you can usually find expired examples with a little searching. For example, I was asked at one point how an algorithm might work to efficiently zero in on the correct five-digit passcode on a keypad, given certain rules or constraints about the numbers (to do with repetition, etc.). As I said, it was almost fun.

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.

Product Manager as Experimental Explorer

Marty Cagan, a consultant with the Silicon Valley Product Group and author of the book Inspired, made a strong case for empowering the product team to investigate problem spaces, conduct discovery processes, meet customers and prospects face-to-face, and seek to deeply understand what people need and what they will love to bring valuable products to the market.

Rich Mironov, a product consultant who advises companies, takes interim product executive roles (he calls this smoke jumping) and writes and teaches workshops. They and others have sought to raise the bar and to highlight the most effective techniques, approaches, and mindsets, while remaining clear-eyed and cautionary about the institutional patterns and incentives that can push back against these approaches.

For example, an empowered product team should understand the goals and outcomes it is seeking and be engaged in a process of iterating experimentally toward meeting those goals. The team should be capable of communicating to others what the current snapshot of the plan is, in the form of a roadmap (much more on this to come), expressed in terms of what is underway right now, what is coming up next, and what is expected to come later.

Many leaders in traditional organizations balk when they see a roadmap communicated this way, especially if what they had in mind when they asked to see the roadmap was really a set of firm release dates on which clearly defined features would be delivered and launched.

But committing to deliver a feature on a certain date, based on a fully baked specification, is a recipe for disaster. That process is too brittle and fails in the face of new information, data from users, stakeholders, and changing market conditions, just to name a few.

This is the same notion from the “lean” movement, popularized by Eric Ries’s book The Lean Startup: The product manager in an empowered team is facilitating a constant cycle that involves learning from what is currently “shipped” and “in the wild,” feeding these insights back into renewed discovery processes driven by qualitative inquiry to explore hypotheses and seek understanding, redefinition of the problem space, identification of further opportunities or experiments worth exploring, decisions about what to build or fix next, and shipping to start the cycle anew.

This cycle shown in Figure 1.1 can be modeled in great detail but is most often reduced to “Build, Measure, Learn.”

Figure 1.1
“Build, measure, learn” is a simple but powerful model that lies at the heart of lean product management, with its bias to action and emphasis on learning and experimentation.

It’s worth noting that despite the title and the fact that it’s a cycle, you generally do not start with building. You start by learning something or by measuring (initially assessing) something, learning about something, and then building a thing.

This process of constant learning, feeding back into discovery, redefinition of problems and opportunities, and iterative design is applicable in the early stages while prototyping new ideas, as well as throughout the life of a product. The approach is still gaining adherents (for example, people like Jeff Gothelf and Josh Seiden have worked hard to bring lean ideas about experimentation to the UX community). Outside of innovative tech companies and start-ups, though, the idea of a product manager as an experimenter (or “mad scientist”) is not as fully distributed and accepted.

But all product managers work with data and spend hours every week studying it closely. Whatever the cycle of learning and iteration, the job cannot be done without accurate signals about what is working and how the software is actually being used, and this focus on managing what you can measure carries through all of these strands mentioned so far—business, engineering, and entrepreneurial experimentation.

The most recent archetype to contribute their superpowers to the ideal product manager is one you should be familiar with: the designer.

Product Manager as Creative Artist

The experimental product manager is already more of a creative type than a simple number cruncher or bean counter. This person is someone who is intensely exploring possibilities and looking for ways to discover new solutions to acute problems.

The rise of user experience design in all its various forms, alongside the business-school friendly notion of “design thinking,” coincided in the culture with widespread awareness of the creative mythology of the Apple computer, the heroic figure of Steve Jobs, and for design aficionados, Jobs’s collaboration with industrial designer Jonathan Ive.

Suddenly, creative founders were getting funding for their own start-ups. Other start-ups were making their first design hires much earlier in the process. Design (or “design thinking”) offered proven methods for harnessing creativity and inventing innovative solutions to interesting problems.

Product management evolved as well. At first, PMs paid lip service to UX design, made their own wireframes based on zero research, and asked designers to, more or less, color them in. But now product practitioners take user experience research and design seriously as core disciplines with invaluable, necessary skills and techniques. They also foster mindsets that are required to develop product experiences that people will love and return to again and again.

The lean movement had already shifted its focus emphatically onto the customer (or potential customer). Conveniently user experience research and design revolves around this exact same obsession! UX has methods and traditions for learning from customers, and provides systems and models and tools for exploring and communicating solutions.

Design also excels at redefining problems and questioning prior assumptions, and much like UX design leads, product managers are charged with inspiring and rallying creativity in others. So alongside the business heads, coders, and founder types turning into product managers, some user experience designers, managers, directors, and VPs now jump to the adjacent product track as their careers evolve.

Three Other Traits Shared by All Great Product Managers

Great product managers tend to have the following personality
characteristics:

• Curious
• Connecting
• Courageous

They are curious almost to the extent of feeling like a busybody, being nosy, wanting to “know all the things,” keeping tabs on everything, and being incredibly “high context” and thorough about understanding.

They are connecting in the sense of constantly “connecting the dots” to form the big picture, orchestrating the performance, keeping people in the loop, providing the glue or lubrication or the circulatory fluid or whatever metaphor you prefer for the combination of emotional intelligence, “soft skills,” and implicit ties that enable teams to thrive and work well.

And they are courageous in the sense of being brave enough to take risks, make mistakes, face problems square on, evaluate failures coldly, and learn ferociously from every experience, good or bad. This courageous behavior sets a tone that encourages others to try harder and seek more difficult goals.

So What Does a PM Do?

OK, so now you know what product managers are responsible for (value and focus), where product managers came from (from all over), and what makes a good product manager (business sense, entrepreneurialism, technical chops, experimentalism, creativity, inquisitiveness, emotional intelligence, and courage—easy peasy, right?).

But how does a PM apply that mix of skills and aptitudes to fulfill these responsibilities? What are the primary activities, processes, and tasks of a product manager, or in other words, “What exactly does a PM do all day?”

For a day in the life of a product manager, check out the section “A Typical Day” in Chapter 2, “Do You Want to Be a Product Manager?”

Key Insights

• Product managers are responsible for value. A sufficiently valuable product will delight customers and support the business making the product financially.
• Don’t confuse product management and project management, but product managers do usually have some project management responsibilities.
• A product owner fills a role in Agile scrum development practices and is not the same as a product manager, but some product managers do fill this role as well.
• Product management originated as a business discipline, influenced by product marketing, business analysis, program management, among other practices studied in MBA programs.
• In the software development world, many engineering managers have evolved into product managers.
• In Silicon Valley (writ large), product management has taken on the entrepreneurial virtues of experimentation and exploration, and the “build, measure, learn” cycle.
• Today, it is becoming more common for UX design practitioners and managers to move into product management roles, bringing the creativity and innovation of design crafts with them. (You are here.)
• Great product managers are (benign) busybodies who constantly weave together the motley strands that make up software and are brave enough to lead teams into the unknown in search of insights and ever greater value.

Back to Product Management for UX People