Product-Minded Engineers in an AI-Native World: Taste, Quality Rituals, and Shorter Feedback Loops
The Pragmatic Engineer
This panel at The Pragmatic Summit asked what separates a product engineer from other engineers, whether that instinct can be taught, and how AI tools are changing the work. The moderator leads product and design at Statsig. The panelists were:
- Michelle Lim, cofounder of Flint, an autonomous website platform, and previously the founding engineer at Warp.
- Drew Hoskins, who moved from staff engineer at Stripe to staff PM at Temporal and wrote The Product-Minded Engineer.
- Tuomas Artman, cofounder and CTO of Linear. The moderator noted that Linear hires almost exclusively product engineers and had no PMs until it passed roughly 30 people.
All three agreed that product-mindedness is mostly a learnable orientation toward users, not an innate trait. They also agreed that it depends on deliberate habits: exposure to good products, direct customer contact, and protected time for quality.
Defining the product engineer
Tuomas gave the simplest definition: a product engineer is "an engineer with some PM sprinkled on top." Such an engineer can implement a vision and also define it. They talk to customers, work out what those customers need, and then build it. Tuomas described this as a full-stack engineer who is "even more full stack," because the stack reaches up into deciding what should be built.
Drew framed it through priorities. A product-minded engineer cares at least as much about what and why as about how. He said you can often tell in conversation. If you ask someone about their career and they describe the technologies they used rather than the things they built, that signals a different orientation.
Drew also widened the idea of a "product." He argued that a function, a class, or a module is a product in miniature. Anything with an interface has to be understood, discovered, and used safely. He joked that humans may no longer read functions because of AI, but said the point held a year ago. His conclusion was that you don't need to work on a user-facing product to be a product engineer. Infrastructure engineers have users too.
Michelle set the product-minded engineer against what she called the "code-minded" engineer. The difference, in her view, is motivation. Product-minded engineers are driven by user impact and think first about users and their problems. Code-minded engineers are drawn to libraries, complexity, and the elegance of systems. She said both kinds are talented. In a startup, though, she finds product-minded engineers more valuable: there are fewer people and fewer roles, so each person benefits from covering the whole arc from defining a problem to testing the solution in the wild.
How each panelist found their way into product work
The moderator asked whether this orientation is innate or can be coached. Each panelist answered with their own path.
Drew said he left college as a "hardcore" algorithms and data structures enthusiast. He joined a compiler team at Microsoft, where he read assembly diffs and worked on back-end optimizations, work that was "not producty even a little bit." The shift came when his team built a framework for constructing compilers, with abstractions such as functions, instructions, operands, types, and symbols. The chief architect described it as "the assembly language for building compilers," and it had a terrible API. Drew's reaction was that nobody wants to program in assembly language. Around the same time, he watched the C# community invest heavily in usability and design standards, such as not abbreviating simple names, partly because C# had to compete with Java by being easier to use. That was his realization that "developers are people too." API design became his entry point, and it grew into a broader interest in product.
Michelle described a real crisis in college about what to do. At a front-end internship at Slack she was handed Figma files to implement, and she felt she wasn't using her computer science background. At Robinhood she did back-end work migrating Presto SQL and saw only SQL, data rows, and latency, with no users. Having disliked both front end and back end, she assumed she should become a PM, since PMs get to talk to users and see the benefit of their work. She later concluded that the industry's front-end/back-end framing had pushed her, and others, into the wrong roles. The more useful split was product engineering versus code or infrastructure engineering. She joined Warp in 2020 as the founder's first engineer, attracted by the idea of modernizing the terminal. There she could come up with ideas for improving the CLI, build them, test them, and watch users adopt them. "I'm definitely a product engineer," she said. "I was just in the wrong internships." Her later post arguing against "front end" and "back end" as labels reportedly went viral on Hacker News.
Tuomas started about 30 years ago making CD-ROM multimedia presentations, before the internet was widespread. That was followed by Flash work, campaigns, and animation-heavy interfaces, then mobile development, infrastructure, and "literally everything in between." He likes hard technical problems, but not for their own sake. He takes them on because they improve the user experience. His example: at Linear he wrote the sync engine for the fourth time, not out of love for sync but because he wanted users to have a great experience. He placed himself on the "implementation quality" side of product engineering rather than the customer-research side.
Taste as strategy: Linear's bet on quality
The moderator turned to taste, which is now contested because engineers increasingly have to prompt it into coding assistants.
Tuomas called taste "super important" and tied it to Linear's founding strategy. Linear entered a crowded project-management market and needed a way to win. In hindsight, he said, the strategy was "ridiculously simple": one word, quality. The goal was a product not two times but ten times better than incumbents. Linear started by building for individual contributors, whom the founders believed were underserved and unhappy with existing tools.
He split quality into two parts. Conceptual quality means figuring out what should be built and how a problem is best solved. Implementation quality means, once that is defined, crafting the best possible experience around it. Linear hired for people whose taste in quality and design matched the founders'.
To interview for taste, Linear runs a full-week process. The company pays candidates to come in and try to ship something. In the early days candidates worked on a greenfield project for a week, and the result went to production by the end. That showed whether they had good taste, because they had to take initiative in shaping the feature. Tuomas said Linear still does this, although the product is now more complex, so candidates ship less often. It still happens sometimes.
Taste as a learnable craft
Drew pushed back on the idea of taste as something mystical that some people have and others lack. He called it a skill and a craft. Its core, in his description, is the ability to put yourself in the user's shoes and selectively forget what you know, so you can think about how the user will discover, understand, and safely use the product. He compared it to chess: you simulate the user's interactions a few moves ahead and anticipate where they will get confused. The skill develops through talking to users and pushing yourself to tell bigger, fuller stories about the user experience.
In interviews, Drew folds taste into standard design problems. He makes sure every problem has a user component, so the design decisions depend on how the candidate understands the user's needs and motivations. He expects staff-level candidates to raise the user on their own. Senior candidates may need some prompting, and he coaches them through it. The anti-pattern he watches for is falling back on existing knowledge instead of reasoning from first principles. Every product has to be distinctive to succeed, he argued, so he adds a twist to the problem. That way it isn't something a thousand people have done before, and he can see whether candidates adapt their "simulation skills" to a new situation.
Michelle tied taste to differentiation in a crowded market. Flint builds autonomous websites for customers such as Cognition, which uses its site to sell to enterprises. Flint competes against many code-generation tools, and its customers need sites that don't look like typical model output: "purple websites with the purple gradient and the rounded corners." If her engineers lack taste, she said, the product will produce tasteless output, which hurts the business outcome.
She named two ways to train taste. The first is exposure. Flint wants engineers to spend real time trying other products. That includes software like Linear, but also physical products, such as noticing how beautifully a MacBook is packaged, and experiences like what makes a restaurant visit great. She personally watches a movie every week, and says seeing many examples of good film helps her see the nuances between good and bad taste. She argued that managers need to give people time for this exposure, not only for building their own product. The second way is talking to customers to learn what they actually love.
Building the muscle on a team
The moderator asked what managers can do to develop a shared sense of taste and product instinct.
Michelle said the first step is hiring people with taste, because it "infects everyone around you." Flint's designer was formerly head of design at Netflix. When the team proposes a short-term incremental improvement, she pushes back and asks how to make it magic, whether they can push the boundary, and whether they really want the same feature every other tool has. Flint also runs a Slack channel called "agentic development," where people share what they learn about AI products and AI engineering techniques. Discussions there sometimes run an hour or two, which the company considers time well spent. Michelle said Flint is "not cheap" about paying for tools: spending money on AI tools is fine if someone learns something new.
Drew noted that he has never been a manager and probably never will be. He drew instead on his years on Stripe's API review, a central group that buddied up with teams building new products and reviewed their APIs. Beyond checking consistency, he added a "developer flows" section to the review template. Submitters had to walk reviewers step by step through what a developer does with the API: where the inputs come from, why the developer calls it, and how the story unfolds. Drew said this had two effects. It got engineers thinking about their users, since many weren't good at writing these flows at first and had to be coached toward "bushier and bushier stories." It also helped reviewers, who weren't on those teams, quickly understand what was being built. Often, he said, teams found their own problems while writing the stories and didn't need to talk to the reviewers at all. He also mentioned Michelle Bu, a principal engineer at Stripe who works on the APIs. She built a "use case compendium" for her organization: a set of North Star scenarios the team would use to judge its product's success. It grew over time into a shared artifact that kept everyone aligned on users.
Linear's Quality Wednesdays
Tuomas described Linear's "Quality Wednesdays," which he placed on the implementation-quality side. It started about three years ago from frustration. In Linear, hovering over an element highlights it instantly, and moving away should trigger a fade-out of exactly 150 milliseconds. That is how the team defined it, and it feels right. After fixing broken fade-outs for about the tenth time, he decided the team had to learn to see these mistakes. If you don't know what to look for, he said, you miss it entirely and never realize you made an error.
At an offsite, he chose a few areas of the app where he had spotted small problems and asked the team to focus on just those areas and find and fix defects. He had seen maybe four. The team found about 20 in a very small part of the application. That led to the weekly practice, which Linear has run for about two years. Every engineer is expected to find a new defect, fix it, and present it to everyone. Tuomas distinguished defects from bugs. Bugs are fixed immediately. Defects are things like a misalignment or a highlight that is missing or looks wrong.
By his estimate, the team has fixed about 2,500 defects this way, and he said he would be "horrified" to see the product without those fixes. He considers the mindset the bigger benefit. Because engineers need a fix for next Wednesday, they are always scanning the product for what's broken. That keeps them in a defect-finding mode, which he believes makes them better product engineers. The moderator added that presenting the fixes gives them visibility and celebration. Tuomas added that it teaches everyone, because people find things others haven't.
How AI is changing the workflow
On AI, Michelle contrasted Warp and Flint. At Warp there was a weekly "product quality rotation," in which one engineer handled polish and bug issues for the week. She credits it with making Warp fun to use. In 2026, she said, you no longer need to wait for one person to work through that queue synchronously. Each engineer at Flint typically runs around four Claude Code agents at once. At stand-up, people say what their primary task is and what they're running in the background. As a result, small product fixes happen throughout the day across the whole team.
She also described her own pipeline from customer calls. She often has sales calls from 8 a.m. to 7 p.m. Recordings and summaries, including any bugs that came up on the calls, post automatically to a Slack channel. Her engineers review the summaries and kick off Claude to fix the bugs. She said she has seen a bug surface at 8 a.m. and get fixed by 11 a.m. When an issue is architectural and too big for Claude to handle directly, she tags Linear in Slack to create a ticket, and the team prioritizes it the following week.
Drew emphasized the shorter feedback loop and the motivation that comes with it. If fixing any user-reported bug takes six months, he asked, why would you bother talking to users? Near-instant fixes make iteration fun. He also said AI is starting to help with product skills. His product team at Temporal uses a set of Claude PM skills, including competitive analysis and "customer signal." That skill takes a feature idea and finds users who asked for it or something similar, with citations to Gong calls, GitHub issues, Slack channels, emails, or support interactions, and suggests who to contact.
He gave a consumer example. The company that makes his car set up an email address where owners can complain, and it uses AI to sift through the incoming messages, since reading them all by hand wouldn't scale. He argued that denoising user input this way will draw more engineers toward product work, instead of making them "recoil in horror" at the thought of their users. He said this applies to business products as well as consumer ones.
Tuomas said the biggest change for him is that trying things now costs almost nothing. In the past, a designer might hand over a complicated design that an engineer suspected wouldn't work. If testing that hunch meant a week of implementation, nobody would try; the engineer would ask for design changes instead. Now you can just build it and see how it behaves. He said this applies to designers too. Several Linear designers spin up Claude to implement their own designs as preview builds, not production releases, so they can use what they designed.
Michelle said the same is happening at Flint. The designer who formerly led design at Netflix has a 12-year career and had never coded. She used to file tickets about imperfect borders, slightly-off grays, hard-to-find features, and weak information architecture for engineers to handle eventually. Now she writes five to six PRs a week, and Michelle said the UX keeps improving every week because engineers are no longer the only ones writing code. The moderator described a similar shift at Statsig. Around Q3 of the previous year, the head of engineering called in alarm: "Your designers and PMs are shipping code." The moderator's answer was that this was great, and the moderator said the attitude has since changed to seeing it as a positive that makes the product better on its own.
Parting advice: customers, metrics, and time for quality
In closing, each panelist offered one piece of advice.
Michelle said nothing replaces talking to customers directly. Use AI summarization, she said, but a human meeting another human builds empathy in a way that reading a call summary never will. She brings engineers on customer site visits and makes sure every engineer attends at least one sales call with her each week.
Drew, speaking from his experience as a tech lead rather than a manager, advised moving along a "gradient" from vanity metrics, through adoption metrics, to metrics that capture real user value, and setting engineers' goals on those. He used a social network as an example:
- All-time sign-ups is a vanity metric, one on which MySpace looks huge.
- Monthly active users suggests people get value, but they might just be addicted.
- Time spent has the same problem, since people might be "watching AI slop."
- Meaningful interactions, such as comments, posts, and connecting with friends, get closer to value.
- Counterfactual surveys go further still. One example: how much would you have to be paid to stop using this network? At Stripe, users were asked whether their company would exist without Stripe. A few years ago, Drew said, the answer was surprisingly often no, which he called a real sign of value.
The catch is that the further along the gradient you go, the harder and slower the measurement becomes. So teams have to be somewhat obsessive about finding ways to measure real value and then tie it to performance reviews, especially for senior engineers.
Tuomas addressed engineering managers directly: give engineers time to build a high-quality product. It sounds "simple and stupid," he said, but no A/B test will tell you whether you're building a quality product, because quality can't be measured quickly. If you ignore it, the product degrades, and a year later you may have a worse product and lose users to a competitor who didn't neglect it. He said engineers want that time because they want to be proud of their work.
He closed with a story from Uber, where he had been a mobile engineer. Opening the app after a long break some years ago, he was "devastated" to find about ten bugs in ten seconds. He tweeted in frustration, asking what had happened and why people had stopped caring. According to Tuomas, the tweet caused a stir inside Uber, the company declared a code yellow and started fixing bugs, and engineers messaged him to thank him for raising it from the outside, which led their managers to give them time to fix the problems.
Well, great to see everyone. Thank you for choosing us over the Gerga session, which that's an honor. We were already knowing when 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 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're the early employee at a startup, you end up being the everything engineer, whether that's marketing or product or, you know, XYZ. And so, Michelle, as, you know, 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 on 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 product. 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.
And then last but not least, we have Tuomas, 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 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&A. So, if you do have questions, queue those up for the end.
So, we're talking about product engineers today. I think the first question we have to ask is actually, you know, 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?
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 PMs sprinkled on top of it. An engineer who can 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, you know, a full stack engineer that is even more full stack as in being able to define the thing that should be built.
Yeah, I would just add that a product-minded engineer or a 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 then I think I would just clarify that for me the concept of a product, like a function is a product, a class is a product, a module is a product. Anything that has an interface that humans... 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, right? 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 that function with the world is essentially a product in miniature. And so, what that means is you don't have to be working on a user-facing product to be a product engineer. You can be deep in the infrastructure, but you still got users and you still got... yeah.
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 else problems solved. Whereas 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 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, the better for a startup.
So, maybe 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?
I'll start here. When I came out of college, I was hardcore and I wanted to do algorithms and data structures because, you know, that's what I knew as an undergrad. And I went and I joined a compiler team at Microsoft and so I was, you know, reading assembly diffs and doing back-end optimizations and stuff. And it 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, you know, it had abstractions like functions and instructions and operands and types and symbols and all these things and you could create compilers with it. And it had a terrible API and the chief architect's vision for this framework was the assembly language for building compilers.
And I just thought, who wants to program in assembly language, you know? Nobody. And then I started noticing the C# community was really into getting into usability and how do we build functional APIs that developers can actually understand? They started having design standards and naming standards and things to just, like, don't abbreviate, you know, simple things. And they were 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, wow, you know, developers are people too. We're building products for developers, and that was my pill, just getting into API design. And then that just sort of blossomed over time into a more general interest in product.
In college I had a 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 was 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 back-end engineering job at Robinhood and I didn't see any users at all. I was migrating PrestoSQL and all I saw was SQL and data rows and latency. So that made me think, oh, if I didn't enjoy front-end engineering or back-end engineering, maybe I should just become a PM. Because I'm sure the 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 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'm definitely a product engineer. I was just in the wrong internships.
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 did a lot of Flash and campaigns, so animations and all that stuff that is 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 Linear 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 guess I'm more geared towards the implementation quality side of a product engineer and not so much on the customer side, but I like to toy around with user experiences and interfaces.
So, let's actually double click on that kind of 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 core is that to being a good product engineer versus something that you 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?
I think it's super important. At least from Linear's side, when we started Linear, we came into a space that was fully occupied. There's so many incumbent solutions for project management. So we had to figure out 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. Our strategy is literally one word and that word is quality. We wanted to build a product that was not two times better, but 10 times better than any incumbent solution. And we started with building for ICs, because we felt that that was sort of the under-served 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, you know, 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 then there's the implementation quality. Once you've defined what you want to build, how best can you create a user experience around that? And that's what we started hiring for. We wanted to get people that had a similar taste in quality and design that we had, and just have a go at it.
Can I double click on that? How do you actually interview for taste?
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.
That's really cool. Okay, 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 something that I would want to debunk. I think it can be learned and it's a skill. It's like a craft. And the elements of that craft are being able to put yourself in your user's shoes, selectively forget what you know, and just think about how the user is 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, right? It's almost like playing chess and being able to see a few moves ahead. It's going through how the user is 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 and pushing yourself to tell bigger stories about the user experience with your product.
And as far as how to interview for design taste, 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 user's need is and what the user's motivations are. And hopefully they bring it up, or if they don't bring it up, then, you know, at staff levels, they just kind of can figure it out. And then at senior levels, maybe they need a little prompting 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, fall back on existing knowledge, rather than thinking through this new thing they're being given from first principles and understanding, 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 product has to be unique, because otherwise it's going to fail in the market, right? And so you want to make sure to give a question that's not just do this thing that a thousand people have done before, but actually give it a twist and then make sure that they can adapt their simulation skills to a new situation.
Yeah, taste is extremely important. It is the way you differentiate your product in very crowded spaces today. We're building autonomous websites for our customers like Cognition. It is very important that we stand out against a lot of other code generation tools. And it's very important for our customers to have really beautiful websites that they can use to sell to their customers. So Cognition, for example, uses it 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 among, you know, model generated content. So if our engineers don't have taste, then the product of what they're building will be creating things that don't have taste either, which would be bad for our end business impact.
So 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. So 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 beautifully it's packaged, or even thinking about restaurant experiences, you know, what makes it amazing.
For me personally, I watch a movie every week, and 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 it's very important for managers, and I think this is the next question, to ensure that folks have enough time to spend not just building their own product, but also being exposed to how other kinds of products work. And 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.
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?
Yeah, so I think the 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 is 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 put it in the channel. And we are encouraging people to talk a lot about it. Sometimes people might spend 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.
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 a sort of centralized body of people who would buddy up with different teams who were building new products, and then we would review their APIs. And of course, we checked for things like consistency, but one of the things that I added to the process was a developer flows section of the template. And it basically asked people who were submitting API designs to take me through a journey of what the developer is doing with this API, step by step. Like 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. It's a skill that you have to learn, and so we would help them 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, you know, 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 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 so I do think that stories are a great sort of medium of communication. Michelle Bu, who's a principal engineer at Stripe and works on the APIs, built a use case compendium for her org, which was, you know, the North Star scenarios of, here's the scenarios that we're going after, and these are the scenarios that we're going to evaluate the success of our product by, how well we 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.
We have this thing called quality Wednesdays that we do. And maybe that's again on the sort of implementation quality side of things. It all started when I got frustrated maybe 3 years ago, because we have this thing with highlights in the application. 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 we defined it, and 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've got to teach the team to see these mistakes, because if you don't know what you're looking for, 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 at an off-site we went through them with the team, and I just asked them to focus on this portion of the app and then come up with fixes, come up with all the 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. I had maybe seen four, and we got 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, if collectively we find all these defects in the application, maybe we need to do it 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 is 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 2 years ago. We fixed probably like 2,500 defects. And I would be horrified to see how the application would feel now if we hadn't done all those fixes. But more importantly, it sets this precedent of you're always on the lookout for your next fix. You're always looking at the product 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 this bug finding mode or defect finding mode, and that helps you become a better product engineer.
I love that. I think it's good to present it, too, and celebrate it and kind of give it some visibility.
And teach everybody, because you will find things that others haven't found.
Yeah. Well, that's great. Switching gears slightly, this can't be a conversation in 2026 without talking about AI, obviously. How have the new tools changed the workflow of a product engineer and made it easier to be a product engineer, or just made that whole workflow look different in your eyes? And how have your personal workflows changed?
Yeah, so talking about Wednesdays, we had this thing at Warp called product quality rotation. So every week there would 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 workstream. Each of the engineers at Flint right now typically has around four Claude 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 get fixed throughout the day by everybody.
And then the other thing that I tend to do myself within my team is that I often have sales calls between like 8:00 a.m. and 7:00. And so I would have the sales call recordings automatically post into this Slack channel, including any bugs that I found during customer calls. And typically my engineers would then look through the summary and automatically kick off Claude to start fixing some of the bugs. And it's really incredible, because sometimes I would see a bug happen at 8:00 a.m. and then by 11:00 a.m. it's already fixed. So use a lot of call recording software, use a lot of summary software, use Claude, and also @Linear within Slack, because some bugs are just a lot bigger than something that Claude could just solve immediately. So when I see that it's more of an architectural issue that we need to fix, I will @Linear to make a ticket, and then we'll prioritize it the next week.
Yeah, obviously the feedback loop is getting much shorter, which makes it so much more fun to iterate. If you know that it's going to take you 6 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 Claude 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 have actually asked for that or something similar, or would be people that I should reach out to, right?" And then it can just list, you know, the Slack for them or the email, and then cite from the Gong call or the GitHub issue or the Slack channel and the support interaction. So tools like that connect people to users.
I was recently... the car company for the car I drive, they set up an email address that people can just complain to about their cars. And then they have an AI sift through all the emails that are coming in, because obviously it wouldn't scale. But now 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 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 input, I think it's 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.
Yeah, definitely. 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. 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; 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. We do have multiple designers who take their designs to the next level, where they're like, "Oh, I want to try it out on the product." And they just spin up Claude and have it implement the designs that they do, and then ship it, not in production, but as a preview build, so that they can actually use the designs that they have. And that's a huge benefit for any engineer and designer.
That's happening at our company as well. So our designer, who was formerly head of design at Netflix, has a career of 12 years and never coded in her life. And it used to be that a designer would look at all these borders that are not perfect or the greys that are a little bit off, or hard-to-find features, bad information architecture, and then she'd 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 pure engineers writing code.
We've noticed that, too. I think probably in 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." The product's just automatically getting better as a result. It's just cool to see how that attitude has evolved in real time.
Okay. So in the last kind of 2 minutes, just any parting wisdom for this group, either from an IC perspective of how to become a better product engineer, or how to coach better product engineering instincts amongst your teams. And then we'll go over to audience Q&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 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.
Love that.
As a leader, I would... again, with the caveat that I haven't... but as a tech lead, my advice would be to run the gradient from vanity metrics to adoption metrics to metrics that really capture the value that users are getting out of it, and then goal your engineers on those metrics. Just to take an example of a social network, you've got your vanity metric, which is like all-time sign-ups. It's like, "Well, MySpace is huge on this metric, right?" And then you align it a little bit more. Okay, maybe it's monthly active users, right? And that user is coming back, which is some indication that they're getting value from the product, right? But or maybe they're just addicted, or maybe
That's not really giving you value. And so, then you think, "Okay, well, maybe time spent, like how much time is this user spending?" And so, obviously they wouldn't come back if they weren't spending more time. Okay, well, but what if, yeah, again, what if they're just re-watching AI slop, or what if they're addicted?
So, then you start looking at, you know, meaningful interactions like choices that they're making, comments and likes, posts, connecting with friends, things that you have decided quantitatively are more meaningful.
Or, you know, even better, you survey users, and you ask them, you know, maybe counterfactual questions like how much money would you have to be paid to not use this social network? Or, you know, at Stripe there was a question that we asked users: would your company exist without Stripe? And the answer, you know, a few years ago was surprisingly often no, like we couldn't have bootstrapped our company without this product. That's a real indication of value, right?
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. So therefore you have to be a bit obsessive about finding those ways to measure real value and then, you know, tying it to the performance reviews of especially your more senior engineers.
Maybe some advice to the EMs: give your engineers time to, you know, create a high-quality product. It sounds, you know, simple and stupid, but there's no A/B test that will let you know whether you're building a high-quality product, because quality is not measurable quickly. 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 you use this one a month and 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 of their work. They want to make sure that they have enough time to ship something that they can be proud of.
I had this thing at Uber. I used to be at Uber as 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 could spot like 10 bugs in 10 seconds. And I just tweeted out, frustrated, saying, like, what happened? We used to care about these things.
And that, you know, 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 for raising this from the outside and having our managers give us the time to fix these bugs."
Article published