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: newsletter.skiplevel.co?utm_…

"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: newsletter.skiplevel.co?utm_…

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: newsletter.skiplevel.co?utm_…

APIs are the invisible backbone of modern software yet they remain a mystery to many product managers. Many PMs I mentored through the @skiplevelcourse commonly tell me technical conversations about APIs often trigger that familiar "I'm not technical enough" feeling. Understanding APIs doesn't require coding skills. It requires a specific mindset and a few practical skills that can dramatically improve how you work with engineering teams. Let me break down some common API misconceptions: → "APIs are too technical for non-engineers to understand" False. APIs are essentially contracts between systems. They define how software talks to other software. The concept is actually quite simple. → "I need to code to work with APIs effectively" Also not true. You need to understand how APIs work conceptually and how to read their documentation but not how to build them from scratch. → "API discussions are best left to the engineering team" This misconception is costing your team time and creating unnecessary back-and-forth. When PMs can't participate in API conversations, requirements get lost in translation. There are some important benefits to product managers who understand APIs, such as: → Writing clearer, more technically feasible requirements → Identifying integration opportunities that drive user value → Asking better questions during technical discussions → Estimating timelines more accurately → Bridging communication gaps between business and engineering From my 10 years of working with product teams as a software engineer, I've identified 3 key API skills every PM should develop: 𝟭. 𝗔𝗣𝗜 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗟𝗶𝘁𝗲𝗿𝗮𝗰𝘆 Learning to navigate and understand API documentation is like getting a map to a new city. It shows you what's possible, what data you can access, and how systems can interact. This skill alone can save weeks of back-and-forth with engineering. 𝟮. 𝗔𝗣𝗜 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗔𝘄𝗮𝗿𝗲𝗻𝗲𝘀𝘀 Understanding the difference between REST, GraphQL, and webhooks helps you grasp the trade-offs engineers consider. This knowledge helps you participate meaningfully in discussions about which approach best serves your users' needs. 𝟯. 𝗔𝗣𝗜 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗕𝗮𝘀𝗶𝗰𝘀 Being able to use simple tools to test APIs gives you independence. Instead of always asking engineers about data structures or endpoint behavior, you can explore and validate assumptions yourself. I've seen PMs transform from anxiously avoiding API discussions to confidently leading them — often after just a few hours of focused learning. Want to develop these skills and work more effectively with your engineering team? Join me for a hands-on workshop: "3 API skills to Work 2x Faster with Engineers" where you'll get real, practical experience with tools engineers use daily. Tuesday, March 25th, 2025 @ 12pm ET This isn't just theory — you'll get your hands dirty with: → Reading actual OpenWeather API documentation (the same ones engineers use) → Making real API requests and seeing how responses work → Using professional API testing tools that engineers rely on daily → Learning to interpret JSON responses without needing to code You'll walk away with practical skills you can immediately apply to your next engineering conversation. Early bird spots end on Tues, March 18th so make sure to grab your spot below 👇

How you frame your impact during PM interviews can completely shift how companies see your value. Here's how to do it: In a recent Skiplevel newsletter interview, Marc Baselga (Founder of Supra and Product Leader) shared what it really takes to land a Product Leadership Role in 2025, offering a powerful framework for articulating your impact during negotiations: Focus ruthlessly on three core dimensions of business value: → Increasing revenue - How have your product decisions directly contributed to top-line growth? → Reducing costs - What efficiencies or savings have your initiatives created? → Improving cycle time - How have you accelerated development processes, decision-making, or time-to-market? Rather than making vague statements about responsibilities, create a detailed impact narrative with specific, measurable outcomes: → "Led the redesign of our checkout flow, resulting in a 17% conversion improvement worth $3.2M annually" → "Implemented a new prioritization framework that reduced development cycle time by 35%" → "Restructured the product development process, eliminating $420K in unnecessary costs" For maximum impact, present these achievements in writing. A comprehensive email might include: → 5-7 specific achievements with quantifiable results → 2-3 unique skills that few other candidates possess → Direct experience relevant to their specific challenges → Concrete examples of revenue impact and team leadership This approach works for both technical and non-technical roles because it focuses on business outcomes rather than technical specifications. The key is quantifying your contribution in terms that matter to the company's bottom line. What specific, measurable impacts have you delivered in your current role? How might you frame those accomplishments to demonstrate clear business value in your next negotiation? ----- Join 7,000+ product managers and leaders to improve your technical leadership skills: newsletter.skiplevel.co

#ProductManagers: Your BRDs should be business-focused, we know that. But they should also provide enough information to help the dev team complete their work. Here are three simple tips to make your business requirements more effective: 1️⃣ Less words, more diagrams: Visuals like user flows and decision trees simplify complex requirements, making them easier to understand. 2️⃣ Make it testable: Replace vague terms with measurable metrics. Instead of saying “fast load time,” specify “1.5 seconds page load”. 🧐 Want to know the third tip? Check out my article, "3 Tips for Writing Business Requirements for Your Engineering Team", to discover the last, equally important tip! I break it down in detail so you can start improving your BRDs today. Here's the link: bit.ly/BDRtips

🚀 IT'S FINALLY HERE! My conversation with @KiwiDenny on "How technical should a Product Manager be" for the Product Management Stories podcast is officially live! Listen now to learn: - How technical should a PM be - Breadth vs. Depth framework for technical skills & knowledge - Translating product requirements into technical implementation as a core technical PM skill - How to have more agency as a PM - Why the topic of how technical a PM should be such a hot topic - How & Why I started Skiplevel - .. and much more! Listen here: bit.ly/45ylQjC 🎧

Product managers, did you come from a technical background? #productmanagement

Q for Product managers: Have you ever worked with a frontend dev that was also the UX Designer and coded everything directly with no mocks? How did you provide feedback to them without disrupting their workflow? 👇This was a question posted by Ashley, a PM in the @SkiplevelCourse community. What advice would you give her? (My advice in comments!) #productmanagement

SUPER excited to share my recent highly enjoyable convo w/ Kirk Fernandes of Merit on building a strong relationship b/w #productmanagers & devs! Not only did I learn a few things myself, but I had a ton of fun😊 See more about the convo in thread below👇

#productmanagers, maximize your relationship with engineers to have the influence you want: