2. Do You Want to Be a Product Manager?

christian crumlish
PM4UX
Published in
16 min readJun 14, 2021

So far the role of product manager probably sounds pretty good. Maybe a bit broad and over-leveraged (scary!) but able to play a pivotal role in what actually gets done that expands the range of influence beyond all but the most domineering UX leader.

If you’re already practicing UX in the context of a product team, or if you’re preparing to transition to a product-oriented organizational model, or being asked to fulfill a quasi-product role in addition to your UX responsibilities, then you’ve got good reasons for wanting to understand what makes product managers tick and what product management is really all about.

Towards the end of this year Rosenfeld Media will be publishing my book Product Management for UX People: From Designing to Thriving in a Product World (you may sign up there to be notified when it is available for order), the culmination of a multiple-year project that has unfolded with the input and support of the Design in Product community.

During the editorial and production process I am sharing early drafts of chapters, and I welcome any feedback here that will strengthen the material.

Beyond that lies the idea of fully moving from a UX-defined role to becoming a product manager yourself, full time. Maybe you’ve started wondering if you want to be a product manager, or even beginning to think that yes, in fact you do want this, you do want to be a product manager. If that’s part of your reason for picking up this book, then this is a good opportunity to practice the old “Five why’s” method of inquiry invented by precocious children, starting with the basic question:

Why Do You Want to Be a Product Manager?

Putting aside the challenges involved in doing any of that effectively, there are a number of reasons why it might have occurred to you that product management might represent a viable career growth direction for UX practitioners:

Professional and career

  • Professional interests
  • Career progression planning

Ambition

  • Realities of current org structure
  • Lust for power (“the dark side”)

Evolving interests

  • Waning interest in UX practitioner work
  • Fascination with business side of product

Professional and career reasons

UX career paths vary across organizations, for sure, but within the realm of design and related practices such as user research and UX writing the most common fork in the road is the matter of becoming a manager of other designers or aspiring to become a principal, leading by example as an individual contributor.

At least in some organizations, there is the possibility of a third path, one that might be thought of more like the “becoming a manager” path, and even less purely about design, which is becoming a product manager at some level and then climbing that ladder.

At Yahoo, before it was subsumed into Verizon, the VP of UED (user experience design) for the search product team, Larry Cornett, moved “up” into the role of VP of Product for that same team. Senior director of UED Luke Wroblewski took on a product role as well. This is the “if you can’t beat ’em, join ’em” approach.

Figure 2.1: At Yahoo, I saw Larry Cornett and Luke Wroblewski made the leap from User Experience to Product leadership roles.

So there are times when the organization may steer you in this direction by offering more or better or richer opportunities on the product track than they do on the UX track. (Another option in such a situation is to fight for better career and professional opportunities for UX practitioners, mind you, but it’s always worthwhile to assess the realities of a given situation as you assess how best to maneuver through it, just as a rock climber will spend some time studying the rock face before plunging onward and upward.)

Take the time to examine these pressures, which are fundamentally external. Be aware of them but look also to your own internal and intrinsic motivations to make sure your chosen path aligns with all of them as much as possible.

Ambition

Another driver for some is surely the opportunity to have the final say on some important things. Despite the stereotype of UXers answering every question with “it depends,” it can actually be frustrating for many to push hard for a strong point of view, stand up for users, make the case for research and design iteration, and still get overruled by someone in a different role who may or may not seem to fully understand the importance of user-centered design.

The urge to become the decider, at least on some things, the desire to be in the room when important things are being discussed and weighed, can also steer one’s thoughts toward product management. This temptation may strike one’s UX colleagues as a flirtation with “the dark side,” or even a selling out of UX ideals in the service of lust for power. (If only.)

There is nothing wrong with ambition. Wanting to have a say in things is also reasonable! At the same time, be careful what you wish for. There are two possible unintended consequences of getting more powerful in your org by wearing a product hat:

  • You may end up perpetuating an inferior approach to product management that dominates UX but does not use its value wisely.
  • You may end up losing what makes work meaningful for you.

