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.

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.

Watch the episode on YouTube:

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 Community:
Website: https://productengineers.com
Discord Channel: https://discord.gg/4sMtRNSgU4

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

Watch on YouTube:

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.

Watch it on YouTube

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
05:00 An Engineering Analogy: System Reliability
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 Silletti
LinkedIn: https://www.linkedin.com/in/peppesilletti/
Website: https://peppesilletti.io

Product Engineers Community:
Website: https://productengineers.com

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.

I recorded this episode because I think every software engineer is feeling something right now that nobody wants to say out loud. We’re scared. AI writes code faster than us, junior roles are getting cut, and every week, some founder on Twitter brags about replacing their engineering team.

But I have to admit something, I was scared way before AI showed up. Four years ago, I was sitting in sprint planning, estimating tasks with random numbers, building features I’d never hear about again. I had no clue if anything I built actually mattered.

I felt replaceable. AI just made it everyone’s problem.

The Frustration Was Always There

The engineers who feel threatened by AI right now are the ones who were already stuck in a broken system. If your whole job is translating someone else’s decisions into code, AI is absolutely coming for that. That’s literally what AI is best at: taking instructions and producing output.

But if you understand what you’re building and why, what success looks like, whether it actually worked, AI can’t touch that. AI has no idea who your customer is. It has no judgment. It can’t tell if the feature you shipped moved the needle or was a complete waste of everyone’s time.

The engineers who aren’t anxious right now all have one thing in common. They understand the customer, make product decisions, and own outcomes. They’re product engineers.

The Smart People Have Been Saying This for Years

Sometimes people act like product engineering appeared out of thin air. It didn’t.

Back in 2019, wrote a piece called “The Product Minded Engineer.” When I read it, it was the first time I actually felt understood. Someone was describing exactly what I was trying to become. Engineers who don’t just ask “how do I build this?” but “why are we building this? What happens if we do it differently? Who actually uses this?”

He listed nine traits. Things like understanding business economics, building relationships with PMs and designers, and tracking the impact of your work after you ship. Every single one of those traits is something AI can’t replicate.

Then there’s ’s Empowered, where he made a bold case. Most product teams are feature teams. They get told what to build, and they just build it. Empowered teams get assigned a problem to solve and figure out the rest. A feature team is exactly the kind of team AI is going to replace.

brought the concept of the product trio: a PM, a designer, and an engineer working together on continuous discovery. For the first time, someone was saying engineers belong in discovery, not just delivery.

AI is proving all of them right.

The System Is Broken, Not You

Product engineers exist because the way most companies build products is fundamentally broken. AI just made it painfully obvious.

Think about your typical product team. A PM figures out what to build, a designer makes it look nice, and an engineer writes the code. Every time you pass information from one person to the next, stuff gets lost. The engineer building the feature knows the least about the actual customer problem. The PM doesn’t understand how hard it is to build. It becomes a game of telephone.

The people who could have flagged the problems early, the engineers, weren’t in the room when the product decisions were made. A product engineer keeps all the context in one place. The customer problem, the business goal, and the technical constraints. Instead of scattering it across three departments that barely talk to each other.

What This Looks Like in Practice

I’ve talked to several companies doing this, and they all do it a bit differently.

At PostHog, engineers make the final call. They decide what to build, when, and how. PMs do research, competitive analysis, and customer feedback, but engineers own the decisions. Raquel Smith, one of their product and engineering leaders, told me the key is being crystal clear about who owns the decision. Once everyone knows who decides, there’s no confusion, no power struggles, no endless meetings trying to reach consensus.

At Zen Educate, Martin Pengelly-Phillips, the VP of Engineering, told me something I keep thinking about. Product engineers, there aren’t caretakers, they’re problem shapers. They still have PMs and designers, but engineers are in the mix from day one. They push back. They ask “are we even sure this is a problem?” That kind of engineer becomes more dangerous with AI, not less.

And then there’s Andsend. Kevin Östlin, the CEO, told me they mapped their bottlenecks and found they were losing 40 days per week in handoffs. Forty days. They dropped the backlog completely. Kevin told me he was still sneaking looks at his perfectly organised Jira project at night, crying a little that they had to let it go.

Now every standup is basically a sprint planning for the day. They never talk about features; they talk about hypotheses to test. They ship multiple times a day per engineer. Kevin said something I loved:

“What has been really interesting is how people that were traditionally very heavy engineers, they knew math, they wanted to do complex algorithms. Those people might as well be the ones becoming your best UI designers or UX researchers. It’s almost beautiful to see people finding their strength through actually getting freedom.”

That’s people coming alive because they finally get to use their full brain instead of just the part that writes for loops.

AI Didn’t Create This. It Just Blew the Doors Open

PostHog has been hiring product engineers since 2020. Linear and Ghost were doing this before ChatGPT even existed. The ideas have always been there.

What AI did is blow up the gap between product and engineering roles. Before AI, working as a product engineer was harder. Prototyping was expensive, synthesising customer insights was slow, and learning new skills outside your comfort zone took forever. Now you can prototype a user flow in hours instead of days and pull customer insights way faster.

AI didn’t just make product engineers faster. It made the old way of working obviously broken. If you’re still on a feature team where a PM writes the spec, a designer mocks it up, and you just code it, AI just made each of those handoffs feel pointless.

And here’s what’s wild. My friend, product leader , pointed out that AI-native companies are showing a completely new pattern. Tiny teams, huge results.

• Cursor: 800 million in revenue with 12 people

• Mid-Journey: 200 million with 40

• Bolt: Zero to 40 million in five months with about 20 people

Growing headcount used to be a flex. Now it’s kind of embarrassing. People at these companies don’t have AI anxiety because every person owns something real. Zero room for passengers.

What You Can Actually Do

If you’re an engineer who’s anxious about AI taking your job, that feeling is awful but useful. It’s telling you that your current way of working isn’t working. And honestly, it never really worked. You were already undervalued, already disconnected from the impact of your work. AI just made it impossible to ignore.

Start small. Next time you get a ticket, ask why. Push back on the problem. Suggest something different. Try to talk to a user before writing a line of code. You don’t need permission to care about the product. You never did.

Every time you do this, you’re building the one thing AI can’t replace: judgment. The ability to look at a problem and know what matters and what doesn’t.

If your company doesn’t want engineers who think this way, and it doesn’t plan to change, I’d be worried. Life is too short to be anxious at a job that’s making you replaceable.

If you’re a leader and your engineers are anxious about AI, that’s on you. Give them ownership, a real problem, and trust. As CTO coach Stefan Schmidt put it, what matters right now is real leadership. Setting a direction and trusting people to get there, not telling them what to build.

The best thing you can do for your team’s AI anxiety is give them something meaningful to own.

The Walls Are Coming Down

The engineers who understand the customer, who make product decisions, who own outcomes, they’re not worried about AI. They’re excited. AI makes them more powerful.

The dream builders have had all along, owning the whole thing from problem to solution to impact, is becoming real. Product and engineering are converging. The walls between roles are finally coming down because, in my opinion, they never really made sense in the first place.

The only question is whether you’re going to be part of that or sit there waiting for the next ticket while AI writes the code faster than you ever could.

If I had a tech company today and I had to choose between hiring a junior engineer or a senior engineer with 10 years of experience who has only ever focused on writing code like a code monkey and completely ignoring the product side of things, I would definitely hire the junior. Hands down, no hesitation.

I know that sounds crazy, especially right now when everyone is panicking about junior developers being replaced by AI. But I think junior engineers now have a really unfair advantage that most people in our industry are completely ignoring.

Everyone is asking the wrong question

There’s one question that you see over and over on social media nowadays, since AI came into our world. What about the junior developers? How are people going to grow into senior developers when AI can do their job? How are juniors going to practice? How are they going to make mistakes if they don’t touch the code and grow into the profession?

I get it. It’s a legitimate concern. But I think that people asking these questions are thinking about it completely wrong.

