Raw capture â raw/product-minded-engineers-ai-native-world.md
url: https://gist.github.com/njt/3948a8decc055472d9f429e4586be273 date_fetched: 2026-07-05 backfilled: true
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A product engineer is defined by motivation, not tech stack. They care at least as much about what and why as how. A product-minded engineer is motivated by user impact; a code-minded engineer is motivated by complexity, elegance, or libraries. The distinction replaces the false frontend/backend split that puts people in wrong roles.
Product engineering applies everywhere, not just user-facing features. Any interfaceâa function, a module, an APIâis a product with users who must discover, understand, and use it safely. You can be deep in infrastructure and still be a product engineer.
Taste is a learnable craft, not a mystical gift. It has two dimensions: conceptual quality (what to build) and implementation quality (how to build it). Taste is built through exposure to many products (software, physical, experiences), talking to customers, and practicing the skill of simulating user interactionsâputting yourself in the user's shoes and thinking several moves ahead.
Quality is Linear's entire strategy. In a crowded market, they chose one word: quality. They aimed for a product 10x better than incumbents, built first for ICs, and hired for shared taste in quality. Quality is not quickly measurable by A/B tests, but without deliberate investment, products degrade and users leave.
Rituals build collective taste. Linear's "Quality Wednesdays" (every engineer finds and fixes a non-bug defect weekly, then presents it) has fixed 2,500+ defects and rewired the team to constantly hunt for imperfections. Stripe's API review process required "developer flows"âstep-by-step user journey storiesâwhich forced engineers to think in user terms and often solved problems before review.
AI dramatically shortens feedback loops and democratizes product skills. Engineers run multiple Claude agents in the background for small fixes. Sales call recordings auto-post to Slack with bug summaries; fixes can ship same-day. Designers who never coded now write PRs using Claude, improving UX directly. AI also helps with product tasks like finding customers who asked for a feature, competitive analysis, and denoising user feedback.
Direct customer contact remains irreplaceable. AI summaries help, but human-to-human meetings build empathy that summaries cannot. Every engineer should attend sales calls and customer site visits.
Goal engineers on real value metrics, not vanity. Move along the gradient from vanity metrics (signups) to adoption (MAU) to value (meaningful interactions, counterfactual surveys like "would your company exist without this product?"). The further you go, the harder to measure, but that's where real alignment lives.
Pithy and provocative quotes
Thomas on Linear's strategy: "We came up with this... strategy is one word, and that word is quality. We wanted to build a product that was not two times better, but ten times better than any incumbent solution."
Drew on the core distinction: "A product minded engineer or product engineer cares at least as much about what and why as they care about how."
Drew on his awakening at Microsoft: "The chief architect's vision for this framework was the assembly language for building compilers. And I just thought, who wants to program an assembly language? Like nobody."
Michelle on being miscategorized: "I didn't feel like I was using my computer science degree to use data structures or algorithms at all... I realized that actually it's because the industry had been using front end and back end engineering, and it ended up putting people in the wrong professions."
Thomas on the origin of Quality Wednesdays: "After the 10th time I fixed one of these highlights not fading out, I was like, I got to teach the team to sort of see these mistakes, because if you don't know what you're looking for, you will just simply miss it."
Drew on measuring real value: "The further you get along that gradient, the harder it is to measure and the longer it takes to measure it. But so therefore, you have to be a bit obsessive about finding those ways to measure real value."
Thomas on the unmeasurability of quality: "There's no AB test that sort of will let you know whether you're building a high quality product, because quality is not measurable."
Michelle on the limits of AI summaries: "There's just something about like a human meeting another human that really develops empathy in a way that reading a summary of calls would never do."
Thomas on the Uber quality collapse: "I opened the app after a long time and I was devastated by all the bugs that I found. I was like, I could spot 10 bugs in 10 seconds. And I just tweeted, frustrated, I tweeted out saying what happened? We used to care about these things."
Tools, practices, and methodologies
Quality Wednesdays (Linear): Weekly ritual where every engineer finds a non-bug defect in the product, fixes it, and presents the fix to the team. Shifts the entire team into constant defect-detection mode. Over 2,500 defects fixed in two years.
Developer flows (Stripe API review): A required section in API design proposals where engineers narrate the user's step-by-step journey: how they get inputs, why they call the API, what happens next. Forces user-centric thinking, surfaces problems early, and serves as a communication medium for reviewers.
Use case compendium (Stripe): A living document of North Star user scenarios for an org. Used to evaluate whether the system maps well to real user needs and to align the team on what success looks like.
Agentic development Slack channel (Flint): A dedicated channel where engineers share learnings about AI products, tools, and techniques. Encourages exposure to external products and builds taste through discussion. Company pays for AI tools to support this exploration.
Customer call recording + auto-summary + Claude triage (Flint): Sales calls are recorded, summaries auto-posted to Slack with bug reports. Engineers can immediately kick off Claude agents to fix bugs. A bug spotted at 8am can be fixed by 11am.
Background Claude code agents (Flint): Engineers run ~4 Claude agents in parallel while working on primary tasks. Small fixes and polish happen continuously throughout the day without dedicated rotation.
Designers shipping code via Claude (Linear, Flint): Designers use Claude to implement their own designs as preview builds or PRs. Non-coding designers now submit 5â6 PRs per week, directly improving UX without consuming engineering bandwidth.
AI-powered customer signal tools (Temporal): Claude-based PM skills that find users who have asked for a specific feature, citing sources from Gong calls, GitHub issues, or Slack threads. Helps product engineers validate ideas and connect with the right users.
Gradient of metrics for goal-setting (Drew's framework): Move teams from vanity metrics (all-time signups) â adoption metrics (MAU) â value metrics (meaningful interactions, counterfactual surveys like "would your company exist without this?"). Goal senior engineers on the hardest-to-measure value metrics to align incentives with real user impact.
Mandatory sales call attendance (Flint): Every engineer attends at least one sales call per week. Builds direct empathy that AI summaries cannot replicate.
Paid work-trial interviews (Linear): Candidates are paid to work on-site for a full week, shipping a greenfield project to production. Reveals whether they have taste, initiative, and the ability to own a feature end-to-end.
Unanswered questions and omissions
How does product engineering scale beyond ~30 people? Linear famously had no PMs until that threshold, but the panel doesn't address the transition: when do you introduce PMs, and how do you prevent product engineers from becoming order-takers or losing ownership?
What's the relationship between product engineers and PMs in an AI-native world? Drew transitioned from engineer to PM, but the panel doesn't explore whether AI is blurring or eliminating the PM role, or how product engineers and PMs should divide responsibilities when both can now do parts of each other's jobs.
How do you balance product-mindedness with deep technical investment? The talk champions user focus, but doesn't address how to prevent neglect of architectural health, technical debt, or infrastructure that has no immediate user-facing impact but is critical long-term.
How do you justify time spent on quality when it's "not measurable"? Thomas argues quality can't be A/B tested quickly, but offers no tactics for defending that investment to data-driven leadership or boards who demand metrics for everything.
What are the failure modes of product engineers? The panel presents product engineering as purely positive. Unmentioned risks: engineers building based on personal taste rather than evidence, bypassing design or PM input, shipping features that don't solve real problems, or becoming attached to their own ideas.
How do you interview for taste at scale? Linear's week-long paid trial is expensive and doesn't scale to all companies. Drew's design problems with user components are mentioned briefly, but there's no detail on evaluating taste in a standard 1-hour interview loop or for non-design roles.
What if an engineer doesn't want to be product-minded? The panel assumes engineers want to develop taste and user empathy. How do you handle strong code-minded engineers who are brilliant but uninterested in customers? Are they a bad fit, or can they be coached?
How do you prevent groupthink in taste? Taste is subjective and culturally shaped. If you hire for shared taste, how do you ensure your product serves diverse users and doesn't become an echo chamber of similar aesthetic and conceptual preferences?
Is AI going to replace the product engineer's product skills? The panel discusses AI as an enhancer, but doesn't grapple with whether AI will eventually generate entire features from user feedback, conduct user research, or make product decisionsâpotentially reducing the need for human product sense.
How do you coach taste remotely? The practices described (Quality Wednesdays, API reviews, site visits) assume some co-located or synchronous interaction. The panel doesn't address how to build these muscles in fully distributed teams.
Speaker A: Well, great to see everyone. Thank you for choosing us over the Gerge session, which, that's an honor. We were worried no one would show up. So. My name's Ma. I lead the product and design teams at statsig. And we have an awesome panel today to talk a little bit about product engineers. How that looks, how you can kind of build that muscle, how you can coach that in your teams, and then some cool stories about how that actually manifests and at different companies. So joining me today are my amazing panelists. So we'll start here. Michelle is the co founder of Flint, an autonomous website platform. She was just telling us about her customers. Websites that just get built overnight by themselves. Very cool stuff. Prior to Flint, she was the founding engineer at warp.dev. and across all these roles in startups, as many of you who are in startups know, when you are the early employee at a startup, you. You end up being the everything engineer, whether that's marketing or product or xyz. And so Michelle, as an early employee kind of built this product engineering muscle and in fact wrote a recent post called stop using front end and back end to describe the engineering you like that apparently went viral in hacker news. So check that out. Next we have Drew, who was such a passionate product engineer that he actually formally transitioned from engineering to production. And so he was a staff engineer at Stripe, jumped to being a staff PM at Temporal. That is a crazy transition. So I'm very curious to hear more about that. But also in the process, he actually wrote the book on the topic we're going to talk about today called the Product Minded Engineer. Then last but not least, we have Thomas, who is co founder and CTO of Linear, the leading issue tracker and management tool for teams. I use Linear. Probably many of our teams are built on Linear. Amazing product. And you know, Linear is famous for hiring pretty much exclusively product engineers and famously did not have any PMs until they grew to over 30 folks. So curious to hear about that culture and how you kind of made that decision early on. Okay, so let's hop in. We have about 30 minutes of moderated discussion and then we will do 15 minutes of audience Q and A. So if you do have questions, tee those up for the end. So we're talking about product engineers today. I think the first question we have to ask is actually what is a product engineer? How do you guys define that? And what does a product engineer do day to day that might look different from a non product engineer?
Speaker B: I can start with a simple explanation. You can build on top of that, to me a product engineer is just an engineer with some PM sprinkled on top of it. An engineer who can sort of not only take a vision and then implement it, but also define that vision, talk to customers, figure out what customers need and then go ahead and build that thing. So a full stack engineer that is even more full stack as in being able to define the thing that should be built.
Speaker C: Yeah. I would just add that a product minded engineer or product engineer cares at least as much about what and why as they care about how. And you can kind of detect it when you're talking to somebody. Like if I was talking to somebody, hey, what have you done in your career? And they started talking about not what they built, but the technologies that they had built it with. And so that's not a product engineer. Right. And so one of the behaviors is just that focus on the user and, and then I think I would just clarify that for me and the product, the concept of a product, like a function is a product, a class is a product, a module is a product, like everything, anything that has an interface that human. I guess humans don't read functions anymore because of AI. But imagine a year ago you might look at a function that's a product because it's got an interface. It's got to be understood, it's got to be used safely, it's got to be discovered. So all these things of connecting the that function with the world, it's essentially a product in miniature. And so what that means is like you don't have to be working on a product, a user facing product to be a product engineer. You can be deep in the infrastructure, but you've still got users and you've still got. Yeah,
Speaker D: yeah. So a product minded engineer is as opposed to a code minded engineer in terms of their motivation. So a product minded engineer is someone who's motivated by the user impact. Like Drew said, when they think of something that they're building, they're thinking about the user, their problems. How are the problem solved? Well, as a code minded engineer tends to be more focused on libraries, the complexity, the elegance of the systems that they get to build. And both types of engineers are talented in their own ways. I find that in a startup it's a lot more beneficial to get more product minded engineers because there are just fewer, fewer roles that you can hire, fewer people in a team. And so the more each person can do everything full stack from defining the problem to solving it and then testing it out in the wild, that is the better for a startup, so maybe
Speaker A: it's making a jump. But I assume that all three of you are product minded engineers. So I'm curious, how did you get your start in this role? Was it just innate? Do you think this is truly something that you just either are or aren't, it's very binary. Or do you think this is a skill set that can kind of be taught and coached over time?
Speaker C: I'll start here. When I came out of college I was like hardcore and I loved algorithm. I wanted to do algorithms and data structures because that's what I knew as an undergrad. And I joined a compiler team at Microsoft. And so I was reading assembly diffs and doing back end optimizations and stuff and was not producty even a little bit, right. And the thing that switched me was my team started building a framework for building compilers. So like, you know, it had abstractions like functions and instructions and operands and types and symbols and all these things and you could, you could create compilers with it and had a terrible API. And the chief architect's vision for this, this framework was the assembly language for building compilers. And I just thought, who wants to program an assembly language like nobody. And then I started noticing the C Sharp community was really into getting into usability. How do we build functional APIs that developers can actually understand? They started having design standards and naming standards and things to just don't abbreviate simple things. Then we're putting a lot of thought into their APIs because they were trying to compete with Java and so they had to do something that was easier to use than Java. And that was when I was like, whoa, developers are people too. We're building products for developers. And that was my pill was just getting into API design and then that just sort of blossomed over time into a more general interest in product.
Speaker D: In college I had really big crisis of figuring out what I wanted to do. So I did an internship at Slack where it was a front end engineering internship, but all I was given are figma files to implement. And so I didn't feel like I was using my computer science degree to use data structures or algorithms at all. And then I ended up working more of a backend engineering job at Robinhood and I didn't see any users at all. I was migrating presto Ql and all I saw was SQL and data roles and latency. So that made me think like, oh, if I didn't enjoy front end engineering or back end engineering, maybe I should just become a pm because I'M sure a PM gets to talk to the users and they get to solve problems and see the benefit of the work that they're doing. And then I realized that actually it's because I've been using like the industry had been using front end and back end engineering, and it ended up putting people in the wrong professions. Instead, you should be thinking about product engineering versus code engineering or infra engineering. And as soon as I found that distinction, I realized that as a product engineer, I would be able to understand the customer problem and then solve it, no matter if it's front end or back end. I ended up joining Warp, which at the time was trying to build a modern version of the terminal. I met the founder, he showed me a slide deck. I thought it was really cool to improve the terminal. I joined as his first Engineer back in 2020, and I was able to come up with ideas for how I can improve the CLI and then also build it and then test it and then see users use it. And that's when I realized that, oh, I am definitely a product engineer. I was just in the wrong internships.
Speaker B: Yeah, I started my career ages ago, like 30 years ago, doing CD Rom multimedia presentations before the Internet was a thing. And it was all about visualizations and great UI and presenting some problem in a visual manner. And then I do a lot of Flash and campaigns, animations and all that stuff that is sort of very intriguing. User interfaces. So I've always done that. Then I've done mobile development and infrastructure and literally everything in between. And I've noticed that I do like very complex technical challenges, but it's not because of the complexity, but because I can use it to actually make the user experience better. So, for example, at linr, I wrote the sync engine for the fourth time. And I didn't do it because I wanted to do sync, but I did it because I wanted the user to have a great experience. So I'm sort of, I guess, more geared towards the implementation quality side of a product engineer and not so much on the customer side. But I like to sort of toy around with user experiences and interfaces.
Speaker A: So let's actually double click on that implementation side of product engineering. A big part of this is probably this concept of taste, which is also hotly contested in an AI world where you're kind of having to prompt taste to a coding assistant in some sense. How would you define taste and how do you think that is? How core is that to being a good product engineer versus something that you, you know, can kind of build that muscle for over time by just talking to customers or kind of being in the weeds on the end to end.
Speaker B: I think it's super important, like, at least you know, from linear side. Like when we started linear, we came into a space that was fully occupied. Like, there's so many incumbent solutions for project management. So we had to figure out, like, what is our entry into the space and how can we win in the space? And we came up with this. In hindsight, it's ridiculously simple. It's literally just like our strategy is one word, and that word is quality. We wanted to build a product that was not two times better, but ten times better than any incumbent solution. And we started with building for ICs because we felt that that was sort of the underserved market. We had heard that ICs weren't happy with any of the project management solutions out there. So we started working on that and we said we want to hire people who have the same sort of taste in quality as we do. And maybe that's two things. There's conceptual quality of figuring out what needs to be built, what should be built, how a problem can be solved the best, and there's the implementation quality. Once you've defined what you want to build, how best can you create a user experience around that? That's what we started hiring for. We wanted to get people that had a similar tasting quality and design that we had and have just have a go at it.
Speaker A: Can I double click on that? How do you actually interview for taste?
Speaker B: We do an interview process that is pretty long. It's a full week. So we work together. We pay for our candidates to come in and actually ship something, or hopefully ship something. In the early days, they actually would ship something. They would work for a week on a greenfield project, and then by the end of the week, we would ship it into production. And that's how we knew whether they had good taste, because they would have to take the initiative in building the functionality and the feature out. And yeah, we still do that today. The product is a bit more complicated, so people don't ship that often, but it still happens someday.
Speaker A: That's really cool.
Speaker C: I'll go next. Yeah, I like thinking of taste in terms of it sounds like this mystical thing that some people have and other people don't have. And so that's, to me, something that I would want to debunk that I think it can be learned. And it's a skill. It's like a craft. It's a craft. And the elements of that craft are being able to shift to shoe shift, to put yourself in your user's shoes. Selectively forget what do you know and just think about how the user's going to experience your product and discover your product, understand your product and then use your product safely. And being able to simulate those interactions almost like playing chess and being able to see a few moves ahead. It's like going through the users, how they're going to interact with your product, what they're going to be confused about. And of course you don't just have that all at once, you have to develop that skill. And that comes from both talking to users, pushing yourself to tell bigger stories about the user experience with your product. And as far as how to interview for design taste, I ask, I squeeze it into my traditional design problems that I give. So I always want to make sure that there's a user component to whatever they're designing. And the design decisions that they're going to make are going to depend on how they conceptualize what the users need and what the users motivations are. And hopefully they bring it up or if they don't bring it up, then at staff levels they just kind of can figure it out. And then at senior levels maybe they need a little prompting to figure it out to think about the user and then you can help coach them through that a little bit. And so one of the anti patterns I see is people who when you're interviewing them, they fall back on existing knowledge rather than thinking through this new thing they're being given from first principles and understanding. Like okay, yes, I've seen something like this before, but this is a little bit unique. I need to adapt my product to this new circumstance because every, every product has to be unique because otherwise it's going to fail in the market. Right, it has to be. And so you want to make sure to give a question that's not just do this thing that a hundred, that a thousand people have done before, but actually like give it a twist and then make sure that they can adapt their simulation skills to a new situation.
Speaker D: Yeah, taste is extremely important. It is the way you differentiate your product in very crowded spaces today, like we're building autonomous websites for our customers, like cognition. It is very important that we stand out against a lot of other co generation tools. And it's very important for our customer to have really beautiful websites that they can use to sell to their customers. So cognition, for example, uses to sell to a lot of enterprises. And so it's very important that the websites they use Aren't these like purple websites with the purple gradient and the rounded corners that are very common amongst model generated content. So if our engineers don't have taste, then the product of what they're building would be creating things that don't have taste either, which would be bad for our end business impact. I think that taste has those two elements to me to be able to, I mean two ways to train it. So one I think we haven't quite mentioned yet is exposure. So it's very important to us that our engineers are spending a lot of time trying out different products. When I'm thinking like different products, it's not just like the software products like using linear all the time and learning all these amazing things that linear does, but it's also trying out really cool physical products, like looking at a MacBook and seeing how beautiful it's packaged or even thinking about restaurant experiences. What makes it amazing for me personally, I watch a movie every week and I'm able to, because I'm able to see a lot of different examples of good film, I'm able to see the nuances in what's good taste and what's bad taste. So very important for managers and I think leads to the next question to ensure that folks have enough time to spend time not just building their own product, but also being exposed to how other kinds of products work. Then the second element of taste is about building something that customers love. And it's very important to talk to customers in order to figure out what customers love.
Speaker A: So you did anticipate my next question, which is around the coaching the management. A lot of folks in the audience are on the management side and have teams. How can you create rituals or best practices or exposure with your teams to build this product engineering muscle and almost train a collective sense of taste?
Speaker D: Yeah. So I think first one is to hire people who have taste. And we've touched on it as well because it really infects everyone around you. Our designer was the head of design at Netflix and every time we come up with an idea that maybe it's a short term incremental improvement, she's like, no, how do we make this magic? Can we push the boundary? Do we really want to have this same feature that all of the other tools have? So if you have someone who's always pushing the bar for magic, it would infect everyone around you. I think the second one in terms of how our company works is that we have this Slack channel called agentic development and people are just encouraged to share what they're learning about the world, different AI products, different AI engineering techniques, and then putting in the channel. And we are encouraging people to talk a lot about it. Sometimes people might spend like an hour or two discussing other people's products or agentic development. And we think that that is very good. And we are not cheap when it comes to helping our engineers pay for the tools. It's okay to spend some money on AI tools if it means you can learn something new.
Speaker C: So I've never been a manager and I probably never will be, but I was on API review at Stripe for a number of years. And so what that was was like a sort of a centralized body of people who would buddy up with different teams who were building new products. And then we review their APIs. And of course we checked for things like consistency. But one of the things that I added to the process was like a developer flows section of the template. And it basically asked people who are submitting API designs to take me through a journey of what is the developer doing with this API step by step, how are they getting the inputs to it? And then why are they calling it and then calling it and then just showing kind of a sketch of how that story would progress. And that did two things. One, it got engineers thinking in terms of their users and how they'd experience it. And a lot of engineers weren't really good at writing developer flows like it's a skill that you have to learn. And so we would help them kind of make bushier and bushier stories. And then the second thing is it helped us understand what they were doing because we weren't working on their product, but we were being asked to review code from different organizations. And so these stories became a medium of communication where they could quickly brain dump us on what they were doing and then we could do a good job of reviewing it. But. And a lot of times what happened is actually as they wrote the stories, they figured out the problems themselves and then they didn't have to talk to us. And then. And so I do think that stories are a great sort of medium of communication. Michelle Boo, who's like a principal engineer at Stripe and works on the APIs, built a use case compendium for her org, which was like the North Star scenarios of like, here are the scenarios we're going after and these are the scenarios that like, we're going to evaluate the success of our product by how well we like map our system to these scenarios. And it sort of just grew over time. And so again, it's just sort of a shared communication medium for people to align everybody and get everybody thinking about their users.
Speaker B: We have this thing called some quality Wednesdays that we do, and maybe that's, again, on the sort of, you know, implementation quality side of things. It all started when sort of, I got frustrated maybe three years ago because we have this thing with highlights in the application. Like, when you hover over something, it highlights instantly. And when you hover out, there needs to be a fade out of 150 milliseconds. Exactly. Because that's how I defined it. And that's, you know, it works nicely and it feels good. And after the 10th time I fixed one of these highlights not fading out, I was like, I got to teach the team to sort of see these mistakes, because if you don't know what you're looking for, like, you will just simply miss it, and you won't even know that you made a mistake. So we did this thing where I selected a few places in the application where I saw a few problems, very small ones, and off site, we went through with a team, and I just asked them to just focus on this portion of the app and then come up with fixes, come up with all small kinds of defects that we had. And to my surprise, people found many more bugs, or not bugs, but defects, than I had anticipated. Like, I had, like, maybe seen four. And we got, you know, 20 out of a very small piece of the application. And that led to the next idea, which is the quality Wednesday part, which is like, well, you know, if collectively we find all these defects in the application, maybe we need to do it, you know, every single week. So we started doing this where every single engineer is expected to just find a new defect in the application, which is separate from a bug. Bugs we fix immediately, but a defect where some misalignment is there or a highlight is missing or doesn't look right, and then fix it and present it to everybody else. And we started doing that two years ago. We fixed probably, like, 2,500 defects. And I would be horrified to sort of see the application how it would feel like if you hadn't done all those fixes. But more importantly, it sort of sets this precedent off. You're always on the lookout for your next fix. Like, you're always looking at the product of like, oh, is it broken? Where is it broken? Because I need to find my next fix for next Wednesday. So it sets your mind up into sort of this buck finding mode or defect finding mode, and that helps you become a better product engineer.
Speaker A: I Love that. I think it's good to present it too, and celebrate it and kind of give it some visibility.
Speaker B: Teach everybody, because you will find things that others haven't found.
Speaker A: Yeah, no, that's great. That's great. Switching gears slightly. So this can't be a conversation in 2026 without talking about AI, obviously. How have kind of the new tools changed the workflow of a product engineer and made it easier to be a product engineer, or just kind of made that whole workflow look different in your eyes? And how have your personal workflows changed?
Speaker D: Yeah. So talking about bug Wednesdays, we had this thing at Warp called Product Quality Rotation. So every week there will be one engineer who's in charge of fixing all of the polish issues and bug issues. And as a result, Warp is a very fun to use product. But what I found is different now is that in 2026, you no longer need to wait for a week and get one person to synchronously work on this work stream. Each of the engineers at Flint right now typically has around four cloud code agents running at any time. So during standup they would say, my primary task for today is xyz, and in the background I'm running abc. And what this means is that a lot of small fixes to the product actually gets fixed throughout the day by everybody. And then the other thing that I tend to do myself and within my team is that I often would have sales calls between 8am and 7. So I would have the sales call recordings automatically post into the Slack channel, including any bugs that people that I found during customer calls. Typically, my engineers would then look through the summary and then automatically kick off Claude to start fixing some of the bugs. It's really incredible because sometimes I would see a bug happen at 8am and then by 11am it's already fixed. So use a lot of call recording software, use a lot of summary software, use Claude and also add Linear within Slack, because some bugs are just like a lot bigger than something that Claude could just solve immediately. So when I see that there's more of like an architectural issue that we need to fix, I will add linear, make a ticket, and then we'll prioritize the next week.
Speaker C: Yeah, I mean, obviously the feedback loop is getting much shorter, which makes it. It's much more fun to iterate. If you know that it's going to take you six months to fix any bug that a user is going to report, then why would you bother even talking to users? And so that instant gratification of being able to fix a bug so quickly is great. And in addition, I think the AIs are starting to help with actual product skills as well. So my product team at Temporal, we have a bunch of clawed PM skills like competitive analysis or maybe a big one for product engineers would be customer signal. Like hey, I have this idea to build such and such a feature. Find me users who would actually have asked for that or something similar or would be people that I should reach out to. And then it can just list, you know, the slack for them and the, or the email and then like you know, site from the gong call or the GitHub issue or the slack channel support interaction and just. Yeah, so tools on the like that connect people to users. I was recently the car company for the car I drive. They, they set up an email address that people can just complain to that email address about their cars and then they have an AI kind of like sift through all the emails that are coming in because obviously it wouldn't scale. But now like we have ways to actually scale our interactions with customers and not have it feel like an overwhelming amount of noise. Especially if you're in a like consumer, if you're on a consumer product, but even if you're on a business product as well. And so the signal to noise, the denoising of the user impact input I think is really going to help product engineers be motivated to go more in that direction rather than recoil in horror when they think about their users.
Speaker B: Yeah, definitely. Like all of these things that were said before, but additionally, maybe the one thing that I think has changed radically is the fact that you can just try out things without really any effort. Like there might have been cases before where you get some design that looks super complicated and you have a hunch that it might not work, but maybe it does. Maybe it feels good if you implement it, but the implementation would take a week. You wouldn't really even try. Like you would ask the designer to make some changes or reconfigure it, but now you can actually just give it a try and see how it actually works in production. And it's not only for product engineers, it's designers as well. Like we do have multiple designers who, you know, take their designs to the next level where they're like, oh, I want to try it on the product and they just spin up Claude and you know, have it, have it implement the designs that they do and then ship it in. Not ship in production, but as a preview build so that they can actually, you know, use their designs that they have. And that's a, that's a huge, you know, benefit for any engineer and designer
Speaker D: that's happening at our company as well. So our designer is like formerly head of design at Netflix, has like a career of 12 years never coded in her life. And it used to be that a designer will look at all these borders that are not perfect or the grays that are a little bit off or like hard to find features, bad information architecture, and then she'll maybe form a few tickets for the engineering staff to take over at some point. She's writing so many PRs now, maybe five to six a week. And the UX of the product just keeps getting better and better every week. Because now you're no longer just having like pure engineers writing code.
Speaker A: We've noticed that too. I think probably like Q3 of last year, I got a freaked out call from our head of engineering being like, Your designers and PMs are shipping code. And I was like, that's great. And now it's like, oh, the designers and PMs are shipping code. This is awesome. Like the product's just automatically getting better as a result. It's just cool to see how that attitude has evolved and in real time. Okay, so in the last kind of two minutes, just any parting wisdom for this group, either from a IC perspective of how to become a better product engineer or how to coach better kind of product engineering instincts amongst your teams. And then we'll go over to audience
Speaker D: Q and A. Yeah, I think that there's no substitute for talking to customers directly. You should totally use AI summarization tools. But there's just something about like a human meeting another human that really develops empathy in a way that reading a summary of calls would never do. So it is important to me to bring my engineers to customer site visits and then I also make sure that every engineer attends at least one sales call with me every week.
Speaker C: As a leader, I would, again with the caveat that I haven't. But as a tech lead, I typically, my advice would be to run the gradient from vanity metrics to adoption metrics to like metrics that really capture like the value that users are getting out of it. And then goal your engineers on those metrics. You know, just to take an example of a social network, you've got your vanity metric, which is like all time signups. It's like, well, MySpace is like huge on this metric, right? And then you like align it a little bit more. You make, okay, maybe it's a monthly active user and that user is coming back, which is some indication that they're getting value from the product, right? But maybe they're just addicted or maybe it's not really giving them value. And so then you think, okay, well, maybe time spent. Like, how much time is this user spending? And so that obviously they wouldn't come back if they weren't spending more time. Okay, well, but what if again, what if they're just reading, watching AI slop? Or what if they're addicted? So then you start looking at meaningful interactions, like choices that they're making, comments and likes, posts like connecting with friends, things that are like, you have decided quantitatively are more meaningful. Or even better, you survey users and you ask them maybe counterfactual questions, like, how much money would you have to be paid to not use this, the social network? Or how at Stripe, there was a question that we asked users, would your company exist without Stripe? And the answer a few years ago was surprisingly often, no. We couldn't have bootstrapped our company without this product. That's a real indication of value. But the problem is, of course, the further you get along that gradient, the harder it is to measure and the longer it takes to measure it. But so therefore, you have to be a bit obsessive about finding those ways to measure real value and then like tying it to the performance reviews of your especially your more senior engineers.
Speaker B: Maybe some otherwise to the ems, like, give your engineers time to create a high quality product. It sounds simple and stupid, but there's no AB test that sort of will let you know whether you're building a high quality product, because quality is not measurable. Sort of quickly, like, if you don't think about quality, your product will degrade over time. So a year later, maybe you will have a lower quality product and your users will abandon you for somebody else if you don't do that. And I can assure you that engineers will want to take that time because they want to be proud in their work. They want to make sure that they have enough time to sort of ship something that they can be proud of. I had this thing at Uber. I used to be at Uber, a mobile engineer. And a few years ago, I opened the app after a long time and I was devastated by all the bugs that I found. I was like, I could spot 10 bugs in 10 seconds. And I just tweeted, frustrated, I tweeted out saying what happened? We used to care about these things. And that created a stir at Uber and they had a code yellow and they started fixing bugs and engineers started tweeting back, DMing me back, saying, thank you, thank you for raising this from the outside and having our managers give us the time to fix these bugs.