Starting a career in Product Management
Starting a career in Product Management
Originally posted February 2020 • Shared while giving at talk to students at Duke University
To students to Duke University:
Intro
Hi, I'm Zack. This memo aims to provide a practical introduction to starting a career in product management.
I have to admit, it's a bit ironic of me to write this post. I don't truly aspire to be a PM and certainly do not think I'm great at the job. My personal career goals are as a founder, leader, and investor.
My path to product management was typical in that it was not typical. As a college student, it may be easy to think the only or best path to being a PM is by studying CS, having a 3.9 GPA, and landing the Google APM role. In reality, your career will be much more messy and will require you to be much more scrappy.
Some of the best PMs I've met came from all types of backgrounds. So, if you're reading this and have ever felt like you don't belong in a PM role, I want to assure you you do belong. Or, at least, you have every right to. As long as you relentlessly focus on understanding your customers and lead your team to innovate on their behalf, you will be well on your way to being a great product manager; degree, GPA, or general background notwithstanding.
This leads me to the first step to a career in product management:
1. Know the path to product management may not be straightforward
I'll dive deep into my story — beyond what you'll deduce from my LinkedIn — because I think it’s important to know the story you typically hear isn't the story that actually happened. Revisionist history is far too common. If you compare your unique journey to what others say their journeys have been, you may quickly become confused and discouraged. So here's the real (and messy) story of my path into product management.
I grew up in East Bend, North Carolina, a town of 600 people. As an only child in a small town, the Internet was my window to the rest of the world. I would eagerly participate in the latest dance craze on YouTube, learn HTML and CSS to make my MySpace profile unique, binge-play Runescape with friends, and browse various online communities (all of this circa 2007).
Later, I studied business at UNC (Go Heels 🐑) and interned at two large financial services companies — Wells Fargo and AIG — that I now never mention when telling my story. I chose to intern at those places because I gave in to the pressure to do what my peers saw as prestigious (or as close as I could get to their ideas of prestige). As a consequence of not chasing areas I felt passionate about, I was unhappy during my time at both companies. I wasn't doing what I loved. I wasn't creating.
So, on my last day interning at AIG, I took a picture of the sea of cubicles in my office and swore to myself I would never return to that life.
Big Break One
As I embraced my love for startups going into recruiting my senior year, a hot new social app called Yik Yak captivated a good portion of the UNC student body. I applied cold for a role being the invisible hand in our 200+ college communities — a role called "Community Manager". A few interviews later, I was sleeping on my friends couch in Atlanta so I could start at Yik Yak immediately. We were a team of 15 supporting millions of users and were #2 in the US App Store. I was helping build something people loved. I could not have been happier.
But I wanted to be more in the trenches of building. I wanted to more directly decide what experience our users would have. So, soon after joining Yik Yak, I eagerly confessed to our newly-hired VP Product my desire to one day be a PM. Skeptically, he noted my desires and that was the end of our conversation.
I spent the next several months unhappy in my role and without the discipline to outperform what was expected of me. Due to my underperformance and lack of technical background, our VP of Product (and, thus, the executive team) didn't support my move to product. At one point, a senior "advisor" to Yik Yak sat me down in a room, looked me directly in the eye, and said: "Zack, you will never be a Product Manager here." I Ieft that meeting with complete clarity that it was time to leave.
Big Break Two
No more than 48 hours after that meeting, due to wild and unforeseen reasons I will not get into publicly, our VP of Product was no longer with the company. The main obstacle preventing me from becoming a PM at Yik Yak was gone. I pounced.
With the support of multiple engineers I had worked with on ad-hoc products and an enthusiastic boost from a Technical Project Manager at the company, I went to our CEO with a proposal: "Give me a chance. If I don't outperform every expectation, I will resign immediately."
He agreed. I moved desks to sit with the product team the next day as Yik Yak Product Manager #2.
While my time at Yik Yak was generally great, it's clear my path to product management was ugly at best. Politics, scrappiness, and luck all played a large role both in me not being a product manager for a while and in me eventually landing the role. The things I want to note here:
Cultivate scrappiness in your skillset. The working world, especially the startup world, is much more of a choose-your-own-journey adventure compared to college. No career counselors, no graduation requirement checklist, and no resume drops for on-campus recruiting. You are responsible for determining your path and making it come to fruition.
Be so good they can't ignore you. Observe the level of output around you and try to double that. Your personal reputation at your company is everything. Produce the highest quality work and make your manager's job easier (make sure he/she fully supports you).
I hope you will learn from my mistakes — but don't be surprised if your path is messy. Generally, everyones is.
2. Develop an informed opinion on what product management means
Josh Elman defines the responsibility of a PM as helping the team (and company) ship the right product to users.
You may also hear PMs referred to as the CEO of the product, but this overstates the role's authority and influence. Being a PM is much more like being an Editor. You have to know your customer (audience), prioritize features (stories), plan roadmaps, keep multiple stakeholders consulted and informed, and generally communicate with humans every single day.
But product management is a relatively new career so its definition changes with time and varies greatly between industries, companies, and teams. How you define product management will also evolve over time. The best way I've found to develop an informed opinion on what product management means to you is to ship real products solving real problems and read about product management (a lot).
2.1. Ship real products solving real problems.
By "real products" I mean you get people to use your product (at least for some period of time) and by "real problems" I mean you identify a need and make sure the product directly addresses that need.
Shipping products will help you discover whether or not you even like building software. I liken interacting with software vs building software to watching a movie vs making a movie. Watching a great movie or show is fun — but even the most outstanding productions are made through a series of long, tedious, and mundane days and sets. I can almost assure you the best and most exciting software products you've used were built in the same way. To love being a product manager, in my opinion, you must find joy in what can be a long, tedious, and mundane process that is software development.
If you find you do enjoy building software, this step should also help you understand which role you most enjoy. I've seen more than a few current or aspiring PMs clearly enjoy solving design problems more than product problems; but, perhaps due to pedigree clouding their vision, they were reluctant to pursue careers in design. Reflect on what you do and do not enjoy, where you excel and where you struggle, and what feels like work to others but a hobby to you. This more wholesome approach will help you determine whether or not product management is the right role for you.
2.2. Read about product management. A lot.
You'll find that many PMs on the Internet write about product management. Cutting through this noise can be tricky so I've listed a few resources I have found helpful in the last section of this doc. [link](<https://www.notion.so/Starting-a-career-in-Product-Management-5f1a7361bf8344eaaa0e59091378ceac?pvs=21>)
The goal of this step is to form an opinion on what product management is at a fundamental level. This may mean diving into the history of the role, what PMs are responsible for at different companies, and what traits engineers and designers look for when working with PMs.
It's worth mentioning "read about product management" does not mean read about agile, scrum, and other forms of project management. While this is certainly part of product development, the best PMs don't obsess over it. Instead, they focus on deeply understanding the customer, aligning and inspiring the team, communicating across all levels and orgs within the company, and generally doing what it takes to ship a winning product.
3. Land the job
The last step breaks down into three sub-steps: become hirable, differentiate your application, and nail the interview.
3.1 Become hirable.
The best way to be hirable is to show you're beyond capable of doing the job and you're coachable. You'll find a few actions helpful in becoming and showing companies you're beyond capable:
Ship products. A repeat of step 2.1.
Document everything. While you and the team build, document everything. The process of shipping product won't be straightforward — it almost never is — and that's ok! Document it through screenshots, pictures, videos, user interview recordings, and writing short reflections.
Create cohesive stories. Soon after you ship (ideally once you've had time to determine whether or not the product is a success), write a case study. Include your documentation. Explain the story of building without focusing too much on process. Don't shy away from including the funny/quirky/unique parts of building the product — they make the story interesting!
While in recruiting mode, you should be able to walk someone through the latest product you've shipped at any given point — ideally in ready-to-pitch time intervals of 15 seconds, 1 minute, and 20 minutes (the 20 min story should include visuals to keep the interviewer's attention). Be sure to include who you worked with, timeline, your role, problems you were aiming to solve, how you discovered and validated those problem, how you defined a winning product, interesting and unique challenges you faced, unique insights you gained, how you aligned and inspired the team, results of the product, and a short reflection.
3.2. Differentiate your application.
In the last four months alone, I've reviewed over 2,000 inbound PM applications at Loom. I spend no more than 8 seconds on each application before making a yes/no decision for a phone screen — I simply cannot give more time.
A critical skill for a product manager is empathy and I beg you to empathize with the hiring manager of every role to which you apply. Generally speaking, every hiring manager is looking for two things: (1) someone that can do the job and (2) someone they like being around. You won't get a chance to show you're someone people like being around until you actually get the interview. But you can show the hiring manager you can do the job.
A pre-interview project is your attempt to anticipate the problems a company is having (or an opportunity they are missing) and proactively solve those problems before you ever even apply. For example, let's say you want to be a PM at Robinhood. Knowing they are growing their product team, you anticipate the needs Robinhood may have in the coming months or years. One that comes to mind, inspired by a dear friend of mind, is "how might we keep customers on Robinhood when the economy turns sour?"
Dedicate 8-10 hours over a week to think through this problem. Interview a range of Robinhood users to understand their mindsets (perhaps a mix of people that traded stocks in 2008 and those that did not). Make assumptions and build a compelling case for a solution. You may find it helpful to double-down on what you uniquely bring to the table — the perspective of a college student / younger consumer. Make a pixel-perfect deck or perfectly-written memo — summary the insights you gained, solutions you explored, and where you would take the project next. Go all-out on this to maximize the "wow" factor.
Next, get your pre-interview project in front of the right person (hint: hiring manager, not recruiter). Stalk the Robinhood product team on LinkedIn and install a free email address hunter to get their respective emails. Record a Loom for each person you find on the product team quickly introducing yourself and introducing your pre-interview project (don't call it that). Send a personalized Loom and email to each of them. Invalid email address? Try again. No reply? Follow-up. Polite persistence, not annoyance, is key.
If you do this right, there is a high likelihood the Robinhood product team (and possibly executive team) will eat it up. They will have no option other than to bring you in for an interview.
3.3. Nail the interview.
It's a bit ironic of me to include this step — I'm not a particularly good interviewer. But a better version of me would do some form of the following.
Focus on product, not process, when walking through your past work. The number one mistake I see inexperienced candidates make when walking me through their past work is focusing too much on process. Focusing on the product you built includes all-the-people-things — understanding constraints (timeline, team, finances, etc); understanding your customer and the market; uncovering and validating problems; ideating and testing solutions; aligning, inspiring, and motivating the team; defining a winning product; measuring success; iterating post-launch; and any random tidbits that stand out and make the product or project unique — are all part of product-building and should be the primary points of your walk-through.
Show you are coachable. Listen intently and make it clear you want to learn. Show humility and confidence.
Be yourself. It's easy to let nerves get the best of you or to go into character to fit who you think they want to hire. But people value authenticity; and those who don't probably aren't the people you want to work with.
Come prepared with thoughtful questions. Interviewers can smell a canned question from a mile away. Avoid them at all costs. Thoughtful questions that cut to the heart of the company's unique business and product strategy stand out in an interviewer's mind. If, at the end of your interview, the interviewer is on the fence about whether or not to move you to the next stage, great questions will push you into the "yes" zone. This has proven itself time after time in the interview debrief process at Loom.
Resources
Links
Nikita Bier's Twitter (a PM skeptic but good entrepreneur and product thinker)
Andy Johns (now VC; strong career in growth and product at consumer companies)
Whiteboard interview framework
The most common mistake I see candidates make in whiteboard or group exefcise interviews is not using a framework to guide the exercise. If it resonates with you, use this framework to guide group exercises or whiteboard sessions to keep you on track and let your interviewer know you're thinking holistically about the development process.
Miscellaneous thoughts
Chasing someone else's idea of pedigree/success will, at best, only lead to short-term happiness. Spend time reflecting on what makes you happy and what you hope to achieve in life. Then pursue that whole-heartedly. For me, it's building something people desperately want but never knew they wanted.
Reflecting on my childhood has played an important role in understanding there areas in which I feel passion and, thus, can produce my best work. For me, this tends to center around communication, online communities, and what I will call Internet culture (e.g. memes).
Struggling to find a product to work on? Think of problems in your daily life with an observant eye. Write an exhaustive list of those problems. Think of ways in which software may help solve those problems. If it helps, externalize these problems and solutions to friends (talking through them may help you better understand them). But don't let your friends identifying risks or "gotchas" discourage you from building. You're shipping product to understand product management. Not to raise venture funding.