Ma: Well, great to see everyone. Thank you for choosing us over the gurg session, which that's an honor. We were worried no one would show up. Um, so my name is Ma. I lead uh the product design teams at Statsig. And we have an awesome panel today to talk a little bit about product engineers, how that looks, um 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. Um, 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 end up being the everything engineer, whether that's marketing or product or, you know, XYZ. And so Michelle, um, 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 backend 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. Um, 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 Producted Engineer. And then last but not least, we have Thomas who is co-founder and CTO of Linear, the leading issue tracker and management tool uh for teams. I use Linear. Probably many of our teams are built on Linear. Amazing product. Um 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. Um, 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, 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, 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?

Thomas: I can start with a simple explanation. You can you can build on on top of that. Um to me a product engineer is just an engineer with some PM sprinkled on top of it. Um a engineer who can sort of not only you know take a vision and then then implement it but also define that vision. Um talk to customers figure out what customers need um and then go ahead and build that thing. So you know a full stack engineer that is even more full stack as in you know being able to define you know the the thing that should be built.

Drew: Yeah, I would just add uh 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 um you're talking to somebody like if I was talking to somebody hey what have you done in your career and they they started talking about not what they built but the technologies that they had built it with and so that's a not a product engineer right and so and and so you know one of the behaviors is just that focus on the user and um 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 like imagine a year ago um 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 um it's got to be discovered so all these things of like connecting 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 userf facing product to be a product engineer. You can be uh deep in the infrastructure, but you still got users and you still got um Yeah.

Michelle: 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. Um, like Drew said, when they think of something that they're building, they're thinking about um the user, their problems, how was problem solved. Whereas a code-minded engineer tends to be more focused on libraries um the complexity, the elegance of the systems that they get to build. And both types of engineers um are talented in their own ways. Um I find that in a startup it's a lot more beneficial to get more uh product minded engineers because there are just fewer roles that you can hire fewer people in the 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 uh the better for a startup.

Ma: So maybe it's making a jump but I assume that all three of you are producted 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?

Drew: I'll start here. I was uh when I came out of college, I was like hardcore and I loved al I wanted to do algorithms you know and data structures because you know that's what I knew as an undergrad at um and I and I joined a compiler team at Microsoft and so I was like you know doing like reading assembly diffs and doing back-end optimizations and stuff and it was not producty even a little bit right and um the thing that switched me was my 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 it had a terrible API and the the chief architect's vision for this um this framework was the assembly language for building compilers and I just thought who wants to program in an assembly language you like nobody and and then I started noticing the C# community was like really into getting into usability and like how 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 then um 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, wow, you know, developers are people too. They're, you know, we're building products for developers. And that's that was my pill was like just getting into API design. And then that just sort of blossomed over time into a more general interest in in product.

Michelle: In college, I had really big crisis of figuring out what I wanted to do. So, I did an internship um 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 um more of a back-end engineering uh job at uh Robin Hood and I didn't see any users at all. I was migrating PrestoQL um and all I saw was SQL and data roles and latency. Um, so that made me think like, oh, like if I didn't enjoy front-end engineering or backend engineering, maybe I should just become a PM because I'm sure like a PM gets to talk to the users and they get to like solve problems and see the benefit of the work that they're doing. And then I realized that actually um it's because I've been using like the industry had been using front-end and backend engineering and it ended up putting people in uh the wrong uh the wrong professions. Um instead you should be thinking about product engineering versus code engineering or infragineering. Um, and as soon as I found that distinction, um, I realized that as a product engineer, I would be able to like understand the customer problem and then solve it no matter if it's, uh, front end or back end. I ended up joining, uh, Warp, uh, which at the time was trying to build a, uh, modern version of the terminal. Um, I met the founder. He showed me a slide deck. I thought it was really cool to improve the terminal. um I joined as his first engineer um back in 2020 and I was able to come up with uh 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 um I was just in the wrong internships

Thomas: I I started my career ages ago like 30 years ago doing CDROM multimedia presentations um before the it was a thing. Um, and it was all about like visualizations and great UI and you know presenting you know some problem in a in a you know visual manner. Um, and then I do did you know a lot of flash and campaigns animations and and all that stuff that is sort of you know very you know very intriguing user interfaces. So I've always always done that. Then I've done mobile development and infrastructure and literally everything in in between. Um, and I've noticed that like I I 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 the user experience better. Um, so you know, for example, you know, at Linear, I wrote the the sync engine for the fourth time. Um, and I didn't do it because like I I wanted to do sync. Um, but I did it because I wanted the user to have a great experience. Um, so I'm sort of I I guess more geared towards sort of the implementation quality side of of a um of a product engineer and not so much on the customer side, but I I I like to sort of, you know, toy around with user experiences and interfaces.

