The Taxonomy of Product Managers (for UX Designers)

Designers and developers I lead (my students, employees, and clients) have been asking a lot this week about product management: who does product management, how it's distinct from project or account management, how to divide responsibilities between product, design, and development. The answer (naturally, since I'm a designer) is "it depends," but I'm going to share what it depends on.

I taught an introductory design course not too long ago with Morten Lundsby Jensen, who's more of a hybrid product manager/designer. When it came to demystifying product management, we had an amazing conversation (which involved drawing on the walls, as it often does at General Assembly), in which we discussed our experience and did some pattern recognition, to create a taxonomy of four common types of product managers. I've shared those below, with some thoughts on how to work well with them. 

Ideally, the product management role is responsible for the business of what products and features your cross-functional software development team should build and when, in what order. There's a great deal of variation, which in my experience clusters into the four common types below. [Note that some of the variation I've seen is in the job descriptions and requirements of the companies they work at, and some is in the background and disposition of the product managers themselves.]

1) The Once-And-Future-CEO

This product manager might be the head of the department, or the first PM at your company. This person almost certainly has an MBA, and has probably founded her/his own company, which may have been acquired by yours. This product manager is a big vision thinker and talker, is great talking big picture with customers and supporting Sales. They can definitely help you figure out what your product wants to be when it grows up, but may have a hard time releasing an MVP that's "less than" full functionality, or helping you prioritize which among equally desirable features to focus on first. As a designer, you'll definitely need to be specific about the feedback you need from this person, and be willing to iterate how you ask. This person's a great advocate for including design in decision-making, if you can get on her good side.

2) The Technical Product Manager

This product manager is almost always amazing to work with. S/he likely has a CS degree, and/or may have been a developer before. This PM uses those tech superpowers to help you figure out what your competition is doing, flesh out requirements, determine the "killer feature," help build street cred with the developers, and build something that's amazing from all sides (technology, business, and end user value). This person might not have enough "pull" with executives or prospective customers, however, so you'll have to team up to double your influence. The best possible combination, in my experience, is when a badass Once-And-Future-CEO runs the department, and hires the TPM to help execute.

3) The Project Product Manager, aka the "Get Sh*t Done" Product Manager

This person has conquered Jira, Confluence, and your procrastination habits. S/he always knows who's doing what, who's waiting on whom for what, and what it's going to cost each day someone lags on a deadline. This person may also have an MBA or a CS degree, but is most comfortable up the elbows in implementation details. They understand every step of the process from ideation to release engineering, and have strong relationships with the smartest person in each functional area. If anyone, anywhere is being vague or hand-wavey, they will zero in on it like white on rice, and flag up (with both kindness and razor-sharp clarity) exactly how that's going to screw the company up six months down the line. 

This PM might frustrate the designers in being unwilling, unable, or uninterested in answering the "whys" that UX designers inevitably are seeking. Hopefully, in those cases, there's a CEO or another type of PM around to work with you on the big vision questions. In the best of possible worlds, there's a project manager who keeps the schedule, leaving the product managers to work strategically on defining what goes in the product and how you collectively should get it there. 

4) The UX-y Product Manager

This person, like you, might have social science or even design degrees. They might have an MBA. They might even have been a designer before they were a product manager. Either way, they have worked in environments where they didn't have a UX designer, and had to do your job themselves. They might enjoy wireframing or user testing, and might be prone to sketching as a way to ideate. This person should be the easiest to work with, because they speak our language and understand the value our methods deliver.

A warning, however: DO NOT GET TERRITORIAL, or butt-hurt if you think they're trying to do your job. Even if they like to create design deliverables. You must figure out how to collaborate well with them, and divide the work between you based on consent and mutual respect. Fight them, or pitch a fit, and you're a net resource drain, in which case you should not be employed there. The UX-y product manager is the best possible advocate for UX design to participate effectively in the product development process. Don't let your insecurity screw that up. 