They’re assuming the only way to grow as an engineer is through writing code, through mastering a tech stack, through years of repetition. And that’s exactly the kind of thinking that’s going to get people replaced. Not juniors, but the seniors who think like that.

Junior engineers coming into the industry right now are still learning how everything works. They have not been polluted by the “always.” They’re still malleable. Their tech brain is still evolving, and that’s the best time to create the engineers of the future.

Writing code is the easiest part

Everyone is focused on the fact that AI is getting very good at writing code, and really, it is. That’s undeniable. But writing code is the easiest part of software engineering.

Think about what actually makes a product successful. It’s not the code. It’s understanding what to build. It’s clarifying messy requirements. It’s talking to users and figuring out their real problems, not the problems they tell you they have, but the ones you discover by watching them struggle. It’s making architectural trade-offs. It’s dealing with production accidents at 3:00 AM when something breaks in a way nobody anticipated. It’s understanding how your changes affect the system as a whole. System thinking.

AI cannot do any of this. And this is exactly where product engineers live. This is the work that matters.

So when people say AI is going to replace junior developers, what they really mean is that AI is going to replace the grunt work. The boilerplate, the simple bug fixes, the repetitive coding tasks. And you know what, that’s amazing, because that was never the valuable part of the job anyway. And plus it sounds more like exploitation than actually teaching anything to junior developers, really.

Start from the problem, not the tech stack

I’m going to say that the best way for junior engineers to get into the industry right now is to stop thinking about tech, at least as the first thing. Stop thinking about what tech stack you should learn. Start thinking about whether it even makes sense to learn coding or not. Instead, start working from a product problem.

Let me give you an example. Let’s say you have this onboarding that is not working well, and people are churning after the first step. Let’s see why. You don’t need to be an expert in product or a UX designer or any of that to start doing this. Otherwise, what’s really the point of being a junior developer who is learning?

You start from there, from the problem. Let’s go look at the session replays. Let’s maybe go talk to some users. Let’s do some usability tests and watch people using the onboarding and see where things break. These are really simple instructions, some guidelines that junior developers can follow. And of course, that means they’re probably not going to do a great job initially. That’s expected, which is perfectly fine.

The best thing is that they will start understanding and seeing how things work. They will start thinking not in terms of solutions, but in terms of problems to solve.

Once they identify the problem, they can start doing some research. They go online to look for best practices. They ask AI. They go ask their senior engineers or other people in the company who understand what they’re doing. How can I do this? What’s a good approach? What do you recommend? And it’s perfectly fine for them to also just try something, anything, and see what happens.

For this to work, you need to work in a company that makes failure a first-class citizen of the system. You must fail to learn. That’s inevitable. And most of the time, that’s the best way to learn, together with working from a problem and not from a solution. That’s also the best way to develop problem-solving skills.

Once the problem is found, the junior product engineer can also suggest how to improve the experience and eventually change it in the code. I expect a junior engineer to have a basic understanding of programming. If they’ve done any courses or university degrees, I am pretty sure they have a good foundation to become dangerous with code. You don’t need 10 years of experience. It is completely feasible to do it from day one. They will need to interact with the code and understand what effect the changes have on the codebase. But I would say it’ll be better to work in an AI-assisted way, using AI to talk with the code, try to understand what’s going on, and implement the changes.

How I accidentally became a product engineer

All of this makes me think about my first job back in 2016 as a software engineer. I just came out of university, but I had already started programming when I was 15 years old. So I had developed some experience, but not really production experience. Mainly some side projects, playing with it. The university really helped me get some better knowledge about databases, software engineering principles, and the stuff there.

In this company, my first job was very challenging. The company was called ViriCiti, a startup in Amsterdam that was building a monitoring system for electric buses all around the Netherlands and in other countries. I was tasked with building the system to update the software on the devices on the buses. We had these small devices running, reading data from the buses, and the system needed to update both the operating system and the applications running on it.

I’ve always been kind of a curious person, really entrepreneurial and proactive. So I thought, let’s just get on with this. Let’s see what I have to do. I just followed my gut.

That instinct to start from the problem is what really made a difference. I didn’t just sit down and code. I went to my colleagues and asked them: what’s the problem that we’re trying to solve here? What does the current process look like? What’s breaking? And I built prototypes and put them in front of people before building the real thing. I watched how they used it and iterated based on their feedback.

That’s the product engineering way of working, in my opinion. Even though back then, I really didn’t know I was doing that.

Did I write the best code? I think not. I probably over-engineered it a lot because I was following design patterns and everything, and I wanted to impress my colleagues. But I already knew a bit of test-driven development, which was very helpful in writing some good code. And while developing, I was also learning at the same time: React, Redux, how to write better CSS, and I was studying how to use Node.js, streaming and APIs.

Eventually, I did it, of course, with help from the CTO and my colleagues. But it was one of the most successful projects of my career, and I still remember it. Back then, I didn’t realise that I was accidentally doing product engineering. I was just trying to solve a problem the best way I could.

Hyper-specialisation is the real risk

I think new engineers really have the opportunity to start with a fresh perspective about how products are built. They can easily overcome senior engineers who have been stuck in their ways for ages, who have only been focusing on the tech part.

Those engineers are the ones who risk more to be replaced by AI. Because AI is getting very good at writing code. Anything that is hyper-specialised is something that AI will do very well eventually, because hyper-specialisation means you have seen the same pattern over and over and over, and you want to apply it. That’s exactly what LLMs are good at. Pattern recognition and applying a solution to a specific problem that’s been seen before.

If anything, the learning process for juniors will be sped up way more thanks to AI. You have a personalised coach that can help you along the way. In the beginning, you are not an expert in product discovery, you’re not an expert in experience design, you’re not an expert in software architecture. But junior engineers can now use a mix of working with mentors together with an AI coach that can give them feedback.

For this to work, it’s very important that these new product engineers work in a company that enables them to do this, that accepts failure as the only way to grow. The best way to grow as an engineer, as always, is by testing something, seeing how it works out in the wild, and getting feedback. Nowadays, with AI, you can do this very quickly. You can build stuff very fast, and you can get feedback more often.

Junior engineers have an unfair advantage of having a very fresh pair of eyes, a very fresh brain that they can use to learn new ways of thinking. They will do way better than engineers who are stuck in their ways.

A playbook for getting started

Now you may say, this is great, but how does it work in practice? How can I get experience if I’m not hired by someone?

Back before AI, what you would do was work on a side project, maybe, or do an internship. You’d try building a Twitter clone or a parking system. Whatever your imagination is, your only limit. You were trying to reproduce a solution, something that already exists.

I think it’s pretty much the same now, but better. You don’t need to be an entrepreneur or a founder to start building a product. You can look at your life and see what problems you have. You can ask friends, ask your family. Ask your communities locally or online. Go out there and look for a problem to solve with your skills. A real problem, not a technical problem, something that is really human.

Then you start talking to people. This is the problem I have, and I have an idea on how to solve it with a tech product. I have a set of hypotheses that I need to validate. You start talking to people, doing interviews, gathering insights about how they behave and what their needs are. Maybe you can do this while reading Continuous Discovery Habits by Teresa Torres, which is one of the best books on the topic.

Once you do this, you can start prototyping. You can do this with Lovable, v0 or Replit. Nowadays, it’s so easy to build a prototype. The same people you interviewed before, you can run some usability tests to see how they use the software, if it makes sense, if there’s any friction. Maybe you can create a landing page and show it to the people you’re talking to, and ask what they think about what the product is going to solve and how it’s going to help them.

Once you have a good understanding of the direction, you start building it properly with Cursor or whatever you like, in an AI-assisted way. You build your first version, your minimal viable product. You ask people to become beta testers so they can use it. You set up monitoring and analytics so you can see what’s working and what’s not. You set up weekly calls with these early customers or users to get their feedback.

In the worst-case scenario, you have learned a lot about how to run a product. You have learned about the end-to-end process of developing a product. In the best case scenario, you may have actually found something that people need, something that they will pay for, and then you can become an entrepreneur. That’s also an option. And really, it is not a coincidence that at PostHog, the pioneering company that made the product engineer role famous, they mainly hire people who were working as entrepreneurs before. That tells you something about it.