Ma: So let's actually double click on that kind of implementation side of product engineering. how you know 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. Um, how would you define taste and and how do you think that is like 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.

Thomas: I I think it's super important like at least you know from linear side like when we started linear um we we we came into a space that was fully occupied like there's so many uncommon solutions for project management um so we had to figure out like what what is our what is our entry into into this space and how how can we win um in this space um and we came up with this you know in hindsight it's it's ridiculously simple um it's literally just like our strategy is is one word and that word is quality um we want to build a product that it was like you know not two times better but 10 times better um than any incumbent solution. Um and we started with with you know building for uh for IC's because we we felt that that was sort of the underserved market like we had heard that IC's weren't happy with you know any any of the project management solutions out there. Um so we started working on that and we we we said like you know we want to hire people who who have the same sort of taste in quality as we do and maybe that's two things like there's conceptual quality of like figuring out what what needs to be built what should be built how a problem can be can be solved the best and then there's the implementation quality like once you've defined what you want to build like how best can you create an user experience around around that. Um and that's what we start started hiring for like we wanted to get um people that had a taste a similar taste in quality and design uh that we had um and have just you know have a go at it.

Ma: Can can I double click on that? How do you actually interview for taste?

Thomas: Um we do an interview process that is pretty long. It's a full week. So we work together. We pay for our um candidates to come in and actually ship something or hopefully ship something. Like in the early days they actually would ship something like they would work for a week on a green field project and then by the end of the week we would ship it into production and that's how we knew you know whether they had good taste cuz they would have to take the initiative um in in in building the the functionality and the feature out. Um and uh yeah we we still do that today. Um the product is a bit more complicated so people don't ship that often but it still happens someday.

Ma: That's really cool.

Drew: Um I'll go next. Yeah, I I I like um thinking of taste in terms of I it sounds like this mystical thing that like some people have and other people don't have. And so that's that's to me something that I would want to debunk that I think it can be learned and it can it's a skill. It's like a craft. It's a craft. And the elements of that craft are are being able to shift to shoehift to put yourself in your user's shoes like selectively forget what do you know and and and and just think about how the user is going to experience your product and um discover your product, understand your product and then use your product safely and being able to simulate those interactions, right? Like actually have almost like playing chess and being able to see a few moves ahead. It's like going through the the users, how they're going to interact with your product, what 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 like, you know, tell bigger stories about the the user experience with your product. And as far as how to interview for for design taste, I ask like I I I I squeeze it into my my like traditional like you know 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 decision the design decisions that they're going to make are going to depend on how they conceptualize what the user's need and what the user's motivations are and and hopefully they bring it up or if they don't bring it up then you know like at at like at 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 um to to think about the user and then you can help help coach them through that a little bit. And so, um, you know, one of the antiatterns I see is like 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 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 hund that a thousand people have done before but actually like give it a twist and then make sure that they can adapt their um their like simulation skills to a new a new situation.

Michelle: Yeah, taste is extremely important. Um it is the way you differentiate your product uh in very crowded spaces today. um like we're building autonomous websites for our customers like Cognition. Um it is very important that we stand out against a lot of other uh code generation tools and it's very important for our customer to be uh to have really beautiful websites that they can use to sell to their uh 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 um that are very common amongst um you know um 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 uh business impact. So I think that um taste has those two uh two elements to me uh uh to be able to I mean two two ways to train it. So one I think we haven't quite mentioned yet is um exposure. So it's very important to uh 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 um the software products like using Linear all the time and learning all these like amazing things that Lena does, but it's also trying out really cool physical products like looking at a MacBook and seeing how beautiful it it's packaged or like even thinking about like restaurant experiences, you know, 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 uh 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 um managers and I think leads to the next question um to ensure that like folks have enough time to spend time not just building their own product but also um being exposed to how um 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.

Ma: So you did anticipate my next question which is around the coaching the management like 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 um with your teams to build this product engineering muscle and almost train a collective sense of taste?

