Become a more technical product manager
Technical foundations for product managers
👋 Hey, I’m Lenny and welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career.
P.S. Don’t miss my PM recruiting service (to hire your next Sr. PM or VP), Lennybot (an AI chatbot trained on my newsletter posts, podcast interviews, and more), and my swag store (great gifts for your favorite PM, or yourself!)
Q: How do I become more technical?
A technical background is a superpower for product managers, as I’ve said before. You’ll make better decisions, understand trade-offs, make more accurate estimates, and communicate with engineers with more confidence, while also creating more career opportunities for yourself. And now that AI is increasingly infused into products, it’s even more important that product managers understand the basics.
To help you level up, I teamed up with Colin Matthews, instructor of the very popular Maven course Technical Foundations for Product Managers. Below, Colin breaks down in the simplest way possible—and with hands-on practice—APIs, code deployments, system architectures, branches, databases, unit tests, and much more. If you’ve been embarrassed, or too busy, to ask your engineers how all this works—this post is for you.
For more from Colin, check out Colin’s Maven course—the next cohort kicks off on May 6! Use this link to get 25% off.
Building a strong foundation of technical skills improves your ability to bridge technical and business domains, uncover implementation issues before they’re in production, and improve your working relationships with your technical counterparts. This quick guide will help get you up to speed and start building your skills with hands-on practice.
Application architecture and APIs
Almost every software product is built with the same three parts: a client, a server, and a database. Things can get a lot more complicated as you grow, but these fundamental ideas stay the same.
The client is your website or app that’s used by the end user.
The server processes requests from the client.
The database is your permanent storage of data.
Your client communicates with your server through an application programming interface, or API.
What is an API?
For most software product managers, we’re talking about web APIs. This is the front door to your server that allows other applications to access data or trigger events.
APIs are everywhere—Meta, Etsy, OpenAI, your bank, your doctor, the weather. These kinds of public APIs are meant to be used by developers outside of the company that built them. Anyone who has permission can start making API calls to get data, submit new information, or even interact with AI.
APIs can also be private. These are intended to be used only within that application or product (versus by third parties).
As a quick example, let’s look at how Airbnb might fetch listings to show you when you search for Toronto.
Breaking this down, we can see that:
The client sends a request to listings at the URL api.airbnb.com and specifies the location as Toronto
The server gets the listings in Toronto from the database
The database returns listings to the server
The server returns listings to the client
Wait, so what exactly is the API?
Is the API the server? Kind of. As we said above, the API is the server’s front door—it’s the set of actions that are available to clients. The API (hosted on a server) will either process the request itself or pass it downstream to be processed.
Going back to our Airbnb example, in addition to fetching Listings, you could imagine the API also allows a client to access Users, Bookings, Prices, and more. We commonly call these endpoints or resources.
Let’s take a look at another example: OpenAI. OpenAI supports a wide range of actions via their API. You can create images, transcribe audio, and get chat responses. Here’s what their API endpoints look like:
OpenAI has organized their API into a few groups—images, chat, and audio. Within each, there are a few endpoints that allow you to take different actions. For example, you could send a request to /audio/speech to create an MP3 file of text-to-speech with the AI voice of your preference.
Here’s an example:
What are some common patterns with APIs?
Once you understand a few basic patterns with APIs, you’ll be able to breeze through technical documentation in no time.
First, there are three main types of APIs:
SOAP: This is a legacy design, still used mostly in health care and financial services.
REST: This is the most popular design pattern; we’ll get into more details below.
GraphQL: This is a newer design created at Meta, most commonly used in private APIs within your own application. It uses the same request types but in different ways.
As mentioned, REST is by far the most popular design for APIs. It supports many different request types, but there are two we’ll focus on today—GET and POST.
GET requests
GET requests do what you think they would: get stuff. Every time you open a web page, your browser sends a GET request to the server at the URL you’ve entered and the server returns some content to be rendered.
In its simplest form, this content can be an HTML file that your browser displays, or it can be a more complex format that needs to be interpreted, like JSON.
Let’s update our Airbnb example above to specify the request type.
Now we can see that we’re sending a GET request to the /listings endpoint. We also specified that we only want listings in Toronto.
Let’s break the request down into its components:
Base URL: The “home” for all API endpoints
Endpoint: The specific resource we want to access
Query parameter: Additional data passed in with our requests
POST requests
POST requests are used to submit new data to the server. For example, we would use a POST request on Open AI’s /images/generations endpoint to create a new image.
We would also include a body with the request, which contains data to be processed by the server. Here’s what that might look like:
As long as we have access, OpenAI will respond to this request with the cutest baby sea otter you’ve ever seen.
Remember that text-to-speech example with an AI-generated voice that we got from OpenAI’s API? Well, that was a POST request.
To generate this, we sent a POST request to https://api.openai.com/v1/audio/speech with the following body:
{
"model": "tts-1",
"input": "Did you know subscribers to Lenny's Newsletter get exclusive discounts with partners? Pretty cool! And there's a Slack channel!",
"voice": "alloy"
}
In response to this request, the API sends back an MP3 file with the text-to-speech phrase.
How can I practice?
Want to try a request for yourself? Follow along to generate your own images using DALL-E and OpenAI’s API.
Sign up for an API account at https://platform.openai.com/signup
Navigate to API Keys. Verify your account and create your first API key. Make sure you copy it!
Using Postman or a web-based API request tool (here’s a free one), make a POST request to https://api.openai.com/v1/images/generations
Add the following Headers
Authorization: Bearer [your-api-key]
Content-Type: application/json
Add the following body in JSON
{
"model": "dall-e-3",
"prompt": "A cute baby sea otter",
"n": 1,
"size": "1024x1024"
}
Send your request!
Software development lifecycle
Now that we understand the basics of application architecture and APIs, we can talk about how engineers actually build software. Chances are you’re following some version of the software development lifecycle, or SDLC. This follows a familiar process:
 | A guest post by
|