Once you’ve done this, you can start looking for companies. I would say the best way is to look for early-stage startups where they would love to have people who understand what it takes to build a product and are not scared to get out there and talk to customers. People who are entrepreneurial and are generalists with a broad skillset.

Portfolios have also completely changed. It doesn’t make any sense to have these websites where you list all the technologies you know, and that you worked as a front-end developer and back-end developer, developing this or that feature. Really, no one cares anymore. It’ll be much better to have a website where you describe how you tackle product problems. Maybe like a case study. You write about it, and if you want, you can even talk about this on social media, on X or LinkedIn. It’s always a good thing to position yourself in your niche, to write about this stuff, so other people know what you’re doing, and recruiters come to your profile and see you have this kind of thinking.

A lot of companies are not hiring junior developers because it’s difficult to train them, and there’s a high supply of senior software engineers. But not all senior developers can be product engineers. They’re stuck in their ways and only focused on their tech side. There is an opening for junior product engineers who can work with the startups being built right now in the AI space.

I’m pretty much convinced that once you prove you can work like this, a lot of opportunities will start to open up for you.

A message for engineering leaders

If you are a manager or a leader, this part is specifically for you. Charity Majors said something that should keep every engineering leader up at night: “By not hiring and training up junior engineers, we are cannibalising our own future.” AWS CEO Matt Garman called replacing junior developers with AI “one of the dumbest things I’ve ever heard.”

So what should you do instead?

Redefine what a junior role looks like. Stop hiring juniors to write boilerplate. Hire them to solve problems. Put them in front of customers. Let them own the full loop from understanding the problem to shipping a solution and measuring if it worked.

Make failure safe. If juniors can’t fail, they can’t learn. Create an environment where trying something and being wrong is not just acceptable but expected.

Pair them with AI, not against it. AI is a force multiplier for juniors. They can learn faster, prototype faster, and get feedback faster. They still need mentorship from humans to develop the judgment that AI doesn’t have. The product thinking, the system thinking, the understanding of what to build and what not to build, and also understanding why. But AI can really help them get better feedback and speed up the learning.

The companies that do this will have a huge advantage in the next five years. The companies that don’t will be fighting to get a good product engineer.

Where to start

If you want to start this journey, let me give you three books that I think are essential for the path I’ve described.

Continuous Discovery Habits by Teresa Torres. This is the book for learning how to talk to customers, validate hypotheses, and make product decisions based on evidence instead of assumptions. It’s the foundation of the discovery part.

Extreme Programming Explained by Kent Beck. This is about the development process itself. How to work in small increments, test-driven development, and shipping continuously. It’ll teach you how to build things the right way.

Don’t Make Me Think by Steve Krug. It’s all about understanding how users actually interact with what you build. It’s short, it’s practical, and it will change how you think about design, even if you’re not a designer.

Whether you are a developer wanting to get started or a manager thinking about your hiring strategy, I hope this made you see the opportunity here. There is a lot of talent out there right now. People with fresh eyes and fresh brains who can be shaped into the product engineers of the future. Some companies are making the mistake of ignoring this. Don’t be one of those companies.

And if you are a junior developer, don’t wait for permission. Start building. Start from the problem. The tools have never been more accessible, and the opportunity has never been bigger.

You can also watch the interview on Youtube:

Anders was named Sweden’s most prominent internet entrepreneur in 2007. He didn’t know the word “entrepreneur” meant starting companies until he was 24. In Swedish, it’s the same word as building contractor.

That detail tells you everything about him. He figured things out by doing them wrong first.

You Have a Known Problem and an Unknown Solution

That’s the frame Anders uses to explain why traditional startup planning fails. You know there’s a problem. You have a rough idea of where the solution might be. But you don’t know what it looks like.

So what do most teams do? They plan the whole route to a destination they can’t see.

Anders’s argument is simple: don’t plan the whole way. Plan one step. Check if you got closer. Plan the next step. The faster you run that loop, the better your odds of finding the actual solution—or discovering there isn’t one before you run out of money.

“Instead of thinking of a single solution that you think, okay, this is what we need to do, you essentially create a machine that allows you to try and test all possible combinations of solutions. And then if there’s only one left, then that must be the best one.”

Killing the Backlog

At Andsend, the company where Anders fully implemented his methodology, there’s no backlog. They removed it completely. Features became experiments. Sprints became daily. The question at the start of each day isn’t “what are we building?” It’s “What hypotheses are we testing?”

I remember Kevin Östlin, CEO of Andsend, telling me about this on a previous episode. It sounded exhausting at first. Then it started sounding like the only thing that makes sense.

Anders adds the organisational layer: everyone owns end-to-end. No product manager translating business goals into tickets for engineers. No engineers waiting for someone to define the problem.

“You define what’s called a one metric that matters, that aligns the direction of everybody in the company. Everybody in the company can then come up with ideas that they believe will move that metric. And they have the authority to implement that end-to-end.”

Build it. Push it to production. Check the metric. Roll back or improve. Repeat.

The uncomfortable part: developers have to talk to customers themselves. You can’t outsource that anymore.

The PR Is the Bottleneck

The biggest pushback Anders gets when implementing this methodology? Killing pull requests.

His case is methodical. An async code review means developer A finishes work, opens a PR, and switches context to something new. Developer B gets interrupted, eventually reviews it, and leaves comments. Developer A—now deep in something else—has to context-switch back. Both people pay a cognitive tax, and the code sits idle the whole time.

“Pool requests is one of the biggest bottlenecks in that process. If you want to minimize the time from coming up with a feature until that feature is in production, it turns out that pull requests is in the way.”

The alternative he pushes for: synchronous code reviews. Pair programming. Review as you go, push when it’s done.

I know the reflex here. Two people on one task feels inefficient. But Anders has the data from Zaplify, Kevin’s previous company: they went from one deploy every two weeks to 30 deploys per day after the methodology was fully in place.

Thirty deploys a day. That number should reframe every conversation you’ve ever had about “moving fast.”

Save to See

One exercise I’m stealing and running with my own team is what Anders calls the save-to-see latency workshop.

Write down every step in your process from “developer has a feature idea” to “that feature is live in production.” Be ruthlessly specific. Save the file. What happens? Does a dev server hot-reload in milliseconds, or does a library PR need to be merged first? Map it all. Then multiply each step by how frequently it happens and how many developers it affects.

“Changing the time it takes from a file change to seeing the change—from 30 seconds to 100 milliseconds—has an enormous impact if you do that a hundred times per day and you have a hundred developers.”

Four-hour builds look terrifying on a timeline. But if they happen once a month, they might not be your real bottleneck. The three-second save-to-see delay that happens ten thousand times a day? That one’s silently destroying your velocity.

With AI writing code faster than ever, these friction points become multipliers. You’re shipping PRs at machine speed but still waiting days for reviews. The math gets ugly fast.

Generalists Are Going to Win

Anders has a strong view on hiring that connects directly to the methodology: specialists are a liability in early-stage startups.

Not because they’re not good at what they do. Because the methodology requires everyone to own end-to-end. A frontend specialist who can’t touch the backend, can’t talk to customers, can’t think about the metric—that person is a constraint, not a resource.

His prediction: generalists, augmented by AI, will outperform specialists at most startup tasks.

“A generalist can fill in any gap they have with AI. And like if you really wanted to move to this methodology from an existing company where you have super structured teams that only do specific things, I’d recommend to sort of have everybody start slowly to move to full stack by adding AI as sort of the fill-in-the-gap layer.”

At Staer, his current startup, the team is 11 people, mostly experienced founders. Computer vision specialists who are also strong general engineers. Nobody has a lane they stay in.

The Machine That Builds the Machine

The question I’m hearing from engineers right now: if AI writes 80-90% of the code, what’s left for me?

Anders’s answer is the most grounded one I’ve heard. Engineers become the people who maintain and improve the machine that builds the machine. The agents are the machine. Engineers remove their bottlenecks, optimise their feedback loops, and make it easier for them to detect mistakes.