Regardless of which Product Manager you're working with, always remember (as my friend Christina Wodtke has written) that the product manager is the one left holding the bag if the team doesn't deliver. It always behooves the designer to befriend the product manager, figure out what makes them tick, establish shared goals, and gain their trust. The moral of the story: Work well with any and all of these product managers, if you want to ship great products that have maximal business and end user impact.

Critique skills are life skills

I've always found that the skills one needs to be a good designer are the same ones needed to be a good person. I've applied my life skills to work, my work skills to life, my "Daring Greatly" fangirl badassery everywhere. 

So I was particularly excited the other day to read a blog post by a dear friend and former employee, who also shares my love for dancing. Janet was part of the original team for whom I created the Embodied Critique method, and took over leading that team when I left the company. She's written a delightful and helpful redux of what she's learned about soliciting, giving, and receiving critique -- as applied to bellydance performance:

To what other contexts have you applied your design communication superpowers? What other superpowers have helped you be a better design communicator? I'd love to have lots more of these conversations. And I need to get back to my dance class. 

Upcoming talks in San Francisco... and Helsinki!

I'm excited to announce that I'll be doing some fun teaching and speaking in the next few months! First up are two "how to get a design job" workshops for General Assembly Alumni, on campus at GA in San Francisco. They'll be the next two Fridays, January 22 and 28 - contact me or GA if you're interested and not yet signed up!

I'll also be teaching a pre-conference workshop at Interaction16 in Helsinki! Tuesday March 1, come learn my Embodied Critique method for badass design communication, critique and iteration, in an international cultural context for the first time! You can register on the Interaction16 site - I hope to see some familiar faces, and am excited to connect with some new ones!



Critique Workshop for Creatives | Saturday, December 5

I'm so very excited to be leading an advanced critique workshop at General Assembly this Saturday -- and even more excited that I'll be teaching it with my partner, artist and professor Mel Johnson

I've never taught with her before, though I have shared a classroom with my lifelong bestie, design powerhouse Josh Silverman, and have heard from many happy students that the joy, excitement, hilarity, and chemistry is palpable. So I have high expectations! I can hardly contain my squee -- and I do know from experience that my squee is infectious. 

Designers, developers, entrepreneurs, product people, with a portfolio, pitch, prototype, presentation -- come learn to critique like a badass, and get deep critique from both of us as well as your peers. If you've already had my Embodied Critique before, there will be some new learnings/additions, too. 

You can register on the General Assembly site -- contact me to get the discount code for current (2015) GA students. Hope to see you there, with a friend!

Designing Social for Mobile

Back in 2008, when I was head of design at Myriad, Europe's largest mobile software company, I wrote an essay for the first edition of Designing Social Interfaces, written by design superheroes of Yahoo! Pattern Library fame, Erin Malone and Christian Crumlish. I rewrote my essay earlier this year for the second edition, which was recently released.

When they reviewed the book's completed manuscript, though, the authors realized something they hadn't expected: the design landscape has changed so much over the past seven years that mobile is now everywhere. Infused in every chapter and every design problem. So my essay became superfluous. I include it here for your education and enjoyment - and I encourage you to buy their book, nonetheless, because it's awesome.



Designing Social for Mobile

for edition two of Designing Social Interfaces, February 2015

I’ve been designing for mobile since before the first iPhone was released. People used to ask me all the time how I could stand it. How could you do anything on those tiny screens? A few years and a billion or so smart mobile devices later, no one’s asking that anymore. The app store model has changed the rules of engagement, the rules of design, and the competitive landscape, and almost overnight, we are all designing “mobile first.”

Mobile design to me (as compared to desktop design) is like writing sonnets—or better, haiku—as compared to writing free poetry. The structured nature of mobile design makes it more important than ever to understand our users’ passions, motivations, context, and decision-making processes.

With that in mind, I share with you my “Dos and Don’ts” for mobile design, some of which are the same as they were all those years ago, and some which have emerged as this space has evolved.



·      Use the 5-minute rule. Mobile users are, well, mobile; they’re going to use your application while standing in line at the sandwich counter/waiting at the bus stop/sitting on the couch waiting for the commercial to be over. Make sure that whatever your mobile app or site’s raison d’être is, it breaks down easily into short bursts of activity. Even better if those bursts of activity are super-entertaining or super-useful.

