Skiplevel: Become More Technical

Software engineer & founder of the Skiplevel Program. Helping product managers and non-engineering roles become more technical ✨

[Skiplevel: Become More Technical @SkiplevelCourse]

2 in 3 leaders wouldn’t hire someone without AI skills.

That’s not speculation. It’s a key finding from the Work Trend Index Annual Report 2024, and it’s a wake-up call: AI is no longer optional for PMs.

Read now how AI Will change the PM role:
🔗 https://t.co/PvRyfhmfbT

[Skiplevel: Become More Technical @SkiplevelCourse]

If technical conversations feel challenging, remember this principle: BREADTH BEFORE DEPTH.

[Irene Yu @iamireneyu]

Product managers–if you want to become more technical, DON'T take a coding class. Try this approach instead:

Focus on BREADTH before DEPTH.

What's this mean?

Understanding the broader technical ecosystem before learning how to code is a fundamental principle at Skiplevel. It's about building comprehensive knowledge across software domains before getting lost in implementation specifics.

Here's why this matters:

Many product professionals believe coding classes will improve their technical communication skills. This is actually counterproductive.

Coding courses teach syntax fundamentals like variable declaration and loop construction...

But when do engineers actually discuss these elements in meetings?

Rarely, if ever!

Real technical conversations center around:

- System architecture decisions
- Solution comparison and tradeoffs
- Technology stack selection
- Deployment strategy planning
- Database and API design
- Performance optimization approaches
- Debugging methodologies

THIS is focusing on breath!