He uses Tesla as an analogy. Robots build the cars. Hundreds of engineers start their morning by checking a monitor: what’s the current bottleneck? They go to the station, reprogram the robot, deploy it, and measure. If it’s better, it rolls out to every robot doing that task. If not, they roll it back.

“I think there’s still a lot of work to be done for that. Like, can the agents actually see the thing? Can they have a fully running lab in the cloud that they can run in? So I think there’s still a lot of work to be done.”

If Tesla can run this model with hardware, we have no excuse not to do it with software.

The Lesson That Stayed

When I asked Anders what one thing an engineer or founder could do tomorrow morning to start improving their iteration speed, he came back to the bottleneck workshop.

Write it down. Every step. Feature idea to production. Calculate the frequency. Multiply by the time. Find the biggest number. Fix that first.

Don’t build a perfect machine and forget to ship the product. But don’t build the product while ignoring the machine either.

Anders crashed his first startup. He didn’t know what a CEO was supposed to do, so he spent his time writing business plans. That’s still where most founders start—planning the whole route to a destination they can’t see.

The faster you stop doing that, the better your odds.

Guest: Raquel Smith, Product & Engineering Executive at PostHog

I invited Raquel because PostHog has pioneered the product engineer role. I’ve been following them for a long time, and they’re one of the companies that shaped how I think about what product engineering looks like when done right. Raquel wrote an article a few years back about why product engineering is the most fun role she’s ever had. I wanted to know if that was still true.

Her answer, more or less: yes. But it requires a very specific kind of company to make it work.

Raquel’s path to PostHog is not the usual one. She studied biology and microbiology. Then she found a company that let her mess around with their WordPress site.

“The first line of code I ever wrote, I wanted to change the header color to orange. I changed the hex number, and I swore I was going to take the site down when I clicked save. But it worked. And it was just this: oh my God, it worked. That’s so cool.”

Then she tried product management for a while, liked the thinking but missed the coding. Started her own startup, owned everything from infrastructure to sales. Then came a job where engineers weren’t empowered, and she could feel the difference immediately.

“I knew that I wanted to code, but I didn’t want to have a PM telling me where to put the button or how big to make the font. I wanted to make those decisions myself. PostHog seemed like a place where I could do that.”

Engineers Make the Final Call

Most companies say they empower engineers. PostHog actually restructured to make it true.

I asked Raquel to explain how decisions get made between PMs and engineers. Her answer was clean:

“At PostHog, engineers are the final call. They decide what to build, when to build, and how to build. That doesn’t mean other people’s opinions aren’t highly valued — we very much value the opinions of product managers, salespeople, marketing folks. But at the end of the day, the engineers are the ones who write the code. So they’re the ones deciding what to build when.”

This isn’t just a management philosophy. It’s a structural commitment. PMs at PostHog own research, context-gathering, pricing, and launch. They bring a detailed picture of the problem to engineers. Then they step back.

“The role of a PM at PostHog is to do the research — understand what needs to be built first, what the competitive landscape looks like, what the numbers look like. Bring all that context to engineers, have a deep conversation. And then it’s handed off for the engineers to say: this is what I’m going to work on.”

What makes it work, Raquel says, is clarity. If you don’t define who owns the decision, you get confusion. If you do, you get speed.

No Guardrails Between Engineers and Customers

One thing that came up repeatedly: at PostHog, engineers talk directly to customers. No intermediary. No approval chain.

“In theory, there are no guardrails. Can you email a customer to ask for their feedback? Can you ask them to get on a customer interview? We’re very much: trust over process. I trust you to make the right call.”

The only exception: large managed accounts, where you check with the account manager first. Otherwise, go straight to the source.

Raquel mentioned she regularly asks interview candidates about their customer interaction history. The answer surprises her every time.

“A lot of the people I interview have unfortunately been put behind a PM or some sort of customer-facing role. Some are never even allowed to talk to customers. For me, that’s just not a fit.”

She described a moment that stuck with me: watching a customer try to drag a node in a notebook, something they expected to work but didn’t. The engineer in the room immediately felt the urgency. That reaction, she said, doesn’t happen through a ticket.

One Person, All the Way Down

PostHog engineers are full stack by design: one person owns front end, back end, middleware, and UX.

“Any time a project has to be handed off to someone else, it slows down so much. It gets in a queue. Someone else has to prioritize it. It’s possible they won’t be able to work on it for a few weeks. We really value having engineers who can write the API, the backend logic, create the front end, make sure the UX is okay — so they can do the entire stack all the way up and down.”

The tradeoff is obvious: this only works with senior engineers, or at least high-slope ones (engineers who learn fast). PostHog predominantly hires seniors and is honest about it. Junior mentorship isn’t part of the model by design, not an oversight.

Collaboration Sucks

PostHog published an article called “Collaboration Sucks.” I asked Raquel about it.

Product for Engineers

Collaboration sucks

“If you want to go fast, go alone; if you want to go far, go together…

Read more

6 months ago · 164 likes · 26 comments · Charles Cook

She didn’t walk it back.

“The worst thing that can happen at a company is that you try so hard to reach consensus with everyone that you never actually do anything. There is no world in which you get 10 people in a room and they’re all going to agree on everything. Not within a short amount of time. We’re a startup. We want to move fast. If we’re wasting half our available time trying to get everyone into agreement, we’re getting half as much done.”

They use an RFC process for bigger decisions: write out the context, the options, the recommendation, then tag only the people whose input actually matters. For day-to-day decisions: someone just has to make the call.

She used a volleyball analogy to explain what feedback looks like once that call is made: the coach doesn’t hold your wrist while you’re hitting the ball. You do the thing. Then you hear how to do it better next time.

AI Makes You a Manager Whether You Want to Be or Not

I asked whether AI had changed the fun of the job. Raquel was honest in a way I didn’t expect.

“It feels, at times, more frustrating. It’s easier to be frustrated when you see someone else doing something wrong and you’re like: no, that’s not what I told you to do. Versus stumbling through it yourself — you’re like, oh yeah, I understand why I screwed that up.”

She described spending a couple of hours this past week building a draggable node feature. The whole workflow is prompting now, less hands-in-the-code and more directing.

“You’re really becoming a manager. Management skills are going to become even more important. There’s still that 20% of coding you have to do yourself because it requires a human brain. But it’s a different type of satisfaction.”

Her concern looks further out: if AI handles the early stages of learning, how do junior engineers become seniors? That’s where you internalize edge cases, failure modes, and system behaviour. If that experience gets skipped, the senior pipeline dries up.

Her counterpoint to herself: people said the same thing about calculators.

I’m not sure the analogy fully holds. But I couldn’t shake it either.

What she’s sitting with as PostHog grows is talent density: whether the clarity of who’s great starts to blur as the org gets bigger and product areas get more complex. She’s already sold on the product engineering model.

“When you start with a really small team and you know everyone, it’s easy to see who’s pulling their weight. But as things diversify — across different product complexity, product maturity, user bases — how do you know that your talent density is staying super strong?”

I don’t know the answer either. But it’s the right question to be sitting with before the org gets too big to course-correct.

CONNECT WITH PRODUCT ENGINEERS
Founder: 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.

Stephan has been building things with code since the 1980s. That’s three tech revolutions: personal computers, the internet, and now AI. When someone with that perspective tells you the role of CTO might disappear for most companies, it’s worth listening.

I wanted to talk to Stephan because he’s coaching CTOs and engineering leaders right now. I’ve been watching startups adopt the product engineer model for years. But I hadn’t thought much about what happens to the people above them. What does leadership even look like when your engineers can build five times faster?

The Efficiency Drive Killed Agile

Stephan was an early adopter. He walked into his university professor’s office with the Extreme Programming book and said: we’re doing this now. He became a certified Scrum Master. He helped companies introduce Scrum.

And then he watched it fail. Over and over.

“What people learned back then is that the tool does not help. The tool does not drive the change. And so a lot of Agile failed for more than ten years.”

