3. UX Skills that Carry Over

There will always be some overlap between the concerns of product managers and UX professionals, and this can function as a healthy tension if addressed forthrightly or a wasteful turf battle if not.

Many UX designers look at this overlap and wonder really how different the two roles are, or need be. For those who are considering moving into a new role, this raises three important questions:

• Which of my existing skills have equipped me (at least in part) to be a product manager (and will continue to be helpful to me in that new role)?
• Which of my existing skills and expertise will be less relevant or entirely unneeded in a product role, and
• What are the new skills and practices I will need to master to complement my foundation in UX?

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.

So, what are the qualities of a UX professional that stand her in good stead as a product leader? It helps first to clarify the boundaries and distinctions between UX and product roles and responsibilities.

You’ll also need to dig a bit into the details and get specific about tasks and skills that might lay in the domain of a product manager, product designer, or UX practitioner. Something called a “skills histogram” gives you a structured way to investigate these questions in your own context and landscape.

Then, with concepts clarified and the landscape mapped, you can take note of the specific areas of user experience mastery that most directly apply to a product management career.

How PM differs from UX

The adjacency between product and UX design can be deceptive. The roles, rituals and practices of the two disciplines are different in many critical ways.

To me, the biggest night-and-day difference between being a UX practitioner and being a product management professional has been the matter of making decisions.

The decider

Of course every role requires decisions and has areas of responsibility where “the buck stops,” and no practice has the monopoly on decisiveness, but in a very real way product management is a role that consists almost entirely of making decisions.

Big decisions (should we build a new feature or fix an existing one?), medium sized decisions (can we ship what we just built or does it still need more work?), small decisions (is this particular bug a blocker for our next release?), and tiny decisions (does this user story belong above that one in the backlog?). An unending cascade of decisions. Decisions all day long from waking to bedtime.

From the trenches

UX leader Peter Boersma, who has experience in product management as well, points out the PMs do not make all final decisions. Designers have final say over critical UX choices. Engineers and need to be responsible for technical architecture decisions, framework choices and so on. PMs don’t have a monopoly on decision-making at all, but at the same time, they make more decisions per hour than any of those other roles.

Still, it’s true that on a mature, empowered team, a product manager facilitates decision-making and ensures that decisions get made through consultation and collaboration across adjacent disciplines.

Matt LeMay makes a similar point: “I do feel the need to say here that good product managers are making decisions collaboratively — I’ve actually seen a number of people transition to PM roles because they want to be “the decider,” only to immediately lose the trust of their team by making decisions in a siloed and anti-collaborative way. If anything, I would hope that people coming from the UX side would be sensitive to what it feels like to be excluded from a decision — and would be inclined to be more thoughtful partners in decision-making.”

If you’re a UX designer who feels like you are sometimes left out when the final decisions are made and your interest in product management has to do with wanting to be the one to make more of the decisions, well your gut instinct is not wrong. I’d be lying if I said that wasn’t one of the goals that motivated me along this path, but let me also just add a note of caution from the school of careful what you wish for. Product managers don’t get to say “it depends.”

One of the hardest things I’ve found about taking on the mantle of decision making is recognizing that it’s impossible to make so many decisions flawlessly. You have to make peace with the fact that you will get some things wrong. You will make decisions that don’t pan out and decisions that make it clear the other choice would have been better.

“When you don’t make a decision, you’ve actually ‘made the decision to delay.’ Many entry-level PMs assume ‘If I haven’t decided yet, then it doesn’t count against me’ but putting off a decision is itself a hidden decision with its own consequences.”
— Clement Kao

For some reason there is a folk consensus among PMs that even if you’re doing well you’re going to make the wrong decision 25–35% of the time. You just have to hope you don’t make a company-killing goof along the way. One good framing for why you need to get comfortable with this is captured in the aphorism from LinkedIn founder (Reid Hoffman) about how (paraphrasing) if you’re not a little embarrassed by the product you release then you waited too long to ship it.

That is, you won’t have the luxury to chase down every data point and every conceivable bit of research up to the point of diminishing returns for each decision, not when you’re making literally scores of decisions a day.

