Ask Women in Product: How can an engineer break into Product Management?

Women in Product
8 min readOct 7, 2019

--

Eleanor Stribling shares interviewing and career tips from her perspective as a hiring manager who has conducted dozens of interviews in the past year for her growing team.

Resume writing photo by vinnikava via Twenty20

This week’s question: How can an engineer break into Product Management? What transferrable skills do you look for and how can one attain those skills?

Answer from Eleanor Stribling

Eleanor Stribling is Group Product Manager at Zendesk and the woman behind @productized_io. You can reach her on Twitter at @eleanorstrib.

The short answer

Let me start with the short answer: get as much product-related experience as you can where you work now to get around the “can’t get the job if you haven’t done the job” problem. As you’re doing that, focus on getting better at these three things:

  1. Imagining what should be built before what could be built;
  2. Working with stakeholders outside of your usual sphere; and
  3. Explaining why you want to change roles in a way that shows you truly understand the challenges.

You might ask, “What makes you qualified to answer this question?” My answer comes from my perspective as a hiring manager of PMs. I’m currently a Group Product Manager at Zendesk, where I lead a growing team of PMs working on our flagship Support product. In the last year, I’ve conducted dozens of phone screens and in-person interviews, looking for PMs with a deep understanding of the technology that enables the products they build. Prior to Zendesk, I worked at Microsoft as a Principal Product Manager and was VP, Product Management and Consumer Insights. I’ve written production code for a small startup, delivered technical talks at conferences, and coded several side projects, so I’m as technically adept as most product leaders.

The long answer

When I look at engineering candidates, I assess them from the opposite angle: what have they done that isn’t all about engineering? What impact did that work have on the business and its customers?

Below, I describe the three non-engineering competencies that I look for in all PM candidates regardless of their background. If you can demonstrate these three areas along with your technical aptitude, you’ll be in great shape to move to a product career.

1. Imagining what should be built before what could be built

When I first became a PM, I was the opposite of an engineer making the change. I had come from the client services side and didn’t know much about programming beyond writing some VB scripts in Excel and simple Python. I went to my boss at the time, who was very technical, and asked him what languages or frameworks I should be learning so I would understand what was possible and can avoid asking engineers for things that couldn’t be implemented. His answer was really annoying at the time, but I’ve since come to understand the wisdom in it: “Just assume everything is possible,” he said. “Your job is to figure out the most important problems customers need to solve and imagine a solution.”

What to do. What can you do to demonstrate your abilities here? You tackle ambiguity head-on. In your current job, find a project where you can take a vague customer problem with a direct impact on the business and come up with an unconventional way of addressing it with a product or feature, then measuring the impact. This needs to be more than a clever or elegant bug fix or implementing something everyone agreed was needed. Look for an issue that doesn’t have a clear and obvious answer, then go and solve it.

How to prepare for an interview. Before you start interviewing, practice telling people about the project as a story. Imagine your audience is an executive who knows the space but not the details; what they care most about are the business and customer outcomes. It’s always great to know the technical details, but practice the story with those in your back pocket — if someone needs to know, they can always ask. Try to get the high-level story down to two minutes and make sure it has a clear beginning, middle, and end, ideally with something you learned from the experience.

What I’d be looking for in the interview. If you are currently an engineer, I’m wondering if you can think beyond the confines of what’s possible to what’s needed when the situation calls for it. Make sure you have examples of:

  • How talking to customers shaped your approach to the problem;
  • What metrics you used to measure success that were directly related to desired customer and business outcomes and why you chose them; and
  • How you explained the solution clearly to non-engineering stakeholders.

2. Working with stakeholders outside of your usual sphere

To be effective, a PM must excel at working across the organization to get buy-in and funding for ideas, soliciting help from other teams, and handling objections from co-workers and customers. The more senior a PM is, the more time they spend doing these types of tasks.