The problem wasn’t the methodology. It was the efficiency obsession. Product managers started working one sprint ahead. Then designers worked two sprints ahead. Then business was planning four sprints ahead.

“Because of the drive for efficiency, you get far away from the ideal of product managers, designers, and developers sitting together, working together at one point in time on one feature.”

We optimized ourselves right back into waterfall. Just with different names for the meetings.

Code Isn’t the Bottleneck

Here’s the uncomfortable observation: most people assumed engineering was the constraint. Stephan never bought it.

“I always thought that bottleneck is in product management. And I think now it becomes obvious to people that that’s the case.”

AI just made it undeniable. If I can build five times faster, I need to ask my product manager five times as often. That math doesn’t work.

“The reaction of product engineering is the merging of some parts of product management and some parts of engineering together with AI. With more local autonomy in decisions and responsibilities.”

The product engineer isn’t a new buzzword. It’s a structural response to a real bottleneck.

You Build the Wrong Thing More Efficiently

Stephan made a point that stuck with me. Waterfall has perceived efficiency gains. You build the wrong thing, but you build it more efficiently.

“The output is worse with waterfall, but the efficiency is better. You build the wrong thing more efficiently with waterfall.”

But now AI tips the scales. The efficiency gains from AI are so large they obliterate whatever you thought you were gaining from working in siloed sprints ahead.

“AI efficiency gains kill the waterfall efficiency gains. So that’s why waterfall will not make a comeback with AI. The ultra anti-waterfall is basically the product engineer.”

That’s a bold claim. But I think he’s right.

Leadership Isn’t There Yet

I asked Stephan how leadership changes when you have autonomous product engineers who own problems end-to-end. His answer surprised me.

“I think leadership will come in. It’s not there today.”

He’s not saying leadership needs to evolve. He’s saying it barely exists in most companies.

“I look into companies, they are very weak on vision. They usually are very, very weak on strategy. They are very reactive to competition, to the market.”

Command structures told people what to do. That’s not leadership. Leadership is declaring a direction and building trust that people will follow.

“Leadership is a very active role in thinking, look, this is a golden future. And we will go there. And then it’s also partially like I’m the leader. Trust me.”

With product engineers making local decisions, someone needs to be weaving a coherent story. Otherwise you have autonomy without alignment.

Managers as Storytellers

So what does that alignment actually look like in practice?

Stephan used an analogy I hadn’t heard before. Imagine people walking through a field. It starts thundering. Everyone is afraid, confused.

“There was always someone who said, don’t worry. The reason it’s thundering is because this morning the thunder god ate something bad. And then people said, okay, that makes sense. Let’s keep walking.”

That’s what managers do. They connect disconnected phenomena into a narrative that helps people keep moving.

“Creating a narrative that makes sense for everyone out of these disconnected things.”

It’s not entertainment. But it’s also a little bit entertainment. Stephan admitted he sees part of his management role as making sure everyone is happy and engaged. “Sometimes it’s like a holiday club.”

The CTO Role Might Disappear

Stephan coaches CTOs. And he’s telling them to prepare for their role to either transform radically or vanish entirely.

“There’s a non-zero chance that the CTO role will go away completely for a lot of companies. If you’re SpaceX, you’re going to have a CTO. But if you have a website with a database, you’re not going to have a CTO.”

His advice: move into a CPTO role. Own AI before someone else does. Drive technical innovation, don’t just execute what product asks for.

“The CTO role that CTOs today think is since eternal times is going to change.”

The Scissors in Your Head

I asked what “bullish on AI” actually means. It’s not about hype.

“Organizations will be able to create much bigger stuff. Things you thought were not possible for one person to build are now possible for one person to build.”

He mentioned a library someone released that had no code. Just a prompt and a hundred test cases. The AI reads them and implements the library in whatever language you need.

That’s not practical yet. But it shows the direction.

“That’s what AI enables. The flourishing of people.”

Make Product Engineer a Promotion

One practical tip stood out. A client of Stephan’s didn’t just rename developers to product engineers. He made it a promotion.

“You need to be promoted to become a product engineer. You need to be able to do this, this, and this. And then you can be promoted.”

It’s painful. But the results are better.

“If you just rename people and roles, you will have a lot of problems with the execution. Making it a promotion, the implementation will be much better.”

Right now, about 80% of product engineers will come from engineering and 20% from product. Stephan thinks that ratio will shift as AI tools get easier.

What Developers Might Find Out

Stephan drew a parallel to journalists. They thought people read newspapers for information and investigative reporting. Then social media arrived.

“They found out what people were interested in was entertainment. People opened the newspaper each morning because they wanted to be entertained, not to be informed.”

He thinks developers might face a similar reckoning.

“Developers will find out with the AI wave that people valued them for different things than they valued themselves.”

That’s not comfortable to hear. But it’s worth sitting with.

We can build faster now. The question is whether we’re ready to let go of identities built around how we used to build.

Else Van Der Berg

Product Lead working with AI-native companies, including Wave Terminal and SwitchUp

I wanted to close out the year by going deep on the topic that started this whole community: the convergence of product and engineering roles. Else Van Der Berg has been living this from the product side, vibe coding for nine months and working with AI-native companies. We spun a wheel of topics and let chance guide the conversation.

The Natural Convergers

Else made a point that reframed how I think about this trend:

“There have always been natural convergers, right? There’s always been these people who couldn’t stick to their lanes.”

She described her first product role in 2016, where she kept reaching out to sales, customer support, and marketing to understand what messages they were putting out there. The response? “Stick to your lane. Your job is to take business requests and translate them into Jira tickets.”

“Later, thanks to Marty Kagan, yes, it is what a product manager is supposed to do, but it came later.”

And in every backlog refinement, there were always a few engineers asking: How did we validate this? What does this feature solve? Who did you talk to?

The main argument against convergence is that you can’t be an expert in multiple domains because the cognitive load is too high and you become a master of none. Else’s response:

“Yes and no. There are these natural convergers who are just more comfortable holding more domains in their heads. Actually having this artificial distinction is much harder.”

This kind of cross-domain thinking is exactly what system thinking enables.

1973 Called

Else found a journal from 1983 describing engineering practices from 1973:

“Developers themselves have a close relation with the clients. This results in high motivation, flexibility and low overhead.”

Developers speccing things out and talking to clients directly. This was the norm fifty years ago, but somewhere along the way, we over-specialized.

The web grew more complex. We needed DevOps, backend engineers, frontend engineers, product managers. The systems got too big for one person to handle everything.

But now tools are simplifying again. Replit, Lovable, Supabase put everything in a nice package with a bow around it. You hit publish and it’s done.

“I think we are able to move back in that direction. Not just because things are simpler, but because people can upskill themselves into other territories with friends like Claude.”

Can Legacy Companies Adapt?

I asked about established companies. Can they adopt this way of working?

Else was skeptical:

“If you have a beast of an organization with a very classical org chart, with a lot of middle management layers, and a lot of people sitting there who are not necessarily convergent and also would like to push against it... it’s going to be very, very difficult, slash impossible.”

She’s met the opposite of natural convergers. The people who say “this is my turf, don’t touch my turf.” The PM who takes it personally when an engineer asks why something is important. The engineer who mocks designers for vibe coding.

“If 50% of the leadership team is people who would love to hold on to these strict specializations, which is not unlikely because these are the people who climbed the ranks in this game, it’s going to be near impossible to change that culture.”

The only path? Something like what Brian Chesky did at Airbnb in 2019. A hard cut. Let go of people. Fundamentally change the culture. That’s a big bet most companies won’t make.

The Small Team Advantage

We looked at the numbers from AI-native companies:

• Cursor: 100 million ARR with 12 people

• Mid-Journey: 200 million ARR with 40 people

• Bolt: Zero to 40 million ARR in five months with ~20 people

• Linear: Less than 50 people

“I doubt that all of a sudden they’re going to shout from the rooftops ‘this year, we’re going to grow headcount by 300%.’ That is not the flex that it was before. I think it’s an anti-flex now.”