·      Focused research and task analysis. Figure out who your user is, what she cares about most, and what she’s really going to use your app for in those five minutes—and make sure your design does those top one or two things well.

·      Expect – and design for – interruption. Not only in the user’s thought process (what was I doing before I lost reception/had to pay for my takeout/arrived at work?), but also between apps AND between devices. These are hard yet important design problems to solve. Case in point: Five months (and at least four update patches) after iOS8 was released with its new multitasking features, I was still cursing every time I received a text that blew away a response I had been writing to another.

·      Dazzle (or at least intrigue) them quickly, or lose them just as quickly. Sure, your engineering and design geek buddies might have fun tinkering with the guts of the settings on their phones, but in the app store world, your users have lots of choice and little patience for delayed gratification.  Make sure your app demonstrates its value immediately.

·      Get familiar with the mobile ecosystem. Take a field trip to a local shop or three and play with the display models. Especially the Android ones, since there are so many. Develop a habit of watching people texting and playing mobile games on the train and reading their email in the elevator. Immersion can quickly make you a local in Mobile-landia, rather than a tourist.

·      Make informed, user-centered decisions about whether to start with a responsive mobile web site or a native app. The right choice is going to depend on your target user base, your business’ goals and engineering capacity. In short: Do you need to go broad, release a small set of features/content to as large an audience as possible, as quickly as possible? Then go mobile web. Do you need to go deep, impress the heck out of iPhone users right out of the gate, with the best possible user experience and use of the latest iOS APIs? Best be going native. Design leadership in the twenty-teens and beyond requires that you be able to facilitate this conversation, and make sure your team makes the most effective choice for the design problem you are solving.

·      Think about the business. How will your app make money? How will your social ecosystem sustain itself? One thing that’s changed is that more and more folks are willing to put up with ads, particularly relevant ones, to get something for free. What will inspire them to pay for the premium version (other than an assumption of annoyance that might no longer be valid)? It pays to understand your particular persona’s motivations.



·      …pare down the feature set too much. Sure, if you’re converting a successful desktop app or site to mobile, you MUST prioritize the flow hierarchy effectively. However, too many mobile designers – even of successful commercial apps – remove key features on a misguided search for “simplicity.” I mean, who thought it was a good idea to release the first version of mobile Gmail without search? Who on earth decided not to let me delete a Dropbox folder in a hurry while waiting for my latte, or reorder my Netflix queue during my bus ride home? There are plenty of interaction design patterns, such as the ones you’ll learn about in this book, that you can use to indicate hierarchy or relative importance. Use them.

·      …think that shrinking a desktop app down to mobile size is going to work—especially on a touchscreen. Many mobile designs that fail do so because the designer (or engineer) who built them assumed that a mobile device was just a very small computer. This is true both from a UI control standpoint (no hover, making clickable elements large enough for clumsy fingers) and from a “how people’s brains work” standpoint (context, as above and as ever, remains king).

·      …assume. You probably know what my dad says happens when you assume. What I mean in a mobile design context: my students were doing a project recently, geared towards increasing public knowledge of and access to below-market-rate real estate in San Francisco. They had a hypothesis that mobile access to this service might not be very important, because people who would benefit from the service might not have mobile device access. Their research proved them dead wrong – 80% of their target audience showed up to an informational workshop, smartphones in hand. Good thing they were such diligent researchers and designed from real user observation, rather than designing from stereotypes or “gut feelings.”

·      …think about software. Not so much in the Lakoff “don’t think of an elephant” sense, but more in the Tufte minimizing the “software artifacts” sense. Mobile design is incredibly intimate. That phone lives in your palm, in your pocket, under your pillow. It’s with you all the time. It flows in and out of your hand like an extra limb or an extra brain, available to fill in the gaps in your knowledge, ability, attention span, or location. When you’re checking Facebook, you’re not thinking about what buttons and sliders and widgets are on the screen, you’re having feelings about the people whose posts you’re reading. When you’re buying a plane ticket online, you’re not thinking about those buttons and sliders either -- you’re having feelings about where you’re going, whom you’re visiting, how much you can afford to spend.

