Designer+PM skills

So, I've discovered and can predict that posting to this blog isn't going to be a regular occurrence. Oops. Life happens.

I've realized recently through assisting with the hiring of a designer here at Netflix that being a designer with product management skills is actually kind of rare. I honestly probably should've known this already, but I've also realized recently that some things that I thought were completely obvious (like how to structure logical IAs) are not so obvious to other people because they simply don't think that way. So maybe everything I'm going to write here seems glaringly obvious to some folks, but maybe it's not to others.

Being a designer with a PM bent is the only existence I have known, and I can't imagine how one could effectively function without the business side of things. I've received feedback that my ability to communicate, manage communication and timelines effectively, and question business decisions is vital to making me as effective as I am.

Communication
Communication seems like an obvious skill. Most designers are (or should be) well-versed in being able to talk about why they chose to make a design decision and what impact it has on the experience.

The less obvious portions of communication are challenging business assumptions and negotiating experiences with engineers. I'll save the first part for later in this post, but as for the latter, I can't imagine being a designer and ignoring technical feasibility. That's like plugging your ears and saying, "La la la la la" loudly.

I see design as being a bridge between business requirements, user experience, and technical feasibility, so for me it's usually:

1. What's the business goals we're trying to achieve? And making sure my design is hitting those goals. 
2. What's the optimal way for the design to achieve those business goals without considering feasibility first? And then making a bunch of different options for ease of communication. 
3. What can be built within the desired timeframe? This requires talking to a engineer who knows his/her stuff. Explain the business goals, explain the design goals you made, show him/her the options, and let him/her assess what's feasibility. Sometimes engineers have really awesome ideas that make your design better. Sometimes they can tell you right off the bat that this thing you're proposing would take months to build, so maybe let's work toward a solution that we can actually deliver in a shorter timeframe.

Of course sometimes you need to put your foot down for an optimal user experience, but most times, a "good enough" user experience is enough to pass muster. You can put it out there and see how users are actually interacting with your design before iterating on it to improve it. And of course, if it's not technically feasible, then the most awesome user experience in the world isn't going to matter because no one is using it. Done is better than perfect, and don't forget to learn and implement and re-evaluate after you launch the first time. (Express, Test, Cycle.)

Managing Communication and Timelines
So I think this one is more on the PM side of things, but is still very important to being a designer. My current role requires a lot of buy-in and agreement from multiple stakeholders to deliver an experience that achieves our desired business goals, is technically feasible within the timeline allotted, and is an intuitive and simple experience for users. Here are some things that I do:

• At the beginning of every spec, I document the business goals that we're trying to achieve with this project, and also (sometimes) key design, ops, or product decisions that were made in conjunction with the design to define the scope of the project.
• I hold design reviews to go through my first pass to mockups so that people can see the design, provide feedback, suggest changes -- and then I follow up afterward, usually the same day, in an email documenting all the changes that were suggested, what I did (or will do) with them, and action items for myself as well as other folks that are needed in order to get us to a final design.
• I have a distribution list to which I send out emails about upcoming design features that everyone should know about.
• I hold a meeting every release cycle to make sure people who are in charge of communicating changes to the users know what's coming and what are the important points to highlight.
• I maintain a Google document with all historical specs I've made so people can reference things we did in the past. I update this regularly with release dates, scheduled design review dates, etc. so people know when things happen.
• I don't usually put dates of releases in emails because that's usually not in my control. The only dates I do provide are "due-by" dates when I need people to reply to me or to do something for me. Otherwise, I let engineering provide the dates.

Question Business Decisions

This is super obvious to me, but I'm going to write about it anyway. I never understood people who just took marching orders without thinking; to be effective, I have to know why we're doing something. What's the issue today (or how do things work today that we think could be better)? What do we want to achieve and why? What kind of impact would this change have on our business? How do we measure that this is working? I don't know how anyone creates an effective design without this information. Heck, I don't know how anyone does anything effectively without this kind of context.

And if you hear something that makes you raise an eyebrow, ask about it. This was part of my personality before Netflix, but it's definitely a behavior that is embraced here. If you don't ask, who will? Sometimes people have already logically thought through all the things that you have questions about, and it's good to hear what their reasoning. Sometimes you're the one with the good points that makes everyone stop and question if we're doing the right thing. Sometimes nobody has any idea whether this is the right thing or not -- that's a great opportunity for some research or A/B testing. In any case, don't just sit there, participate. Know the reasons why.

One last thing...

Separate from being a designer with a PM bent, you should probably also have a working knowledge of some technical things, too. Even if you don't understand the finer details of how things work, you should at least be curious about how things are working behind the scenes. This helps you communicate with engineers in the correct terminology, prevent you from making rookie "I don't know how the system works" mistakes (aka shortcut your design process in some cases), and suggest helpful alternatives. Sometimes engineers think in straight lines, and as a designer who thinks about all sorts of different approaches, you could end up suggesting a fantastic solution (or the seed of one) because you understand a bit of the system. I've even been asked to consult on things that doesn't even have a UI because I understand the big picture of a system.

If you're a designer not doing these things, it doesn't mean you're a bad designer. These are just things that I've found to be useful and effective in my career.