How to Become a Technical Product Manager

Most people know what a Product Manager is, but few know what a Product Manager does. Luckily, the world has given us a few archetypes to help us on our journey of understanding Product Management.

There’s Adam, the Google Product Manager who estimates the number of podcast listeners in Lithuania on a post-it note during lunch.

There’s Amber, the Intuit Product Manager who invites her customers to Corporate Headquarters to participate in a focus group.

And there’s Eve, the former Software Engineer who has decided that writing emails to the marketing department is more fun than debugging a Java 6 codebase written by a girl who retired four years ago.

As you make your way into Product Management, you’ll hear about these stereotypes and think fine, but at 3pm on Tuesday, what is Product Manager Eve actually doing!? Unfortunately, the most common resource on Product Management doesn’t really help us understand the role. In terms of books, Cracking the Product Manager Interview is probably the most popular Product Management resource, and Lewis Lin’s Decode and Conquer is another.

While both resources are useful to prepare for an interview, the nature of Product Management has changed substantially since both books were published. And that’s only the interview-related resources. In order to understand the nature of the job itself, the gold-standard guide to Product Management is still a PDF published by Ben Horowitz in 1997.

To put that into perspective, in 1997 the hottest tech product in the world was the Tamagatchi.


Remember these?

Despite the growing interest in Product Management, I’ve found few resources that explain what product managers actually do. Moreover, I’ve found hardly any resources that explain what technical product managers actually do.

I think it’s time to offer my brief but contemporary perspective on Technical Product Management. Specifically, what the job is, why it’s different from “non-technical” product management, and a bunch of practical interview tips to help you succeed in your job search.

My Path to Product Management

My path to Product Management wasn’t straightforward.

After graduating college, I hadn’t received any job offers I was excited about, so I decided to spend the next few months working on passion projects. That summer, I decided to start building and flipping eCommerce stores. I spent the next year immersed in the world of eCommerce. In addition to building my own stores, I helped some small businesses in New York with freelance consulting work. After a year of being a digital nomad in my native New York (i.e. living with my parents and occasionally travelling to Europe), I felt my skills starting to plateau, and so I decided to start exploring opportunities at startups.

I had become increasingly interested in blockchain technology during this phase, and I decided to focus my efforts there. Product Management seemed like the obvious path for my skill set. I sort of knew how to program, I felt comfortable doing sales, and I liked designing interfaces.

After applying to a few startups, I finally landed at a 15-person blockchain company in Brooklyn. It was my first real job after college, and my first experience as a PM.

When I started the job, I worked on nearly all aspects of the business. I redesigned the website, setup an email marketing funnel, and gave demos to prospective customers at meetups. Most of my work was ad-hoc.

After a few months, I was promoted, and my responsibilities became more narrowly defined. The company was preparing to go-to-market and had a long list of features that needed to be built to be seriously considered by customers. From that point on, it was my job to write product requirements for all of our new features. Each week, I’d sit down with the founders and write up requirements documents that would dictate the work our engineering team would work on for the duration of their sprint.

The job ended up being a good fit for my writing-heavy humanities curriculum in college. I wrote dozens of specs, and read Joel Spolsky’s blog.

What is a Technical Product Manager?

The main job of a PM is to ensure that a company delivers a product that aligns to a company’s mission. The PM meets with her stakeholders to decide which features to deliver, and at what cost. It’s the PM’s job to ensure that their product delivers value to the customers and the business.

However, the job of a Technical PM is to ensure that the work outputs of the engineers help support that mission.

Here’s a little 2x2 with some of the tactical differences between the two flavors of Product Managers:

Business PM Technical PM
Stakeholders are users Stakeholders are engineers
Plans launch Plans sprint
Press Release Product Requirements Document
Napkin math Sequence diagram
Dependency on designers Dependency on dev ops
Google Analytics Datadog
Sketch VSCode
Writes emails Writes JSON

So, while a business PM might own a launch, a TPM will usually own the requirements for a new feature. Your ability to succeed in requirement gathering requires three main skills:

Be comfortable scheduling meetings with people in other parts of the organization

As a PM, one of your main jobs is communication across teams. While the engineers usually have more tasks than you, you have more leverage. Scheduling the right meeting with the right people in order to unblock a project or help someone make a decision is often worth more than two weeks worth of code.

Have a lawyer’s understanding of programming

Why a lawyer’s understanding? Because lawyers are often tasked with describing technical details to laypeople. If you’ve ever read a memo prepared by a lawyer, you’ll notice that they explain technical details in an extremely simplified level of detail. As a TPM, you should have a similar understanding of software. Remember, it’s not your job to help the engineers implement features. Your only job is to understand how a piece of code might benefit the business so that you can prioritize engineering work accordingly.

Be capable of summarizing technical information in a written format