Neither of those things will necessarily happen, but if ambition is your sole reason for looking into product roles, the risk is a lot higher.

44 Signs You Are Becoming a “Real” Product Manager

Note to editor: This is intended to be a guest sidebar / “view from the trenches” and we discussed making it a two-page spread if possible?

In his essay 44 Signs You Are Becoming a Product Manager, John Cutler (head of product research and education at Amplitude) gives a preview of the slings and arrows that go along with the decision-making responsibility of a product manager. He starts by asking “How do you know you’re on your way to earning your PM/PO wings? What signals progress? Your first release? Getting “certified” ? Putting together a pretty roadmap?” before saying No, it’s these 44 signs (reprinted with permission):

  1. You’ll feel like you are annoying the crap out of your team
  2. You’ll find yourself sheepishly asking for an estimate
  3. You’ll realize that estimates are worthless, but still be pressured for a “rough sense of timeframe”
  4. You’ll struggle to explain why your intuition is valid (and be right)
  5. You’ll struggle to explain why your intuition is valid (and be wrong)
  6. You’ll be pressured to ship something before it’s ready
  7. You’ll try to make something perfect when you should have shipped it months ago
  8. You’ll face the harsh reality of a usability test
  9. You’ll put together the best roadmap in the world, and get everyone to buy-in, and then everything will change in an instant
  10. You’ll forget a seemingly trivial detail that will cause a massive delay
  11. You’ll rabbit hole on a seemingly important detail that will cause a massive delay for no apparent customer value
  12. You’ll be blamed for being too solution focused
  13. You’ll be blamed for being too high level
  14. You’ll find out that a new competitor is killing it
  15. You’ll have to break crappy news to your team (often admitting that you’re to blame)
  16. You’ll be jealous about ___________ and how they do product (and be reminded of that fact because they incessantly blog about it)
  17. You’ll fancy yourself as technical but be humbled daily
  18. You’ll fancy yourself as UX-savvy but be humbled daily
  19. You’ll fancy yourself as business-savvy but be humbled daily
  20. You’ll say “my team”, but feel oddly distant from your team
  21. You’ll be worried about “distracting” your team, and find yourself not being transparent. And this will come back to haunt you
  22. You’ll find yourself parroting something engineers told you, and realize just how little you understand
  23. You’ll be asked to make your backlog / roadmap more visible, but then be derided when you shift things around
  24. You’ll have a day filled with meetings, and realize you added absolutely no value
  25. You’ll run a great meeting, and no one will notice
  26. You’ll work up a full-fledged wireframe, and then try to tell your UX team member that you don’t have a design in mind
  27. You’ll ship a dud feature that no one uses
  28. You’ll ship an awesome feature that no one even notices
  29. You’ll have to implement an exec’s idea, and know it sucks. And then have to live through the success theater that accompanies the release of said idea
  30. You’ll try to follow up on the impact of shipped features, but get overwhelmed by the next batch
  31. You’ll want to pull your hair out listening to your team debate the technical merits of two, almost identical approaches
  32. You’ll advocate for your pet solution against an almost identical team proposed approach
  33. You’ll tell a customer “it’s on the roadmap” and hear them laugh out loud
  34. You’ll say “No” to something just to prove to yourself that you have some influence and a point of view, and then realize that doing that is stupid
  35. You’ll say “Yes” to a customer in a moment of pure delusion, and then find yourself stubbornly trying to defend a feature that only they will use
  36. You’ll hear that you are not technical enough for the role
  37. You’ll hear that you are too technical for the role, and lack the soft skills
  38. You’ll go to a conference and learn about Lean Startup, and then come back to work and realize that the word hypothesis scares the shit out of people
  39. You’ll be the single wringable neck
  40. You’ll find yourself running cover for your team
  41. You’ll find yourself cursing your team under your breath
  42. You’ll be “empowered” on paper, but find yourself taking orders
  43. You’ll catch yourself giving orders, and learn to empower your team instead
  44. You’ll think you’ve learned from your mistakes, and you’ll magically make them again (just to make sure the learning is ingrained)

