Can we talk about the PM — Designer Tension?

It’s probably obvious, but not every Product Manager, Designer, or Developer does the same job.

I’ve seen it discussed most often for design. Designers don’t just “make something pretty.” They do lots of types of work: visual, information architecture, interaction, and coding (I’m sure there are more). Christina Wodtke came up with a good corollary for PMs. We come in three main flavors — Business, Design, and Engineering.

This is great, but we don’t talk very much about the overlap. As a PM who falls more on the “design” side of that framework*, there can be a lot of overlap between my role and design. It’s very easy to define either the PM or Design role as “solves a problem for users.”

Sometimes it’s easy to divide a project.

When I worked on the Kickstarter Start Page, everyone on the team naturally fell into a role:

• I was a Project Manager. I scheduled meetings and reviews, took notes, got feedback, asked the content team for copy, and tried to keep us on track. I figured out what deliverables we’d be making to make progress.
• Aaron was the visual designer. He could take any sort of content and an idea for a deliverable and make it amazing. It’s a little heartbreaking that everyone else can’t see all the designs he made :)
• Zack built things. He’s a designer, and he could turn around and build any of Aaron’s designs within a day.

We still worked together on the designs, but we each had our own scope. That meant there wasn’t much tension.

Mostly, it’s not that easy.

Many projects have elements that both the PM and designer will be interested in. What problem are we trying to solve? What’s the product strategy? How does this integrate with the rest of our features? How will a user actually use it? What’s most important thing to build?

That overlap can create a struggle. That struggle can leave a bad taste in everyone’s mouth and hurt the team, even if the project goes well.

One of my least favorite work memories is an argument I had with a designer while working at Microsoft. We were working on a tight schedule and had to pick the last feature that would make the release. We had different ideas about what that feature should be, and we were both convinced we were right. We were also both convinced we had the final say.

It was something that would impact the user experience, and it who owns that experience — Product or Design? You can argue it either way, because both play a huge role. We couldn’t escalate, because our managers also both thought that their discipline should own the decision. We ended up asking a User Researcher for his opinion to solve the disagreement, but neither of us felt very happy about it.

I’ve seen more situations like this. I find them to be particularly unfortunate because PMs and designers with overlapping skills have the potential to make some of the strongest products.

I spent a bunch of the last year working on the Backer History and Activity Feed revisions with Jessica. Jessica is a really strong “all around” designer — she does strategy work, mockups, visual comps, and codes. Sometimes she plays an individual role (she did only development for the recent version of Erin Nolan’s site), but most of the time she prefers to work end-to-end.

As a PM it’s easy to be insecure when you’re working with a strong all-around designer. “If the designer is making the mockups, why am I here? Do I just calculate metrics? Am I only responsible for problems? Aren’t I supposed to be defining what the Product is? Do we really need my role at all?”

This can play out in bad ways:

• Sometimes the PM will obscure strategy decisions. This gets hidden under the guise of “well I’m just trying to save you time so you can do production work…” but it’s really just a way to shut out the designer from what the PM wants to work on.
• Sometimes the PM does a set of mockups, but the designer makes the exact same thing again, to do it “right.” This is a way for the designer to claim ownership.
• Sometimes the designer makes really great visual comps, then the PM decides they disagree, and goes to tweak them and show them to a broader team without checking back in.

These power plays are just lame. Having a PM-design team with a similar skill set means you always have someone who can understand what you’re doing, and critique it to make it stronger. This should really be a dream scenario.

Jessica and I got lucky. We didn’t have a particular strategy going in, but we ended up working well together:

I did a bunch of up front research to try to define what we were doing before she was assigned to the project. I stopped at some really minimal “MVP” mockups.

When Jessica started, she didn’t try to re-do what I’d already done. Instead, she did some of her own research, looked at what I had, evaluated it, and re-imagined my ideas into something different. She was able to add her own pieces, without throwing anything away. (An example: rather than just using the current navigation paradigm, she reconsolidated information to communicate more effectively).

She still clearly had used my work, but had dramatically improved upon it. Because she’d so clearly incorporated what I was already thinking about it, it was easy to work together and go from there.

This set a pretty consistent tone for the rest of the project. We both looked at mockups or comps together, make revisions, and created concepts we both agreed to present to our executive team. It was definitely the project I’ve gotten the chance to actually work with someone instead of coordinating between people, and that was great.

I was a little surprised to see how well it could go, given we both wanted to do the same work. I’d like to have more projects go like that. So, here are a couple takeaways for how other overlapping PM — Designer teams can do this.

I’ve framed this from the angle of being the PM, because that’s what I am. That said, I’d be thrilled if I worked with a designer and they brought this up, so I think it can be applicable both ways.

Talk to the designer up front, as soon as you figure out what you’re working on.

This is especially important the first time you work with a given designer. You want to figure out what parts of the project they’re interested in and want to work on.

Some good questions:

• What part of this project are you most excited about?
• Do you want to be determining this strategy work, or would you rather X?
• Have you worked on something like this before?
• What are some resources / designs you like in this space?

If you want to do the same things — acknowledge that! It’s okay! Just do them together. Talking it through will help you understand what both of you want to work on, and why you want to work on it. Chances are you both just want to make a great product for the user.

Even if you don’t have an “allocated” designer, you can usually you can guess which designer you’d end up working with on a given feature. I’ve definitely reached out to designers before we formally started a project. From the designer side, if you find out a PM is working on something you’re really interested in, go talk to them about it! I never mind when people ask me about my work.

(This is often a good thing to do with developers as well. Some like have a lot of input in production definition.)

Actually work together.

Once you both know what you want to work on, put that into action.

If you both wanted to make early mockups — both make mockups! Don’t fight over who gets to do it (or make identical ones). That’s the time when you can be broad and you want to explore lots of concepts, so there’s no harm in both trying it. Either divide things up, or each make a couple concepts and then get together to combine your ideas.

This also lets you get in a round of critique before showing your managers, customers. The time will be saved later, because you’ll be able to move faster in reviews.

Don’t talk badly about each other.

When you really wanted to do a piece of the project, it can be hard ot let it go. (Even if you know it’s best for both of you). When that happens, if it doesn’t turn out the way you want, it’s even worse.

It’s tempting to say “well if I’d been doing that piece, I would have done X.” Don’t. You don’t need to be competitive. Just go talk to the other person and make improvements. It’ll make your team look worse as a whole if you run around criticizing each other. Work out issues within your team, and you’ll get much better results.

Overall

Let’s be more honest about this overlap between PMs and designers! It can be really challenging to work with someone who has a very similar skill set. Double that if they want to do the same work you do. That’s okay.

Call it out at the beginning and figure out what you want to learn and do. Worry less about who “owns” a certain step in the process, and worry more about how to go through the whole process together.

* While my degree doesn’t say design, I’ve still taken UCD, Interface Design/HCI, Information Architecture, and Usability Testing. My senior capstone was in design. I’ve done a lot of projects where I played a design role. I’m not saying that every PM has this overlap, or should have this overlap. If you have a Business PM, they’d be more likely to experience this type of tension with a strategy or marketing team.