Tyler Folkman
Chief AI Officer at JobNimbus | Building AI that solves real problems | 10+ years scaling AI products | LinkedIn Top Voice
“The customer doesn't experience your defect rate. They experience the number of defects that you push out there.”
The Growth Podcast · Product & Design · September 2026
Context
Folkman was explaining why the uptime of large companies looks worse than it has in years. His argument is that their quality did not get worse, they are simply shipping far more code at the same defect rate, so the same percentage now reaches many more people. It is his case for spending AI-won speed on quality checks rather than on shipping again.
Transcript
…take. And that was more like six months ago that people that I would hear that when Claude was newer on the scene, especially for PMs. I'm like, no, Claude does not. You ask Claude how long it'll take six months ago, and it's like, oh, a week. And they'd say, go build it, and it'd be like, built.
…hooks are, when I need to use them. Talk to me a little bit about from product to engineering. What engineering loops should be out there? What engineering hooks should be out there? And then PMs, like interfacing with engineers. When does the PM work? PM loops end and the engineering loops begin.
Some of the most important loops for engineers right now are quality loops. The thing that people don't talk enough about, in my opinion, is if you ship, let's say, twice as fast with AI and your quality rate maintains the same rate. Let's say you have a 1% bug defect ratio or something. Your customer experiences twice as many bugs if your quality doesn't improve. The customer doesn't experience your defect rate. They experience the number of defects that you push out there. And so we're seeing this. I mean, you look at big companies, their uptime is the worst it's been in a long time. And my opinion is it's not that their quality got worse, actually. It's that they're just. Just shipping more code. And so more things go wrong at the same rate. And we've seen that. And so we've really started and tried to invest in quality improvements through loops for engineering…
And should PMs be pushing PRs? Where does that go till? Should PMs be working on engineering tasks at all? I
think it's definitely appropriate for PMs to work on engineering tasks where it makes sense. Like, let me give an example. I don't know if I'd put a PM working on our back end billing system and making upgrades to it that could impact people's money flow and all that. There's a lot of like…
Okay, so that's one part of it, which is PMs doing engineering work. It sounds like PMs shouldn't be trying to become engineers, but if they're doing some front-end changes where, again, they have put in probably more time on it than the reviewer would need to, then it might make sense. What about…
More from The Growth Podcast
