There's a good chance that you've used a product Andrew Chang has worked on. To date, he's worked at Google, LinkedIn, Twitter and FedEx and he's currently the Director of Product Management at Wealthfront, leading their financial planning product efforts. Today, we're lucky to sit down with Andrew and learn about his journey.
In this post, Andrew discusses his transition from product marketing management (PMM) into product management, what parts of that transition were easy versus hard and his advice for others as they're preparing for product management interviews.
Kenton Kivestu: Let's jump in. How did you get into product management?
Andrew Chang: The drive to become a PM really came from getting a lot of exposure to the role as a product marketing manager (PMM) at a series of tech companies.
Right after business school, I joined Google as a PMM. After Google, I joined LinkedIn when it was still quite small - about 700 people - also as a PMM. The team I was on there was small, so I worked closely with the PM (it was Jack Chou, who was great and went on to be head of product at Pinterest and now Affirm!) I was paired with. I got a ton of exposure to working directly with engineers and providing input on the product direction.
After LinkedIn, I was in a similar scenario at Twitter, working as the sole PMM for the small business segment collaborating closely with PM. Twitter was growing rapidly at the time. Ultimately, that growth required a larger small business marketing team with specialized skill sets for different aspects of marketing.
KK: Is that what prompted the shift to PM for you?
AC: That was part of it, although there were a few other reasons as well. First, I really enjoyed the analytical part of the role and was itching to put my analytical skills to use. Second, I meshed really well with a lot of the engineers and designers from an interpersonal perspective. And third, I was really interested in influencing products earlier in the life cycle. As a PMM, you're often downstream and more focused on messaging and handling the go-to-market work.
KK: Did the transition feel natural?
AC: In some ways, yes. For example, as a PMM, you work very closely with PMs, and sometimes the rest of the team (engineers, designers) doesn't always make a major distinction between the two roles. I remember telling one engineer on the team I was the PM now and he said, "Wait, weren't you already doing that?"
KK: Haha. In what ways was the transition tough?
AC: Well, really building a deep understanding of how engineers work and what it actually takes to build a product correctly is a years long learning process. It involves lots of trial and error.
KK: I agree. Why do you think it's so messy?
AC: You need real life cycles of decision, action, and results to really learn the lessons, and those cycles takes time. For example, how do you learn the tradeoff between deciding to prioritize a 2-week sprint to refactor part of the code base versus shipping a major customer feature? If you choose to ship the customer feature, you might find yourself wishing you'd fixed the code instead because its messiness has cost an extra three days on every other feature you've built since. You just need some of those "Whoops, that was the wrong decision!" moments to learn the craft.
KK: What advice do you have for people looking to break in?
AC: Some companies favor talent over experience, but I think most people I know have transitioned into the role via an internal transfer - because most companies want some experience (even if it's industry knowledge vs. role knowledge).
I've seen people from client services or customer support leverage their customer knowledge, designers leverage their user empathy knowledge and engineers leverage their technical skills to transfer in.
Small, growing companies are particularly good environments for this. They tend to be less rigid on requirements and they value domain expertise, so they don't have to train on the industry and the PM function.
So: find a space you like, get your foot in the door at a growing company and eventually make the shift into product.
KK: That makes sense to me. What about when it comes to interviews? How do you advise people to prepare?
AC: First, assess yourself across the core PM skills - that's a good starting point. But also, think about which skills each particular company really values. Some companies have a strong preference for technical skills while others might really value a strong user experience and design sense. Finally, I think you want to hit some baseline in each category and then blow out one to two categories where you really shine.
KK: Agreed, it's nice to hang your hat one to two skills. Which skills do you personally care most about when interviewing candidates?
AC: Product sense is the top of the list for me.
I want to know: does this person know the difference between good and bad products? Do they have an appreciation for quality user experiences?
KK: Is product sense innate or can you build it? If it's something people can build, how should they go about it?
AC: You can get pretty far with dedicated online research. There is great content out there - like First Round Capital's blog posts. Recently, the founder of Superhuman had a post about quantifying product market fit. You could spend years learning that single concept, but that blog post just cuts through and delivers so much value. You can find similar quality content on product tear downs, building roadmaps, etc.
KK: I read that post - it's fantastic. And you're right, there is a ton of great content on the craft of product management now. A decade ago it seemed like the only thing available was Ken Norton's canonical post on How to hire a PM.
AC: Yes! Another piece of advice is talk to as many PMs as possible.
Interview them about their jobs. Ask them about the toughest parts, the most unexpected parts, etc. And ask them to give you practice interviews as well!
KK: Yes, practice makes perfect! Getting back to skills, aside from product sense, what matters most to you as a PM hiring manager?
AC: Critical thinking and decision making. Can the candidate break down a problem and really tease out the underlying issues? Do they take complexity and decompose it in a systematic way?
KK: How do you like to test for that?
AC: I like to pick a tool from the PM tool kit and see how they can think about it. For example, at a prior company, we picked the topic of re-engaging users as a broad topic and then each interviewer dug into the candidate's ability to think through methods to do that.
As a product team, we'd debated re-engagement strategies and tactics a lot internally, so we had a sense for what we wanted as a thorough and thoughtful answer.
KK: Would this be within the context of a specific company? For example, how do you re-engage Wealthfront customers?
AC: No. I aim for a more general approach. You want to have a discussion without a priori knowledge about our company or product situation.
KK: How do the best candidates approach a question like that?
AC: The people who stand out are structured thinkers and outline how they're approaching the problem. They ask good clarifying questions and check-in verbally (e.g., "I could explore this path or that path, I'll start here unless you'd like me to do otherwise.") That type of response is great because I like hearing the different paths, but if I want to dig into certain skills, it's nice to be able to say "Ok, let's do X first."
KK: Do you like people to whiteboard their process?
AC: I don't care. I don't naturally whiteboard, so I don't like it when people force you to do so. It's a tool, but it's not the only way to do things! Do you whiteboard?
KK: I do - guilty as charged. But I'm very visual in my thought process - I don't care if others do as long as I can follow their thought processes.
When you think about testing product sense and critical thinking, do you have go-to interview questions?
AC: No, I don't have a staple I'm going to. For me, it always changes and it's always role-specific.
KK: Got it. Any last pieces of advice?
AC: If you're not technical, get some experience talking to engineers. If possible, just sit down with friends who are engineers and ask them to explain something technical to you. For example: walk me through everything that happens when I load Yelp.com in my browser or open the Yelp app. You'll learn a ton (e.g., caching, querying a database, etc.)!
To sum it up, here are three key points that stick out from our conversation with Andrew, what he learned when breaking in and his advice for others.
Finally, if you're considering a career in product management, we encourage you to check out our Getting started guide, which is chock full of insights from PMs at companies like Google, Amazon, Stripe, Facebook, Twitter and more. If you're interested in learning more about Andrew, you can find him on Twitter here: @achang.