After you’ve scheduled meetings and extracted information from your stakeholders, you’ll need to distill your findings into a requirement document or a JIRA ticket. Writing is one of the most important TPM skills. You’ll need to summarize information from several meetings into bullet points that business people can understand. If you’re able to schedule meetings with the right people and summarize those meetings as bullet points, you’re 90% of the way towards being an excellent TPM.

Preparing to Apply

When you apply for a TPM position, the hiring manager is trying to answer one big question while reading your resume: is the candidate comfortable working with engineers? The answer is usually conveyed in your experience. Have you worked on a hackathon team? Did you sit between an engineer and a designer in your last job?

If you’ve already worked as a non-technical PM, getting experience working closely with engineers is the best step towards getting past the resume stage. Remember, you don’t need software engineering experience to get here. You only need to prove that you’re capable of contributing to technical discussions.

As a general rule, having some hands-on programming experience is helpful. Luckily, the extent of this knowledge can be fairly narrow. No, you don’t need to know algorithms. But, here’s the one skill that will put you on a fast-track towards success: be capable of building a CRUD API. What’s a CRUD API? CRUD is just an acronym for create, read, update, delete, which are the main verbs associated with REST APIs. Building a CRUD API entails a few steps:

  1. Write code to retrieve and insert data from a database
  2. Host the database on the cloud
  3. Host the code on the cloud, and expose an HTTP endpoint
  4. Invoke the code from the terminal as a CURL request

If you’re able to accomplish this, you’ll be in a great position to communicate technical concepts during your interviews. You might be wondering whether this is really necessary for a TPM.

In my opinion, while it’s not absolutely necessary, I believe a baseline level of hands-on ability is necessary for having the confidence to work on a technical team. And, while you can practice the algorithms in Cracking the Coding Interview until your dry-erase marker runs out, you’ll be disappointed to learn that 99% of modern software engineering is building very simple features, like getting a user’s birthday from the database.

While some companies do use algorithm ability as a makeshift aptitude test, this is not very common for TPM interviews. Instead, the main aptitude test for TPMs is whether you can take a large amount of information and convert it into concise bullet points.

The Interview Process

The Phone Screen

During the phone screen, hiring managers are looking to answer three questions:

  • Is the candidate comfortable working with engineers?
  • Can the candidate explain technical concepts clearly?
  • Is the candidate familiar with the software development process?

The Technical Interview

If you’ve made it past the phone screen, you’ll usually be invited to chat with the hiring manager. This is usually your prospective manager. Their goal is to evaluate you according to the same metrics listed above, but in a little more detail. You’ll be asked longer-form questions, such as:

  • Walk me through a product you built (if you don’t have formal PM experience, talking about a CRUD API you built is a great talking point here!)

The On-Site

Just like the technical interview, this stage is designed to evaluate you based on the same core metrics: whether you’re comfortable working with engineers, can explain concepts clearly, and understand the software lifecycle. Expect the questions in this stage to be more open-ended. You’ll probably be given a case study-esque scenario to answer, which will require you to organize your thoughts using a whiteboard. You can expect questions, such as:

  • Our company is going to partner with Stripe in order to accept payments. Walk through the changes we need to make on our backend to support Stripe, and then break those changes up into JIRA ticket-sized chunks
  • Your development team comes to you in the middle of the project and lets you know they discovered an issue that will impact project timelines by adding another 20% to the overall timeline. Do you push back?
  • You’re asked to create a new product. Where do you start?

The Offer

If you’ve gotten here, congrats! There’s just one obstacle left before you’re home safe: the negotiation. Negotiation deserves its own section. It’s a basic skill that will help you earn $10,000s more over your career. In short, you should know this: even if you’re a new college grad without any experience, recruiters still expect you to negotiate. Remember, the company already wants to hire you, and negotiating with your recruiter will not change that.

You’ll usually know you’re approaching an offer if the recruiter asks you to chat on the phone after your onsite. You won’t get a phone call if you’re being rejected. And while an offer is not guaranteed yet, you should start preparing for the conversation if a recruiter asks to speak on the phone.

Winning the Negotiation

Before the offer, you should mentally prepare yourself to negotiate. I find it helpful to organize my thoughts on a sheet of paper.

  • Write down three numbers: how much you expect the company to offer, how much you’ll say you want, and how much you actually want.
  • Then, write down a few bullet points explaining why you’re a strong candidate.
  • Finally, write down a few bullet points with non-cash items you value (such as a free laptop, vacation days, flexible WFH, etc.)

When you get on the phone with the recruiter, remember: even if you’re offered your target cash compensation from the outset, you’re leaving money on the table by not countering at least once.

The conversation should go something like this:

Recruiter: We’re thrilled to offer you a position on our team. We’re offering you $85,000 in cash, along with 10,000 shares of stock options. Do you have any questions for me?

