You don’t need to code. But you do need to understand this.

👋 Hey friends,

A few weeks ago, I confidently told my engineering team, “Yeah, sorting and filtering on this table should be pretty straightforward, right?”

The look on their faces told me everything I needed to know.

Turns out, what I thought was a “quick win” feature was actually one of the most technically painful projects we could tackle for our backend infrastructure.

If I’d had that conversation three months ago, before I started working with a backend team again, I would’ve put that feature at the top of the roadmap. We would’ve burned weeks of eng time on something that wasn’t worth the complexity.

That moment reminded me: being “technical” as a PM has nothing to do with writing code.

It has everything to do with understanding your systems well enough to make smart calls about what’s hard, what’s easy, and what’s worth the pain.

AI skills aren’t optional anymore—they’re a requirement for staying competitive. Now you can earn a Master of Science in Artificial Intelligence, delivered by the Udacity Institute of AI and Technology and awarded by Woolf, an accredited higher education institution.

During Black Friday, you can lock in the savings to earn this fully accredited master’s degree for less than $2,500. Build deep expertise in modern AI, machine learning, generative models, and production deployment—on your own schedule, with real projects that prove your skills.

This offer won’t last, and it’s the most affordable way to get graduate-level training that actually moves your career forward.

Learn More

“Do I need to know how to code to be a PM?”

Short answer: No.

Longer answer: It depends on what kind of PM you want to be and what problems you want to solve.

I’ve worked with three different team types now. My first two teams were frontend only. My startup team was full stack. And now, I’ve adopted a backend team for our reporting platform.

Each one required different technical fluency, not because of coding skills, but because of system understanding.

When I work with frontend teams, I need to understand component libraries, state management, and performance trade-offs for what users see.

Now with backend, I’m learning about data pipelines, query optimization, and why certain features that look simple on the surface are actually architectural nightmares.

I don’t need to write a single line of code to gain that understanding. But I do need to ask a lot of questions, sit in on technical discussions, and build enough context to have an opinion on prioritization.

Peter Deng broke down 5 PM types: Consumer, Growth, Business/GM, Platform, or Research/AI.

The key insight -Your technical depth and skills should match the problems you’re solving and the team you’re on.

If you’re building developer tools or APIs, yeah, you probably need deeper technical chops. If you’re working on consumer-facing features, you need to understand enough to know what’s feasible and what’s a six-month project in disguise.

But here’s what every PM needs, regardless of type:

System fluency. The ability to understand how your product works under the hood well enough to make informed trade-offs.

The confidence to ask questions. “Walk me through why this is hard” is one of the most powerful questions a PM can ask.

Enough context to have an opinion. You don’t need to architect the solution, but you should be able to weigh in on whether it’s worth doing.

Here’s how I build technical fluency on new teams:

1. Sit in on technical discussions (even if you don’t understand everything)

I attend backend architecture reviews now even though half the terms fly over my head. By the third meeting, I start picking up patterns. By the fifth, I can ask better questions.

2. Ask engineers to “draw it out”

When I don’t understand how something works, I ask someone to literally sketch the system architecture. Visual learning > trying to decode technical jargon.

3. Learn the constraints of your stack

You don’t need to know how to code in Python, but you should know if your backend is built in Python. You should know if your database struggles with certain query types. You should know what makes deployments risky.

4. Build a “what’s hard, what’s easy” mental map

After every technical conversation, I update my internal map of what’s painful for my team vs. what’s straightforward.

Before this month, I thought table sorting was easy. Now I know it’s hard for our backend setup. That knowledge changes how I prioritize.

ChatGPT is a superpower if you know how to use it correctly.

Discover how HubSpot's guide to AI can elevate both your productivity and creativity to get more things done.

Learn to automate tasks, enhance decision-making, and foster innovation with the power of AI.

Download the free guide.

“I can’t be a PM because I don’t code.”

That’s not true. But here’s what is true:

You need to understand the systems you’re working with well enough to make informed decisions about what to build and when.

The level of depth you need depends on the type of PM you want to be and the team you’re on. A PM working on internal data tools needs different technical fluency than a PM working on a mobile app.

But all of us, no matter what kind of PM we are, need to build enough context to have an opinion when it matters.

If you’re trying to figure out how “technical” you need to be:

You don’t need to become an expert. You just need to close the gap between “I have no idea” and “I understand enough to make a call.”

Being technical isn’t about coding.

It’s about building enough understanding to know what’s hard, what’s easy, and what’s worth fighting for.

See you next Friday,

– Stef

💬 Want to talk product? I’m mentoring on ADPList! If you’re figuring out how technical you need to be, navigating your first backend project, or just need a sounding board, you can book a free session with me right here.

If you like Stef the PM, here are a few other reads worth checking out: