Engineer's coding skills are maybe a little bit less
leveraged 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 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 might 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 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 engineer also, we know like
writing code is not the only thing that matters.
There's like three skill sets. 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 these higher level
skills such as product skills, collaboration skills, ownership
skills. So many conflict or
misunderstanding between product and engineer, how to handle this
kind of conflict? It's almost like speaking a
different language. Because with the engineer, their
brain is indexed around the system.
The product manager who's only thinking in terms of like the
user stories. But in my book, I call it the
great re-indexing, because when you're developing a product, you
start with the user journey and then you go to the system.
That's the great art of software engineering really.
Hey, quick pause. My goal with Tech Lead Journal
is simple. Learn from the best in tech so
we can all grow together. If this resonates with you, hit
subscribe to follow the channel. It's the biggest way for you to
support the show and help us keep bringing great guests and
insights to you. Thanks for being here, and let's
get back to it. Hello.
Welcome back to another new episode of the Tech Lead Journal
podcast. I have with me Drew Hoskins.
He recently published a book titled Product-Minded Engineer.
I think this topic is gonna be quite relevant in this AI age
era. People are talking a lot now
about being a product engineer, product-minded engineer.
They're kind of like similar. So welcome, 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, maybe let's level set in the very beginning, right?
Because this term has been coined for quite some time now,
product engineer. I think even a long time ago
when there used to be like a lot of scaleups, 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 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 of course, they're an
engineer, so they need to figure, they have to, they need
to understand the how, what, how they're gonna accomplish it.
But, you know, 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 technology do they
use to build it? That's a pretty good litmus test
for 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 do wanna underscore 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 who are other engineers in this case.
And those people have like usability problems.
They have requirements. So anything really from the big
to the small can be considered a miniature product.
So you can bring these skills no matter where you are in the
stack. I love how you define it very
succinctly, right? So an engineer who cares about
the why and the what versus just the how, right?
Because I think techies sometimes we love our languages,
our frameworks, and now it's like AI tools that we use.
But also cares so much about the why and the what that they
build, right? So I think that's a pretty nice
definition. So you mentioned a lot about,
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? Well, in consulting, I mean,
you're actually even more of 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 build a product for many
different users. That's one of the fun parts for
me. So I probably wouldn't be a good
consultant. 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, 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 why, right?
Coming back to what you said, I think is important in what you
do. So I think for, you have been
around for quite some time. You know, you have been in a
different companies. And actually when I look at your
history, I think you are kind of like perfectly suitable to write
this book. So you have worked in Microsoft,
you know, Meta, Stripe as, last is like a senior staff engineer
or something like that, right? So purely IC.
And then recently you moved into product management which is like
becoming a product manager. So tell us a little bit more
from learnings, from your learnings in these great
companies. And then what actually you meant
by, you know, switching to product manager now.
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 "hardcore", you know, I double majored in math.
I loved algorithms. You know, I was very much into
the how. And I ended up working on this
kind of compiler framework that was ill fated.
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 tools.
And my thought was who wants to code in Assembly language?
Like I don't, like I didn't like the vision.
I thought like all of our APIs were really hard to use.
But the C# 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 like a us- like an API usability
mindset over to, we were actually at C++ code base.
And so like, hey, let's like import some of the good work and
thinking that's like being done in the C# community over to 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
another API team were like, I'm gonna date myself here, but
tablet PC. It was like an inking interface,
you know, APIs for people who wanted to build like tablet
applications. And I did 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 prototypes. I mean, it was painful and it
was a big lesson, but also, like 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 that was a humbling
experience and really taught me that I needed to connect with my
users more. 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, hey,
here's what you should go do. But at Facebook, Facebook was
very much about this. This is, 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? And you have to be very good at
prioritizing your time or you're not gonna get...
And my first couple years, frankly, I kind of struggled
with that. My projects were hit or miss
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
Facebook was I founded this company called, or this, this
project called Ent schema, which was like a really powerful ORM
and sort of development platform for modeling our data.
Like our graph like 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, so to speak. Like I was a developer at
Facebook and then I became somebody serving developers at
Facebook. And so I had a lot of empathy
for that role because of 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 churning out code,
and - which I guess Claude, Claude Code is like a coding
machine archetype frankly - and a product engineering hybrid.
And I was considering going into management, 'cause 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, you're gonna go far.
So he helped me understand like sort of what my niche was at a
company where, you know, 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
churned 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 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 lots of experimentation.
But whereas at Stripe, 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 concensus building. There's a lot of document
writing and so you get a lot of people who are at Stripe, who
are very producty, first of all. Like Stripe has done a great job
of hiring product-minded engineers.
And secondly a lot of people were very collaborative.
And so I became a much better collaborator at Stripe.
And then, you know, finally, I moved to Temporal Technologies,
which is like a durable execution platform or you could
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 book that just came out with
O'Reilly. And I thought, well, and I 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, 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 chops 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 leap
of faith, but then the deal came through.
So, so yeah, so I've been a product engineer for a couple
years now. I mean a product manager for a
couple years now. Right.
Wow. I think, I can see the kind of
like learnings that you had in all these companies, right, that
brought you to your current role now.
So I think the, a few theme that I like to call out.
Like for example in the beginning you learn about, you
know, product thinking, usability of the users, right,
using your product. And then at Facebook, you learn
about entrepreneurial 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, which is, now you're doing a the product management
itself, right? So I think when you did the
switch, what was your biggest struggle, maybe should I say?
Is it like not being able to produce code more or like what
kind of things that you struggle in the beginning when you switch
to product manager? Oh, in this last couple years,
you mean at Temporal? Yeah.
Well, I mean, okay, so I did take a downlevel to become a
product manager which I was happy to do.
I mean, 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 10 years out.
Don't like think of a down level as like a career setback.
'Cause you'll get back, you know, to the level that you
were. And so yeah, look, five 10 years
out when making these transitions.
And so that was fine. I was okay with that.
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, 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 asking 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, but I'm also influencing the
go-to-market teams and other folks around the company.
And so just the stakes are higher.
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're 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 these type of
engineer, right, product engineer, I think I can see, 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 think
they're always around in meetings.
You know, 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 beyond what the PM has written,
maybe or beyond just what the engineer has written, which is
typically just one or two lines. So these are some of the traits
that I see. So maybe from your observation
as well for people in the industry, at your side, what are
the skill gap that are still kind of like missing, you know,
for an engineer, a pure engineer, a techies 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
the user scenario. And so what is that?
I mean, it's basically a story about, you know, the way that
engineers are gonna interact. Or sorry, the way that users are
gonna 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 going to tell little stories in the conversation that
are gonna 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
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 like some other
level engineer is gonna start with just thinking like, let's
say, you're working on a coffee ordering app, right?
And they're gonna think about the like click the pay now
button or something, right? And then 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 happens 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?
Maybe you should be catching state from previous interactions
to speed up, speed it up. And so you start thinking about
this 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 before? Well then maybe you've got some
sort of favorite system that you're providing, that help them
reorder things that they've reordered in the past and cut
out a lot of those checkout steps.
And then, you know, you start thinking more about the
customer's situation and empathizing with the customer
more deeply. Like maybe that customer is
actually on their commute and they're gonna pick up their
coffee on the way to work. 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 and more
product-minded, you start flushing 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, 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, so that's the sort of
like in just 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 more fluff 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 say that, right?
Understanding the persona, the impact, how they're using your
products. But for some engineers, they
will think this is the job of product manager, right?
So, what they expect is like, okay, they do the this kind of a
story, you know, scenario and all that.
Then they will write a ticket for me and I'll just, I just try
to understand from the ticket and implement that.
So 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 experience on how to handle or navigate this
kind of conflict? Yeah, no, you're absolutely
right. I mean, 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, 'cause
there's no PMs in that. And then when I have had a PMs,
they're often very busy and they don't think in the level of
detail that is like there's a lot of product decisions to be
made that are kind of underneath the level at 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. Imagine like, it's almost like
speaking a different language because the engineer, their
brain is indexed around the system, right?
They've got like the system diagram in their head.
They have the UI mockups and the relationships between the
different UI screens. And then you've 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 very painful.
And so having a person who has both indexes in their head, even
if they may be 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 a thing that I need to do.
Then you can identify that non indexed, you know, reads are
gonna be a risk, right, based on the scenarios that 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'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 maybe 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 writing a test
that's just very, very likely to occur in production because
that's what users, you know. Like if your homepage has a
default query of your database, like maybe your Netflix, and
there's like the homepage query is the thing that's gonna happen
all the time. Then you write a test for that
scenario, right? And so upleveling 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
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 or start asking them like for more
context. And then you'll build that
muscle. Yeah.
So I like your analogy just now about two different indexes, in,
you know, the people's mind, right?
So one is indexed more for, 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 haven't
heard before. So I think for engineers who are
still struggling, like what do you mean by, you know, different
mindset so this is one analogy that I think we can use.
So I think writing scenarios is...
Oh, sorry. I was just, in my book, I call
it the great re-indexing because basically like when you're
developing a product, you start with the user journey and then
you go to the system and it's like a kind of a bit of a
process to get from one to the other.
You know, it's actually, that's the great art of software
engineering really is basically just re-indexing.
Yeah. So I think this is also
something that we can use practically, right?
So whenever we are in the, like for example in the
non-engineering discussion, we have to remind ourselves, switch
our index. Use the other brain, probably,
the other parts of the index to actually, you know, talk more
rather than, you know, still at the architectural system level.
So, yeah, writing scenarios is definitely something very easy,
practical for engineers to step up, right, in terms of having
product engineering mindset. But in your book, you also kind
of like cover like four different pillars, right?
You mentioned about Develop, Deliver, Discover, and Define.
I think this framework is, I feel is very, you know, strong,
so that people know what is the roadmap for them to improve or
increase their product-minded, product mindset, right?
So tell us about this framework. How do we actually use it and
what do they entail, actually? Yeah.
So this is called the Double Diamond Framework.
And 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.
Picture two diamonds like side by side, right?
And so like, you've got 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 the
heck you're gonna do. And then you are talking to
customers, figuring out what the problems they have.
And then you go to the Define phase, which is like defining
the product you're gonna build that will solve their problems.
And that's like a convergent phase because you're trying to
like figure out exactly what you're gonna do based on the
things. And then you get to the how
stage, which is like the Develop 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
refactoring, starting to play with different database,
architectures and, or depending on your domain, you know,
whatever technical challenges that you have.
And then it's finally Deliver, which is again, a narrowing
phase where you're starting to polish and test and get it out
to production and experiment. Or and like do, like to do your
like, metrics and A/B 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...
And sometimes they even skip all the way 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 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 Develop phase.
It sounds like you're in the Define phase or whatever.
And a good way of resolving this tension because then you can
have an explicit conversation about where you are in the
roadmap. Even if you don't have some
grand process built around these four phases, you can still kind
of use it day-to-day. Right.
So I totally understand when you mentioned 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, you know, the ticket for them to work on, they
develop. And not only that, they stopped
there. So the, what do you call it?
The dis... 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, 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 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, they have to
discover your feature. 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 10th of the
cost of building it, right? And 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 in the error
message as it's 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 core thing built and now it's about putting in the
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've made, it
helps your manager understand what you've done.
Right. So, yeah, 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?
'Cause it's not so easy to get a metrics if you just deploy it
and put it out there, right? So I think, this also comes back
to how you develop the stuff as well.
So I think, what I think you are trying to say is like this
framework exists but we are not asking engineers to be good in
all of them, right? But at least know some aspects
of them, be part of the discussion, you know, in order
to shape the feature much better.
How do you think the engineer should think about now you have
these pillars now? Do I need to always be involved
in all different phases when I build a feature?
Or like tell us practically, how do you use this framework in our
day-to-day life? Yeah.
So if you are, if you don't have access to a PM, then would need
to be involved in all four phases.
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 think that you can help the PM narrow down the
possible solutions. Like there's no point in 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 role for an
engineer early in the Discovery phase.
And then starting with the Define phase and on to Develop
and Deliver, the engineer's gonna get much more involved.
I personally, have things I enjoy about all four areas, so.
Yeah, so thanks for that addition, right?
So I think narrowing options itself, knowing what is the
possibility to build. Because for example also if you
work on legacy product, right? You know, the challenges, the
constraints, you know, with the current architecture, the
current system. So you kind of like know what
options that the PM has, so that you don't fight in the end.
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 sales person 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 read the,
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 doing, which is
gonna help me make decisions later in the project when the PM
underspecifies 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 anybody that they think 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 relatively low work
to just tag along with some of these other roles as an
engineer. Sometimes you can provide some
insight to like, especially if you're working on a technical
product, right? Where you can provide a deeper
understanding to your customers 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. It's okay to tag along or to
watch the video transcript, right?
'Cause you're gonna be learning. So don't just assume that
because you're not gonna be providing value mean that, this
doesn't mean that you shouldn't at least understand what's going
on there. I think that's a very good tip,
right? So, I think even though you
don't have something to sort of contribute, you can still learn
from those experiences. So you mentioned something very,
interesting, right? Engineers now themselves can
also use LLM to kind of like learn from all those things,
like transcript conversations. And now I think it's a good
segue to talk about a AI impact to, you know, engineering,
product engineering and all that.
Because I think one aspect that people kept talking about is
like the impact of AI. Now that we can produce code
much faster, engineers now have more time presumably to start
thinking about, you know, the product aspect.
So what do you think personally for your situation, right?
What is the impact of AI with maybe your role or maybe the way
you see it for product engineer? Yeah.
Yeah, I'm absolutely trying to figure this along out, along
with everybody else at this point.
One thing I'll say, a couple things here.
One is at my company Temporal, product is a bottleneck right
now. And I think it's feeling like
increasingly a bottleneck. One of the things that I started
to see is a lot more prototypes coming out of engineering, is
just completely awesome, right? Like I love seeing, you know,
all these demos every, you know, in our sprint showcase 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 decision making that
it takes to get it out? And, so yeah, I would say, you
know, what Kent Beck was saying recently about my book was that,
you know, Drew was helping to heal 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 sides
haven't been talking to each other.
Like if you, one of the reasons I wrote the book was because
there was no engineering literature about some of these
topics. And 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, what Else van der Berg calls M-shaped people, right,
who've got like spikes in engineering skills as well as
spikes in product skills. And 'cause it's such a leveraged
combination, especially in the age of AI and especially when,
you know, engineer's coding skills are maybe a little bit
less leveraged than they were two years ago.
And so, you know, I think some folks will shift over to product
but that's sort of... but I thought, 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.
And I might go back, I might, I'm actually kind of jealous of
like the engineers right now 'cause they have all these
amazing new tools that they're getting to use.
And I'm like, I'm kind of missing out on it.
Like I'm using Claude Code and some, and I'm writing some
samples and stuff. But like, it's not really, it's
not really the same. And I'm missing out on some of
the fun, so maybe I'll go back and be a hybrid engineer again.
Right. So I think that's a very good
experience that you're experiencing, right?
So, but because we talk a lot about engineer having more
product mindset, is there such 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, Bolt,
Replit kind of tools to actually build prototypes themselves as
well. So what is your thought on this
like PM becoming more technical as well?
Is this something that is also happening that people should do
as well in the industry? I think that I would
characterize it differently. Like okay, vibe coding as 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 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 is gonna be shipping product design, but just to like
have something to show people. And similar with the code, like
if I wanna underst- if I wanna show off some specific
interaction that I'm focusing on, I can vibe code that.
But it's not, I wouldn't call that being more technical as a
PM. 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.
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 do think that for PMs who do have technical
skills, it is, it remains a very high leverage skillset.
And 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 keep
talking about this product engineer because now that the
engineers, maybe part of their work has been, you know,
automated by AI, you know, churning code and, you know,
doing all this, you know, fancy stuff, right?
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 still 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 can...
Like I said, like if you have a technical background, you can
definitely do both. 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, their 10th
hire or something. And, there's just, you know,
like, so they have to be the PM at first.
And 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 skillset.
Yeah. As far as I can tell.
So I think there's a danger of, you know, missed expectation,
right? So people now think with AI you
can replace engineers, you know, do vibe coding.
So I think like what you mentioned earlier is like
production, great quality. I think this is something that
probably sometimes it's a hit and miss 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 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 a product engineer.
Sorry, ratio of product manager and, 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 churning 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 don't have a ratio for you and
it'll depend on the company. I feel like there needs to be
more product, total. Product thinking total in the
orgs than there is today either ratio.
Now whether that comes in more engineers becoming hybrids or
more PMs being hired? I don't know the answer.
But, yeah, it's gonna be a profound shift, like.
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 would say that's a good sign for engineers who
are... You know, I think there's like
three skill sets, 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 as you become more senior.
So looking to pick two of them is probably a good idea.
Yeah, so I think that's very good tips, right?
So people, system and product. So I think now if AI can help a
lot in terms of, you know, churning out code, but we all
know, right, as engineer also 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 expectation they have now is
like using AI 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 tips that you can give maybe to, you know, engineering
leaders or maybe these executives to maybe correct
their mindset in a way. Is there some something that you
can chip in here as well? Yeah, sure.
I mean, if you're not already doing it, you know, asking why a
lot is, is a good practice of just making sure you're bringing
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 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 an important skill.
More writing down the stories and scenarios and then sharing
those with your team and using that 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 are they a good
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 all 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'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 if you're a leader of like, hey, we all agree that
these are the scenarios that we care most about.
And then you share those stories and people nitpick them.
And then you've got your like compendium of stories or your
like document full of stories that are like, these are the
ones we're going for, for this milestone.
It's a great leadership technique.
And then finally, I mean, you know, finding ways for yourself
and for your team to engage with the 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've 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. You know, 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 engineers
instinctively put up walls. What that means is they lose
sight of what the users actually want.
And then that causes problems. Like there was this, recently, I
drive a Lucid Air, Lucid the car brand, electric car brand.
And I drive a Lucid 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.
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, that 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 'cause it's
fixing so many problems. And they had just, frankly like
the trick was just to like not lose the connection with, I mean
I'm probably minimizing some of the engineering stuff that
happened, but like, 'cause I'm not at 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 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 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, mention some of them.
Like thinking more about whys, start writing more scenarios
based kind, write more documents, 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 stakeholders, product and
engineers. And yeah, engage with the users
more. I think this is 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 the kind of product
mindset needed. 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're new to in the industry, they're
not strong enough yet at the engineering level, but at the
same time people now expect them to have more product thinking.
Is there 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.
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
freeform quiz where you have to like type the answer, right?
You're gonna learn better in the freeform quiz because in the
multiple choice quiz, you can just look over the answers and
you can see, oh, well it's gotta be this one 'cause 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
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 still feel like that's a very
important way to train and force yourself to do.
And so even if you've got something that could give you
the answers, you know, sometimes not using it or thinking
critically of at least thinking critically and editing what it
did, I think it's gonna continue to be important and it's gonna
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 skillset. 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?
You can write more, or if you haven't gotten a job yet, you
can write more apps. 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 skillset. 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 haven't talked about, but just skills of like getting
things done 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, see things through, don't just write the first
prototype and then move on to something else.
Yeah. Again, another analogy I haven't
heard before about, you know, using quiz versus the freeform
kind of like quiz, right, to kind of like explain about this.
'Cause, yeah, I believe if you use a lot more of these AI
tools, yes, you're just giving given options.
Sometimes it's just one option, right?
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
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 shipping is definitely
important, but also don't forget about the other aspects, right?
I think the good thing now for me at least personally with AI,
I can ask all random questions that I'm interested in when
working on something that kind of like 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, including your book, which I
find there are a lot of practical tips 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 in your book that we haven't really covered
today? Well, I hope so.
Yeah, I mean, it's, so the book is like, really, it's framed
around these four pillars that you asked me about earlier to,
you know, Discover, Define. And it's showing how product
skills are used at all four like stages in the journey.
And so it covers, you know, topics from product architecture
to error messages, which is one of my favorite topics of like
writing good error messages and that are actionable and help,
actually help users. And prioritization.
Yeah, there's lots of good stuff.
Dogfooding so like using your own product and just how to
write scenarios better. So there's a bunch of different
topics. It's sort of a, somebody called,
one of my readers called it the speedrun your product thinking.
So it's 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, critical to talk
about now. Yeah, so I think, yeah,
dogfooding, thanks for sharing that because I think some
engineers don't actually use the products.
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, dogfood your
product. Use your product because you can
empathize with the users experience, which is you,
yourself, and try to improve your product thinking as well.
So Drew, thank you so much for sharing all this.
I hope people check out your book, especially engineers who
are now trying to become much more product-minded, because
it's very important skill in this AI age.
I have one last question for you which is like a tradition in my
podcast. I call this a three technical
leadership wisdom. Think of it just like an advice
you wanna give to the listeners to, you know, close this.
Is there any version that you can share with us today?
Yeah. So I guess number one would be
to have metacognitive skills, which by that, I would mean
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, if 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 workforce.
Like, Hey, here's my skillset. 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 wanna
double down on your strengths and there's times in your career
where you wanna show up your weaknesses.
And just thinking strategically about that can go a long way
towards making sure that you're happy 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 thing that is the least, is the thing that the
like LLMs are like the furthest away for being able to do.
One of the fun things about ownership skills is that you
been, can be more in control of your own destiny, right?
Like you can work on fewer failed products and things like
that because you're the one who can see them through.
And so that would be my second one.
And the 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 figuring out what this Moltbot thing is,
Moltbook thing is, 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 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 last
tip there always, very important, right?
Sometimes also this is also my perspective, right?
So don't also let the company you work at kind of like drive
where you should be, right? What you should learn, right?
So for example, if you're working, I dunno, in 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 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-minded engineering mindset, is there a place where
they can find you online? Yeah.
So I have a blog on Substack at drewhoskins.substack.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 depending on the tier of
account that you have, but I will try to 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
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. You know, coming back to your
theme, you know, improving yourself, time to learn
something outside of just the engineering aspects.
I know that we all talk about AI these days, but I think product
mindset is definitely very critical in this era.
And yeah, and I hope people check out the book.
So thank you so much again, Drew, for this conversation.
Thanks Henry. I loved your questions.
They're really thoughtful.