These companies will grow, but not headcount for the sake of headcount. People are just more effective with AI tools.

M-Shaped People and the Master of None Problem

The counter-argument came up during our conversation: aren’t you spreading yourself too thin?

Else admitted the cognitive load is real:

“There is the risk of the cognitive load just being too high. The wall of output, right? I sometimes think of myself as Neo from the Matrix. They need to learn how to drive a helicopter and then they can drive a helicopter. It’s a little bit like that, except it doesn’t go into my brain, it’s just on my laptop screen and I still need to get it from there inside my brain.”

But before AI, she couldn’t lock a senior systems architect into a meeting room and ask a thousand stupid questions. Now she can do that with Claude Code.

“I absolutely see the risk, but I do not think it necessarily has to be the case. The cognitive load is almost higher when you’re not allowed to drift into the other lane.”

Product Market Fit Collapse

Here’s what really got my attention. Else talked about how the concept of “post-PMF” might be dying:

“It used to be pre-AI era, we talked about pre-PMF and post-PMF. Pre-PMF everything was fuzzy. Then we hit product market fit. Wow. And now we can coast. We don’t need to innovate as much. Just optimize what we have.”

That world is gone.

“Even if you are not AI native, some AI native company is coming for you.”

Stack Overflow had product market fit, and then people started typing into ChatGPT instead. Their numbers collapsed.

“The only way to keep product market fit is to stay on this treadmill. You have to keep running. You have to keep innovating. And the only way you can do that is to have this pretty different org structure with all of these M-shaped convergent people who are bringing so many diverse ideas to one problem.”

Legacy companies relying on maintained PMF are in trouble. They don’t have the learning velocity to keep up.

Is Over-Specialization Anti-Agile?

We ended on something I’ve been thinking about for a while. When you have specialized roles with handoffs between them, true agility becomes nearly impossible.

PM does discovery, writes tickets, talks to designer, designer creates wireframe, engineer gets the wireframe. Even if they work as a “trio,” unless they’re literally in the same room multiple times a day, you get delays.

“I’ve been working in product trios for a long time and it was always like, okay, we’re going to have engineers and designers and product people all with the same context. But then the reality is the developer cannot show up. The developer is in a sprint. And I want to run a cool landing page test. And I’m saying to the designer, please do this landing page. And they’re like, no, I’m doing production grade designs for the sprint.”

The only way to be truly agile is to own the whole process yourself and remove the handoffs entirely.

As Else put it: everyone always told her to focus on post-PMF companies because you earn more money. She liked the uncertainty of pre-PMF work.

“Ha ha, you’re all pre-PMF now, guys.”

Kevin Ostlin

Co-founder and CEO of Andsend, former CTO of Zapplify

Kevin told me his team runs daily sprints. Not weekly. Daily. Each standup is basically a sprint planning session for the next 24 hours. My first reaction was: that sounds exhausting. My second reaction was: wait, how does that even work?

Turns out, they’ve built something he calls an “iteration factory.” And the results are wild.

The Old Way Was Broken

Kevin’s previous company, Zapplify, ran textbook Scrum. UX designers, engineers, QA, product managers. One week sprints. Backlog with stories and epics. Everything looked great on paper.

“The problem in that type of organization is of course that you end up creating a lot of bottlenecks. That’s one aspect of it, from a performance perspective. But of course, the engineers are also very unmotivated.”

When they mapped out all the bottlenecks, the numbers were absurd: a team of nine was losing roughly 40 days per week in handoffs and lead times alone.

That’s when Kevin started asking a different question. Instead of optimizing the existing process, what if they built a factory designed to spit out iterations? Fast iterations. Daily iterations.

Killing the Backlog

The first big move was painful. They deleted Jira. Not metaphorically. They actually removed everyone’s access.

“I was still during the nights in the beginning, sitting with my computer and looking at this perfectly structured project in Jira and just enjoying the structure and also crying a bit that we will have to let this go now.”

I laughed, but I get it. There’s something comforting about a well-organized backlog where everything is planned and prioritized, even when it’s all wrong.

Because here’s the thing: when you have a product manager as gatekeeper for everything, with sprints planned in advance, you can’t actually respond to what you learn. You’re executing a plan, not solving problems.

“That was the enabler for all of this. Suddenly everyone realized that we don’t know what to do anymore.”

And that’s exactly the point. Not knowing forced everyone to figure it out together.

Hypotheses, Not Features

The language shift matters. At Andsend, nobody works on features. They work on hypotheses.

“We have daily sprints. So every standup is basically a sprint planning for the day. The mindset shift is very interesting how everyone just thinks about, today we should get this hypothesis to production.”

A hypothesis looks like this: “Introducing a product video in the hero section on the website should increase the number of activated users.” Clear input, measurable outcome, and you can test it today.

They deploy on average more than one new iteration per day per engineer. Some hypotheses are product-facing. Some are deeply technical, like “if we introduce these three dimensions to our vector space, that should increase clicked cards in the feed.”

The technical ones still tie back to user behavior. That’s the key.

Engineers Who Actually Talk to Customers

This is the part that made me jealous. Every engineer at Andsend is in customer meetings. Not optional. Not occasionally. Regularly. It’s what turns engineers from ticket takers into problem shapers.

“Nothing makes you feel as much ownership as if you meet the customers, you feel the problem. You don’t just see it, you feel the problem by actually creating a connection with the customer and making a promise to the customer.”

They’ve even experimented with engineers owning customer relationships entirely, handling follow-ups and everything. The goal is everyone in one to three customer meetings per week.

Why does this matter? Because when you make a promise to a real person, you ship differently. You’re not implementing a ticket. You’re keeping your word.

Filling the Gaps with AI

I asked the obvious question: how do backend engineers suddenly become competent at UX?

Kevin’s answer: AI fills the gaps. They gather all customer interview transcripts in folders, then ask AI questions about patterns across conversations they haven’t personally attended. They can marry qualitative insights with quantitative data before writing a single line of code.

For design work:

“We actually don’t use Figma at all anymore. We only use tools like Lovable or even just prompted away in Cursor. We make it on our local and then share it to the rest of the team.”

No Figma at all. Product engineers generate prototypes in code-first tools and iterate from there—a shift that’s changing how we design products.

The Tesla Analogy

When I asked about scaling, Kevin pointed to Tesla’s factory:

“In a Tesla factory, the engineers work exactly like this. They go out in the production, they have hypotheses, they make a change, and they observe metrics and document your change. They can do that in a day and then watch what happens.”

Tesla’s goal is apparently one car every 10 seconds. They’re at one every 90 seconds now. Still insanely faster than competitors who don’t operate this way.

The key to scaling isn’t adding more process. It’s observability. Everyone needs to know what changed yesterday without a bunch of meetings to find out.

So You Want to Try This

Kevin’s advice for leaders considering this shift:

First, challenge yourself on why you want to do it. If it’s because you read about it and it sounds cool, it probably won’t work. You need internal conviction.

“Something like this is something you have to sort of internally build a conviction around and a belief in.”

Second, write it down. Use AI to stress-test your thinking. Ask it to respond as an engineer reading your document. Then as a CEO. Find the trade-offs. If you can’t find any, you haven’t thought hard enough.

Third, find your champions. There are always one or two engineers who naturally get this. Back them. Amplify their successes. When they ship something fast and it works, make sure everyone knows.

“First and foremost, you got to understand why you’re doing it yourself. And if it’s just because you read it and it looks cool, it’s probably not going to work.”

Could my team run daily sprints? Honestly, I don’t know. But after talking to Kevin, I’m more curious about what’s actually blocking us from trying.

Martin Pengelly-Phillips

VP of Engineering at Zen Educate

“Software engineers at Zen Educate are problem shapers. They’re not ticket takers.”

That line from Martin’s job postings caught my attention. What does it actually mean to transform engineers from implementers into shapers? Martin walked me through the journey.

The Full Circle Journey

Martin started in the film industry, building technology for visual effects. There were no product managers or designers. Software developers figured things out by talking directly to artists and supervisors.

