If I had to choose between a junior engineer and a senior with 10 years of experience who's only ever focused on writing code, I'd pick the junior. Every time. In this solo episode, I explain why junior engineers have an unfair advantage right now, and why the seniors who only think in code are the ones who should actually be worried about AI.

I break down what AI can and can't replace, why starting from the problem instead of the tech stack is the fastest way to grow, and share the story of my first job in 2016 where I accidentally became a product engineer before I even knew the term existed. Plus: a practical playbook for juniors who want to break in, and a wake-up call for engineering leaders who've stopped hiring them.

---

TIMESTAMPS

00:00 I'd Hire the Junior — Here's Why

01:00 The Wrong Question Everyone Is Asking About AI and Juniors

02:00 What AI Can't Do: The Real Work of Software Engineering

06:00 My First Job in 2016: Accidentally Doing Product Engineering

09:00 Why Hyper-Specialisation Is the Real Risk

11:00 The Unfair Advantage of Fresh Eyes

12:00 A Playbook for Getting Started Without a Job

14:00 From Side Project to Entrepreneur

15:00 How Portfolios Have Changed

16:00 A Message to Engineering Leaders

17:00 Three Essential Books for the Product Engineer Path

19:00 Wrap-Up

---

KEY TAKEAWAYS

1. Junior engineers have fresh, unmolded minds — they haven't been "polluted by the old ways." That malleability is their biggest asset in a world where the rules of engineering are changing fast.

2. Writing code is the easiest part of software engineering. Understanding what to build, clarifying messy requirements, talking to users, system thinking — AI can't do any of this. This is where product engineers live.

3. Hyper-specialisation is the real risk. If your value is pattern recognition and applying known solutions, that's exactly what LLMs are good at. Seniors stuck in their ways are more replaceable than adaptable juniors.

4. Start from a real problem, not a tech stack. Look at your life, talk to people, and find a human problem to solve. Build a prototype, run usability tests, iterate. That's your new portfolio.

5. For leaders: stop hiring juniors to write boilerplate. Hire them to solve problems. Put them in front of customers. Make failure safe. Pair them with AI, not against it.

6. The companies that invest in growing junior product engineers now will have a massive advantage in five years. The ones that don't will be fighting over a shrinking pool of senior talent.

---

RESOURCES MENTIONED

- Continuous Discovery Habits by Teresa Torres

- Extreme Programming Explained by Kent Beck

- Don't Make Me Think by Steve Krug

- The Lean Startup by Eric Ries

- Clean Architecture by Robert C. Martin

- Continuous Delivery by Dave Farley

- The Pragmatic Engineer newsletter by Gergely Orosz

- PostHog's Product for Engineers newsletter

- Lovable, v0, Replit — AI prototyping tools

- Cursor — AI-assisted coding

---

CONNECT WITH PRODUCT ENGINEERS

Host: Peppe SillettiLinkedIn: https://www.linkedin.com/in/peppesilletti/Website: https://peppesilletti.io

Product Engineers:

Website: https://productengineers.comNewsletter: https://newsletter.productengineers.comLinkedIn: https://www.linkedin.com/company/product-engineers

---

SUPPORT THE SHOW

If you're a junior developer wondering where you fit in the AI era, or a leader who's stopped hiring juniors — share this episode with someone who needs to hear it. Drop a comment 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

podcast.productengineers.com

What if the real runway isn't money but learning speed? Anders Fredriksson has spent 20 years building startups and watching teams fail the same way: big plans, slow feedback, zero learning. Named Sweden's most prominent internet entrepreneur in 2007, he's now writing the book on what he calls the Speed methodology — Optimising Startups For Speed Of Iteration.

In this episode, we dig into why backlogs are dead weight, why pull requests are your biggest bottleneck, and why end-to-end ownership changes everything. Anders shares how his team went from deploying every two weeks to 30 deploys per day, why the one metric that matters replaces your entire planning process, and what happens when AI agents take over the coding while engineers build the machine that builds the machine.

GUEST

Anders Fredriksson - Serial Entrepreneur & Author of "Speed: Optimizing Startups for Speed of Iteration"

Anders has 20+ years of startup experience, from being named Sweden's most prominent internet entrepreneur in 2007 to now building Staer.ai, where the team writes virtually no code by hand. He's spent his career figuring out why startups move too slow and what to do about it.

Find Anders:

LinkedIn: https://www.linkedin.com/in/andersfredriksson/

X: https://x.com/andefred

TIMESTAMPS

00:00 Introduction and Guest Welcome

01:00 The Speed Hypothesis: Small Steps Beat Big Plans

05:00 Implementing Speed at Ansen

09:00 No Backlog, No Sprints — Daily Experiments Instead

11:00 From Two-Week Sprints to 30 Deploys Per Day

14:00 When Speed Doesn't Apply: Known vs Unknown Solutions

19:00 Runway Is Learning Speed, Not Money

25:00 Generalists Win in the Age of AI

30:30 What's Left for Engineers When AI Writes the Code

36:00 Agents Working Toward Outcomes, Not Just Outputs

39:00 The Biggest Pushback: Killing Pull Requests

47:00 Top Tools and Practices: Monorepo, TypeScript, CI/CD

54:00 From Crashed Startups to Writing the Book on Speed