If anything, modern agile development processes anticipate this with their emphasis on “rough consensus and running code.”

One abstraction layer from design

Another big difference is that product managers are not designers!

Good ones care about design, and the role does involve providing requirements and other materials to help inform design, sometimes guiding designers, and always facilitating the building and implementation of designs. But the last thing a designer wants is a product manager who “helpfully” does the wireframes or has a few (cast-iron) “ideas about how to design it.”

A great product manager will be an advocate for user experience practices and will value and champion design, while being careful not to tread on the preserve and prerogatives of the design team.

Now it’s true that product managers still make diagrams and solve problems and so on, but if your passion is pushing pixels and your happy place is in Sketch or Figma, then be aware that most product managers spend very little or no time using design software.

If you’re the kind of designer who has never feared design management and derives creative satisfaction from deploying a team of talented individuals and bringing out their best work collectively to make something amazing, then taking your hands off the pixel-pushing controls may not feel like deprivation.

Pragmatism and synthesis vs. idealism and purity

When I was senior director of product management at CloudOn, a startup we subsequently sold to Dropbox, we counted it as a great victory that even our engineering leadership framed many of their arguments about what technical, process, or product decision they favored in terms of what would be best for the user experience.

We knew this verbiage might go no deeper than lip service and may still lean heavily on personal opinion about what makes a great experience vs. rigorous user research and testing based insights and so on, but it was still a beachhead in the ongoing dialogue about how best to make software.

At the time I was running the UX practice as well. It was not just the UX reported up into me (as it often does roll up to product leadership in many tech organizations) but that at the time I did not have a leader for the team to both give me leverage and to argue with me about the best way forward.

I was trying to wear both hats, as UX lead and as a product director. As best as I could I tried to stake out distinct points of view and weigh them against each other. But the truth is that — much like playing a card game against yourself — the ability to see both sides collapses the debate and I always knew what I really thought and wanted to do. I actually craved a strong UX leader to spar with and find the best results.

At one point, in a meeting when once again someone made a case for doing or not doing something or fixing or not fixing something by appealing to the user experience I caught myself replying “f*** the user experience” — meaning, in short, that we couldn’t afford to keep fiddling with the dang thing and we needed to ship it despite this compromise.

But I did shock myself when I heard myself say that.

The truth is that UX is a role for idealists, purists, seekers, and revolutionaries. Compromise is hard for such folks. As yeoman of the common man, tribune of the people, we UXers stand up to power and fight for the rights of the end user. Music swells, as do our heads. We are, dare we say it, better than our colleagues!

OK, not every UX enthusiast gives off that “I don’t even own a TV” vibe but let’s just say there is a serious need for the voice of the user to be represented when decisions are made.

Product managers do not have the luxury of purity or single-minded idealism. We do have ideals. We have values. We have north-star goals and we have many masters. A big part of product is navigating the path of balance between competing priorities, without losing sight of the mission.

Taking this thought a step further, Matt LeMay emphasizes that “the idea that you need to give up the purity of a single perspective and be able to synthesize and compromise is so important, and it isn’t discussed enough,” and I really think he’s right.

UX Superpower Alert

Probably the great comeuppance I’ve experienced since achieving roles with real product authority is that the end result is always something different from what I personally might have shipped had all the decisions been left up to me. No good idea comes out the other end of the process unchanged and fortunately I have come to view that as an additive, holistic process where the end result frequently transcends anything I might have cooked up on my own. Even if anchored in a tradition that prizes purity of motive and pixel-perfection, most of us grounded in UX are past masters at synthesizing holistic solutions that address multiple converging forces, needs, and cross-pressures.

Lean into it!

This posture will inevitably clash with any one very strong point of view or area of expertise. The sales team, customer support, the CEO, the data reports, the app store reviews, and the roadmap may all be shouting about entirely distinct Very Important Things at the same time. As a PM you have to pick and choose and you have to sometimes disappoint.

The day-to-day tasks are mostly different