END OF SIDEBAR

One side effect you are guaranteed to experience is the burden of all this decision making. Like the proverbial dog who caught the car, you’ll inevitably at some point feel overwhelmed by the weight of critical decisions landing in your in box. It comes with the territory. Mind you, some people thrive on it!

Evolving interests

As you’ll see in Chapter 3, product work and UX work do exist on a spectrum with some overlap, some gray area, which tends to be at the strategic, system-level, big-picture, research and data-informed, concept model end of the spectrum.

For folks who already prefer that mix of tasks and specialties over the more production-oriented design craft end of the UX spectrum, transferring into product management can represent a way to continue moving in this direction, toward orchestration.

It’s also possible to become more interested in other aspects of making software that don’t bear on design as directly, even if they may still keep an intense customer focus. The business aspects of a product manager role rarely impinge on the creative world of user experience research, strategy, and design.

For sure, some UX leads end up getting deeply knowledgeable and wise about the business aspects of the experiences they are responsible for (and this in turn can lead to more informed choice down the road about whether to shift to a more business- oriented role a such as product manager or to stay in the UX lane and hang onto that savvy as yet another superpower in your kit).

Others among us are moving through a series of roles. There are engineers who become UX designers and then see in product management a way to combine those aptitudes in a single role.

In many ways, these are the best reasons for exploring a change of role, driven as they are by your internal and intrinsic needs and interests. At the same time they do not alone guarantee a successful satisfying transition if the organizational support is absent.

So, Are These Good Reasons?

All these reasons are legitimate and as we’ve seen they all come with their own caveats and consequences. You don’t need a good reason to explore a potential opportunity to grow. But do take some time to think about the tradeoffs and opportunity costs involved in pursuing a product management career or in sticking with user experience.

Look especially closely at whether you are falling for a “grass is greener” fallacy that romanticizes the advantage of the alternative or the road not taken and minimizes the mowing, weeding, and manure spreading that produced your neighbor’s green lawn.

In particular, UX practitioners considering the fork in the career path known as product management need to understand the day-to-day realities of doing the job

But What Exactly Do Ya Do, Here?

As UX folks start to rub elbows with product people you become acutely aware of (and possibly even worried about) the gray area where responsibilities overlap. And, for sure, the two roles do share many values (user-focus! research! iteration! testing/measuring! etc.).

This focuses more attention on these shared concerns, and can somewhat obscure the ways in which the roles differ, so you should know that the jobs are quite different indeed.

Anybody considering product management as a career should ask themselves two questions, first:

  1. Do I love spreadsheets?
  2. Am I a good writer?
  3. Am I deeply curious about interpersonal dynamics?

This is because product management is not a design job. It requires some familiarity with design of course and a deep sensitivity to user experience concerns, but the day-to-day tasks and craft work of product management rarely involve pushing pixels.

Oh, there’s a bit of diagram-making for sure, and there are a lot of PMs out there making wireframes and even prototypes, but even those folks spend the vast majority of their time working with words and data, not pictures.

So if you love spending your days in Figma or Sketch or Swift, then you might not enjoy giving most or all of that up for the product role and responsibility. Instead of living inside creative art-making software packages, you’re likely to spend the bulk of your time using agile scrum project management tools such as Jira (with Confluence usually), doing things like:

  • Writing specification docs
  • Decomposing epics into user stories
  • Grooming the backlog
  • Planning upcoming sprints
  • Answering developer questions on tickets
  • Reviewing demos and either accepting them or asking for revisions
  • Reviewing automatic test data
  • Looking at burn-down charts and other visualizations of progress.
  • Conducting retrospectives.

