From Designer to Product Manager

Getting into product management can feel like a catch-22.

There are few formal junior PM roles, but recruiting teams want to hire PMs with a history of holding the title. If you initially commit to being a designer, engineer, or marketer before entering product management, it’s hard to have teams view you as anything else.

People don’t study product management in school — every PM has learned to paint their unique combination of skills in a more PM-friendly light. This is one of the first hurdles to entering the discipline: breaking free of the previous title you’ve been assigned, and learning what makes you walk and talk like a product manager (even if you’re not there yet).

I came to product management through design (via pre-med — but that’s a longer story). There were many things I loved about being a designer. Going to school in Silicon Valley and watching startups whiz by on the news, it was clear to me that we needed a focus on real user needs. I went deep into user research, problem framing, prototyping, testing. I loved design, but didn’t like what I observed: designers typically weren’t decision-makers or decision-facilitators.

Being a designer was great for me in the same way that being an engineer is great for others: I got to go deep in my craft. I advocated for new user experiences and interaction patterns, the same way that engineers own the details of architecture and the integration of new technologies. But at the end of the day, I didn’t know whether my work was making a difference for the business, and whether it would cut through the noise in the backlog and get prioritized. This was what got me interested in product management: if you could balance design, tech, and business efficiently, you’d always be working on something driving value.

Here are three things that helped me close the gap between “designer” and “product manager”:

Choose PM roles that optimize for your strengths

It became obvious to me pretty early in the job hunt that not all PM roles are the same. Some PMs are almost-engineers, others almost-designers, still others almost-analysts or consultants. Many swap back and forth depending on what’s needed. It’s hard to tell from a bullet point job description what being a PM at a given company really means (it can even vary wildly between teams).

This is most important from a technical perspective — in my experience, your technical background drives your PM job opportunities. If you’re coming from software engineering, you might find a home in technical software; if you’re coming from design, the most logical fit is a consumer-facing product where your research and interaction skills are relevant. This is not a hard and fast limitation, of course, but it’s easier to get hired when your product bent matches your company’s. Your transition to PM will be a lot easier in an environment where you can flex your design skills and immediately add value on the user side, while slowly learning more about the business and technology sides of things.

I did a couple of things to try and suss out whether I’d be a good PM for a given company: informational interviews, and LinkedIn-browsing their current PMs. Informational interviews (read: messaging PMs and asking for a 30min chat to learn about their work) can help you get a sense for how the product teams operate, which skills and working styles they value, and what qualities teams might be looking for in interviews. On LinkedIn, if a company’s PMs are all ex-engineers, or if they’re all ex-designers, that will help give you context about what skills the company values and what version of PM you’re applying for.

Find 2–3 stories to fill your gaps

PMs sit at the intersection of design, business, and technology. No one expects you to excel at everything, but you need to have a couple of stories to fill the gaps.

For me, the gap was technology. I couldn’t “ship my own products” without help, and it was hard to get the kind of high level understanding of technical difficulty that PMs need without an existing product and an engineer to walk me through it.

Though my work experience was all non-technical roles, I went out of my way to learn from the engineers adjacent to me. I attended their standups and listened in on their grooming sessions; I pair-programmed on basic tasks like writing unit tests and changing automated email content. I asked “why” a lot, whenever they mentioned that a task was particularly difficult or easy.
In school, I put myself through engineering classes where I had to write code. I took an online course in writing SQL queries. I took classes where we had to deliver coding products on a timeline, so I could understand where the time crunches were.

None of this experience was perfect, and I’m still not much of a coder beyond simple web dev. But going through the motions and asking the right questions has shored up my “technology” experience to satisfactory PM levels.

Having a few of these stories at hand will help dispel the biases you could encounter, too. It’s easy to assume that a former designer would be overly focused on the user, or not have a technical background. Doing your due diligence in other PM areas can help combat the notion that you’re really just a designer trying to do PM.

Learn the tools and keywords

Designers and PMs use different language, and live in different tools. As a PM, it’s generally more important to use Sketch or Pivotal Tracker than it is to use the Adobe Creative Suite or iMovie. PMs tend to be judged more by the numbers, so it’s important to elevate instances where you tangibly improved product outcomes. You want to be familiar with the product development lingo: Minimum Viable Product, Agile development, design thinking, Business Model Canvas, and working with key assumptions and hypotheses (to name a few). It sounds like a list of buzzwords, but being immersed in the language that product managers use is important. It will help you in the critical mindset shift that designers have to make when becoming PMs: in your day to day work, business value and tech feasibility have to be weighted equally with the user value that designers focus on.

There’s no silver bullet for getting into product. (I think if you tried to summarize my notes above, you’d get “fake it til you make it.”) Sherman and I started Path to Product because we struggled to get here, rewriting ourselves into product management from other roles. We know that designers, engineers, and others can become great PMs — and we’re here to examine and support that transition. Hopefully we can provide a little of the “product management school” we all wish we’d had.

Continued in From Designer to Product Manager (Part 2): Challenges You’ll Face