“I kind of started almost naturally in that go talk to people, understand the problems that they have and then sort of slowly try to build a solution from there.”

Then he joined Intercom, known for being product-led, and found people who shared his approach. Having product managers and designers wasn’t about removing ownership from engineers. It was about acceleration.

“It’s very hard to be great at everything. So if you’re there as an engineer and as a product engineer, you care about the experience and all, but you just might not have the skill, the time to go deep in those areas. So having these other people that you could suddenly pull on and leverage was really great.”

The Frustration of Being a Ticket Taker

What’s wrong with the traditional model? Martin put it simply:

“You never really understand what you’re doing and why. You’re sort of, it’s just an endless sea of requests. Eventually, the new tech becomes mundane, the chasing new tech becomes a bit less of a dopamine hit. And so you start to think, well, where else am I getting my fulfillment?”

When multiple stakeholders disagree about priorities, the engineer becomes the point where all that tension collides. No opinion of your own, just trying to satisfy everyone.

“Not only are you not getting that fulfillment in understanding, but you’re also being torn in many different directions. That’s very draining.”

The word I keep hearing from engineers is impact. The ones who are unsatisfied don’t feel like they have any.

The Transformation at Zen Educate

When Martin joined Zen Educate, they were close to the ticket-taker model. PMs wrote tickets, assigned them to engineers, and engineers had to get approval before shipping.

“That’s just all very slow, but also quite not fun for engineers.”

The shift involved engineers in problem definition from the start. Now when a PM identifies important problems, engineers are in the room asking: Why do we think this is the problem? Have we defined what success looks like? Is there actually a different problem here?

Same with design. When a designer ideates on solutions, engineers help figure out what’s feasible, what can be built faster using existing infrastructure, what would delay getting value into users’ hands.

“We still got today quite a linear process where there’s problem definition, solution ideation, technical assessment, and implementation. But with the engineers that have really embraced this product engineering mindset, those loops and feedback loops are getting tighter and tighter.”

Some teams take this even further, running daily sprints and treating everything as experiments rather than features.

The Definition That Stuck

Martin shared his one-line definition of a product engineer:

“It’s someone who loves solving real problems for users and just happens to be skilled at leveraging technology to do that.”

The difference from a traditional engineer is that the product engineer focuses first on the problem, not the technology. They’ll solve it with code most of the time, but sometimes they won’t.

“The mark of a product engineer is someone who solves a problem sometimes by not building anything.”

What Actually Changed

The mechanics matter. Zen Educate built a six-week process with problem definition and scoping in the first couple weeks, solution design in the middle, technical assessment, and then implementation.

“We’ve actually created quite a lot of lead time in the process. That’s how we tackled the main challenge of laying the tracks far enough ahead that the team can run at it well.”

They also experimented with engineers partnering directly with commercial leaders, skipping the traditional product hierarchy entirely. One engineer paired with an account manager to spike out a solution before a full team took it on.

“That’s been very successful and also a lot of fun for everyone, especially on the commercial side who suddenly get a closer glimpse of what does it mean to actually build something and iterate on it.”

The Constant Reinforcement

The biggest challenge isn’t process. It’s permission.

“The thing that’s maybe obvious and simple is the need to constantly tell people and reinforce that you can do this.”

Engineers coming from traditional environments are nervous. Am I stepping on the PM’s toes? Am I allowed to ask these questions?

“Making that okay and safe and re-emphasizing continuously that no, as a team this is how we do better. And actually, the PM is gonna thank you because they’ve got a lot to do.”

Then there’s the skill gap. Some engineers have never thought about user problems this way. They haven’t understood the commercial aspects of the business.

“It’s okay to not know. It’s okay to get it wrong. If we’re giving you the ability to have more influence, more impact, we’re not also expecting you to nail it first time.”

Scaling the Culture

I asked Martin how this scales. His answer: constant effort.

“Anyone who says ‘I’ve got the culture now and it will stay forever,’ that doesn’t work. You have to work at it every day in how you show up, how others show up, what you recognize and reward.”

The dangerous zone is the messy middle, when you’re too big for the founder to talk to every engineer but too small for autonomous groups to maintain culture on their own.

His advice for leaders wanting to adopt this model:

Challenge yourself on why. If it’s just because you read about it and it looks cool, it’s probably not going to work.

Write it down. Use AI to stress-test your thinking. What would an engineer think reading this? What would a CEO think? Find the trade-offs. If you can’t find any, you haven’t thought hard enough.

Find champions. There will always be engineers who naturally get it. Back them, amplify their successes, and provide cover if needed.

“First and foremost, you got to understand why you’re doing it yourself.”

Toms Vārpiņš

Product designer with 12 years of experience turning complex ideas into impactful products. He’s worked on everything from fintech systems to AI-powered health tools and e-commerce growth. With a mix of tech and communication skills, Toms loves solving tricky problems, running workshops, and learning about everything from design and engineering to economics, philosophy, and music.

Toms is a former colleague of mine from Kinsta. When I invited him on the show, I wanted to understand what’s actually happening in the design world with all these AI tools. Engineers have Cursor and Copilot. What do designers have? And more importantly, is anyone actually excited about it?

The Useful Parts

Toms uses ChatGPT constantly, but not in the way the marketing would have you believe. He’s not generating entire design systems from a single prompt.

“It’s very useful to use ChatGPT to start out anything because if you’re starting a project from zero, there’s always some kind of information available. You can put that together with your brain dump into GPT and it will make some kind of sense of your thoughts, give you some more accurate wording.”

The key word there is “start.” He takes the output and thinks through it again. Copy-paste answers don’t work because every product is different.

What I found most interesting was his habit of asking for contrarian opinions:

“What I keep doing a lot is when you ask anything to ChatGPT, it’s very good to ask for the contrarian opinions, the ones that are outside of the boundaries. It allows you to check how far your basic understanding is from the edges.”

That’s a trick I’m stealing immediately.

Where Did All the Wireframes Go?

I asked Toms about low-fidelity prototypes. You know, the black and white sketches meant to isolate the user journey from visual distractions. With tools like Lovable and V0 generating polished UIs instantly, does anyone wireframe anymore?

“I haven’t seen much wireframing recently, and I haven’t also myself done much of wireframing.”

Here’s the problem. When you show stakeholders something that looks finished, they focus on the wrong things. Toms shared a trick he used to use: deliberately making the UI horrible so stakeholders would focus on the flow instead.

“If you come too early with a thought, with an idea laid out, but specifically made the UI horrible to look at so that idea would be on the flow. And that now distracts from the problem because now you design high fidelity.”

But if you go too rough, they think you haven’t put in effort. It’s a losing game either way.

Generative Mediocrity

We did a live demo comparing Lovable and V0. I gave both the same simple prompt: “A landing page for the product engineers community to gather emails.”

The results were fine, and that’s exactly the problem.

Toms coined a term that stuck with me: generative mediocrity.

“It takes the average of everything. But if you look at any SaaS website, Lovable for example, it is fine tuned. There’s all kinds of small touches that technically, practically are not important from a technical aspect, but from the human perception aspect, those little details, that craft aspect, is what creates trustworthiness into the product.”

The AI gives you the average of what exists on the internet, which means it’s not bad, but it’s not distinctive either.

I showed Toms a job board I’d been working on. It took 43 iterations to get something that actually felt right. The difference? I fed it my brand guidelines, mood boards, and specific visuals. Context matters enormously.

“This feels like massaged. It feels like someone has put in effort into making this happen.”

That’s what 43 iterations buys you. Not a magic prompt.

The Excitement Question

I asked directly: are designers excited or anxious about these tools?

Toms didn’t sugarcoat it:

“I have not really seen designers really celebrate. Those who celebrate, I’ve noticed, are very focused on the website creation side.”

Marketing websites? Great use case. You need vibes, you need directions, AI can generate lots of options. But product design is different. Every input field, every button connects to backend services that took time to develop. You can’t just generate frontends and connect them to backends easily.

He told me about a previous company that tried using AI tools for landing pages. The first draft was great. Then they made edits and it started losing context. When developers looked at the generated code?