What to do. Look for opportunities to work with people outside your immediate product development sphere in the job you have now. Some tips:

  • Consider taking on a project like the one I described above. Other equally viable venues include a company hackathon, doing “ride alongs” with your PM, or other cross-functional projects.
  • Listen more than you talk at first. Understand what other people’s jobs are like and who their stakeholders are. For example, when you talk to marketing folks, you will learn about the metrics they use to measure success, what their main stressors are, and what big events they are planning.
  • Learn to pitch ideas with your stakeholders’ point of view. When you understand your stakeholders’ priorities, you’re better able to pitch your ideas to them. You’ll know how to highlight the benefits that their buy-in will bring. For example, for Henry in Marketing who has to come up with content for a big customer event in three weeks, show him how your project could offer useful material for him to present there, or in the future.
  • Find opportunities to talk to customers as much as possible. You must learn to look at your product from the perspective of your customers. Ask your PM and designers if you can join customer calls. Put your hand up to go to events. When you attend events, write up notes, try to spot themes or trends, and offer recommendations on the next steps. Volunteer to refine some use cases and walk through them to get your PM’s feedback. Volunteer to ask questions rather than being a fly on the wall.

How to prepare for an interview. Again, it’s all about storytelling. Be prepared to talk about the work you’ve done with other stakeholders. It’s okay if you haven’t led a giant cross-functional initiative; be sure to share your thoughts about what motivated people in the situation and how you worked through objections with them.

What I’d be looking for in the interview. You’ll want to demonstrate your ability to align incentives. Show that you understand how to help others achieve their goals in ways that will help you reach yours. It doesn’t matter if the work didn’t result in a product. A situation where you took the initiative to hear from customers and translated that input into action can make a very compelling story.

3. Explaining why you want to change roles in a way that shows you truly understand the challenges

The most disqualifying thing engineers who apply for PM roles have done during interviews with me is to demonstrate a poor understanding of what the PM role actually is. Too often, I hear quotes from Steve Jobs to describe what product management is about. Other people describe the role through a string of buzzwords (AI! VR!). Yet others tell me they want to be a PM so they can “call the shots.” All of these things are indicators to me that you haven’t done your homework. It’s as if I had applied for a junior developer role after being a PM, and in the interview, I say I want the job so I can make all of the technical decisions for the team, all while repeatedly quoting Linus Torvalds.

What to do. From the outside, the PM role might look glamorous, but it’s often a difficult role where everything is your fault when something goes wrong. You have to influence people who don’t report to you, and if things go well, the credit goes to the team. You’ll want to show people that you’re aware of these challenges, have seen them firsthand, and yet you’re still motivated to do the job.

This is where the first two tips will really help you — you’ll see firsthand what being a PM is like by doing aspects of the role yourself or working closely with someone who is a PM as you pursue tasks beyond the regular scope of your job. Read blogs written by PMs who are not in your organization (like this one!). If you have friends who are PMs, talk to them about their challenges at work and their mistakes.

How to prepare for an interview. Aside from taking the other steps I outlined above, I’d recommend watching the “Start with Why” TED Talk. Once you’ve done that, write down all of the reasons why you want to make the switch to Product in a stream of consciousness style for two or three minutes. Then go through your list and circle the things that you feel the most deeply. That’s your why.

What I’d be looking for in the interview. When I talk to you about why you want to make the switch, I want to see that you:

  • Have an idea of what you think you’d be good at and where you might need to grow;
  • Can explain why you want to work on our product and how you’d make it better; and
  • Have an understanding of the challenges of being a PM and are ready to take them on.

In Closing

When I consider a candidate who comes from an engineering role, I need to be pretty confident that they will join my team with the mindset of a Product Manager. I suspect this is true for all hiring managers.

The bottom line: show that you can stop being a developer who has great technical implementation ideas. Instead, be the person who can articulate a vision around customer needs, rally the organization behind it, and find a path to value.

--

--