Technical leaders (whether you're a PM or an engineer) excel because they comprehend how these components interconnect. That's what enables meaningful technical discussions.

Developing this broad understanding helps you:

→ Reduce technical insecurity
→ Ask better questions
→ Effectively research technical topics
→ Understand documentation and diagrams
→ Speak confidently about technical aspects
→ Evaluate requirement feasibility

If technical conversations feel challenging, remember this principle:

BREADTH BEFORE DEPTH.

----
Sign up for my FREE email mini-course "Tech Essentials for PMs": https://t.co/z6IuFoaLlZ

[Skiplevel: Become More Technical @SkiplevelCourse]

"We need to improve our orchestration layer.'' 🤔

Orchestration coordinates how services work together in sequence, keeping your product's workflow organized.

PMs: Understanding this = better planning, resource allocation & timelines.

Full breakdown 👉 https://t.co/UQpjSdEv3r

[Skiplevel: Become More Technical @SkiplevelCourse]

🔑 PM wisdom: Before building in-house, ask ''Do we really need to build this ourselves?''

Third-party solutions can save months of dev time while delivering better results.

Stop wasting dev time: Get our guide here👉 https://t.co/GM45jQM81E

[Irene Yu @iamireneyu]

The most underrated product decision: Buy vs. Build.

Before jumping to building a solution in-house, you should ask yourself: "Do we really need to build this ourselves?"

In many cases, a third-party solution can do the job faster, cheaper, and more reliably than an in-house build.

Payment processing, authentication, data analytics are examples of really complex systems that many companies spend months or even years developing from scratch, only to realize later that an existing solution could have saved them significant time and resources.

In fact, I remember once spending weeks trying to build my own timezone conversion library thinking it'd be a challenge but do-able. Turns out it's a lot more complicated than I imagined. I quickly found a pre-built timezone conversion library (moment.js) that did the job beautifully and only took an hour to integrate.

The truth is, smart integration decisions can:
→ Accelerate your time-to-market
→ Reduce technical debt and maintenance burden
→ Allow your engineering team to focus on what truly differentiates your product

But what exactly is a product integration?

A product integration is when two or more software products are connected to work together seamlessly. These integrations allow different tools, systems, or services to exchange data, automate processes, and improve functionality without requiring users to switch between platforms.

A popularly talked about type of product integration is a third-party integration

This specific type of product integration connects your product to an external service or tool built by another company. Instead of developing a feature in-house, you integrate with a third-party provider to leverage their technology.

There are four primary ways to implement third-party integrations:

1️⃣ APIs: For deep, customizable connections (like Google Maps in your booking app)
2️⃣ SDKs: For faster implementation with pre-packaged code (like Facebook Login)
3️⃣ Webhooks: For real-time, event-driven updates between systems
4️⃣ Embedded Widgets: For plug-and-play UI components with minimal dev work

But how do you evaluate which third-party solutions are right for your product?

And which integration method is best for your needs?

I'll be sharing a comprehensive Step-by-Step Guide to help PMs confidently research and select the right integrations in the upcoming issue of the Skiplevel newsletter.

Subscribe now so you don't miss it! 👇

----
Join 7,000+ PMs and leaders to improve your technical leadership skills: https://t.co/f5IHOTwd7C

[Irene Yu @iamireneyu]

"How technical do I need to be as a product manager?"

The annoying answer is: well, it depends. The answer isn't one-size-fits-all.

Your technical requirements depend on four key factors:
→ Your industry
→ Your company culture
→ Your product's technical complexity
→ Your customer profile

If you're managing developer-facing products like MongoDB or working at tech-forward companies like Google, technical understanding (and some depth is essential to your role.

But regardless of your specific PM role, you'll always need a solid foundation in technical concepts to communicate effectively with engineering teams.

Watch the full video for my complete breakdown on navigating the technical aspects of product management.

What's been your experience with technical requirements in PM roles?

----
Join 7,000+ PMs and leaders to improve your technical leadership skills: https://t.co/f5IHOTwd7C

[Skiplevel: Become More Technical @SkiplevelCourse]

If you want to experience what it's like to make actual API requests in a real tool, join the waitlist now for the next "3 API Skills to Work 2x Faster with Engineers: Hands-on Workshop".

Last time, we sold out, so you'd better run! 🏃🏽https://t.co/xv6hSoLHEN

[Irene Yu @iamireneyu]

"I have read API documentation before, but never did a hands-on exercise like this."

That quote from an attendee of yesterday’s "3 API Skills to Work 2x Faster with Engineers: Hands-on Workshop" sums up the whole point of why I created this workshop.

APIs are a crucial technical skill for product managers yet most PMs don’t actually understand how they work.

Why? Because APIs are abstract. You can’t just read about them and "get it."

You actually have to work with them to really understand them.

Engineers understand them intimately because they get to work with them as part of their daily work.

But many product managers don't get this opportunity.

That’s why in this workshop, attendees rolled up their sleeves and practiced 3 API skills hands-on:

→ Exploring real API documentation
→ Making actual API requests in a real tool
→ Understanding how APIs and their components fit together

These skills help PMs confidently research third-party integrations and also test APIs without completely relying on engineers.

But this wasn’t just a tutorial. Every attendee had to make their own decisions throughout the workshop.. just like in real-life product development. This is crucial for critical thinking.

Many of the PMs that attended struggled with reading API docs or getting requests to work.. and that was on purpose.

It's only through struggling can PMs really empathize with what engineers do daily by really feeling the nuance, complexity, and trial-and-error of building software.

Because when you’ve lived it, you ask better questions, make better decisions, and build better relationships with your dev team!

If you want to join the next session, add yourself to the waitlist for the next API workshop here: https://t.co/14ktW7geR6

We'll schedule a next date depending on how many people join the waitlist!

----
Join 7,000+ PMs and leaders to improve your technical leadership skills: https://t.co/f5IHOTwd7C

[Skiplevel: Become More Technical @SkiplevelCourse]

✔️ Essential API skills every PM should know
✔️ A practical, no-code approach to working with engineers
✔️ Hands-on experience with real API tools

Grab your spot before it’s too late ⬇️
https://t.co/ThAl52vxmx

[Skiplevel: Become More Technical @SkiplevelCourse]

API Skills to Work 2x Faster with Engineers: Hands-on Workshop registration ends TODAY!

This isn’t just another webinar. It’s a hands-on, practical session designed to help PMs like you walk away with 👇

[Skiplevel: Become More Technical @SkiplevelCourse]

4 slots left. Grab your slot now ⬇️
https://t.co/bZ4bNA1PGd

[Skiplevel: Become More Technical @SkiplevelCourse]

PMs, imagine this:

Instead of waiting days for an engineer to answer a question, you check the API docs yourself and get an answer in minutes.

Instead of unclear requirements causing rework, your specs are clear and correct the first time.

[Skiplevel: Become More Technical @SkiplevelCourse]

PMs, API skills can save you hours of back-and-forth.
Join Irene Yu on March 25th for 3 API Skills to Work 2x Faster with Engineers: Hands-on Workshop. Learn to read API docs, test APIs, and work smarter with your team.

[Irene Yu @iamireneyu]

The best PMs focus on iterability of business requirements, NOT perfection.

I see this mistake from PMs all the time as a dev: agonizing over creating the "perfect" requirements doc before showing engineering.

But your first draft will always be wrong in some way.

→ Engineers will identify technical constraints you didn't anticipate.
→ Users will behave differently than expected.
→ Market conditions will shift.

Striving for perfect requirements is like trying to predict the exact path of a hurricane a month in advance.

Instead, embrace iterability.

Create requirements with clear outcomes that can evolve as you learn.
Share your thoughts early with engineers to uncover technical realities.
Test assumptions quickly with real users.

The most successful PMs I've mentored don't seek perfection, they seek progress.

They understand that requirements are living documents that improve through collaboration, not solo masterpieces.

Here's how I like to put it: "I don't need perfect requirements. I need a PM who can adapt when we inevitably discover something we didn't anticipate."

What's your approach?

Do you find yourself seeking perfection or embracing iteration?

#productmanagement

----
Join 7,000+ PMs and leaders to improve your technical leadership skills: https://t.co/f5IHOTwd7C

[Skiplevel: Become More Technical @SkiplevelCourse]

ONLY 10 SPOTS LEFT!!! Sign up now ⬇️ https://t.co/bZ4bNA1PGd

[Skiplevel: Become More Technical @SkiplevelCourse]

If you’ve ever felt lost in an API discussion, you’re not alone. Many PMs think APIs are too technical to understand, but the truth is, you don’t need to code. You just need to understand how APIs work.

[Skiplevel: Become More Technical @SkiplevelCourse]

Join Irene Yu's 3 API Skills to Work 2x Faster with Engineers: Hands-on Workshop on March 25th where you'll get real, practical experience with tools engineers use daily.

[Skiplevel: Become More Technical @SkiplevelCourse]

Few slots left! Sign up now ⬇️
https://t.co/THSGBqsDxU

[Skiplevel: Become More Technical @SkiplevelCourse]

Tired of feeling lost in technical conversations? We got you! Join our March 25th API workshop and walk away with real, hands-on API skills to work better with engineers.