Every month I teach a Tech Term You Should Know (TTYSK) and a tech essay to level up your technical literacy and collaborate well with dev teams. Ask me anything and I'll cover it in an upcoming issue.

This issue's TTYSK is "Throttling". Scroll to end to learn more 👇

“You’re not technical enough.”

As a product manager, hearing these words—or even sensing them unspoken—can feel like a gut punch.

Have you ever walked out of engineering meetings questioning your competence? Or hesitated to push back on a technical decision because you didn’t feel “qualified”?

You’re not alone. I often hear from PMs about the challenge of juggling business priorities while navigating technical execution. And the truth is, it’s not about your ability to code or debug issues.

It’s about how you lead—technically.

This brings me to a LinkedIn post I recently came across that hit home.

Bosky’s post resonated with me because I’ve seen this struggle firsthand. It reminded me of Claire, a product manager I worked with at Amazon.

Claire was a Senior Product Manager at Amazon Ads with eight years of experience in the advertising industry. She had previously served as a director and vice president and built a reputation for delivering impactful products and driving strategic initiatives.

Yet, after an engineering meeting one day, she came to me looking defeated. “I barely understood what was going on in there,” she admitted. “I felt completely out of place.”

Despite her impressive experience and leadership background, Claire found herself struggling when technical discussions veered into system architecture, APIs, and scaling strategies. The gap between her expertise in advertising and the technical depth required for her role was intimidating. What struck me most, though, wasn’t her lack of technical knowledge—it was her courage to be vulnerable and ask for help.

Over the next five months, I became her “tech mentor.” We spent time breaking down technical concepts, practicing how to ask better questions in meetings, and building her confidence as a technical leader. Watching her transformation was incredible. By the end, she was able to navigate technical discussions much more comfortably, and when she spoke, the dev team listened.

Claire’s story (and the one in the LinkedIn post) highlights a fundamental misunderstanding many PMs face:

Being “technical enough” isn’t about coding or knowing all the answers. It’s about demonstrating technical leadership.

Developers don’t expect you to solve technical problems for them, but they do expect you to bring clarity, alignment, and thoughtful guidance. They want a PM who:

• Helps them navigate trade-offs between product priorities and technical realities.

• Advocates for both business goals and sustainable development practices.

• Asks the right questions to uncover blind spots.

This is what technical leadership as a PM looks like. It’s a skill you can build, no matter your starting point.

Here’s how you can start developing technical leadership in your role.

Make things Easier and Clearer

After every interaction with engineers, ask yourself: “Did I make things easier or clearer?”.

As a PM you want to remove roadblocks and clarify requirements so that engineers can focus on doing their best work. This might mean:

• Providing detailed, unambiguous problem definitions and requirements.

• Asking questions to surface hidden complexities or dependencies.

• Proactively addressing potential misunderstandings to avoid misalignment later.

When you prioritize clarity and problem-solving in your conversations, you enable engineers to work more efficiently and make better decisions.

Embrace Curiosity over Certainty

Instead of feeling like you need all the answers, focus on asking better questions. For example: “How would this approach impact scalability if user traffic doubles next quarter?” or “What dependencies should we consider before committing to this timeline?” These kinds of questions show that you’re thinking strategically about the product and its technical implications.

Prioritize Technical Alignment

Make it a habit to align product goals with technical needs. This might mean ensuring technical debt gets addressed in the roadmap, balancing feature delivery with long-term system health, and proactively discussing trade-offs during planning sessions.

Translate complexity for stakeholders

One of the most valuable roles a PM can play is acting as the bridge between developers and non-technical stakeholders. Learn to distill technical details into language that executives, designers, and marketers can understand.

Invest in your own learning

You don’t need to be an expert, but building a foundational understanding of technical concepts can go a long way. Focus on learning topics like how APIs work, the basics of system design and scalability, and common engineering workflows such as CI/CD or version control.

If you’ve ever doubted your technical abilities as a PM, know this: You’re not alone. And you don’t need to become an engineer to lead effectively in technical discussions.

Like Claire, you can transform your confidence and build technical leadership skills over time. Start with curiosity, focus on alignment, and trust that your unique perspective as a PM is just as valuable as any technical expertise.

👉 📬 Reply to this email for more content on how to be a technical leader as a product manager.

Learn AI in 5 minutes a day

What’s the secret to staying ahead of the curve in the world of AI? Information. Luckily, you can join 800,000+ early adopters reading The Rundown AI — the free newsletter that makes you smarter on AI with just a 5-minute read per day.

Sign up to start learning.

💡 Tech Term You Should Know (TTYSK)

Throttling

Throttling is a strategy to keep your servers running smoothly during high-traffic periods by managing how many incoming requests they process at a time. Unlike rate limiting, which is a strategy for limiting network traffic by placing a cap on how often someone can repeat an action within a certain timeframe, throttling focuses on spreading out excess traffic rather than blocking it outright, to prevent overload and maintain system stability.

For example, imagine SurveyTool, a platform that helps companies collect employee feedback by processing survey responses in real time. The server for SurveyTool can handle up to 80 survey responses per second across all its users without slowing down or crashing.

Here’s what happens during a busy day:

• Company A sends 10 survey responses per second, using part of the server’s capacity.

• Company B sends 30 survey responses per second, adding to the load.

• Company C sends 150 survey responses per second, far exceeding what the server can handle when combined with the other companies’ traffic.

Altogether, these companies send 190 survey responses per second, which is well beyond the server’s total capacity of 80. Without throttling, the server would try to process all the traffic at once, causing it to slow down—or worse, crash entirely.

Throttling prevents this by temporarily delaying or queuing the extra requests from Company C. Instead of overwhelming the server, these excess requests are spread out over time. Meanwhile, Companies A and B continue sending their responses without any interruptions.

Here’s how throttling works behind the scenes:

• Delaying extra requests: Excess requests are temporarily paused or queued to avoid overwhelming the server.

• Prioritizing critical actions: High-priority tasks, like survey submissions, are processed first, while less critical actions (e.g., refreshing dashboards) are delayed.

• Scaling back nonessential features: Nonessential features, like real-time survey stats, may be scaled back temporarily to focus on core functionality.