This episode is a conversation with Judith Bohlert — a freelance software engineer based in Germany, self-employed for 3 years, building greenfield MVPs and prototypes for early-stage startups — about how freelancing with AI tools affects the job, pricing, and the identity of an independent engineer.

We get into the case for moving from time-seller to product engineer-consultant, why a productized service or a value-based offer is now the obvious response to AI freelancing economics, and why your personal brand — not your stack — is the only moat left when average code becomes a commodity.

TIMESTAMP

0:00 — How AI changed a Monday morning for a freelance dev

4:15 — Tools that actually work: Claude Code, Cursor, GitHub Copilot

5:41 — Repricing your work: hourly vs fixed vs productized vs value-based

17:46 — Use AI to work less, not more: the case for the four-day week

22:04 — Personal brand as the only moat when code is a commodity

35:00 — The freelancer label is dying, the consultant role is rising

38:54 — Advice if you want to start freelancing now

GUEST

Judith Bohlert is a freelance software engineer based in Germany, with around 3 years of self-employment experience, focused on greenfield MVPs and prototypes for early-stage startups. She writes the low noise newsletter — a calmer take on working in tech, without hustle culture or the productivity-hack treadmill.

Website:https://www.judithboehlert.com/

Newsletter (low noise newsletter):https://www.lownoiseclub.com/

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

CONNECT WITH PRODUCT ENGINEERS

Host: Peppe Silletti

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

Peppe's website:https://peppesilletti.io

Product Engineers Community:https://discord.gg/4sMtRNSgU4

Share this episode with a freelance developer friend who's billing hourly and starting to feel it.

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

One of today’s guests has a name for it: the infinite workday.

And that’s exactly the problem today’s guests set out to fix. Mark Barbir and Sanden Gocka are the founders of Earmark — an AI meeting note taker that turns live conversations into shippable work in real time. We get into how they actually use it day to day, how it helps product teams, where the new bottleneck of product work has moved, and what it looks like when an idea you just said out loud turns into a working prototype before the call ends.

If you’ve been hunting for AI tools for product managers that go beyond generic summaries, I’m walking you through them, and you can decide if it’s worth trying.

GUESTS

Mark Barbir and Sanden Gocka are the co-founders of Earmark. They previously worked together at Mindbody, a large enterprise SaaS company with a 400-person delivery organisation, and later crossed paths again at ProductPlan, where Sanden was an engineering manager and director. After years of watching product and engineering leaders drown in meetings and artefact work, they set out to build the tool they wished they had: an AI meeting assistant that generates the artefacts a conversation implies, in real time, while the meeting is still happening.

Mark’s LinkedIn: https://www.linkedin.com/in/markbarbir/Sanden

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

Earmark: https://www.tryearmark.com

TIMESTAMPS

00:00 The Invisible Second Shift: PM Meetings Problem

01:49 The Infinite Workday: Why PMs Work After Hours

07:49 Vision Pro Pivot: From Presentation Coach to Meeting AI

11:35 Why Vision Pro Failed (and What They Learned)

14:13 Engineering Translator Card: Understanding Technical Talk

16:00 Specs, PRDs & Code in Real-Time During Meetings

19:00 Make Me Look Smart: AI for Shy PMs

28:32 PMs Are Now The New Bottleneck

31:56 Dog Food Success: How Earmark Built Earmark

40:09 How to Get Started with Earmark

REFERENCES

Cursor: https://cursor.com

Linear: https://linear.app

MacWhisper — the local speech-to-text tool Sanden used in his early hacked workflow

AssemblyAI (referenced in the co-marketing case study story): https://www.assemblyai.com

CONNECT WITH PRODUCT ENGINEERS

Host: Peppe Silletti

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

Product Engineers:

Website: https://productengineers.com

Discord Channel: https://discord.gg/4sMtRNSgU4

Share this episode with a teammate who is still writing their PRDs at 10pm.

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

---