Michelle: Yeah. So um 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. um our designer was the head of design at Netflix and every time we come up with an idea that like 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. Um I think the second one um in terms of our how our company works is that we um have this slack channel called agentic development um and people are just uh encouraged to share what they're learning about the world different AI products different like AI engineering uh 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 like agentic development and we think that that is very good. Um and we are not cheap when it comes to helping our our our engineers pay for the tools like it's okay to spend some money on AI tools if it means you can learn something new.

Drew: So, I've never been a manager and I probably never will be, but um I was on API review at Stripe for a number of years. And one of 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 would review their APIs and of course we checked for things like consistency. But one of the things that I added to the to the process was um like a developer flows section of the the template and it basically asked people who are submitting API designs to take me through a journey of like what is what is the developer doing with this API you know step by step like for like how are they getting the inputs to it and then like how are they why why are they calling it and then calling it and then just showing kind of a sketch of like how that story would progress and that did two things is 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 um 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, 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. Um but and a lot of times what happened is actually as they wrote the stories they figured out the the problems themselves and then they didn't have to talk to us and then um and so I I do think that stories are a great sort of medium of communication. Michelle Buu, who's like a principal engineer at Stripe and works on the APIs, um, built a use case compendium for her her or which was like, you know, the the northstar scenarios of like here's 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 our system to these 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.

Thomas: We have this thing called some quality Wednesdays that we do. And maybe that's again on the sort of you know um implementation quality side of things. Um it all started when when sort of I got frustrated maybe 3 years ago because we 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. um because that's how I defined it and that's you know it it it works nicely and it feels good. Um and after the 10th time I I fixed one of these highlights not fading out I was like I I got to teach the team to sort of see these 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 you won't even know that you made a mistake. Um so we did this thing where I I selected um a few places in the application where I saw a few problems you know very small ones and at an offsite we went through um with a team and I just tked them to like just focus on this portion of the app um and then come up with fixes come up with you know all small small kinds of defects that we had and to my surprise um 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. Um and that led to the next idea which is the quality Wednesday part which is like well you know if if if collectively we find all these defects in in the application maybe we need to do it you know every single week. Um so we started doing this where every single engineer is expected to just find a new defect um 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 is missing or doesn't look right. Um, and then fix it and present it to everybody else. Um, and we we started doing that two years ago. We fixed probably like 2,500 defects. Um, and I I I would be horrified to sort of see the application how it would would feel like if if you hadn't done all those fixes. But more importantly, it it sort of sets this precedent of um 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, you know, find my next fix fix for next Wednesday. So, it sets your mind up into sort of this this, you know, buck finding mode or defect finding mode. Um, and that helps you become a a better product engineer.

Ma: I love that. And I think it's good to present it to and celebrate it and kind of give it some visibility.

Thomas: Teach everybody because like you will find things that other others haven't found.

Ma: Yeah. No, that's great. That's great. Um, 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 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 how have your personal workflows changed?

Michelle: Yeah, so talking about bug Wednesdays um we had this thing at warp called product quality rotation. Um so every week there will be one engineer who's in charge of like fixing all of the pol like polish issues and bug issues and uh as a result um warp is a very fun to use uh product. Um but what I found that found is different now is that in 2026 um you no longer need to wait for a week and get one person to synchronously work on uh this work stream. Um 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 like a lot of like small fixes to the uh to the product actually gets fixed throughout the day by everybody. Um, and then the other thing that I tend to do myself and within my team is that um I often would have um sales calls between like 8 am and 7. And so I would um have the uh sales call recordings automatically post into uh the Slack channel um including like any bugs that like people that I found during customer calls. And typically my uh engineers would then like look through the summary and then automatically kick off cloud to start fixing some of the bugs. And it's really incredible because sometimes I will see a bug happen at 8 a.m. and then by 11:00 a.m. uh it's already fixed. Um so use a lot of call recording uh uh software, use a lot of summary software. Um use clot and also uh add linear within Slack because some bugs are just like a lot bigger than something that clot 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 um and then we'll prioritize the next week.

