# Product-Minded Engineering in the AI Era

**Podcast:** Tech Lead Journal
**Published:** 2026-03-09

## Transcript

Engineers' coding skills are maybe a little bit less leverage than they were a few years ago.
Today's guest is Drew Hoskins, former senior staff engineer at Meta and Stripe, and the author of Product Minded Engineer, a book teaching engineers to think beyond code and build the product mindset that matters most in the AI era.
So in your definition, what is product engineer?
My definition would be an engineer who cares at least a month as much about the what and the why as the how.
So what are they doing and who are they doing it for?
One way you can tell a product minded engineer is when you ask them about their history of their career and they tell you what they built rather than say what technologies they use to build it.
What is the impact of AI with your role or the way you see it for product engineer?
Product is a bottleneck right now, and it's feeling like increasingly a bottleneck.
I've started to see is a lot more prototypes coming out of engineering, which is completely awesome.
And then what I'm feeling is like everybody looks at me and they're like, okay, we have this demo, like help us get this out.
And I'm just like, oh god.
As engineers always we know like writing code is not the only thing that matters.
There's like three skill tests.
There's like people skills, there's system skills, and then there's product skills.
And you probably are going to need all three of those don't just do more code, but develop some of these higher level skills such as product skills, collaboration skills, ownership skills.
It's almost like speaking a different language, because the engineer, their brain is indexed around the system.
The product manager who's only thinking in terms of like the user stories.
In my book, I call it the great reindexing, because when you're developing a product, you start with uh the user journey and then you go to the system.
That's the great art of software engineering, really.
Thanks for being here, and let's get back to it.
Hello, welcome back to another new episode of the Techly Journal podcasts.
I have with me Drew Hoskins.
People are talking a lot now about being a product engineer, product-minded engineer.
They're kind of like the similar.
So welcome, uh Drew to the podcast.
I'm really looking forward to discuss about this so that we can help people to become much more product engineer mindset.
Thanks for having me, Henry.
This is gonna be really fun.
Yeah.
So Drew, um, maybe let's level set in the very beginning, right?
Uh, because this term has been coined for quite some time now, product engineer.
I think even long time ago when there used to be like a lot of uh scale-ups, uh, people started talking about product-minded engineer or product engineer in short.
So, in your definition, what do you think is product engineer?
Yeah, my definition would be an engineer who cares at least amount as much about the what and the how as or sorry, the what and the why as the how.
So, what are they doing and who are they doing it for?
And uh, of course, they're an engineer, so they need to figure they have need to understand the how, what how they're gonna accomplish it.
But you know, one one way you can tell a product-minded engineer is when you ask them about their history of their career and they tell you what they built.
Uh, uh rather than say what technology they use to build it.
It's a pretty good litmus test for um who might be considered product-minded.
It's not an exclusive club, it's not like you need some rare skills to be a product-minded engineer.
And it and also I I do wanna underscore the the idea that infrastructure engineers can be product-minded engineers, right?
Because everything is a product, anything that you check into your code base, any function or class can be viewed as a product, right?
It has an interface, it has users of other who are other engineers in this case, and those people have like usability problems, they have requirements.
So in anything really from the big to the small can be considered a miniature product.
And so you can bring these skills no matter where you are in the stack.
I I love how you define it very succinctly, right?
So an engineer who cares about the why and the what, this is just the how, right?
Because I think tech keys sometimes we love our languages are frameworks, and now it's like AI tools that we use.
Uh, but also care so much about the why and the what that they build, right?
So I think that's a pretty nice definition.
Um so you mentioned a lot about um, you know, the build itself, right?
So the product.
Does it mean that if I work in a consulting or if I work in non-product, you know, companies, can I still be a product engineer?
Uh well, in consulting, I mean you're actually even more of uh beholden to the needs of the people that you're consulting for.
So you have to have a lot of awareness of your users in that case.
I certainly like personally, I enjoy the challenge of trying to develop a product for for many different users.
Um that's one of the fun parts for me.
So I probably wouldn't be a good consultant.
But uh, but yeah, absolutely.
I mean, you know, just a few users or millions of users, like in all of those cases, product skills come into bear.
Right.
So this term uh I think we we should clarify it's not just specifically for engineers who work in a product companies, right?
So no matter where you are, I think you can still the mindset, the what and the why, right?
Coming back to what you said, I think is important in what you do.
So um I think for you you have been around for quite some time, you know, you have uh been in uh different companies, and actually when I look at your history, I think you're kind of like perfectly suitable to write this book.
So you have work in Microsoft, you know, Meta, Stripe, as um last is like the senior staff engineer or something like that, right?
So purely IC.
And then recently you moved into product management, uh, which is like becoming a product manager.
So tell us a little bit more from learnings, uh, from your learnings uh in these great companies.
Um, and then uh what actually you meant by you know switching to product manager now?
Uh are you still doing some kind of engineering thing or are you just purely a product manager now?
Yeah, sure.
I'll start from the beginning.
So I started at Microsoft on a compiler team.
I was like quote unquote hardcore, you know.
I I I double majored in math, I loved algorithms, you know, I was very much into the into the how.
And I ended up working on this kind of compiler framework that was ill-faded.
It didn't, it didn't make an impact.
But the chief architect's vision for the framework was to be the assembly language for people who wanted to build compilers or jitters or other other tools.
And my thought was who wants to code an assembly language?
Like I don't like I didn't like the vision.
I saw like all of our APIs were really hard to use.
But the C sharp community was doing really great work on API usability at the time.
And so I started doing some work on my team to kind of bring you know like a user like an API usability mindset over to we were actually a C code base.
And so like And let's like import some of the good work and thinking that's like being done in the C sharp community over just C.
And that's how I kind of that's how I got the API usability bug.
I wanted to write APIs that made other people really productive.
And then I switched Teams over to Windows and I worked on this um another API team, or like I'm gonna date myself here, but tablet PC.
Uh with like an eking interface, you know, APIs for people who wanted to build like tablet applications.
And I did a uh a usability study.
And back in those days, it was actually like a one-way mirror, like where I sat on one side and they couldn't see me and I watched them code.
And it was like the most humbling experience I've ever had in my life because they struggled to use my my prototypes.
I mean, it was it was painful and it was a big lesson, but also like I'm I'm very attracted to difficult things.
So I thought, oh, well, this is a really this is way more interesting than I thought, like this whole design thing.
And so um, that was a humbling experience and really taught me that I needed to connect with my users more, and uh, and even though I was interested in usability and in product thinking, I wasn't there yet.
So then at Facebook, I think the thing I learned at Facebook was to be more entrepreneurial and to prioritize my time better.
Because I was used to being given more tight, like like, hey, here's what you should go do.
But at Facebook, Facebook was very much about just this is um I joined in 2009, it was very much like distributed autonomy, not a lot of consensus building.
You just go do a thing, you know.
Uh, and you have to be very good at prioritizing your time, or you're not gonna get in my first couple of years, frankly, I kind of struggled with that.
My projects were hit or missed, but because like I didn't necessarily have a really good understanding of what the impact would be.
And so this started to teach me that hey, like product thinking is not just about usability, it's also about like what do users actually want in the first place, and like what's the best way to like what are the things that are gonna make the most impact.
My biggest claim to fame at at Shasebook was I I founded this company called or this this project called Entschema, which was like a really a really powerful ORM and sort of development platform for modeling our our data, like our graph, like uh users and groups and status updates and photos and all those things.
And it was like a huge step change in productivity for the company.
And in that journey, I was a former, like I was I moved down the stack in so to speak.
Like I was uh a developer at at Facebook, and then I became uh somebody serving developers at Facebook.
And so I had a lot of empathy for that role because of my my couple years of experience.
And so then around this time, as I'm working on this project, they developed this system of archetypes, which were five kind of staff level roles that they've seen engineers be successful with at the company.
And the archetypes were a generalist, a specialist, a fixer, a coding machine, which is somebody who's just very, very productive at turning out code, and uh, which I guess claude cloud code is like a coding machine archetype, frankly, and uh and a product engineering hybrid.
And I was considering going into management because, like, you know, I was senior now, and of course, at some point you're supposed to figure out whether you're like gonna go to management.
And my manager was like, no, look, like there's this archetype, which you seem to be, which is a product engineering hybrid.
And if you just keep doing what you're doing, like you're gonna go far.
And so he helped me understand like sort of what my niche was at a company where you know, or in the early days, it felt like you had to be a coding machine.
Like that was the like all the most wanted engineers were coding machines, and that was never me.
Like I wasn't somebody who just turned out a lot of code.
And so, like learning about these archetypes and finding that there was a role for me, really accelerated my career and uh also just my impact of just understanding who I was and how I fit into the scheme of things.
And then when I moved to Stripe, I think the thing I learned at Stripe was being more collaborative.
As I mentioned earlier, Facebook is a very like distributed autonomy kind of company, not a lot of consensus building, at least back back then, and uh lots of experimentation, but where it's a Stripe, it's it's more it's a like Stripe builds developer APIs for moving money, which have to be pretty rock solid.
And so there needs to be a lot of consistency building, there's a lot of document writing, and so you get a lot of people who are um at Stripe who are very productive, first of all.
Like Stripe has done a great job of of hiring product-minded engineers, and secondly, a lot of people who are very collaborative.
And so I I I became a much better collaborator at Stripe.
And then, you know, finally I I moved to Temporal Technologies, which is like a durable execution platform, or you can think of it as a workflow engine.
And I was at the time I was I was writing the outline for the product minded engineer, the the book that just came out with O'Reilly.
And I thought, well, and I was had been a customer of Temporal, and they reached out to me, and I was expecting them to reach out and ask me to come be an engineer.
But they reached out and asked me to come be a PM.
And they needed somebody who like was a former developer who really understood their customers, um, who are pretty technical folks by and large.
And I thought, you know what, this would be a fantastic way to like deepen my product jobs so that I can then do a better job writing the book.
But I didn't know whether I was gonna get the book deal at the time.
So it was a little bit of a leaf of faith, but then the the deal came through.
So yeah, so I've been a product engineer for a couple of years now.
I mean a product manager for a couple of years now.
Right.
Wow, I think um I can see the kind of like uh learnings that you had in all these companies, right, that brought you to your current role now.
So I think the a few themes that uh I like to call out, like for example, in the beginning you learn about you know product thinking, usability uh of the users, right?
Uh using your product.
And then at Facebook you learn about entrepreneurial uh thing and you know autonomy and impact, right?
I think that's kind of like also important as a product engineer and being collaborative at Stripe, um, which is uh now you're doing uh the product management uh itself, right?
So I think when when you did this switch, what was your biggest struggle, maybe should I say?
Is it like not being able to produce code uh more or like what what kind of things that you struggle in the beginning when you switch to product manager?
Uh oh, in this last couple years, you mean a temporal?
Yeah.
Yeah.
Well, I mean, okay, so I I did take a down level to become a product manager, which I was happy to do.
I mean, I I think I was recently interviewing a bunch of people who've transitioned to the product manager, and you know, the advice is like look five to ten years out.
Don't like think of a down level as like a career setback because you'll get back, you know, to the level that you were.
And so yeah, look five, ten years out is fine when making these transitions.
And so that was that was fine.
I was okay with that.
Um, I think like as far as the actual behaviors I struggled with, I mean, I one thing is when you're a product-minded engineer among engineers, there's a default, there's an amount of clout that you get because you're an engineer on the engineering team, like you're a tech lead.
And so people like I found it easier to lead from that position.
As a product manager, I'm in a different org from the engineers.
They don't necessarily know who's this guy who's like asking them to do things.
I'm not the one who's gonna have to be on the hook to build the thing that I'm advocating for.
And so I find that I need to show my work more.
Like I have to actually like show the user quotes of like the people who are at me for things and like be more detailed on like the scenarios that I write, and just you know, really provide more supporting evidence for what I'm saying because there's a little less default built-in trust.
And also I'm not just influencing engineers, I'm also influencing the go-to-market teams and and others other folks around the company.
And so they're just the stakes are higher.
And um, and so yeah, showing my work is like the biggest thing that I've had to you know being more rigorous about that.
And even if I already kind of know the answer, like of what we need to do, I go ask users and then like, and maybe I'm wrong and maybe they correct and they show me something that I missed, which often happens, or even if I was right all along, I still have that data that I can show how the product should work.
Right.
I think from my experience as well, looking at uh these type of uh engineer, right?
Product engineer, I think I can see um you mentioned a couple of things, right?
Like being able to influence, I think that's kind of like very important because not just influencing within the engineering team, but also to the users, the stakeholders, the partners and all that.
The second thing is I I think they are always around in meetings, you know.
Uh, uh people ask them to join just because they have a breadth of knowledge and you know not just the technical skills but also the non-technical aspects as well.
And they care about the users, right?
So maybe sometimes we can see it when they draft you know the ticket, right?
The issue that they're working on, they will put more things uh beyond what the PM has written maybe or beyond just what the engineer has written, which is typically just one two lines.
So these are some of the traits that I see.
So maybe from from your observation as well for people in the industry at your site, what are the skill gap that are still kind of like um missing you know for an engineer, a peer engineer or techs who want to become a product engineer more.
Yeah I think for me the I would call it the fundamental primitive of product thinking is this is the user scenario.
And so what is that?
I mean it's it's basically a story about you know the way that engineers are gonna interact or sorry the way that users are going to interact with your product.
And so if you're just like in a conversation with like a staff level engineer, you're gonna hear them talk about, well, what if this happens and then this happens, right?
And they're gonna tell little stories in the conversation that are going to ground the conversation in something interesting.
And that's something that product minded engineers are like you have to be able to do that.
A story would consist of a of a persona or a person who's doing the thing, and then they have to have a motivation for why they're using your product.
And then a sequence of steps that they go through as they use it.
And so, you know, maybe a pure engineer, infrastructure engineer or some lower level engineer is gonna start with just thinking like uh, like let's say you're working on a coffee ordering app, right?
And they're gonna think about the like click the pay pay now button or something, right?
And then they're gonna they're gonna design what's inside of that, what happens when you click the button.
But that's just one very narrow window in the story, right?
So what happened first?
Well, first they had to like select the item and they had this whole ordering flow that they went through.
How do they even get to the to that in the first place?
And then you start to think in terms of the conversion rate of that flow, like how much how well are users proceeding along that journey to get to the actual purchase button, which is what you want them to do.
Um, maybe you should be catching state from previous interactions to speed up speed it up.
And so you start thinking about this, these these like you start simulating out what the sequence of steps that users are doing.
And that's the simulation aspect of the story.
But then also tell me more about the user.
Like, are they repeat customer?
Have they ordered this floor?
Well, then maybe you've got some sort of favorite system that you're providing that help them reorder things that they've already ordered in the past and cut out a lot of those checkout steps.
And then, you know, you start thinking more about the customer situation and empathizing with the customer more deeply.
Like maybe that customer is actually on their commute and they're going to pick up their coffee on the way to work and they're in the car and like they're trying to interact with your multi-step checkout flow while driving which is not safe.
And so you know as you kind of become more product minded you start fleshing out these stories and making them bigger and bigger and then by the end you're thinking okay well actually what about voice commands like what maybe we integrate with voice and we um now you're looking up the Siri kit SDK and like trying to figure out if you can integrate like cheaply integrate voice commands into your app.
And so um so that's the sort of like it just started getting out like zooming out and getting more context using the story as a way to guide you through that journey of like okay I've got a tiny little story.
What happened before or what's happening next and then who is this person and why are they doing it?
And so you're just kind of like adding adding more flesh to the story until you've like covered what you need to cover to make a good product.
Yeah to me that kind of like sounds doable right for an engineer who wants to have more product minded engineer mindset, right?
So it's like understanding the user stories, the user journey.
Some people also uh say that, right?
Understanding the persona, the impact, how they're using your products.
But for some engineers, um, they will think this is the job of product manager, right?
Um so uh what what they expect is like okay um they do the this kind of a story um you know scenario and all that then they will write a ticket for me and I'll just and let's try to understand from the ticket and implement that so what what do you think the challenge of this because I can see so many how should I say conflict or misunderstanding between product and engineer simply because of this so do you have any uh experience on on how to handle or navigate this kind of conflict yeah no you're absolutely right I mean there's there's those of us so I've been in a bunch of teams where I didn't have a PM because I was doing like developer infrastructure right and so it's like okay you've got to be a product minded engineer because like or someone in your team needs to be because there's no PMs in that um and then when I have had a PMs um they're often very dizzy and they don't think in a level of detail that is like there's a lot of product decisions to be made that are kind of underneath the level that which they understand and that a lot of that comes from your knowledge of the system that they don't have and then the communication is very painful between like a product manager who's only thinking in terms of the product like imagine like it's almost like speaking a different language because the the engineer, their brain is indexed around the system, right?
They've got like the system diagram in their head, they have the the the UI mockups and then the the the relationships between the UI screens.
And then you got the product manager who's only thinking in terms of like the user stories and the timelines of like, okay, the user does this and then this and this and this.
How do you communicate with somebody whose brain is indexed entirely differently than yours is?
It's it's very painful.
And so having a person who has both indexes in their head, even if they're maybe the not the, you know, you may not be the deepest database expert, but you maybe know enough about the database to know that like, oh, indexing is the thing that I need to do, um, then you can identify that it non-indexed you know, reads are gonna be a uh a risk, right?
Based on the scenarios that um the PM has brought or the ones that you figured out.
And so the PM may not know to focus on like the scenarios that are gonna be scalability problems, whereas you know that.
So it's really this combination of skills that's like incredibly powerful.
Even product managers that I talk to who are formerly engineers are like, oh, I use my technical skills all the time in my new role because they just understand that that's it's that combination of like two indexes in your brain that's so powerful.
I think like an early way to develop these skills is to write scenario tests.
And so you maybe you're you're used to writing unit tests, which are like I'm gonna exercise some tiny little piece of functionality about my product, but a scenario test would be a test where you are actually like writing down a user scenario and then going through those steps.
Or maybe you're you're writing a test that's just very, very likely to occur in Fed because that's what you just, you know, like if your home page has a default query of your database, like make maybe you're Netflix and there's like the home page query is the thing that's gonna happen all the time, then you write a test for that scenario, right?
And so uploading yourself from writing unit tests to writing scenario tests is a really good way to practice your product skills.
And if you don't know what the scenario is to write, then go to the talk to your PM and say, hey, like I'm writing tests, and I'm not sure I'm writing scenario tests, I'm not sure exactly which ones are the most important.
And start asking them why, start asking them like some more context, and then you'll you'll build that muscle.
Yeah.
So I I like your analogy just now about two different indexes uh in you know the the people's mind, right?
So one is indexed more from from like architectural, maybe system level, while the PM is indexing more on the you know user journey, the impact and all that, right?
So I think that's kind of like a good analogy that I've I haven't heard before.
So I think for engineers who are still struggling, like what do you mean by uh, you know, different mindset?
Uh so this is one one analogy that I think we can use.
So I think writing scenarios is yeah, oh sorry.
I mean in my book I call it the great reindexing, because basically, like when you're developing a product, you start with the the user journey, and then you go to the system and and it's like a kind of a a bit of a process to get from from one to the other, you know.
It's uh it's actually that's that's the great art of software engineering, really is is basically just re-indexing.
Yeah.
So I I think this is also something that we can use practically, right?
So whenever we are in the like, for example, in a non-engineering discussion, we we have to re remind ourselves switch our index is the other brain, probably the other parts of the index to actually um you know talk more other than you know still at the architectural or system level.
So yeah, writing scenarios is definitely something uh very easy, practical for engineers to step up, right, in terms of uh having product engineering mindset.
But in your book, you also kind of like cover like four different pillars, right?
Uh you mentioned about develop, deliver, discover, and divine.
I think this uh framework is I feel is very you know strong, um, so that people know what is the roadmap for them to improve or increase their product minded product mindset, right?
So uh tell us about this framework, how how do we actually use it and what uh what do they entail actually?
Yeah.
So this is called the double diamond framework, and it's it's it's a process framework.
So it's not a process, it's like a way of thinking about process, right?
And the four stages are discover, define, develop, and deliver, as you said, and it's called double diamond, you fix your Q diamonds like side by side, right?
And so like you've got your your first stage is discover, and that's a very like opening up phase, right?
You're looking all over the place to figure out what what the heck you're gonna do.
And then um you're talking to customers, figuring out what the problems they have, and then you go to the define phase, which is like defining the products you're gonna build that will solve their problems, and that's like a convergent phase because you're trying to like pick figure out exactly what you're gonna do based on the thing, and then you get to the how stage, which is which is like the development stage, which is like, okay, now let's explore a bunch of different ways to solve to build that product that we did.
And that's when we're actually starting to play with different database architectures and or depending on your your domain, you know, whatever technical challenges that you have.
And then finally deliver, which is again a narrowing phase where you you're starting to polish and test and um get it out to production and and experiment, or and and like do like do your like metrics and and A V tests and stuff like that.
And so what's interesting about these what's most interesting about these phases is first of all, like the thing I see engineers do the most often, that's a mistake, is they jump to the develop phase, right?
So they start building something.
Is it the right something?
Maybe maybe not.
They've kind of skipped over the discover and define stages and jump straight to the solution, and then they start deciding you know which which um and sometimes they need to skip all the way to the the to the deliver phase, and they just have a solution and then they just like write that and then they ship it.
And so I would say, first of all, like, yeah, make sure you're building the right thing because you know there's a high cost to you know, you're wasting your time by building something that's not gonna make an effect.
And then I think the second thing is like I I get into a I see a lot of arguments where one person is like trying to just get the thing shipped, and the other person is still trying to explore different solutions, and you get these arguments and people aren't really saying that, but that's what you can tell that they're just sort of in different mentally in different phases in the double diamond process.
And so if you can if you notice that you're having an argument with a coworker about of this nature, like you're impatient or they're impatient.
Check in on like, hey, I'm in the developed phase.
It sounds like you're in the define phase or whatever, and um, it's a good way of resolving this tension because then you can have an explicit conversation about where you are if in the roadmap, even if you don't have some some grand process built around these four phases, you can still kind of use it day to day.
Right.
So I I I totally understand when you mentioned uh developers or engineers tend to jump into develop, right?
So simply like from the industry, I what I can say is like they're waiting for the PM to kind of like discover and define the thing.
Um, you know, the ticket for them to work on, they develop.
Uh and not only that, they stop there.
So the the what do you call it?
The this oh sorry, the deliver phase, right?
So at the end, they also don't care so much about whether you know the features they build are used, what kind of metrics, you know, uh what's the user journey like after using the product.
So tell us about the importance of this deliver aspect as well, because I think sometimes it's really missing from engineers.
I agree.
I agree 100% and um I think the biggest thing I see people miss is discoverability.
And so there's a sort of you know we mentioned scenarios earlier as like stories that you tell and a very classic user scenario starts with discover and then understand and then use right so first of all you have to discover your features they have to figure it out and then they have to actually use it safely to accomplish their goals.
And I see people make mistakes in all three of those pieces of the user journey but one of the more classic ones is the discovery where it's like hey I've got my feature but like nobody knows it exists and they don't find it and the engineer isn't necessarily thinking in terms of that kind of like growth hacking mindset of like how do I get people using my feature.
But the thing is you can add a discoverability hack that's just gonna 10x the usage of your feature at like a tenth of the cost of the building it right so it's often an extremely high leverage thing to be doing to, you know, like, okay, you've got an error message, and like the solution to your error message is to use your feature.
So like tell them tell the user about your feature when in the error message as a very simple discovery mechanism.
So that's a classic.
And yeah, a lot of those things get driven during the deliver phase when you've kind of got the course thing built, and now it's about putting it in context of like the rest of your product and making sure people find it and then making sure that it's safe and then having the metrics feedback to then understand whether it's making the impact that you hoped.
And also like, you know, tracking metrics is huge for you know your career as well, because if you can show the impact that you made, it helps your uh your manager understand what you've done.
Right.
So yeah, I definitely tracking metrics is very important, right?
So and especially because when you want to track those metrics, you kind of like need to put the instrumentation, the observability aspects into your solution as well, right?
Because it's not so easy to get a metrics if you just deploy it and put it out there, right?
So I think uh this also comes back to how you develop this stuff as well.
So I think what I think you are trying to say is like this framework uh exists, but we are not asking engineers to be good in all of them, right?
But at least know some aspects of them, uh, be part of the discussion, um, you know, in order to shape the feature much better.
How do you think um the engineer should think about now you you have this pillars now?
Do I do I need to always be involved in all different phases when I build a feature?
Or like how t tell us practically how do you use this framework in our day-to-day life?
Yeah.
So if you are uh if you don't have access to a PM, then you would need to be involved in all four phases.
Um if you do have access to a PM, then I mean, I personally get involved in the discovery phase anyway, because I enjoy it and I also say that you can help the PM narrow down the possible solutions.
Like there's no point in the the the PM going and asking users if like would you like a trip to Mars if you can't get them to Mars, right?
And so like helping narrow down the options and helping the PM focus their efforts on what matters is a is a role for an engineer early in the discovery phase.
And then starting with the define phase and on to develop and deliver, the engineers gonna get much more involved.
Um I personally uh have things I enjoy about all four areas.
So yeah.
So thanks for that addition, right?
So I think narrowing options itself, uh knowing what is the possibility to build, because for example, also if you work on legacy product, right?
You know the challenges, the constraints, um, you know, with the current architecture, the current system.
So you kind of like know what options that the PM has uh so that you don't fight in the end.
What one of the ways that I will get involved in the discovery phase as an engineer is I'll like ask the PM or the salesperson or the like solutions architect or you know, the forward deployed engineer or these sorts of people like, hey, can I tag along in your meetings or can I can I read uh can I watch the trans video transcript or whatever?
And really I'm just kind of immersing myself in what the humans are that are using my product are are doing, which is gonna help me make decisions later in the project when the PM under specifies things, right?
Or when I have insights based on my knowledge of the system that I can combine with that information.
And so there's some pretty high-leverage ways you could have an AI now go and find out all the user context for you, like, hey, would anybody like this feature that I'm thinking about building?
And then just have like a LLM go and search for um anybody that they think would would be interested.
And then now you've got some leads to reach out to, right?
And so like it's actually pretty easy to and and relatively low work to just tag along with some of these other roles as an engineer.
Sometimes you can provide some um some insight to like, especially if you're working on a technical product, right?
Where you can provide some deeper understanding to the to your customers um for the hard questions.
And then even if you don't even if you don't think you're going to provide value, that's okay to it's okay to tag along or to watch the video transcript, right?
Because you're gonna be learning.
So don't just assume that because you're not gonna be providing value, meaning that doesn't mean that you shouldn't at least understand what's going on there.
Yeah, I think that's a very good tip, right?
So uh I think even even though you don't have something to sort of contribute, you can still learn from those experiences.
So you mentioned something very uh interesting, right?
Um engineers now themselves can also use LLM to kind of like learn from all those things, like transcripts, conversations, and now I think it's a good segue uh to talk about uh AI impact to you know engineering, product engineering and all that, because uh I think one aspect that people kept talking about is like the impact of AI now that we can produce code much faster.
Uh engineers now uh have more time, uh presumably to start thinking about you know the product aspect.
So, what what do you think personally for for your situation, right?
What is the impact of AI with maybe your role or maybe uh the way you see it for product engineer?
Yeah, yeah, I'm absolutely um trying to figure this along out along with everybody else at this point.
One thing I will say, a couple things here.
One is at my company, Temporal, uh product is a bottleneck right now, and I think it's feeling like increasingly a bottleneck.
One of the things that I've started to see is a lot more prototypes coming out of engineering, which is completely awesome, right?
Like I love seeing you know all these demos every, you know, in our in our Sprit showcase every every couple weeks.
And then like what I'm feeling is like, you know, everybody looks at me and they're like, okay, we have this demo, like help us get this out, right?
And I'm just like, oh god okay I've got so much work to do.
And so more product skills threaded throughout the organization, I think will really help engineers be more empowered to get their own prototypes out to production and make those you know like every prototype comes with like a list of decisions that need to be made about it right and so it's like how do we drive the the decision making that it takes to get get it out and um so yeah I would say you know what Kent Beck was saying recently about my book was that you know Drew is helping to shield the rift between product and engineering.
And I think that's an interesting way of phrasing it because if you think about it, these are two very tightly related disciplines right the product and the engineering side and there has been this artificial divide and the the size haven't been talking to each other.
Like as you one of the reasons I wrote the book was because there was no engineering literature about some of these topics.
It's like the topics are well known in like the design community, the product community, but like nobody bothered to tell engineers about it.
It was as if we were like in different silos and we never talked to each other.
And so I think there's gonna be a combination, like more people who are um what Elsa Vandenberg calls uh M-shaped people, right?
He's got like spikes on engineering skills as well, spikes and product skills, and um, because it's such a leveraged combination, especially in the age of AI, and especially when um you know engineers coding skills are maybe a little bit less leveraged than they were uh two years ago.
And so, you know, I think some some folks will shift over to product, but that's sort of but I saw I also think that there's an enormous potential in just getting more people who are hybrids, and you don't have to go all the way over to product to like add value.
I and I might go back.
I might I might I I I'm actually kind of jealous of like the engineers right now because they have all these amazing new tools that they're getting to use, and I'm like kind of missing out on it.
Like I'm using quad code and some and I'm writing some samples and stuff, but like it's not really it's it's not really the same.
And I'm I'm I'm I'm missing out on some of the sponsors.
So maybe I'll go back and be a hybrid engineer again.
Right.
So I I think that's a very good um experience that you're experiencing, right?
So but because we talk a lot about about engineer having more product mindset, is there such a thing as a PM being more technical, right?
PM, you know, who could write code?
Is this something that is also happening?
Because again, with the introduction of these AI tools, now presumably you know, PM can do vibe coding, you know, all these, you know, lovable, bold, rapid kind of tools to actually build prototypes themselves as well.
So what what is uh your thought on this?
Like PM becoming more technical as well.
Is this something that is also happening that people should uh do as well in the industry?
I think that I would characterize it differently.
Like I okay, uh vibe coding is a PM.
One of the things that it gets me is for example, I don't need to go to knock need to go knock on a designer's door to like mock up a UI, right?
Like I can I can vibe code that and that lets me show off like ideas more rapidly without all that back and forth with design.
Just to again, not to like say that this will be the shipping product design, but just to like have something to show people.
And uh similar with the code, like if I want to understand if I want to show off some specific interaction that I'm focusing on, I can bycode that.
But it's not I wouldn't call that being more technical as a PM.
I and I don't think that that's a way to gain technical skills as a PM.
Like I still think you need the fundamentals of like computer science or you know, system critical thinking that maybe it helps with a little bit, but at the end of the day, like the PM isn't writing production code, you know, and I without those technical skills, I don't see that happening.
But that said, I I do think that for PMs who do have technical skills, it is a it remains a very high-leverage skill set.
And um, like I said, like with the PMs I've been talking to who have technical skills, they say it's indispensable.
And it's one of the reasons that they have been able to stand out among some of their peers.
Yeah, so I think in the end it's like two different disciplines, right?
So some people have a good spectrum of skills from both disciplines.
I think definitely those people will be highly valuable, and that's why people are uh keep talking about this product engineer, because now that the engineers maybe part of their work has been, you know, automated by AI and you know, churning code and you know, doing all this um, you know, fancy stuff, right?
Um now actually to increase improve on the other discipline, right, which is the product mindset.
Similarly, I think it could also happen with the PM learning more technical stuff.
But I think uh still they are these are probably too hard to expect one person to be good at at the same time, right?
So which brings me to Well, let me just like say one thing, which is like you you can like I said, like if you have a technical background, um you can definitely do both and and you know, a lot of founders are this way, right?
Like a lot of founders don't have they don't hire a PM until they're you know you know they're Kent higher or something and um they're just you know like it's so they have to be the PM at first.
So I do think that there's a lot of people that can do both, but I don't think vibe coding is your way to gain, you know, like vibe coding is not the route to that technical skills that yeah, like in fact.
So they I think there's a danger of uh, you know, um mis expectation, right?
So people now think with AI you can replace engineers, you know, to do vibe coding.
So I think like what you mentioned earlier is like production great quality.
I think this is something that probably sometimes is a hit and miss uh using all these AI tools.
We can still hear so many security issues or maybe bugs happening.
But I think one challenge as well, like how do you evolve the system?
Because I think AI now is kind of like not good in refactoring its own solution.
Maybe they could it can give you hints of what the system is all about, but still you need a technical ability to actually shape the system.
So people talk about, you know, maybe ratio of uh product engineer, sorry, ratio of product manager and uh you know engineering, right?
So I think this tends to change as well after the introduction of AI.
So, what do you think is a good ratio now?
Because if you're saying now you are also kind of like still the bottleneck and engineers now turning more code.
So, what do you think is a typical good ratio?
Or how should people shape their team structure?
Yeah, that's a good question.
I I I don't have a ratio for you, and it will depend on the company.
I feel like um there needs to be more product total, product thinking total in the orgs than there is today.
I have a ratio now.
Whether that comes in more engineers becoming hybrids or more PMs being higher hired, I don't know the answer.
But um, yeah, it it's gonna be a profound shift.
Like um, and the good news is like, you know, in a lot of these companies, like the product manager role is one of the few roles that's paid on the same pay ladder as the engineering role.
And so it's like it also has involves rare skills that are hard to acquire.
And so, yeah, I I would say that's um that's a good sign for f for engineers who are um you know, I think there's like three skill stats, right?
There's like people skills, there's system skills, and then there's product skills, and like you probably are going to need all three of those, but then you can kind of pick like maybe two of them to like it's gonna be harder and harder to get by with just one of the three that you're spiked on um as you as you become more senior.
So looking to pick two of them is probably a good uh a good idea.
Yeah, so I think um that's a very good tips, right?
So people, system, and product.
So I think uh now if AI can help a lot in terms of you know churning out code.
Um, but we all we all know, right?
As engineers also we we know like writing code is not the only thing that matters, you know.
You have still all this collaboration, defining what the right thing to build, right?
And also the other aspects, like for example, communication influencing and all that.
So do you think there's a good tips that you can give to engineering leaders or maybe stakeholders, you know, because the expectations they have now is like using AI, uh we can improve you know the productivity of engineering by a lot, right?
Even they're thinking about laying off engineers and all that.
So, what what tips that you can give maybe to you know engineering leaders or maybe these executives to um maybe um correct their mindset uh in in in a way?
Uh is there some something that you you can uh chip in here as well.
Yeah, sure.
I mean, if you're not already doing it, you know, asking why a lot is um is a good a good practice of just making sure you're creating in more and more context about what you're really trying to do.
Switching your viewpoint constantly between the system and the users, going back between those two indexes we talked about.
That's uh uh not an easy thing to do, and you can easily kind of get stuck in one or the other.
And so just switching, realizing when you need information from the other index is uh an important skill.
More writing down the stories and scenarios, and then sharing those with your team and using that as an as a mechanism to get alignment, right?
So one of the powerful aspects of stories that we didn't talk about yet is everybody understands stories, and so not only there are they good a way to discover potential problems that you might need to overcome in your product, but they're also a good way to communicate to other people whose brains probably work differently than yours.
But the story is that sort of medium of communication, or that you know, we a lot of us, you know, grew up hearing bedtime stories or reading children's books, and so we we've all read stories from an early age, and so a good way to communicate to people, and it's a good way to get alignment across a lot of people as you're a leader of like, hey, we all agree that these are the scenarios that we care most about.
Um, and then you share those stories and people nitpick them, and then you've got your like compendium of stories or your your like document full of stories that are like these are the ones we're going for for this milestone.
Uh is a great leadership technique.
And then finally, I mean, you know, finding ways for yourself and for your team to engage with users, customer support is one way.
One of the things that I see commonly missed is especially on consumer-facing businesses, is the walls go up because there's so many users and they got so much feedback and it's just so much noise, right?
And people have their hot takes.
And you can't get work done as an engineer if you're constantly dealing with like customer input.
Yeah, it's a little bit easier on a on like a business-to-business kind of B2B thing, but still, and even on an internal tools team, it can be distracting.
And so a lot of inst engineers instinctively put up walls.
What that means was they lose sight of what the users actually want.
And then that that causes problems.
Like, there was this um recently, I I owe I drive a lucid air used to do the car brand, um, electric car brand, and I drive elucid air, and the company was having a lot of quality issues, right?
Just with their software.
Like the hardware, the everything about the drive was great, but the software, there were software problems.
And it was hard to give them feedback.
Like it was like, and so they set up this email that you could just email address you could like users could just send feedback to it.
And then they had an AI sift through all of the feedback and figure out what the most important and most frequent things were, and then present that to the engineering team.
And they made this, they just made this big like quality release, and everybody's really excited about it and really happy about it because it's fixing so many problems.
And they had just, frankly, like the trick was just to like not lose the connection with uh I mean I'm I I'm probably minimizing some of the engineering stuff that happened but like because I'm I'm not with the company but they just found a way to reconnect with their users.
And so that was that would be my top advice is just like make sure you're staying connected with the users and then finding a way to balance the randomness of it from the the feedback.
And um it could be like getting reports from your support team to make sure that you're they're passing things through to you.
It could it could be lots of things but just find a creative way to to stay connected.
Yeah I think those are very good tips right I would say maybe if I can just um mention some of them like thinking more about why start writing more scenarios based kind write more documents um you know documenting all this user journey and scenario because I think that's a good way to actually collaborate and align your expectations with uh stakeholders product and engineers and then yeah engage with the users more I think this is uh quite straightforward but I think sometimes we neglect doing it.
So maybe now the advice for junior engineers because I know that you have been around in the industry you understand the impact of AI you also see uh the kind of product mindset needed um some juniors you know may have difficulty now to find a job simply because of you know this AI thing happening so what will be your good advice for juniors now because they are new to in the the industry they are not strong enough yet at the engineering level but at the same time people now expect them to have more product thinking is there's such practical tips for them that you can give them as well yeah this is a great question so I'll do my best being not a junior engineer anymore uh so like hopefully this doesn't come across as tone deaf.
One of the things okay so imagine you're doing a quiz and on the one hand let's say you're doing a multiple choice quiz and on the other hand it's a free form quiz where you have to like type the answer right it you're gonna learn better in the freeform quiz because in the in the a multiple choice quiz you can just look over the answers and you can see oh well it's gotta be this one because it can't be those other three and so a lot of that work of generating an answer was done for you by the author of the of the quiz and generative AI is effectively doing that for you it's basically like reducing something that was previously like something you had to work hard at to like a multiple choice quiz.
But you are also a generative intelligence.
And so, and that's an important I I still feel like that's a very important um way to train because and force yourself to do.
And so even if you've got something that could give you the answers, you're sometimes not using it or thinking critically of at least thinking critically and editing uh what it did, I think it's gonna continue to be important and it's going to differentiate the people who have a like steadier growth to their career and like ramp up to the level of getting a new job versus people who kind of stay stuck at this sort of like intro level, entry-level um skill set.
And then I think the second thing is like you could do two things with your extra time.
So okay, you're you can ship more code now, right?
Um, you can write more, or if you haven't gotten a job yet, you can you can write more apps.
And that's and that's a good thing to do, you know, just like doing more of that, but also consider some of the time that that's freed up to improve your skill set, you know.
Like, don't just do more code with the extra tools that you have, but develop some of these higher level skills, such as product skills, collaboration skills, ownership skills is another one that we we haven't talked about, but just skills of like getting things done and and and seeing them through end-to-end.
Those are all good ways to upskill and then be ready for somebody to hire you.
So, yeah, speak things through, don't just write the first prototype and then move on to something else.
Yeah.
Uh again, another analogy I haven't heard before about um, you know, using quiz uh versus the free form um kind of like quiz, right?
So kind of like explain about this.
Because yeah, I I believe uh if you use a lot more of these AI tools, yes, you're just giving given options.
Sometimes.
It's just one option, right?
Uh until you criticize it and ask it differently in the different prompts maybe ask them to tweak something.
So if you don't train that muscles definitely maybe we we don't even have a multiple choice quiz.
It's like one way quiz that you just you know clicking on and on right like a wizard.
But also I think the other thing is like uh shipping is definitely important but also don't forget the about the other aspects right I think the good thing now for me at least uh personally with AI I can ask all random questions that I'm interested in uh interested in when working on something that kind of like uh forces you to also learn something new right and if you're interested you can dig deeper you know through other materials, resources and all that uh including your book uh which I find um there are a lot of practical tips um for engineers to start having this product thinking mindset it's not like a theory thing but more practical steps that people can find as well so speaking about that as we move towards our you know end of conversation is there anything important um in your book that we haven't really covered today uh well I hope so um yeah, I mean it's so the the book is like really it's framed around these four pillars that you asked me about earlier, just you know, discover defined, um and uh it's showing how product skills are used at all four like stages in the in the journey.
And so it covers, you know, topics from product architecture to error messages, which is one of my uh favorite topics of like writing good error messages and that are actionable and help actually help users.
And um prioritization.
Yeah, there's lots of good stuff, dog fooding, so like using your own product and um and just how to write scenarios better.
So there's a bunch of different topics, sort of a s somebody called one of my readers called it the speed run through product thinking.
It was supposed to be very practical of like you know, much more applied to the engineering role than something you would read from like the design or the product community.
So yeah, there's a bunch of stuff, but I don't know that there's any one thing that stands out as uh critical to talk about now.
Yeah.
So I think yeah, dog fooding that uh thanks for share uh sharing that because uh I think some engineers don't actually use the product.
For example, so sometimes if you build B2B, right, sometimes it's also difficult for you to get access to.
But always don't forget if you have a chance, dog food your product, use your product because you can empathize with with the user's uh experience, which is you yourself, um, and try to improve your product thinking as well.
So uh Drew, thank you so much for sharing all this.
I hope people check out your book, uh, especially engineers who are now trying to become much more product-minded uh because it's very important skill in this AI age.
Uh, I have one last question uh for you, which is like uh tradition in my podcast.
Uh, I call this the tree technical leadership system.
Think of it just like an advice you want to give to the listeners to, you know, uh close this.
Uh, is there any version that you can share with us today?
Yeah, so I I guess number one would be to have metacognitive skills, which by that I would mean uh thinking about thinking, like stepping back and thinking, what am I good at, what am I not good at, what do I need to improve?
What do I need to, what is like my what are my superpowers, and where is it that I am the most leveraged as an employee.
I think it's just so critical to just be stepping back sometimes and thinking about how you think.
And this can reflect by being having a conversation with your manager, like, hey, like this is the kind of or like somebody you're thinking of like going to work for.
It's like, hey, here's my skill set.
Like, what do you think of this?
Like, this is what I'm good at, this is what I don't love as much.
And then also using that to decide, like, there's times in your career where you want to double down on your strengths, and there's times in your career where you want to show up your weaknesses, and just thinking strategically about that can go a long way towards making sure that you're happy and uh and productive.
So that would be one.
I think two is building ownership skills.
And by that I mean like I said earlier, seeing things through and being accountable to the outcomes is just always critical.
And it's the seeing that is the least is the thing that like LLMs are like the the furthest away from being able to do one of the fun things about ownership skills is that you then can be more uh in control of your audacity, right?
Like you can work on fewer failed products and and things like that because you're you're the one who can see them through.
And um, so that would be my second one.
And this third one is just take the time, take some percentage of your time to getting better, right?
Like at being curious, it could be learning more, it could be learning about this whole new AI thing, it could be going and thinking out what this Moltbot thing is, Moltbook thing is, uh, you know, whatever, whatever just being curious, it could be about practicing, it could be reading a book or a blog, but allocate a percentage of your don't let the company that you work for take away your time to becoming um better in your career.
You don't let them overload you to the extent that you're not still learning and not getting better.
Yeah, so I think that's the the last tip there, always uh very important, right?
Uh, sometimes also this is also my perspective, right?
So don't also let the company you look at kind of like drive where you should be, right?
What should what you should learn, right?
So for example, if you're working, I don't know, in the financial industry, you always learn about financial, but also like maybe spend time to actually you know learn other aspects of other jobs as well, because one day it might come handy uh for your next career.
So, Drew, thank you so much for your time today.
If people want to connect with you, find you online, ask you more about you know product mind minded um engineering mindset.
Is there a place where they can find you online?
Yeah, so I have a blog on Substack at Drew Hoskins.com.
You can connect with me there.
You can also reach out on LinkedIn.
I understand that LinkedIn doesn't always let you include a message, um, depending on the tier of account that you have.
But I will uh try to uh connect with you and see if you want to chat or have feedback about the book or looking for advice, you know.
I'm pretty open on on that platform.
Right.
So thank you so much for writing this book.
I think this is one of the rare materials that engineers can do to upskill themselves.
Um, you know, coming back to your theme, or you know, improving yourself, time to uh learn something outside of just the engineering aspects.
I know that we all talk about AI these days, but I think uh product mindset is definitely very critical uh in this era.
And yeah, and I hope people check out the book.
So thank you so much again, uh Drew for this conversation.
Thanks, Henry.
I loved your questions, they are really thoughtful.