You: That sounds great, and I’m thrilled to have the opportunity to join your team. This is the job I want. That said, do you have any flexibility on that number?

Recruiter: Is there a specific number you had in mind?

You: Given my experience in {skill} and {skill}, I believe {your target amount + 20%} is fair.

Recruiter: Thanks, that’s slightly more than we expected, but I’ll check with the hiring manager and let you know.

Here’s a secret: within 10 minutes to 24 hours, the recruiter will call you back offering you more money. No strings attached. I’ve used this tactic in every job I’ve been offered, and it’s earned me tens of thousands of dollars more over the course of my career.

Remember, there’s never any downside to negotiating. You’ve locked in the offer, and the company has already invested thousands of dollars into interviewing you. They want you to come onboard, so don’t leave money on the table by just accepting the first number they provide. Your salary will compound over your career, so starting a new job with an even slightly bigger number will put you ahead in the long run.

Career Growth

As a PM, you’ll notice that small actions you take can have a big impact on your team. You’ll often serve as the face for the engineers, which means you’ll be giving presentations to the rest of the company about what the engineers have been working on. Use these opportunities to clearly explain the business value of each engineering project.

If you’ve ever worked as a PM, you’ve probably been irked when someone mistakenly refers to Product Management as Project Management. Now’s a good time to dispel the difference between the two: while Project Managers are responsible for the timely execution of a project, Product Managers are responsible for the strategic alignment of engineering effort to a corporate goal. Basically, the Product Manager is an insurance-measure against runaway engineering work.

Here’s a way of thinking about it: PMs work for Heads of Product. The Head of Product has a budget. Say, $2mm to build an engineering team to migrate a database from Oracle to SQL. The Head of Product reports to the COO, or someone at the executive level. They’re responsible for justifying the expense towards achievement of a business goal. But since they’re working on budgeting or hiring all day, they’re not in a position to ensure that their engineers are making the correct trade-offs on a day-to-day basis between the $2mm, high-value, project, or some random feature request from the customer service team.

As a PM, your job is to ensure that your team works on the highest-impact work. But, importantly, your job is also to help justify the cases where that work is deprioritized in favor of other things. Maybe the customer service team truly had an important bug that needed to be fixed, and now the $2mm project is behind schedule.

As a good PM, you’ll need to present this justification to the Head of Product, so that they can be assured that their $2mm project isn’t in jeopardy, and that you had the organization’s best interests at heart the entire time.

Usually, these sorts of justifications are conveyed in a presentation that you give to various stakeholders. In giving presentations, your success metric should be whether the least technical person in the room understands the value of the most technical thing you’ve presented.

You’ve probably heard the age-old metaphysics question: if a tree falls in the forest, does it still make a sound? When it comes to your job as a TPM, you should know that engineering work is only noticeable in your organization when someone gives a presentation explaining why it’s valuable to the business. Take advantage of these opportunities, and you will go far in your role.


With this guide, you’re hopefully better equipped to succeed in your journey towards becoming a TPM. For those of you who are dually interested in software (code) and business (strategy), it’s one of the rare jobs which strikes a good balance between the two worlds.

As I’ve mentioned in the guide, you don’t need to be super technical to be hired, but it helps to have one minor technical skill you’re capable of accomplishing on your own. Whether that’s building a CRUD API to fetch stock prices or building a slackbot to notify your colleagues whenever a new user signs up on a website, you’ll profit from having this skill sharp and ready to deploy in your job interviews. And when you’ve crushed the interview and are nearing a job offer, just remember: negotiation never hurts, and it’s the easiest thing you can do to earn more money over the course of your career.

I’ve worked with a variety of PMs, and they’ve all approached their roles slightly differently. One of the benefits of being a PM is that you’ll be able to behave with a fairly high degree of autonomy, even early on in your career. While there are some rules of thumb that can point you towards success, I would caution against following any single set of guidelines too closely. Being a PM is largely about making decisions under uncertainty, and being confident in your reasoning for making a particular decision. In a nutshell, this means making judgements from first principles, and following a how-to guide verbatim won’t help you achieve the type of decision-making autonomy that distinguishes great PMs. However, my hope is that this guide can at least provide an introductory framework for developing your own mental models about the TPM role.

Because you’re reading this guide, my guess is that you’re already in the top 10% of PM candidates. You’ve likely learned many of the tactics so far - what the role entails, what to say in an interview, and what resources to read beforehand.

But the most important skill of all is developing an independent thought process. If you develop the ability to reason from first principles and combine that with the tactical knowledge of sprint planning, customer discovery, and API development, you’ll be unstoppable.

Did you enjoy this?

If you've enjoyed reading anything here, you should consider signing up for semi-regular emails from me. That's the first place I go to share anything that's on my mind.