“They’re like, we can, but it might be easier and more maintainable if we just rewrite it, but we can use this as a reference.”

So much for replacing the team.

Everyone’s Stepping on Everyone’s Toes

We got into the bigger picture. Roles are blurring. PMs want to prototype without waiting for engineers. Designers want to ship without handoffs. Engineers want to understand business impact.

“I feel like design is kind of merging with project management or product management always wants to move into other spaces.”

I shared my take: AI just made it clear that everyone wanted to do more than they were allowed to do before. PMs were blocked by slow prototyping. Designers were stuck being pixel monkeys. Engineers were code monkeys. Everyone was frustrated by the assembly line.

If code becomes a commodity and anyone can create designs and PRDs, does that mean we’re supercharging individuals at the expense of others? Or does it let us test more ideas?

“The current trend that we have seen is that AI is used kind of as excuse to downsize company, to keep the company lean and make it more efficient instead of expanding outwards, which is the original promise of AI.”

That’s the uncomfortable observation. The marketing says “do more.” The reality seems to be “do the same with fewer people.”

The Question Nobody’s Answering

Toms left me with something I’ve been thinking about since:

“In the end, who will pay you for your product? Are you solving a customer problem? Do your customers even have this problem? Are they willing to pay for this problem?”

You can vibe code an app in a day and get to the project graveyard 99% faster than before. But the fundamental questions don’t change: does someone want this, and will they pay for it?

We can build faster, but we still have to figure out what to build. That’s why thinking in experiments rather than features matters more than ever.

Toms’ LinkedIn

Michele Sollecito & Luis Rodrigues

Michele is an Engineering Manager at Meta with 15 years of experience. Luis is a Software Engineer at New Store.

I asked our community a simple question: what is system thinking in one sentence?

The Butterfly Effect in Your Codebase

Have you ever seen a small, well-intentioned change create chaos across an organization? Michele has seen it plenty of times.

“The classic one is when you focus on measuring productivity, perhaps by counting lines of code or number of PRs. And then fast forward a year or two and you see that the entire culture of the company changed and people behave differently. Because fundamentally you create an incentive for them to do so.”

Luis added a story that hit close to home for many of us: the mandate to reach 80% code coverage.

“There’s lots of ways for you to reach that number. You could write a test that exercises the code but doesn’t actually test anything, doesn’t assert anything, and boom you get the 80%. But you’re not actually doing anything.”

The downstream effects are worse than the original problem. Teams that don’t understand why they’re testing end up coupling tests to implementation details. When someone wants to refactor, the tests break, so nobody refactors, and the architecture degrades over time. All of this from a well-intentioned mandate to improve quality.

Your Department is Not a Universe

One pattern I keep noticing is that every department lives in its own bubble. Developers obsess over agile and continuous delivery. Designers talk about design thinking. Managers have their own vocabulary. Everyone optimizes for their own metrics without considering how the pieces fit together.

Michele gave a concrete example:

“Some teams might pride themselves for doing continuous delivery. You can release to production 50 times a day. We’re all happy. And then you’re like, hey, if we release major features in production without giving marketing and product folks the chance to create the right expectations and audience and marketing campaigns, we’ll only find the outcomes that we would have gotten from those changes because we’re not playing in sync.”

Luis has seen even tighter feedback loops break down within teams:

“I’ve seen this happen where you have people who work technically inside the same team, but they work in isolation. The designer does something, throws it over the fence. A day later, the developer gets very frustrated by the designer’s wild imagination. He says no, this is impossible to do. It requires me to refactor. Sends it back. And a day later, the designer comes up with a revision.”

The resentment builds, people start blaming each other, and the root cause is that they’re not working together because nobody designed the system for them to work together.

Code is Not the Bottleneck

With LLMs writing code faster than ever, everyone keeps saying “code is not the bottleneck.” Michele pushed back on the entire framing:

“Software development is not manufacturing. There’s a lot of focus in the industry on throughput, productivity. How do you define productivity? There has to be time at the denominator. What do you put on the top? Is it lines of code? If you analyze it formally, it kind of cracks down.”

The deeper problem is that we’re treating product development as if it were an assembly line, where speeding up one part makes the whole thing go faster. But that’s not how complex systems work.

“Even if we were able to accelerate software development by 10x, I mean, you’re running to nowhere. The point is you still need to understand those things. That’s the hard part of product development, not ‘we just need to build it all.’”

Luis connected this back to the delays inherent in our work:

“Even if you write code 10 times faster, you’re shipping all these features, but then you’re ignoring the fact that there are people that use the software. Because they’re human, they need time to adapt, to understand. That delay is exactly what we need to make the product better, to make decisions.”

Building fast without understanding what you’re building just gets you to the graveyard faster.

Why Organizations Create Wrong Incentives

Michele traced the root cause back to how companies are structured from the very beginning:

“A lot of companies start by hiring a panel of executives. I might hire you Giuseppe, you’re the executive for product management. And Luis, you’re the executive for sales. Now fundamentally, what that message says is: you’re going to be entirely and fully responsible for product. You hire your own people and do whatever you want.”

This cascades all the way down as VPs hire directors who hire managers who hire teams, and everyone ends up reporting to different hierarchies with different goals and different incentives.

When things go wrong, the blame game begins:

“If we fundamentally believe that the outcome is the sum of the parts, and that’s the belief behind splitting the responsibility across the executives, then when things don’t go well, I’m like, hey, I’m doing my part. Who’s not doing their part? You don’t see it as: we might all be doing our part well, but we’re doing it in a way that doesn’t really fit together.”

The Social-Technical System

What makes software development particularly tricky is that it’s both a machine system and a social system at the same time.

Michele explained the difference:

“Machines are made by inanimate parts. These parts don’t have their own goals. You cannot create the wrong incentives in a codebase because a codebase doesn’t do anything on its own. But developer teams are different kinds of systems, social systems, where each member has their own goals.”

When you create incentives that force people to choose between what’s best for themselves and what’s best for the company, we all know how that choice typically goes.

Luis added another layer:

“Developers have emotions about the state of the codebase. That ends up making things worse and creates this kind of crazy dynamics.”

That’s what makes this a social-technical system, where the code affects the people and the people affect the code in ways that are almost impossible to fully predict.

What Can You Actually Do?

I asked Michele and Luis what individuals can do when they don’t control the structure around them. Michele was both optimistic and pessimistic:

“Thinking things through, mapping them out, talking to people. That helps a lot. If you tell people, hey, there’s a chance that this is going to happen because by doing this, that’s how people are going to react and that’s going to cause this, which is going to cause that. Sometimes people will fall for it.”

But he was honest about the limits:

“Most of the time it really doesn’t work. You will find a band of people where you’re going to go to the pub and have a lot of fun talking about this stuff. But then you’re still going to crash by the wrong incentives and structures in place.”

Luis preferred demonstration over evangelism:

“I would probably demonstrate system thinking rather than try to push any books or videos. Show that two things that seem unrelated are actually connected, and point out that something might have an impact on this other seemingly unrelated thing. People might listen to me or not, but you keep trying.”

Why Product Engineers Matter

This is where the product engineer mindset becomes crucial. When you care about more than just the technical part, you start seeing the gaps between elements.

Luis put it perfectly:

“Having this wider view is really helpful to get people to care, or at least start to think that it’s possible to care beyond your little bubble. Because you’re looking out across all sorts of barriers, front end, back end, design, engineering, product, you see the gaps between the elements. You think a lot more about the interactions of these components.”

Michele went further, calling it a baseline expectation for seniority:

“If you come in at a level of experience where you’re considered somewhat senior, I would take it as a baseline expectation. Otherwise, you’re counterproductive, de facto, and people who know anything will probably not hire you at all.”

That’s a strong take, but I think he’s right. The problems we face aren’t technical in isolation. They’re about how technical decisions interact with organizational decisions, which interact with user behavior, which feeds back into what we build next. You can’t navigate that without thinking in systems.

Michele’s LinkedIn