Designers spend their days researching, sketching, ideating, critiquing, prototyping, testing, and so on. Design managers do art direction and other design strategy and leadership functions, manage the career and professional development of designers and so on.

Product managers write email. They send Slack messages. They write spec docs. They write proposals. They write release notes. They groom backlogs. They update roadmaps and present on how last quarter went to stakeholders. They talk to customers (hey, that’s not so different! — or shouldn’t be). They query databases. They consume data reports like water. They lie awake at night worrying about every single thing.

UX vs Product skills histogram

User Experience and Product Management are both “magpie” disciplines. They both draw from multiple sources, are syncretic, and cover a different subset of skills and aptitudes from team to team, and from individual to individual. Over the years, I have found it useful to make something I call a “skills histogram” to assess myself, direct reports, potential hires, and teams as a whole.

Author’s Note: After I shared this method with Erin Stratos from Ford Labs she adapted it to her own team and I’ve incorporated some of her ideas into how I do it now.

The easiest way to grok this idea is to make one for yourself, so here’s what you do. First of all, make a list of the UX skills you are familiar with, bonus points if you can arrange them roughly from the strategic discovery, systems thinking and design research end to the design craft and practitioner execution end of the spectrum.

There is no right or wrong list or order. I would expect your list to vary from mine, but I am suggesting this kind of sort for a reason which will become apparent presently.

So the last time I made this list for myself I came up with something like this (Figure 3.1):

Figure 3.1: Don’t worry too much about anyone else’s opinions about terminology or jargon. Use terms that make sense to you and your cow-orkers.

• Branding
• UI System creation
• Front end development
• Sound & motion
• Visual design
• Conversational design
• Prototyping
• Studio critique & iteration
• Interaction design
• Wireframing
• UX Writing

That was my list of crafts, and then continuing “upstream” or “bigger picture” in the process, I finished my list of UX skills with these (Figure 3.2):

Figure 3.2: One person’s single item is another person’s list of three or four, so again no right or wrong answers.

• Content Strategy
• Collaborative design
• Service Design
• Sketching
• Information architecture
• UX strategy
• Personas & user journeys
• User research
• Research synthesis
• Stakeholder facilitation
• Concept Modeling
• Usability Testing

The first or top half of the list are UX skills that are not part of product management. The latter half are UX skills that many product managers are at times responsible for.

UX histogram

Now, turn your list on its side and assess yourself for each of the skills or areas of expertise. I’m ok with eyeballing it, but to help with calibrating, use a 9 point scale with these touchpoints:

1 — novice

3 — beginner

5 — competent

7 — proficient

9 — expert

Rate yourself, and be honest! There’s no value in fooling yourself. Remember that you don’t need to be an expert in every part of the job to be a good UX practitioner, but if you know where you aren’t as strong you can seek out collaborators with complementary skills, or use this insight to inform your professional development goals.

So, while I mainly lead teams, advise CEOs, and coach product leaders these days, as a UX practitioner here is my current self assessment (Figure 3.3):

Figure 3.3: Voila! My UX histogram. What does yours look like? Do you recognize yourself in the mirror?

Product & UX histogram

Now let’s talk about the skills that are part of product management but rarely the responsibility of a UX practitioner.

Note: It’s ok if you don’t yet know what a lot of these things are. It’s cool if you do, though, and I’m sure you must if you’ve been doing UX work in a product context at all up to now. But regardless, we will go into these topics in detail, worry not.

Here’s a working list (Figure 3.4):

Figure 3.4: As with earlier elements of this list, these items are just the latest iteration of the skills I find most relevant in my work and on my teams, and it borrows ideas from Erin Stratos, as noted above.

• Customer interaction
• Market research
• Data analysis
• Sprint planning
• Backlog maintenance
• Bug tracking
• North star metrics
• Acceptance criteria
• User stories & epics
• Roadmapping
• MVP definition
• Prioritization
• Revenue modeling
• Hypotheses & experimentation
• Risk management
• Architecture strategy
• Product-market fit

Now turn that whole longer list on its side and score yourself on these other items. You can leave lines blank if you haven’t even encountered them but give yourself at least a point if you’ve worked with product managers doing these things, or on teams that talked about these matters.