Drew: Yeah. Um the I mean obviously the the feedback loop is getting much shorter which makes it it's so 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 you know that instant gratification of being able to fix a bug so quickly is great. And um in addition I think the AIs are starting to help with actual product skills as well. So, my product team at at Temporal, we have a um a bunch of like clawed PM skills like competitive analysis or like maybe a big one for product engineers would be customer signal. Like, hey, I have this idea to like build such and such a feature. Find me users who would actually like have asked for that or something similar or would be people that I should reach out to, right? And then it can just like list you know the Slack for them and the or the the email and and and then like you know site from the gong call or the GitHub issue or or the Slack channel support interaction and just yeah so so tools on the like c like that connect people to users. Um, I was recently, uh, my 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. Um, 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 a business product as well. Um, and so that the the signal to noise, the denoising of the the user impact input, I think, is really going to help product engineers like be motivated to go in more in that direction rather than be like recoil and horror when they think about their users.

Thomas: Yeah, definitely like all of these things that were that were said before, but um additionally maybe like the the one thing that I I think has changed radically is um the fact that you can just try out things without really any effort. Um like there there might have been cases before where you you get some you know some some design that looks super complicated and you you you have a hunch that it might not work but you know maybe it does like maybe it feels good if you implement it but the implementation would take a week. um you wouldn't really sort of even try like you would ask the designer to sort of make some changes or or you know reconfigure it but now you can actually just give it a try and and see how it actually works in production and it's not only for product engineers it's designers as well like we we 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 out in the product and they just spin up cloud and you know have it um have it implement the designs that they do and then ship it in not not ship in production but as a preview build so that they can actually you know use their designs um that they have and um that's a that's a huge you know benefit for for any engineer and designer

Michelle: that that's happening at our company as well so our designer um 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 like you know borders that are not perfect or the grays that are a little bit off um or like a hard to find features bad information architecture picture and then she'll maybe like form like a few tickets for the engineering uh staff to take over at some point. Um she's she's writing so many PRs now. Um maybe five to six a week. Um and uh the UX of the product just keeps getting better and better every week because now uh you're no longer just having like pure engineers uh writing code.

Ma: We've noticed that that too at 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. Um, and it's just cool to see how that attitude has evolved in real time. Um, 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 Q&A.

Michelle: Yeah, I think that there's um no substitute for uh talking to customers directly. Uh 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 summary of calls would never do. So um it is important to me to uh bring my engineers to customer uh site visits and then I also make sure that um every engineer attends at least one sales call with me every week.

Drew: Yeah. As a leader, I would uh again with the caveat that I haven't but um but as a tech lead, I I typically um like I I my my advice would be to like run the gradient from vanity metrics to adoption metrics to like metrics that really capture val 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, right? 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 that's not it's it's it's not really giving them value. And so then you think, okay, well maybe time spent um like how much time time is this user spending? And so that obviously they wouldn't come back if they're weren't spending more time. Okay, well what if again what if they're just reading watching AI slop or what if they're addicted? Um, so then you start looking at, you know, meaningful interactions like choices that they're making, comments and likes, posts, like thing like connecting with friends like things things that are like you have decided quantitatively are like more meaningful. Um or you you know even better like you you ask you you survey users and you ask them like you know maybe counterfactual questions like how much how much money would you have to be paid to not use this this social network or you know how you know at Stripe there was a question that we asked users like would your would your company exist without Stripe and and the answer like in you know a few years ago was surprisingly often like no like we couldn't have bootstrapped um our company without this product, that's a real indication of value, right? And so if you can um you know, 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 you so therefore you have to be a bit obsess obsessive about finding those ways to to measure real value and then like you know tying it to the performance reviews of your of your especially your more senior engineers.

Thomas: Um maybe some advice to the EM um like give your give your engineers time to to you know create a highquality product. Um it it sounds you know simple and stupid but there's no AB test that sort of will you know let you know whether you're building a high quality product because quality is not measurable sort of quickly. Um like if you don't think about quality your your your product will degrade over time. So a year later maybe um you will have a lower quality product and your users will abandon you for for somebody else if you don't do that. Um 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. Um I had this thing at Uber. I used to be at Uber a mobile engineer. Um and a few years ago like I I opened the app after a long time and I was I was devastated by all the bugs that I found. I was like I I could spot like 10 bugs in 10 seconds. Um and I just tweeted frustrating frustrated I tweeted out saying like what happened like why we we we used to care about these things. Um and that you know created a stir at Uber and they they had a code yellow and they started fixing bugs. Um and engineers started tweeting back DMing me back saying thank you thank you for for raising this from the outside and having our managers give us the time to to fix these bugs.