Unless you’re an interaction designer, of course, in which case you’re thinking about the software all the time.

The point is, in mobile more than anywhere else we’ve designed for: if you’re having a conversation about features and what UI controls are on the screen, rather than the experience you’re delivering, you’re having the wrong conversation, and your app will suffer.



In 2009, when I wrote the original essay for the first edition of this book, mobile phones were highly disconnected devices. Heavy dividers separated social interaction in different applications – email, texts, or calls to contacts lived in their own silos, and Facebook, Twitter, and other networks lived in their own separate universes.

At that time, it seemed revolutionary to point out that “contextually speaking, mobile phones are by definition social networking devices,” and to encourage designers to “break out of the classic phone/phone book mental model and transform that experience to include 21st-century-style social networking.” It’s exciting to see that as a design community, we have taken up the challenge and initiated more transformation and disruption that I could have imagined.

The depth of connection enabled by the mobile user experience has increased along with this transformation, and brought with it not only new opportunities, but also privacy concerns we designers need to consider. I like to make an analogy to politics, which is what I studied in college. In government, there’s a tradeoff between Protection and Freedom. Individuals locate and re-locate themselves along that spectrum depending on their context (race or class, what’s happened in their local communities, whether it’s an election year, etc.) With respect to mobile design, the tradeoff is between Convenience (or Pleasure) and Privacy – and people will also locate and re-locate themselves similarly. The same hard-working tired mama, for instance, might bristle at letting an app her employer accesses save her credit card details, but not blink an eye at leaving the same data on the servers of an app company that allows her to press a single button and have takeout on her doorstep when she arrives home with the kids. The point? It’s become complex. Find out where your user stands, and why.


A few final questions to consider in your mobile experience design process:


·      What does the intimacy my user has with his/her phone mean for how s/he experiences mobile social networks? (Think about the difference between the majority of my Facebook or Twitter friends, as opposed to the ones whose updates I set to vibrate in my pocket.)

·      What experience am I offering my users to make it worth it for them to trust me/my app with their data? What is and isn’t ethical to do with the data, for the purpose of improving the personalization of their experience? How about for the purpose of improving the business’ bottom line?

·      What kind of experience can I offer my user that is special because I have an aggregate understanding of all the people participating in the ecosystem, what their relationships are to one another and to the content of this particular app?


If my own experience is indicative, thoughtfulness on these topics will make your design process more exciting, and your applications more compelling.



This week in my classroom, my UX design intensive students started working on their second project, a web site redesign. This is the second week of the program, and we have given them several different new UX methods for ideation and discovery, as well as a list of deliverables and a process to follow. After a few days of workshop time and student questions, I noticed a common thread: although they had been asked to generate sketches and user flows and sitemap drafts, many, if not most of them, found themselves staring at one or two blank or sparsely-populated pages, not knowing where to go next, and feeling very frustrated.

When I dug into it with each of them, I heard a similar story. Millions of ideas swirled around in their heads, and they struggled to find the right one and harness it. Kind of like the “flying skeleton keys” scene in the first Harry Potter film. When I asked them about those ideas, their faces lit up -- they were able to tell me about each one, what had inspired them, and why they had talked themselves out of it. When I asked if I could see how they had made these conclusions, however, I was met with blank stares. All the editing and ruling out had happened in their heads, before they allowed themselves to create anything. So they were left empty-handed and frustrated, feeling as though all the spark-flying, new-synapse-firing work they had done during the course of the week had been all sound and fury, signifying nothing.

After about the sixth of these conversations, the proverbial light bulb went off in my head. I went to the front of the classroom, took a marker, and wrote in giant letters on the board:


I got all their attention, got them to take this in, think about it, and have a quick discussion about it. Why not, I asked them? Show your thinking process, one said. Allow yourself to get messy, said another, quoting a treatise against perfectionism I had given a few days earlier. How about being able to get anything done in the first place?