Full disclosure, here is my full stack Product / UX histogram (Figure 3.5):

Figure 3.5: Of course others may disagree!

When I look at the skillsets that go into product and user experience practices that I feel I am strongest at today, it makes sense in retrospect at least why I gravitates first toward the strategic / planning end of the UX spectrum and also why I ended up going deeply into product.

Product & UX histogram

So a product histogram would be the two leftmost categories in the list, but dropping off most of the design craft (Figure 3.6):

Figure 3.6: So this is my product histogram.

Note: You may ask why you bothered to rate yourself in UX skills that don’t apply much to product management and if you did I’d say so that you have the fullest context possible and can view these various subsections of the spectrum as related to each other.

If you are a UX or product practitioner, your own histogram can help you explore areas to strengthen and existing strengths to lean into, can help you select mentors and recognize the kinds of team you’ll grow on.

As a team lead, you can make histograms (they don’t have to be this detailed) for each team member and essentially overlay them to see where the team as a whole is strong or weak, needs mentoring or coaching or augmentation, even possibly where you are over-indexed on some particular skills that’s in everybody’s comfort zone.

We’ll dig into new product management skills for the bulk of this book but in the rest of this chapter let’s look at which of your UX skills and experiences are going to be most useful on a product teams. Spoiler alert: I already mentioned that the part of the histogram list that overlaps product and UX is your preexisting sweet spot, but let’s dig into the big four as I see it:

1. information architecture
2. intense customer fascination
3. solving problems through iterative design
4. leading through influence

First, let’s start with the old school concept of IA.

Information architecture

If there’s one core user experience aptitude that I think most directly applies to product management, it’s that oldest of “old skool” practices, information architecture (or IA for short). For some people IA still just means figuring out sitemaps and the names of navigation menus, when that has always been just the tip of the iceberg.

The critical contribution of information architecture to software design is the mapping of a “meaning layer” that is abstracted from the specifics of the pixels, the bits, the lines of code, the data records, etc. Information architecture provides a toolkit that a product manager can use to forge consensus about what exactly it is that everyone is getting together to build, what is it for, who is it for, what does it do, how, and why? What problem does it solve? Where does it fit into the customer’s daily journey, how does it provide a better fit for the jobs to be done than the existing ways of doing these things.

How is it all organized and structured? Where is the internal complexity and how is it presented in a more digestible way to various stakeholders who need to interact with the product?

Concept models, architecture, diagrams, user journey, swim lanes, flow diagrams, and even the humble old site maps can function as the sort of edge artifact that multiple disciplines can rally around and use as a blueprint or map of where we are today and where we’re headed.

The ability to block out information relationships, explore logic and flows in a formalized document that other folks can respond to comes in handy endlessly in product communication, alignment and coordination.

IA is a superpower that will aid your own thinking and your ability to rally and persuading your colleagues.

From the Trenches

Maps make great posters. When you help your team visualize what you’re making or how it’s supposed to work, you can print it out huge and hang it up on a wall where everyone can see it and talk about. This is a gift to everyone else of something that you needed anyway.

When I was at the Yahoo Developer Network, we one time published all of our services in the form of a subway map and gave it out to everyone on our platform. Another time we brainstormed a concept model for our new Open Strategy, printed it on a plotter, and hung it in a heavily trafficked hallway near us.

We also attached a magic marker on a string, scribbled on it a bit, and tore the corners some so people would understand that it was a conversation, and not a declaration. Once a week or so we’d consolidate all the latest comments, re-routed arrows, stickies, cross-outs, and additions, update the concept model, re-flow it and print it out again for further comment. This became almost a game anyone on the team could play and since I sat on the other side of the cubicle wall I got to hear fascinating debates about the purpose and meaning and opportunity of our new platform strategy.

Getting outside the building

A concept popularized by the lean startup movement is “get outside the building.” It tells us not to wait passively to find out what our customers and potential customers want or need or find frustrating. We can learn a lot from product analytics, market research, sentiment analysis, and even customer feedback and customer support reports, but there’s no substitute to getting out of our comfort zone and meeting our customers and other stakeholders in their work environments.