TIMESTAMPS

00:00 How Product Development Worked Before AI

01:06 Discovery: Slow Data, Slow Analysis

02:17 Design: Always a Bottleneck

03:43 Delivery: Scrum in a Waterfall Company

06:36 Measurement: The Phase Everyone Skipped

07:00 The Feature Factory Problem

07:43 How AI Changed Discovery

09:06 The New PM: Full-Stack Product Builders

12:00 How AI Changed Design: Three Approaches

15:44 How AI Changed Delivery: Four Levels of AI Collaboration

20:00 Tools: Cursor, Claude Code, Codex, Superpowers, nWave

22:22 How AI Changed Measurement

24:16 AI-Native Startups Are Finally Agile

25:37 Daily Sprints and Same-Day Feedback (Andsend)

26:39 The Convergence of Product and Engineering Roles

28:39 What This Means for Your Career

---

RESOURCES MENTIONED

- PostHog — product analytics platform with AI-powered insights

- Andsend — AI-native startup with daily sprints

- Cursor — AI-powered IDE

- Claude Code — AI coding agent by Anthropic

- Codex — AI coding agent by OpenAI

- Superpowers — AI agent framework for software development

- nWave — multi-agent framework for the full product development lifecycle

- Lovable, V0, Bolt, Stitch, Replit — AI prototyping tools

- Figma MCP — integration between AI agents and Figma

- MCP Protocol — Model Context Protocol for tool integration

---

CONNECT WITH PRODUCT ENGINEERS

Host: Peppe Silletti

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

Website: https://peppesilletti.io

Product Engineers

Website: https://productengineers.com

Newsletter: https://newsletter.productengineers.com

Community: https://discord.gg/4sMtRNSgU4

---

SUPPORT THE SHOW

If you've seen AI change how your team builds products — or you're still stuck in the old way — share this episode with your team. Drop a comment with what phase AI impacted most for you: discovery, design, delivery, or measurement.

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

---

GUESTS

Michele Brissoni - Founder of BrickX Consulting, Fractional CTO, Host of Forge of Unicorns Podcast

Michele has 20+ years in software engineering, starting with behavioural engineering at Ferrari F1 during the Schumacher era. He invented the Software Craftsmanship Dojo, led a DevOps transformation at IBM across 15,000 people, and has hosted 80+ episodes interviewing the people behind 52 unicorn companies.

Alessandro Di Gioia - Software Craftsman, Technical Coach, Co-founder of Alcor Academy

Alessandro co-authored "Agile Technical Practices Distilled" with Marco and Pedro Santos, a multi-award-winning book on TDD, refactoring, and software design. He's been teaching outside-in development at conferences like NDC, DDD Europe, and DevOps Days for years. He's the primary builder behind nWave's deterministic execution system.

Marco Consolaro - Software Craftsman, Technical Coach, Co-founder of Alcor Academy

Marco co-authored "Agile Technical Practices Distilled" and has spent years teaching software craftsmanship and TDD. He brings a focus on the human side of engineering — sustainable pace, team dynamics, and the importance of trust in building quality software.

Find them:

- nWave GitHub: https://github.com/nWave-ai

- Michele's LinkedIn: https://www.linkedin.com/in/michelebrissoni

- Alessandro's LinkedIn: https://www.linkedin.com/in/alessandro-di-gioia/

- Marco's LinkedIn: https://www.linkedin.com/in/consolaro/

---

TIMESTAMPS

00:00 Introduction and Guest Welcome

03:00 The Origin Story: From Early AI Tools to nWave

08:03 The Career Lesson Behind nWave

10:17 Discuss nWave: Understanding What to Build and For Whom

26:16 Design nWave: Architecture with Adversarial Reviews

38:41 DevOps and Distill nWaves: CI/CD and Acceptance Tests Before Code

41:42 Deliver nWave: Outside-In TDD with Fresh Context Every Step

52:51 "Doesn't This Make You Slower?" — The Rework Argument

01:02:25 What Do You Do While nWave Is Working?

01:05:34 Closing and How to Contribute

---

RESOURCES MENTIONED

Link with all research material used to build nWave: https://drive.google.com/file/d/1yvSDNwj-F1amEavoX3Qz4oRZfw-9XKF9/view

---

CONNECT WITH PRODUCT ENGINEERS

Host: Peppe Silletti

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

Product Engineers Community:

Website: https://productengineers.com

Discord Channel: https://discord.gg/4sMtRNSgU4

---

SUPPORT THE SHOW

If this episode changed how you think about AI-assisted development, share it with an engineer or team lead who's struggling with AI code quality. 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

In this episode, I explain why business outcomes are lagging indicators you can't directly control, while product outcomes are leading indicators tied to user behaviour that your team can actually influence. I walk through the Cynefin Framework, how to test if a product outcome is any good, what a feature factory looks like, and practical things you can start doing right now to speak the language of outcomes.

TIMESTAMPS

00:00 Why Engineers Never See the Feedback Loop

03:00 Business Outcomes vs Product Outcomes — The Definitions

07:00 Why Product Development Lives in the Complex Domain (Cynefin Framework)

09:00 How Business Outcomes Get Translated into Product Outcomes

12:00 The Four Tests of a Good Product Outcome

15:00 From Features to Experiments — Redefining “Done”

18:00 The Feature Factory and Vanity Metrics

21:00 What You Can Do as an Engineer Right Now

25:00 The One Question That Separates Product Engineers from Software Engineers

RESOURCES MENTIONED

* Cynefin Framework by Dave Snowden

CONNECT WITH PRODUCT ENGINEERS

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

Product Engineers Community:Website: https://productengineers.comLinkedIn: https://www.linkedin.com/company/product-engineers

SUPPORT THE SHOW

If you’re an engineer who’s tired of just closing tickets without knowing if any of it mattered — share this episode with your team. 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

--

Every software engineer is feeling it right now — the anxiety. AI and software development are colliding fast: AI is writing code faster than us, junior roles are disappearing, and every week someone claims they replaced their entire engineering team with a chatbot.

But here's what the headlines miss: the engineers who understand customers, own decisions, and drive outcomes? They're not just surviving — they're thriving. That's what a Product Engineer is. And in this episode, I share everything I've learned over four years of researching this shift, and why I'm convinced product engineering is the answer to the question every developer is asking: how do I make myself irreplaceable in the age of AI?

👍 If this resonates, hit like — it helps more engineers find this.

🔔 Subscribe for weekly research on product engineering, tech careers, and the future of software development.

---

TIMESTAMPS

00:00 Every Engineer Is Scared Right Now

01:30 How I Felt Replaceable Before AI Even Existed

03:00 The Origins: Product-Minded Engineers, Empowered Teams, and the Product Trio

08:00 What Actually Is a Product Engineer?

14:00 How Product Engineering Teams Work (PostHog, Zen Educate, Andsend)

22:00 AI Didn't Create This Trend — It Just Made the Gap Obvious

25:00 How Leadership Has to Change

28:00 What Happens to PMs?

32:00 Can This Scale? The AI-Native Company Pattern

35:00 What You Can Do Right Now

---

RESOURCES MENTIONED

- "The Product-Minded Engineer" by Gergely Orosz

- Empowered by Marty Cagan

- Continuous Discovery Habits by Teresa Torres

- PostHog — product engineering team model

- Interview with Raquel Smith (PostHog)

- Interview with Martin Pengelly-Phillips (Zen Educate)

- Interview with Kevin Ostlin (Andsend)

- Stefan Schmidt — CTO coach

- Else van der Berg — product leader

- Cursor, MidJourney, Bolt — AI-native company examples

---

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 you're an engineer wondering where you stand in the age of AI, or a leader trying to figure out how to structure your team — 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

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

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

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

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

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

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

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

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