It’s the very same block that writers find ourselves facing -- that Anne Lamott addresses head-on in Bird By Bird. Allowing ourselves to be imperfect, to write “shitty first drafts,” is the only way to write anything at all. Getting the ideas out into some form one can see and touch is the precursor to being able to effectively assess and hone those ideas.

I encouraged all the students to slow down, get all the ideas captured in some form or other, along with the hypotheses that inspired each idea and whatever questions arose in their heads that inclined them to rule the ideas out. Then they could look across all the ideas and edit, cross out, combine, build on, or otherwise use their ideation as a foundation. Their shoulders collectively dropped from their ears, and they heaved a collective sigh of relief.

What we learned: Every finished creation, every journey, can only begin when we take the first step. Even when that step is off the cliff’s edge, unsure of whether you’re wearing a parachute.  

Talk the talk, walk the walk, wave the wave

I am beyond delighted to be teaching the UX Design intensive at General Assembly in San Francisco this winter! I am going to try to push myself to share more insights here, since there are many many many coming up, in this classroom of twenty brave badasses who have taken a 2.5-month hiatus from everything normal in their worlds in order to come soak up 25-ish combined years of career experience from me and my fierce co-instructor, Mandy Messer.

A few week one observations:

  • "Innie" (in-house at a software company) design experience is different from "outie" (agency/consulting) experience after all.
  • The social science of UX is as important, if not more so, than the "hard science" or even the art.
  • I do have a story for everything. Folks seem to learn a lot from hearing them. 
  • I love teaching.

Friends, colleagues, students -- please feel free to comment or ask questions! There's a lot going on here -- tell me what you'd like to hear about!

Brain in a jar no more

One of the major career realizations I've had in the past several months is about the role of emotions in software design and development. While it might be the cultural nature of the software industry to reduce us to feeling like a brain in a jar at the office, there's nothing more damaging -- not only to a UX designer, but to the team as a whole, and the quality of our output. I'm not just talking touchy-feely psychological damage. I'm convinced that being disconnected from our emotions makes us messier and less effective at our jobs, and lowers the quality of what we produce. 

The story goes something like this: 

I hired a brilliant new UX designer to join my team, and assigned her to work with a group of particularly intelligent, yet rather opinionated, developers on a project of some significance. "Fresh eyeballs" always see a fresh angle on a product, and she did her best to use her outsider perspective for the good of the team and the product. The developers, however, shut her down at every turn. I don't like it, they'd say. That's not how we want to do it. And this brilliant, promising designer, before starting to question her choice of new employer, asked me for help. 

When I thought about it, I realized that every good software designer should not only want, but need, constructive feedback from her peers, particularly the developers. What made the feedback she was getting NOT constructive? It was purely subjective and not actionable. I realized that using some social science methodology, some design studio methodology, and some good old-fashioned feminist collective communication skills, I could probably make a difference. 

What I did: created a design critique methodology, and a training for said methodology, with the goal of teaching everyone to actively solicit and effectively provide actionable critique. The key principle: if you feel something, great. Just don't stop there. "I don't like it" is not a critique, it's a starting point to find your critique. Why don't you like the design? How does it make you feel? What questions does it raise? Start with the emotion, feed it to the intellect, and share the output.

I gave this training to the development team and the design team collectively, and I was delighted to see that everyone came out of it feeling like they had useful tools with which to present their work, receive useful feedback, and iterate effectively. Without anyone feeling steamrolled. From what I've heard, everyone on the team feels better about the time spent in meetings, and has greater "skin in the game" in the overall process. So I'm feeling good about it. 

Short version: ignoring feelings doesn't help make good software. Not being aware of feelings, and stating them as though they're facts, does the opposite of making good software. Showing up for our feelings, and using them as the basis of inquiry and collaboration, helps make good software, happy designers, and happy developers. I've seen it happen. 

I'm revising the slide deck from the design critique training and will post it soon! In the meantime, if you have questions, ask away!