Product Engineers - Create Fiercely

Peppe Silletti
  • 0.0 (0)
  • TECHNOLOGY
  • EVERY TWO MONTHS

Unpacking the product x engineering convergence. Interviews, research, and stories from the field. newsletter.productengineers.com

Episodes

  1. Why Your Leadership Style Won't Survive Product Engineers (CTO Coach)

    2 FEB

    Why Your Leadership Style Won't Survive Product Engineers (CTO Coach)

    Is your leadership style built for an era that's already ending? Stephan Schmidt has seen tech transform three times: home computers, the internet, and now AI. As a CTO coach with 40+ years of experience, he's watched command-and-control crumble, agile get diluted, and now product engineering emerge as the response to AI-accelerated development. In this episode, we explore why the bottleneck was never engineering (it was always product management), how AI is killing waterfall for good, and why CTOs need to evolve into CPTOs or risk becoming obsolete. Stephan doesn't hold back on what it really means to be "bullish on AI" and why developers might face the same identity crisis journalists did with social media. --- GUEST Stephan Schmidt - CTO Coach & Author of "Amazing CTO" Stephan has over 40 years in tech, from writing video games as a kid to coaching CTOs and engineering leaders today. He's been through the home computer revolution, the internet boom, and is now helping leaders navigate the AI transformation. --- Find Stephan: - Website: https://amazingcto.com- LinkedIn: Search "Amazing CTO"- Book: "Amazing CTO" (available on Amazon) --- TIMESTAMPS 00:00 Introduction and Guest Welcome 01:17 Stefan's Journey into Tech 02:05 Tech Revolutions Over the Decades 03:05 Leadership Evolution in Tech 05:04 The Rise of Agile Methodologies 07:49 Challenges with Agile Implementation 09:52 Emergence of Product Engineers 14:40 Leadership in the Age of Product Engineers 19:57 The Changing Role of CTOs 22:47 The Evolving Role of the CTO 23:31 Defining the CTO's Responsibilities 25:21 Building Efficient Tech Teams 28:15 The Importance of AI in Modern Organizations 32:12 Empowering Non-Technical Leaders with AI 37:53 The Future of Product Engineers 41:09 Advice for Leaders Adopting Product Engineering 44:51 Conclusion and Contact Information --- KEY TAKEAWAYS 1. The bottleneck was never engineering - it was always product management. AI just makes this obvious. 2. Waterfall keeps creeping back because of "efficiency" - designers work 1 sprint ahead, product 2 sprints ahead. AI breaks this pattern because speed gains kill waterfall's perceived efficiency. 3. Leadership (not management) becomes critical - declaring a vision and getting people to follow, not command-and-control. 4. Teams are too big - if only 3 of 5 people engage in standups, you have 2 teams pretending to be one. 5. Code will become less important as an artifact - like binary is to us today. Think bigger. 6. Product engineering should be a promotion, not a rename - make engineers earn the title through demonstrated skills. --- RESOURCES MENTIONED - "Amazing CTO" by Stephan Schmidt - Extreme Programming by Kent Beck - Article: "Why We Always End Up with Waterfall" - Amdahl's Law (system bottlenecks) --- CONNECT WITH PRODUCT ENGINEERS Host: Peppe Silletti LinkedIn: https://www.linkedin.com/in/peppesilletti/ Product Engineers Community: Website: https://productengineers.com LinkedIn: https://www.linkedin.com/company/product-engineers --- SUPPORT THE SHOW If this episode made you rethink your leadership approach, share it with a fellow tech leader who needs to hear it. Drop a comment below with your biggest takeaway. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.productengineers.com

    46 min
  2. Why Your Product Trio Is Actually Waterfall in Disguise (Product Lead)

    17/12/2025

    Why Your Product Trio Is Actually Waterfall in Disguise (Product Lead)

    Product managers who vibe code. Engineers who make product decisions. Designers shipping prototypes without handoffs. The roles are blurring, and it's not just because AI makes it possible - it's because staying in your lane might be what kills your company. Else Van Der Berg has been crossing domains for 15 years, and now she's watching the convergence accelerate at AI-native companies like Wave Terminal and SwitchUp. In this episode, we explore why natural convergers have always existed (but were told to "stick to their lane"), how AI-native startups are staying impossibly small while scaling revenue, and why product-market fit collapse means every company is pre-PMF again. --- GUEST Else Van Der Berg - Product Lead & Solopreneur Else has 15 years of product experience and currently works with two AI-native companies: Wave Terminal (an AI-native terminal and dev tool) and SwitchUp (AI-native internal tools). She's spent the past nine months vibe coding, building AI agents, and exploring the convergence of product and engineering firsthand. As a "natural converger," she's been pushing domain boundaries long before it had a name. Find Else: - LinkedIn: https://www.linkedin.com/in/dr-else-van-der-berg-42b8b6a2 --- TIMESTAMPS 00:00 Introduction and Guest Backgrounds 07:30 How PM, Design, and Engineering Roles Are Evolving 16:59 Why AI Makes the Convergence Real (Beyond the Hype) 19:38 Can Legacy Tech Companies Adapt to This Shift? 25:25 Scaling Culture: Why AI-Native Companies Stay Small 34:04 Real Examples: Unsend, Wave Terminal, and the Iteration Factory 40:09 Product-Market Fit Collapse: Why Everyone's Pre-PMF Again 44:46 M-Shaped People: Masters of None or Cross-Domain Advantage? 55:35 Why Over-Specialization Is Anti-Agile 01:01:32 Wrap-Up --- KEY TAKEAWAYS 1. Natural convergers have always existed - that 1973 journal proved developers worked directly with clients. We artificially specialized and now we're going back. 2. AI-native companies are the new anti-flex - Cursor: $100M ARR with 12 people. Mid-Journey: $200M ARR with 40 people. Growing headcount isn't cool anymore. 3. Product-market fit collapse is real - Stack Overflow got destroyed overnight by ChatGPT. Every company is pre-PMF now because AI competitors can appear instantly. 4. The handoff tax is more expensive than learning - product trios sound nice until the developer can't make the interview and the designer is "too busy with sprint work." 5. Delivery is discovery now - at Wave Terminal, they shipped a full app builder in 3 weeks just to validate if people would use it. Building is cheaper than talking about building. --- CONNECT WITH PRODUCT ENGINEERS Host: Peppe Silletti LinkedIn: https://www.linkedin.com/in/peppesilletti/ Product Engineers Community: Newsletter: https://productengineers.com LinkedIn: https://www.linkedin.com/company/product-engineers --- SUPPORT THE SHOW If this episode made you question whether you're a natural converger who's been told to stay in your lane, share it with someone who needs permission to cross boundaries. Drop a comment below with your take on the convergence trend. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.productengineers.com

    49 min
  3. Why Deleting Your Backlog Makes You Ship Faster (CEO Explains)

    01/12/2025

    Why Deleting Your Backlog Makes You Ship Faster (CEO Explains)

    What if your entire sprint cycle fit into a single day? Kevin Ostlin went from running traditional Scrum with a perfect Jira backlog to deleting the whole thing and watching his team ship faster than ever. As co-founder and CEO of Andsend, he's built an organization where backend engineers design UIs, everyone talks to customers, and the team deploys more than one feature per engineer per day. In this episode, we explore why they mapped their bottlenecks and found 40 days per week lost to handoffs, how daily sprints became their new normal, and why Kevin now thinks of engineers as product managers leading armies of AI agents. This isn't about going faster for the sake of speed—it's about closing the loop between customer pain and shipped solutions. --- GUEST Kevin Östlin - Co-founder & CEO at Andsend Kevin is a founding engineer turned CEO who previously built Zapplify, a sales automation platform that reached thousands of customers before he shut it down to pursue a new mission. At Andsend, he's building an AI relationship agent for consultants and freelancers while experimenting with a product engineering model that eliminates traditional bottlenecks. Find Kevin: - LinkedIn: https://www.linkedin.com/in/kevinostlin/ - Andsend: https://andsend.com --- TIMESTAMPS 00:00 Introduction and Welcome 02:40 Kevin's Background and Andsend's Mission 05:42 Traditional Scrum and Its Bottlenecks 10:28 Dropping the Backlog and the Jira Tears 16:27 Daily Sprints and Dynamic Product Groups 23:09 How Hypotheses Work in Practice 31:00 Backend Engineers Becoming UI Designers 40:36 Scaling This Approach Beyond Startups 47:02 The Next Challenge for Andsend 49:44 Q&A: Daily Sprint Rituals and Metrics 57:23 Q&A: Testing Ideas and Finding Your Audience --- KEY TAKEAWAYS 1. They mapped 40 days per week lost to bottlenecks in a 9-person team - designer handoffs, product manager meetings, code review delays. That exercise made the problem so obvious they had to act. 2. Kevin literally cried over deleting his Jira backlog - but they never needed it again. Dropping the backlog forced everyone to form dynamic "product groups" around hypotheses instead of pre-planned tickets. 3. Daily sprints aren't really sprints - they're a mindset shift. Every standup is sprint planning for the day. The goal: get one hypothesis to production per engineer per day, with 2-3 people working as a pair or trio. 4. Backend engineers became UI designers through customer exposure + AI - when you're in customer onboarding calls and have Lovable/v0 to fill skill gaps, you start designing because you feel the problem. They don't use Figma anymore. 5. Evaluation is the hardest part - you can't evaluate Thursday's deploy until next week. Their unlock: qualitative interviews with customers they've built relationships with since onboarding, backed up by session replays and metrics. --- RESOURCES MENTIONED - Zapplify (Kevin's previous startup) - Andsend (current company) - Amplitude (analytics platform) - Lovable, v0, Bolt, Replit (AI prototyping tools) - Tesla factory engineering culture - AWS deployment frequency example --- CONNECT WITH PRODUCT ENGINEERS Host: Peppe Silletti LinkedIn: https://www.linkedin.com/in/peppesilletti/ Product Engineers Community: Website: https://productengineers.com LinkedIn: https://www.linkedin.com/company/product-engineers --- SUPPORT THE SHOW If this episode inspired you to rethink your team's velocity, share it with someone stuck in sprint planning hell. Drop a comment below with your biggest takeaway or tell us about your own bottleneck mapping experiments. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.productengineers.com

    52 min

  4. 21/10/2025

    Software Engineers As Problem Shapers (Not Ticket Tackers)

    What if product managers, designers, and even VPs of Engineering are "pure overhead"? Martin, VP of Engineering at Zen Educate, makes the provocative case that engineers could technically build and maintain a product without anyone else—so every other role needs to prove they're accelerating engineering, not blocking it. His journey from building VFX pipeline tools in the film industry to leading product-led teams at Intercom shaped his conviction: engineers who love solving real user problems (and just happen to use technology) are the ones who sometimes solve problems by not building anything at all. In this episode, we explore why "problem shapers" beat "ticket takers," how Zen Educate transformed from a world of PM-assigned tickets to engineers partnering directly with commercial leaders, and why a team of six engineers working on six different problems isn't a team—it's just people sitting together. Martin doesn't hold back on the trade-offs, the challenges of getting engineers to believe they're allowed to do this, and the practical steps for anyone trying to make this shift. --- GUEST Martin Östlin - VP of Engineering at Zen Educate Martin started his career in the film industry building pipeline tools for visual effects teams before discovering product-led development at Intercom. Now he leads engineering at Zen Educate, a British startup tackling the global challenge of education staffing. He's leading the transformation from ticket takers to problem shapers across a distributed team of 40+ people. Find Martin: - LinkedIn: https://www.linkedin.com/in/martinpp/ - Zen Educate: https://zeneducate.com --- TIMESTAMPS 00:00 Introduction and Welcome 01:51 Martin's Journey Through Film Industry and Tech 04:16 Before Product-Led: The World of Feature Requests 06:16 Frustrations of Being a Ticket Taker 08:43 The Aha Moment at Intercom 13:06 Leadership's Role in Fostering Product Mindset 18:35 Problem Shapers Not Ticket Takers - What It Means 23:10 Measuring Collaboration and Team Health 26:11 How Teams Are Structured at Zen Educate 28:02 A Typical Week for Engineers 30:48 How Problem Shaping Works in Practice 33:47 Handling Handoffs Between Roles 36:34 The Impact of AI Tools on Their Workflow 43:51 Challenges in the Transformation Journey 48:06 Scaling This Approach as the Company Grows 51:24 Practical Steps to Start Implementing Product Engineering 56:01 Where to Find Martin --- KEY TAKEAWAYS 1. Engineers are the only required role - you can build and maintain a product without PMs, designers, or VPs. Everyone else is "pure overhead" that must prove they accelerate engineers rather than slow them down. 2. Problem shapers vs ticket takers - engineers at Zen Educate define problems with the team, challenge assumptions, and contribute solutions. They're not waiting for PM-written tickets or asking for sign-off before shipping. 3. Product engineers solve problems by NOT building - the best definition: "Someone who loves solving real problems for users and just happens to be skilled at leveraging technology." Sometimes the answer is zero lines of code. 4. Teams need focus to be teams - six engineers working on six different problems aren't a team, they're just people who sit together. Real teams rally around shared problems with clear accountability. 5. Three steps to implement this: (1) Internalize why you want this (not just because it sounds cool), (2) Write it down with clear trade-offs, (3) Find champions who get it and amplify their wins publicly. Start small or go big depending on your context. --- RESOURCES MENTIONED - Intercom (Martin's previous company) - Lovable (AI prototyping tool) - Figma (design tool) - Marty Cagan's article on "product builders" - Developer experience surveys - Session replays and product metrics tools - Extreme programming concepts --- CONNECT WITH PRODUCT ENGINEERS Host: Peppe Silletti LinkedIn: https://www.linkedin.com/in/peppesilletti/ Product Engineers Community: Website: https://productengineers.com LinkedIn: https://www.linkedin.com/company/product-engineers --- SUPPORT THE SHOW If this episode challenged how you think about roles and ownership, share it with an engineering leader who needs to hear it. Drop a comment below with your biggest takeaway or tell us about your own transformation from ticket taker to problem shaper. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.productengineers.com

    57 min

  5. 05/09/2025

    How AI Exposes Designers Who Can't Think (Product Designer)

    What happens when AI tools promise to turn anyone into a designer—but deliver "generative mediocrity"? Toms Varpins, a product designer with 12 years of experience spanning fintech, healthcare, and e-commerce, doesn't mince words about the current state of AI in design. While tools like V0, Lovable, and Figma can spit out a landing page in seconds, Toms argues the real work hasn't changed: you still need vision, iteration, and an understanding of first principles to build something people actually trust and want to use. In this episode, we explore how AI is affecting designers, developers, and product managers—not by replacing them, but by blurring the lines between their roles in ways that raise uncomfortable questions. Toms and Peppe dive into live demos with Lovable and V0, dissecting what these tools get wrong (and occasionally right), why 40+ iterations beat a one-line prompt, and what "craft" actually means in an age of AI-generated interfaces. They also tackle bigger questions: If code becomes a commodity and AI agents talk to other AI agents, what's left for us? What happens to the SaaS ecosystem? And if everyone can build everything, who's going to pay for any of it? --- GUEST Toms Varpins - Product Designer Toms is a product designer with 12 years of experience building interfaces for fintech systems, AI-powered health tools, and e-commerce platforms. A former colleague of Peppe's at Kinsta, he's passionate about running workshops and exploring the intersections of design, engineering, economics, philosophy, and music. He believes product design is closer to product management than graphic design—and that the UI you ship is just 5% of the real work. Find Toms: - LinkedIn: https://www.linkedin.com/in/toms-varpins/ --- TIMESTAMPS 00:00 Introduction and Welcome 03:44 AI Tools in the Design Process 12:39 Low Fidelity vs High Fidelity in the AI Age 21:26 Blurring Lines Between Roles 30:02 Can Everyone Do Everything? 36:38 Live Demo: Lovable vs V0 46:37 Iterating to Quality: 43 Drafts Later 48:47 If Anyone Can Build, Why Do We Need Developers? 53:06 The Bigger Questions: SaaS, Economy, and the Dead Internet --- KEY TAKEAWAYS 1. Generative mediocrity is the default - AI tools are trained on average internet data and produce average outputs. The first draft will look generic because it's literally the statistical average of everything. Craft, detail, and trustworthiness come from iteration and human judgment. 2. You still need vision and understanding - Toms and Peppe tested one-line prompts vs detailed ChatGPT-refined prompts with Lovable and V0. Even after 40+ iterations with brand guidelines, Peppe's job board needed human direction. Without vision for who you're serving and what feeling you want to create, AI just generates presentations, not products. 3. Roles are blurring, but knowledge isn't expanding - Designers can now code simple front-ends. PMs can prototype. Engineers can design. AI makes execution faster, but strategic thinking, problem understanding, and technical limitations still require deep knowledge. The question isn't "can everyone do everything?" but "who coordinates when everyone can do everything?" 4. Cost and economics matter more than we think - There's an inflection point where continuing to iterate with AI costs more than hiring a person. And if software becomes a commodity anyone can generate, what happens to SaaS tools, monitoring platforms, and the entire internet economy built on services? 5. The uncomfortable question: what's left for us? - If AI agents talk to other AI agents, who needs analytics tools, marketing platforms, or even interfaces? The future might not be about individuals losing jobs—it's about entire business models becoming obsolete. We're at the peak of the hype cycle, and the hard questions about value, markets, and purpose are just beginning. --- RESOURCES MENTIONED - ChatGPT (for thought organization and content generation) - V0 (AI coding assistant from Vercel) - Lovable (AI prototyping tool for websites and apps) - Figma Make - Supabase (backend database integration) - Visual Studio with Copilot - Notebook LM - DeepSeek and Qwen (Chinese AI models) - Product Engineers job board (demo: https://productengineers.com) - Dead internet theory - Innovation curve and trough of disillusionment --- CONNECT WITH PRODUCT ENGINEERS Host: Peppe Silletti LinkedIn: https://www.linkedin.com/in/peppesilletti/ Product Engineers Community: Website: https://productengineers.com LinkedIn: https://www.linkedin.com/company/product-engineers Discord: Available via productengineers.com --- SUPPORT THE SHOW If this episode made you question what happens when everyone can build anything, share it with a designer or developer navigating the AI transition. Drop a comment with your biggest takeaway or tell us: after 43 iterations with AI, what did you learn that you couldn't have learned any other way? This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.productengineers.com

    59 min
  • 5 Episodes

About

Unpacking the product x engineering convergence. Interviews, research, and stories from the field. newsletter.productengineers.com

Information