Where else will you spend your time? In email (or Slack, but definitely writing and replying to a lot of messages), and in your calendar software, scheduling meetings that don’t interrupt makers from their most productive times of day, facilitating agile rituals typically on bi-weekly cadence (planning, daily standups, demos, retrospectives), and reporting to the larger company, leadership, or board on roadmap updates quarterly if not monthly.

And that’s just the writing part.

You really do have to like numbers, math, analysis, spreadsheets, and databases to be a great product manager. It’s a very metric-informed, evidence-based practice. Some of the most valuable signals you get about what to ship next and how the things you’ve already shipped are faring comes in the form of massive waves of data that yield up their insights only through manipulation, reframing, study, and deep familiarity.

From the trenches:
Clement Kao, Principal PM at Blend & Cofounder at Product Manager HQ (PMHQ) points out “As an exception, truly amazing B2B PMs can get away without numbers, since they’re so deeply locked in with each individual customer’s priorities, needs, and mindsets. That said, there’s definitely no escaping numbers in B2C!”

And Matt LeMay of Sudden Compass raises a good nuance: “This is sometimes but not always true. I don’t like any of those things (“numbers, math, analysis, spreadsheet, or databases”), but I have the three qualities you described earlier.

For UX designers, the material you work with is the substance of the experience: the words (copy), the visual metaphors, the interactions, and the broader experience. Just as a potter develops out of necessity and aptitude a subtle and sophisticated feel for the texture, granularity, and performative properties of their clay, a UX practitioner develops a similar feel for the digital software materials with which they craft affordances.

For product managers, in a very real sense, the material you work with is this welter of data (alongside qualitative signals, of course), which has its own texture, granularity, and informative properties. It requires deep immersion for sustained periods to develop the necessary feel for your own product’s data.

Much in the way (I imagine) a farmer might notices something amiss in the sounds of the livestock in the yard or the number of eggs produced today or this past week, a product manager develops very sensitive antennae (or if you’re a pop culture enthusiast, call it a “Spidey Sense”) that react fast when the morning report on key northstar metrics herald an unexpected dip in daily active users or a spike in sales.

sidenote in author’s voice: And that’s before even getting into machine learning (ML) and other flavors of artificial intelligence (AI).

If you love charts, graphs, visualizing multi-dimensional data, numerical analysis, sleuthing, and “living in your data,” then you’re going to love product management.

A Typical Day

So you know what your days are like now doing UX. Depending on your role you may spend time conducting and analyzing user interviews and other forms of research and discovery, sketching, exploring and iterating on design solutions at a high or detailed level, critiquing and reviewing the design work of colleagues, developing and testing prototypes, crafting production ready interfaces, and so on.

You may spend entire days with minimal human communication and maximum time with a drawing package filling your large screen, lost in the creative flow of finding ever more satisfying solutions to challenging problems.

Not all days are the same, but there are recognizable patterns.

Similarly, product manager workdays change depending on where you are in the rhythmic development cadence, on the role you play on the team, and on the approach to product management pursued by your organization.

But there are recognizable patterns.

So, for example, across multiple product management roles I can synthesize a generic typical day that would fit many real days across those years, something like this.

At home / before official workday starts

4:30 am — wake up in the middle of the night and remember something important that nobody else is tracking. Either jot it down on the night-table or get out of bed, move to the home office, and update a jira ticket or reply to a message before getting some water and going back to sleep. (Maybe answer a few other overnight messages from remote teams first, while you’re up.)

6:30 am — get out of bed, look at Slack on phone, reply to some messages. Do morning routine: coffee, shower, dress, coffee, breakfast, email, Slack, Jira, coffee.

7:30 am — review daily update of northstar metric data. If anything seems interesting, dig into the source data and try not to lose track of time. If anything turns up that is threatening or promising and immediately actionable, notify other people of the issue and start a process of figuring out how to address it in time.

At work / real “workday:

9:00 am — facilitate daily standup with team (developers, sometimes the UX folks but they don’t always show up, other contributors), in this case functioning as a defacto PO (product owner):

  • You bring the donuts. (Literally, sometimes, and figuratively in the sense product expert Ken Norton has popularized, all the time).
  • Review quickly with each person what was accomplished yesterday (compared with what had been expected), what they expect to work on today, and whether anything is currently blocking their progress.
  • Keep the meeting moving, addressing anything that can be clarified right away (“Ankit, can you get Allie the credentials she needs for github?”) and tabling other items to follow up on afterward.

9:30 to about 2:30— A patchwork of:

  • meetings with other managers (in the sense of non-makers; that is, people for whom meetings are productive, as opposed to developers, designers, and other people for whom meetings tend to disrupt their creative flow), such as leads of adjacent teams (such as Eng, UX, Sales, and Operations), your own manager, managers who report to you (if any)
  • communication with customers, potential customers, and other stakeholders
  • spec writing, roadmap review, backlog grooming, message responding
  • data analysis, perhaps today involving customer feedback, poring over product analytics dashboards, sale forecasts, hardcord profit-and-loss Excel spreadsheets, or periodic reevaluation of progress against OKRs or other key performance indicator metrics.
  • lunch eaten at the desk

2:30 to about 5:30

  • meeting with makers towards the ends of their days (these can be regular 1–1s with people who report to you (if any), working meetings with team members to explore and solve problems, or task-based check-ins to track progress, provide guidance, and give support.
  • spec writing, roadmap review, backlog grooming, message responding
  • data analysis

At home again / after “workday”

6:30 to ??

Finally have time to

  • read long-form industry articles, product craft essays, reports from colleagues that you can never get to during the work day
  • similarly, work on long-form writing, analysis, and modeling projects without interruptions
  • try to be present at home with your family and loved ones
  • check data one more time before going to sleep.

But that’s just me, so for the rest of the book, you’ll hear from other product managers sharing a typical day in their lives, to give you a broader perspective on the various flavors of product management and environments in which it’s practiced.

So What if You Don’t Want to Be a Product Manager After All?

Whether you came into this merely curious or were on the fence but now you are positive that UX is the life for you and the siren song of product management no longer sounds so sweet, it will still behoove you as a UX practitioner to understand product management as well as you possibly can, among the many respected adjacent disciplines you work with and might even feel relieved that somebody wants to do that part of the work that you appreciate without feeling a desire to do yourself.

If you’re still unsure, the rest of the book should help provide you what you need to better inform that career decision.

And regardless of where you feel you are headed in the long term, you can still derive benefits from absorbing the product frame of mind, one in which you view yourself not just as a UX or user-centered designer but also as product designer (or researcher, strategist), working alongside PMs and product engineers.

Likewise, if you’re one of the many UX folks being pressed into fulfilling some of the non-design aspects of product work without having (or wanting) a PM title, working either in the absence of PMs, filling in as best you can, or in an organization that distributes more product work to UX people, these insights can prove helpful to you.

So even if you merely seek to understand the product point of view and work more productively with product managers, read on to foster that deeper understanding and better collaboration.

Key Insights

  • There are many legitimate reasons for considering a move from UX to product, some of which derive more from external pressures and others that come from internal or intrinsic wants. All come with caveats and it’s worth spending some time to examine your own reasons and look at the pros and cons associated with these factors with clear eyes.
  • The most common reasons are a desire for professional and career advancement and a shift in interests (“what gives you joy”) in work.
  • Product managers spend a lot more time writing and working with numbers than they do drawing screens and diagrams.
  • Success as a product manager depends in part on a willingness and ability to become deeply intimate with data. It’s hard to do this if that doesn’t sound interesting (or even “fun”) to you.
  • A product manager’s typical day looks a lot different from that of a user experience practitioner.

You can sign up to be notified when Product Management for UX People is available for pre-order at Rosenfeld Media.

--

--

christian crumlish
PM4UX
Editor for

Product leader @dinp.xyz, writing Product Management for UX Designers (Rosenfeld Media) and Growing Product People (Sense and Respond) — more xian @crumlish.me.