59:00 One Thing You Can Do Tomorrow Morning

KEY TAKEAWAYS

1. Optimize for learning speed, not runway — if you're not learning fast enough, money won't save you. The build-measure-learn loop is only as good as your cycle time.

2. Replace backlogs with a One Metric That Matters (OMTM) — a living, short-term metric that every person in the company can impact daily. Change it frequently as you learn.

3. End-to-end ownership means engineers own the full loop — from understanding the customer problem to shipping to production and measuring impact. No handoffs to product managers.

4. Pull requests are your biggest bottleneck — asynchronous code reviews kill deployment speed. Replace them with synchronous pair programming or, with senior teams, skip reviews entirely.

5. The engineer's new job is building the machine that builds the machine — maintaining agent infrastructure, removing friction, and ensuring AI can verify its own work.

6. Do the bottleneck workshop — map every step from feature idea to production, multiply frequency by time, and fix the biggest number first.

RESOURCES MENTIONED

- "Speed: Optimizing Startups for Speed of Iteration" by Anders Fredriksson (upcoming book)

- Lean Startup by Eric Ries (build-measure-learn loop)

- Nx (monorepo orchestration tool)

- Blacksmith (fast CI runner)

- Kubernetes (container orchestration)

CONNECT WITH PRODUCT ENGINEERS

Host: Peppe Silletti

Website: https://productengineers.com

LinkedIn: https://www.linkedin.com/company/product-engineers

SUPPORT THE SHOW

If this episode made you rethink how fast your team actually moves, share it with a founder or engineer who's stuck in two-week sprint cycles. 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

podcast.productengineers.com

What happens when engineers — not product managers — have the final say on what gets built? Raquel Smith is a product executive at PostHog and has lived this model for years. In this episode, she unpacks why product engineering is still the most fun role she's had, how PostHog keeps engineers directly wired to customers with zero gatekeepers, and what it really means to own a feature end to end.

We also get into the uncomfortable parts: how AI is changing the dopamine rush of coding, why collaboration can actually slow you down, and what Raquel worries about most as PostHog scales. Honest, direct, and full of hard-won insights.

---

GUEST

Raquel Smith - Product Executive at PostHog

Raquel took an unconventional path — from a biology/microbiology degree to self-taught engineer, PM, startup founder, and now product executive at one of the most engineer-empowered companies in tech. She's been at PostHog for several years and leads multiple product engineering teams.

Find Raquel:

- PostHog: https://posthog.com

- Email: raquel@[guessthedomain]

---

TIMESTAMPS

01:30 From Biology to Self-Taught Engineer

07:00 The Four Ingredients for Fun at Work

09:00 What Makes PostHog Actually Different

13:00 No Gatekeepers: Engineers Talk Directly to Customers

15:00 End-to-End Ownership and Full-Stack Product Engineering

17:00 Where Engineers End and PMs Begin

20:00 PMs as Context Providers, Not Decision Makers

22:00 Why Collaboration Can Slow You Down

25:00 The Diversity of Perspectives Objection

27:30 Max the Hedgehog and PostHog's Brand

30:00 The PostHog Website Redesign

31:30 Company Meetups

32:00 AI and the Coding Dopamine Rush

37:00 Productivity Gains and New Bottlenecks from AI

41:00 AI Across the Product Development Process

44:00 High Ownership as a Hiring Filter

46:00 Coordinating at Scale Without Bureaucracy

52:00 The Future of Product Engineering

---

KEY TAKEAWAYS

1. Engineers are the final call at PostHog — they decide what to build, when, and how. PMs provide context, not directives.

2. Direct customer contact is non-negotiable. Watching a customer struggle is more motivating than any backlog ticket. No layers between engineers and users.

3. Collaboration has a cost. Single engineers owning features end to end — from API to front end — is faster than consensus-driven teams. Limit who you involve and when.

4. AI changes the feel of coding, not just the speed. It's more like managing a junior dev than writing code yourself — easier to get frustrated when something else does it wrong.

5. DevEx becomes more critical as AI speeds up code output. A 15-minute slowdown that was 6% of a 4-hour PR is 100% of a 15-minute AI-assisted PR.

6. Talent density is the hardest thing to protect at scale. When the org gets complex, it's harder to see who's actually pulling their weight.

---

RESOURCES MENTIONED

- PostHog: https://posthog.com

- "Collaboration Sucks": https://newsletter.posthog.com/p/collaboration-sucks

- Frictionless — book on developer experience in the AI era

- Raquel's article: https://posthog.com/blog/why-product-engineering-is-so-fun

---

CONNECT WITH PRODUCT ENGINEERS

Host: Peppe Silletti

LinkedIn: https://www.linkedin.com/in/peppesilletti/

Website: https://peppesilletti.io

Product Engineers Community:

Website: https://productengineers.com

Newsletter: https://newsletter.productengineers.com

LinkedIn: https://www.linkedin.com/company/product-engineers

---

SUPPORT THE SHOW

If this episode made you rethink how much ownership your engineers actually have, share it with someone who needs to hear it. Drop a comment 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

podcast.productengineers.com

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

podcast.productengineers.com

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

podcast.productengineers.com

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

podcast.productengineers.com

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

podcast.productengineers.com

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

podcast.productengineers.com