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?

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.

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.

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.

>> 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?

>> 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.

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

>> 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.

>> 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.

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.

>> Can can I double click on that? How do

you actually interview for taste?

>> 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.

>> That's really cool.

>> 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.

>> 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.

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?

>> 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.

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.

>> 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.

>> I love that. And I think it's good to

present it to and celebrate it and kind

of give it some visibility.

>> Teach everybody because like you will

find things that other others haven't

found.

>> 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?

>> 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.

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.

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

>> 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.

>> We've noticed 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.

>> 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.

>> Love that.

>> 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.

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.