On an individual level, product folks are encouraged to commit to something like contact a customer outside of work at least once a week, but like so many of these customer-centric practices, they really only work when the organization is committed to ongoing user research and product discovery in general.

Your background in UX should give you a keen understanding of the fundamental role research plays in user-centered design. Furthermore, if you move into a product manager role, you are going to find a natural ally in the UX researchers in your organization (or, in some cases, you will need to fight to hire user researchers).

There is a risk that product managers will pursue their own rogue research and outreach missions without coordinating with user researchers or other marketing research teams. If this happens, there can be a lot of wasted and duplicative effort, sometimes justified because the questions being asked or the research goals are oriented differently.

Believe me, though, it’s more than worth it to find common ground with anyone else talking to real people who do or might use your product. At the very least ask to piggy back on each other’s forays into research, but ideally, work together to develop a shared agenda and make the most of interviews and other research modalities, as a team.

UX Superpower Alert

This alert comes with a caveat. Your time involved with UX research clearly provides you with superpowers when it comes to techniques for understanding customers. At the same time, sharing the responsibility for product discovery with people who may follow different conventions can be challenging if you aren’t willing to make space for approaches that may not seem ideal to you. Maybe you won’t be leading the research. Figure out how to make the research as successful as possible, regardless.

Alëna Iouguina wrote a wonderful guide to how product managers and UX researchers can pair with each other productively, based on her experiences at Shopify (https://ux.shopify.com/good-things-happen-when-a-product-manager-pairs-with-a-ux-researcher-a88923c94ce8). She makes the point that the product manager must ultimately act on the insights derived from the research (in a way that the researcher does not) and that the ability to collaborate on shaping the inquiry is the best way to drive research in a productive direction.

I’m particularly fond of this diagram she shares in the article, showing a virtuous cycle of ongoing research, learning, launches, and further research, ad infinitum (Figure 3.7).

Figure 3.7: Alëna Iouguina shares this cycle that shows where the optimal spaces for collaboration occur in the research / launch cycle.

Data-informed design and experimentation

Now for some of you this third UX aptitude that applies well to product management may be a bit of a reach. UX has not made its peace with data in every organization. (Some do not gather data robustly or analyze it rigorously, others silo the data away from the design and creative processes, and others still use data oppressively to dictate design decisions in a manner that leaves UX designers with bad associations for the concept of data in general).

One phrase you may hear thrown about that makes me bristle a bit is “data-driven design.” Data is not a good driver. Data, please don’t take the wheel. My dashboard doesn’t steer my car. But data is hugely important for keeping the wheels on the road, the car in its lane, and the destination firmly in sight. So, like many I prefer to talk about “data-informed design.” I can’t imagine doing UX design or product management the way we used to, almost entirely based on our guts or at best some up front research and then hit or miss based on what we could gather about some traffic, some clicks. and some sales.

Today I am spoiled. I work on well instrumented products and can examine the user pathways and stumbling blocks in my products in an incredibly fine grained way that would have made me envious a decade ago. I have so much more information now about what is happening, but it’s important to remember that these funnels and retention curves and clusters and so on almost never tell us why anything is happening. Fortunately, they do frequently suggest hypotheses that we can explore and test through experimentation.

UX today, in mature organizations, includes using the design toolkit to solve problems and shape experiences to test hypotheses and learn through experimentation which experience works best, which design suits best, which solution delivers the improved results we’re looking for.

So, if you practice UX with that little bit of the scientist (or possibly mad scientist) spirit, combined with the artist’s creative ability to harness the unconscious to make leaps and craft novel solutions then you’ll find this experience and sensibility a perfect fit for product management.

If none of what I says is making sense, then you may have a somewhat larger gap to fill before transitioning to product, and in the meantime when you work with product managers, you can start by asking to be included in conversations about the data they are reviewing and interpreting and what it appears to be telling them about the current designs and their needs and expectations for UX as they seek to meet further goals.

Leading through influence

Over many years of mentoring up and coming UX practitioners I’ve often found that people are looking for opportunities to become leaders. This is probably the second most common theme I encounter in coaching after “Do I need to become a manager to get promoted?” It’s not unusual to hear this desire framed in fairy mundane terms. How do I get promoted to lead designer? How do I become a principal designer? How do I get to be in charge?

My advice usually boils down to telling folks that leadership is usually demonstrated rather than bestowed. When we are deciding who from a team to promote into a leadership role, the first thing we look for is who is already leading people?

Leaders lead and do not wait to be assigned the task of leading. I’m not talking about petty power grabs and declaring yourself in charge of things, but more nuanced things like filling voids that need addressing, catching things before they fall, re-focusing a meandering meeting to bring it back to the decision to be made, going to the white board with a marker to clarify the terms of the debate or the details and consequences or two possible logical flows.

Great UX designers lead all the time. They build consensus. They persuade and influence. They marshal arguments and (yes) data. They use their visualization skills to sketch diagrams and models that help communicate and clarify. They surface contradictions and embrace them as design challenges or constraints. They facilitate workshops that get everyone on the same page.

Does any of this sound familiar? These are all things product managers do.

Product managers are rarely people managers (unless they are product leads managing other product managers). The designers, developers, sales people, data scientists, business analysts, customer success professionals, customer support staff, and the marketing team do not report to the product manager. Setting yourself up as a dictator and trying to just tell everyone else what to do is a nonstarter. A PM leads by persuasion, by influence, and by making everyone else’s life easier.

Product Managers Are from Mars…

When UX designers tell me they are thinking about becoming a product manager, one of the things I always try to mention quickly is how different the day-to-day work really tends to be. This may not be obvious immediately, especially if we have been emphasizing the common ground, the shared values, even the small pool of overlapping skills and techniques and concerns, but it’s worth noting that the craft work differs greatly. Where designers frequently spend much of their time in various drawing programs or other tools for making prototypes a product manager typically spends most of the day communicating and consuming information.

I’ve known some designers with terrible spelling and grammar, almost as a point of pride. They do the visuals. The colors, the proportions, the layout, even the typography, but writing? That’s someone else’s job. (Of course there are UXs writer and content strategists and so on who already write for a living.) Product managers write a lot. Email, specs, more email, slack messages, user stories, hypotheses, reports, roadmap entries, bug reports, sprint retrospectives, you name it. There’s a lot of writing involved.

Once the email is caught up and the spec work is done, there may be some meetings, ideally scheduled in a way that doesn’t interrupt the precious “maker time” of designers and programmers. They are acutely aware that meetings count as productivity for you, the PM, but not so much for them.

When you’re not writing things down so that anybody who ever encounters it will understand it without reference to any prior knowledge, you’ll be facilitating crisp on point standups. Or kickoffs or working meetings. And when you’re not in meetings, you’ll spend several hours every day either poring through spreadsheets or mySQL output or analytics package charts and diagrams. And when you’re not diving deeply into date you’ll be reading reports, studies, research, articles, and anything else you can get your hands on to feed your insatiable need to make the next round of changes and improvements to your product so that it can continue to grow and progress.

Key Insights

• UX is allowed to say “it depends” but Product needs to make a decision.
• Product cares about the UX and may even direct it in some cases but doesn’t do the design work directly.
• There is a large set of skills that overlap between UX and product and these can be a good foundation for changing careers, but regardless one can review your strength across the spectrum for your role, or for a whole team, and look for ways to complement and strengthen the weaker areas.
• Information architecture is a product manager superpower that’s incredibly useful for articulating and visualizing meaning and relationships and fostering consensus about the shared concerns of the team.
• User researchers are natural allies to product managers and experience with the use of research in UX is a good foundation for product work.
• The use of design to develop experiments and test hypotheses and the measurement of design impact through user data and key performance metrics carries over from sophisticated UX design practices to the core day-to-day obsessions of product managers.
• Product managers spend a lot more time with columns of numbers and bulleted lists than they do with the visual design of screens.

—

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