
The Product-Minded Software Engineer - turingbook
https://blog.pragmaticengineer.com/the-product-minded-engineer/
======
sdnlafkjh34rw
There is a con to being a product minded software engineer. When you are in
organizations that do checkbox driven development (i.e. build features so it
looks like your product has the widest feature set), it can be disheartening.
You will ask why build this? and will get a believable answer. However, once
it get's built you will notice that no one pays attention to the feature (no
analytics, no reports, no iteration, etc.). At some point in the future, maybe
a year or two down the line, you will notice a huge bug raised with the
feature. Whoops for 20% of the users, it didn't work. You feel bad at first
for your bug, but then realize, that no users even noticed the feature gone.
Your suspicions that you were building something that didn't even matter are
confirmed.

This has happened to me a lot. I was on a team that was on one of the "most
important" projects to the company. We had the CTOs daily attention. You felt
important and we had a large team who worked hard to ship it in one year. It
was deemed a success by the CEO and myself and many of the team members got
staffed on other teams (basically the next highest priority project for the
company). Some other engineers got put on legacy duty for maintaining the
project. After a year, I barely heard about the project (we had so many new
projects) but we still maintained it and it was still on our website. 1.5
years later, I get a p2 bug that basically shows the whole product had stopped
working for 3 months due to a front end bug. I got pulled to fix the bug and
worked hard to find it and fix, but at the end I was demoralized because I
realized my team had wasted a year on a feature no customer cared about enough
to complain until 3 months after it stopped working.

Basically, it can be really demoralizing to be product minded engineer if your
organization is not. This happened in an org that heavily talked the talk
about product market fit and testing, but the truth was we were checkbox
driven. We just wanted the widest feature set among competitors (even if they
didn't always work).

~~~
jcelerier
> You feel bad at first for your bug, but then realize, that no users even
> noticed the feature gone. Your suspicions that you were building something
> that didn't even matter are confirmed.

Having been in a position where I was talking a lot to users, I can assure you
that they _do_ notice. But they won't report it, just shrug and have a
slightly decreasing opinion of your software.

~~~
AnIdiotOnTheNet
Says a lot about software developers and IT in general doesn't it? That users
would rather just work around the problem and continue doing their job than
even bother telling us about it.

~~~
bpizzi
Well, it does says a lot about users too. The typical user would have a hard
time describing a software problem beyond 'I don't know, it is just not
working anymore'.

~~~
robocat
That is a terrible attitude IMHO - why should they have to have to learn how
to talk to developers? Your cynicism towards “typical users” probably harms
you and your career.

I find that the vast majority of _people_ are not stupid: they have learnt
that trying to get things fixed is usually a waste of time. As a developer I
truly understand this from when I’ve tried to get others to fix their
software, and I am _very_ good at describing problems.

Regularly I am the one that created the software problem, and if I were a
better developer I would have avoided making the problem in the first place
(or had ways to detect it, or easy ways for my clients to tell me).

Edit: simplified.

~~~
bpizzi
> That is a terrible attitude IMHO - why should they have to have to learn how
> to talk to developers? Your cynicism towards “typical users” probably harms
> you and your career.

I think I'm sensing a bit of anger in your tone, looking how you move the
subject on my person. Sorry if I offended you in any way, it was not my
intention to offend anyone. Me and my career are ok so far, if that's of some
relief to you.

We are surely not working in the same area then. Mine is as a vendor of
enterprise stuff, for Big Corps. In my place, not relying in users' proactive
and qualitative feedback is a pretty decent attitude in my eyes, it tends to
deploying more reliable software, thus to invoices actually collected, which
finally leads to having an actual paycheck.

------
keyP
I've met Gergely, the author, a couple of times a while back and he's a great
guy and I think we work in a similar way. In the majority of my roles I was
initially hired as an engineer but then moved to engineering management and
the points highlighted in the article are very familiar.

I often found that features would be requested from product owners/business
and developers would implement it no questions asked but at lunch time,
developers would rant about the requested feature's value. When asked if it
should be brought to the PO's attention, I often saw the attitude of it not
being their problem, they're getting paid either way (whether that's a company
culture issue, general developer apathy, or burnt by past experience of
questioning management is a different question). I think product-engineers
feel a bit more invested in the product and have the soft-skills to influence
or provide feedback in a manner conducive to business listening.

In my teams, I try to foster this type of communication and I've noticed a lot
more developers opening up and providing valuable product-orientated feedback
which often has an upward positive spiral of them feeling more appreciated and
speaking more. Naturally a lot of engineers still want to just code and go
home but team culture can really highlight and encourage engineers who may not
be confident to speak up initially.

Ironically, as someone with more engineering experience on paper, it's been
tricky to find a job directly as any form of product or engineer manager, I
always had to go in as an engineer then be promoted after a year or so which
isn't always ideal (or referred via a friend). I feel Product and Technical
skills are still often considered mutually exclusive a lot of the time but I
think that's inertia from when technical skills were still considered a cost
to the business.

~~~
Nursie
Conversely, when such feedback and communication is overlooked or ignored,
over and over, engineers often stop giving it even when they are interested.

POs in my recent experience could benefit from listening more to their
developers, who often know the domain much better than they do. (Or perhaps
the wrong people are becoming POs)

~~~
abright
This, I've gotten pretty fed up with my current company because management
just hands out work with no real explanation. Even more frustrating is that
any significant technical design work is done in closed door meetings where
the only people invited are development and product managers.

I've stopped giving feedback and I'm nearly at a point where I've stopped
being interested. It frees up my mind and motivates me to work on my own
projects on nights and weekends so I can actually have a say.

~~~
keyP
I've had this happen to me and seen it happen as a third party. It's a
cultural issue and whilst I can see that difficult to change in large
companies, startups with this mentality often demoralise developers quickly
IME.

This is often how waterfall projects are/were run in large companies
historically but now companies want agile everywhere but they don't implement
the right processes to facilitate it. You end up with behind closed door
decisions, promises made by PO that it will be done in the next sprint, and at
no point has anyone with either the courage or technical know-how stepped in
to point out that it's not feasible.

------
daguar
The spectrum of (product engineer) <\---> ($NEEDS_A_NAME) has been one I've
encountered a lot and which I find is underappreciated in hiring and team-
building.

The way I think about it is that you're giving weights to one of two different
goals:

1\. Building the right thing

2\. Building the thing right

I've found that in early-stage work, you really really need to have engineers
who are more interested in (1) than (2). I'd probably say a product engineer
who's a good fit for early stage work probably has an 70%/30% mix of what
motivates them between these two goals.

The strongest product engineers also have a keen sense of the power of
MANUALLY handling some cases as a way to learn. At small scale, the cost of
manually handling something can be way lower than building for that case. So
another attribute I've seen is that strong product engineers are either okay
with or even actively enjoy supporting users in those edge cases, talking with
them as a way to learn.

I'd be curious to know how companies most effectively hire for and/or
cultivate these kinds of behaviors in eng teams.

~~~
ebiester
I'd say the word you're looking for is Software Crafts[man,woman] but I don't
necessarily believe the two are exclusive, but rather horizontal and vertical
axes.

There is a difference between someone actively making compromises between time
to market and features, and someone who doesn't understand how to write
software in a maintainable fashion but can get something quickly out to
market. There are even people who are good at neither.

~~~
rileymat2
This is an understated point, there is a difference between intended technical
debt and incompetence.

At a very micro level, yesterday I was looking at a simple JS object with 6
entries, and 3 different naming conventions. Doing even simple changes without
code-completion in the code base is mentally taxing.

------
ThalesX
This might sound like a rant, it probably is but I’m sick and tired of
articles that create this perfect personna, meddle in theory but behave like
they’re sprouting truths. The ninja rockstar developer, the amazing product
guy... I could write an article right now about any profession.

The reason you need the CPD (Coal/People/Dreaming) focused worker in your coal
mine is bacause he will:

1\. Understand that coal is an important product.

He will give himself to this quest and personal mission to understand how
people use coal and just how much society depends on it. This will push him to
better himself in its exploitation.

2\. Be a dreamer.

Most people will just wave their hand and dismiss the possibility that coal
extraction is a flatbed for innovation. Your coal focused worker will spend
all his time thinking about new ways to work with coal. That will increase the
creative output of the whole operation thus raising the bottom line.

3\. Be a people person.

Coal mines are dreary places that’s why your 10x coal worker will have social
skills. He’ll need to keep the people around him entertained and challenged so
that he may create friction value.

Anyway, turns out I can’t write a proper article in one go but I will end this
unsubstantiates comment by saying that most of these articles target the
management type that makes ill informed decisions based on blog aricles, and
the fact that this kind of feedback loop exists in the world infuriates me.

Later edit: just reread the article and got angry again. What’s the value in
this? Can we really throw such absolutes right now?

I’m sorry if the post author is somehow seeing this comment, it’s not a bad
post, it’s a bad post type _in my opinion_ as it brings nothing new to the
table.

Actually, it might make the reader feel like product developing is this weird
arcane _science_ and that unless he has those attributes he’s not this unicorn
product engineer, when the reality is that _most_ product engineers can’t
become what is described in this article because the work they do is tied to
reality, not to the rainbows and clouds world of our imaginations.

~~~
gregdoesit
OP here. I’ve written this based on what qualities I’ve observed several of my
engineering colleagues exhibit, who are pretty good at building products and
working with PMs. And who consistently get stellar feedback from business
stakeholders, certain teams going straight to them, to discuss new ideas.

I beg to differ the article is super generic, as it closes with very
engineering specific recommendations to build a “product-muscle” for developer
[1]. This is the kind of advice and coaching I give to devs around me who
would like to make more product/business impact.

[1] [https://blog.pragmaticengineer.com/the-product-minded-
engine...](https://blog.pragmaticengineer.com/the-product-minded-
engineer/#tips-to-become-a-more-product-minded-engineer)

~~~
ThalesX
Of course I am not going to argue with the person behind the article as the
simplest explanation is that I misread, misunderstood, misjudged etc.

However, I will ask you three questions to clarify this for me, of course
optional:

1 - Do you think it’s possible for one person to do half of the things you
listed?

2 - Do you think it’s possible for most product people to do most of the
things you talk about outside of companies such as Microsoft, Uber and
similar?

3 - Should the product minded engineer be interested in users or the
stakeholders?

~~~
gregdoesit
And I’m also not going to argue with people who have different experiences - I
can speak for my own experience, and generalise it, finding others who might
think similarly, which is what I’ve done here. This is to say YMMV. But to
your questions.

1 - Doing half the things I listed. I hope this is not a loaded question, but
I’ve seen people do all of them. It usually starts with people who are both
good communicators, are curious about the “why” on things, being interested in
how the business works. Then they bring product ideas. The nice you bring
product ideas to the table, as an engineer, making pragmatic trade-offs is
pretty straightforward (if we build a slightly modified feature, we can get
the same business impact, but a lot less eng complexity). The rest is about
looking out ways to get early feedback (prototyping, hallway testing etc) and
challenging weird edge cases. The first few of these I’m seeing a lot around
me.

2 - I don’t fully get the question about product people. Also, I spent a good
deal of my career working at Skype/Microsoft and Uber, so I don’t think I can
give a definite answer. If it helps, at Skyscanner, a smaller startup, I had
even more product say as an engineer, than I did at Uber or Microsoft. I
suspect everything I wrote assumes an environment where engineers are
empowered and close to the product, and data about the product usage/revenue
generated.

3 - I’d say have a lot of curiosity on how the product works and how users use
it, and generate value for the company. Then you need good communication
skills to build trust with the product stakeholders - to understand more about
the business, how they think, and to be able to showcase your ideas,
prototypes and accommodate feedback for them.

~~~
ThalesX
I did a little read through again and noted down my thoughts.

This is mostly in relation to my view that a single person ... would have
trouble, with filling all these roles within the 8 hours given per day and
under the assumption that he actually understands them all and is not just
winging it.

And I do get

Sorry for the sarcasm in the writing, it’s who I am and yes I do feel bad
sometimes.

—

> Product-minded engineers don’t settle for getting a specification and
> jumping to implement it. They think about other ideas and approach the
> product manager with these. They often challenge existing specifications,
> suggesting alternative product approaches, that might work better.

Do you do this for every backlog item? I have assumptions about all tasks I
receive and sometimes believe them to be less than ideally researched. Do I
challenge all the time? I feel like that would land me in a bad place with
multiple people over time.

> When coming with ideas, product-minded engineers don't just get these from
> thin air. They take the time to understand how the business works, how the
> product fits in, and what its goals are.

This is just a part of the paragraph, there are more ideas about user
preferences and data analytics. Business is constantly changing, the product
should ideally pivot based on user needs, goals change at least ocasionally.

In order to keep this loop going I personally feel like I either have to half
ass it and pretend like I understand so we can get the release ready by the
deadline or actually do this properly and that feels for me like a full time
job rather than a bullet point to do on the side as an engineer.

Sure, I can say I look at analytics and talk to users, set up blind interviews
and calls all the while following the business moves but _in my case_ I would
most likely be an impostor unless this would be a pretty large part of my
work.

> Curiosity and a keen interest in "why?"

Just pasting headline from now on as there is a lot of text.

This paragraph encompases the job title of business analyst, project manager
and business intelligence.

Let’s just assume I do have time in my workday for developer, business
analyst, project manager, business intelligence and business strategy.

So all the points up until now, I can do cause I am amazing. And not just half
ass them but fully get the ‘why’ and understand them all.

> They are smooth communicators, making it clear they're interested in
> learning more about how other disciplines work. I frequently see them
> grabbing coffee, lunch, or doing a hallway chat with non-engineers.

I know I said I’ll paste the title but this one flows nicely. Also, I am
obviously a bad communicator but an amazing marketing and sales guy cause I
spend the time talking to them about what they do all the time. But this is
just fun chat, understanding new domains of expertise, I can squeeze them in
my daily 8 hours.

> They also start making product tradeoffs, evaluating the engineering impact.
> They often go back to the product manager, suggesting a completely different
> feature to be built, given the product impact would be similar, but the
> engineering effort vastly smaller.

Architect, strategy, consultant. EZPZ I am 10x. But it’s doable, probably
becomes annoying after awhile but with the time I spent analyzing all my
product users and doing reports on them I probably come up with better ideas
than my colleagues who work full time on this.

> Because they do it all in their head, using their engineering and product
> insights, they get to valuable conclusions remarkably quickly.

Oh, I thought this was based on user data, nvm I just do it in my head. I
don’t need no data, I read it once and now my trimatrix quantum brain will
just curve fit for the optimal solution. I think my colleagues love me for my
mental abilities.

> This could be doing hallway testing with colleagues, showing the work-in-
> progress feature to the product manager, organizing a team bug bash on the
> beta build, and many other, creative ways.

I love how my whole team always has time for my ad-hoc bug bashings. I thought
I was the only one with the time needed to handle ~ 10 roles to perfection.

> They are continuously thinking:"how can we validate that people will use
> this feature, the way we think they will?"

A little bit of psychology right here, nothing much, will fit right in my
schedule, I’m only around 50% filled.

> It can take weeks to get enough reliable data to draw conclusions. Even
> though they might be working on a new project, they make checking on the
> results one of their top priorities. It's not a time-consuming activity, but
> it needs that additional persistence from someone wanting to know: how is my
> work really doing?

Oh, just some weeks of daily context switches to check on my baby. No boss,
I’m also working on the other tasks for which I needed to do all roles, but I
also log and audit the feature. Don’t worry, it’s not a time consuming
activity, I just need to:

> spend a good amount of time debating hypothesizes and learnings with the
> product manager and data scientists.

It’s ok, I just need to brush up on my data science. 51% filled.

Alright. What next, I still have 49% of my daily 8 hours. Oh I know, I’m going
C-Level!

> What is the business model? How is money made? What parts are most
> profitable, what parts of the company are expanding the most? Why? How does
> your team fit into all of this?

I don’t need no CEO, CFO, CIO and / or ang form of c-level. I got this guys.

There’s something missing though, my 8 hours are filled with so many roles and
I am still bored. I know!

> Pair with designers, UX people, data scientists, operations people and
> others, who frequently interact with users.

Can’t wait to brush up on my design and UX, luckily I already know Data
Science and Operations from my other roles. I’m sure I won’t bother the UX all
that much, he probably doesn’t do a lot of stuff anyway cause he’s not a
product engineer.

—

Anyway, I feel real bad for having you on the end of my stick for what is
really not a bad article. Just caught me frustrated with some aspects of it
and saturated. I think your insights are valuable, a good guide, but maybe a
bit too demanding of the role you are tryint to define.

So again, I am sorry, I know it’s not the easiest thing to get out there and
be exposed to unfounded criticism but these were my 2c.

Best of luck!

~~~
Hasu
There are several points here where you assume that as an engineer, you need
to learn to do another job entirely, here:

>This paragraph encompases the job title of business analyst, project manager
and business intelligence.

>Let’s just assume I do have time in my workday for developer, business
analyst, project manager, business intelligence and business strategy.

Here:

>Architect, strategy, consultant. EZPZ I am 10x.

Here:

>I thought I was the only one with the time needed to handle ~ 10 roles to
perfection.

Here:

> It’s ok, I just need to brush up on my data science. 51% filled.

Here:

>I don’t need no CEO, CFO, CIO and / or ang form of c-level. I got this guys.

>There’s something missing though, my 8 hours are filled with so many roles
and I am still bored. I know!

And here:

>Can’t wait to brush up on my design and UX, luckily I already know Data
Science and Operations from my other roles.

But I think the point you're missing is that you don't need to do all those
jobs fulltime, you just need to have a baseline level of understanding of the
underlying principles and needs of those roles. Which isn't that crazy - the
"product manager"/"product owner" roles are a smorgasbord of skills and
responsibilities, and most people who fill those roles aren't experts in every
single skill and responsibility, just like every engineer isn't an expert in
both kernel code and frontend frameworks.

The way I see it, the "product engineer" is between a product manager and a
full stack engineer - someone with a certain level of understanding of
different parts of the code, and different parts of the business, but not an
expert at any. A generalist whose generalist skills go beyond just the
engineering domain, but that doesn't mean they're specialized in all of those
skills.

Is it easy to acquire all of those skills, even to the generalist level needed
to be useful even though you're not an expert? No, of course not. But you also
don't have to do it all at once. Doing any of the items on this list can add
value, and once you get used to doing it, it's part of your daily routine.
Then you pick up something else. It adds up over time.

~~~
ThalesX
I understand you need to be a bit of everything.

When we talk on HN about managers that have technical competencies and try to
get into the development process we bash them for thinking they understand,
but we sometimes argue that we need to understand and do all roles and it
works...

I could make any list of desirable characterisics and it would make those that
follow it better professionals. Does the list of OP not match any other job
than product engineer? Would a tester not be a better employee with the same
understanding, or an HR person?

~~~
Hasu
>When we talk on HN about managers that have technical competencies and try to
get into the development process we bash them for thinking they understand,
but we sometimes argue that we need to understand and do all roles and it
works...

I can't speak for every conversation on HN, but personally, I have no problem
with technical managers that know what they're talking about, as opposed to
non-technical managers that attempt to make technical decisions. If someone is
trying to be a 'product engineer' but doesn't have the first idea what they're
doing about anything beyond software development, I agree that would be
counterproductive.

>I could make any list of desirable characterisics and it would make those
that follow it better professionals. Does the list of OP not match any other
job than product engineer? Would a tester not be a better employee with the
same understanding, or an HR person?

Well, it matches the job of... product. Which hasn't always been a separate
job from software development, and in some companies it still isn't.

I think there's a distinction to be drawn here, though. An HR person certainly
might benefit from insights into the company's business, talking to customers,
etc., and it very well could make them more effective at their job. But for
the person building the product, it's more relevant to what they're doing
every day, since it directly determines both the input and output of their
work. I suspect sales has a similar dynamic - understanding the customers and
the product is going to highly relevant. A software engineer who just
completes tickets and focuses only on purely technical problems might be
effective, just as a salesperson who thinks that selling cars, selling
software, and selling biscuits are all the same process might be effective,
based purely on talent in the relevant skills (strong technical skills for the
dev, strong interpersonal skills for the salesperson), but I'd expect the same
person to be much more effective if they added some of these product skills,
where the force multiplier isn't quite there for HR or Accounting.

Of course, not every skill is going to be helpful for every role. As a
software engineer, interpersonal skills are likely to be very useful, but
learning to close a sale probably isn't going to have much benefit. The point
of the article is that the author finds that software engineers who have these
product skills are much more effective at making good software than software
engineers who don't.

------
ridaj
As a PM I would agree that some of these traits are really able to increase
team effectiveness. For example, just in a recent project, we saved weeks of
work after asking the developer to be more upfront about tradeoffs.

However a big, big caveat on #1 "proactive with ideas/opinions" and #3
"curiosity and keen interest in 'why'". These are also traits of a different
kind of engineer — the opinionated one _with poor product insights_ and who
_isn 't interested in feedback_ and constantly derails the team by sharing
their thoughts on what we should and shouldn't do.

Of course I prefer working with an engineer with product opinions and who asks
why than one who doesn't, but if you're an engineer who's looking at this
article and thinking "oh, this says I should start blurting my opinions out
about the product more often and asking people why they are doing things the
way they are", well that doesn't work well. To be really efficient I think you
need to look at it more as "I should share and be curious about whether my
insights on product and strategy are valuable to the team", then listen to the
feedback about it.

~~~
tgtweak
As a product manager you should not be asking anyone to build you anything
without properly explaining the why. It starts with the why, and a good
engineering team will offer how+when. If you get overly involved in the how
you'll end up with ignoring that insight and the responsability that comes
with it.

Being on both the side of product and engineering, more often than not it's a
lack of collaboration and trust between the two that leads to poor products
and frustrated engineers. Your last paragraph hints at this.

 _Poor product insights_ \- some of the most competitive features I've seen
make it into a product found themselves there because an engineer decided to
build it to fix a pain point of their own (often after having that feature
request ignored by product owner)

Humor your engineers and give them creative ownership over a feature (from
suggestion to implementation)- you'll be surprised how effortlessly it comes
out.

"I should share and be curious about whether my insights on product and
strategy are valuable to the team"

Good advice for everyone in the team, wish it was followed unilaterally.

~~~
ridaj
> "I should share and be curious about whether my insights on product and
> strategy are valuable to the team"

> Good advice for everyone in the team, wish it was followed unilaterally.

Indeed, and this is how I approach my responsibilities as well. I grew myself
in service of the team rather than telling people what to do / not to do.

> Humor your engineers and give them creative ownership over a feature (from
> suggestion to implementation)- you'll be surprised how effortlessly it comes
> out.

From firsthand experience, it works well sometimes, and when it works it's
really magical. But it unfortunately doesn't work every time, because some
folks really just want to be told what to code (don't want to engage), and
other folks want to engage but don't have the skills (creativity, awareness of
the pros and cons of various relevant UX patterns, user testing, etc). I give
as much creative ownership as possible and really wish it could delegate it
entirely though (does make my job easier).

------
gatherhunterer
> They're someone who would likely make a good product manager if they ever
> decide to give up the joy of engineering.

Read: If they ever decided to stop working and start siphoning funds to start
their own company.

When companies are small the engineering managers are the product managers and
the product is good. When a company reaches the point of over-reaching they
divide their concerns and hire managers who don’t know how to build the
product and are paid to act like they are doing so while whipping engineers
who have no interest in the product. Big companies that make good products do
so by provisioning small teams with personnel who are essential to their
collective goal. They mimic the small company.

~~~
encoderer
Accurate

------
jiofih
I am a “product minded” developer and feel absolutely murdered after a couple
years at a large European tech co. The product, and teams, and goals, and
people, and managers and everything at all keeps changing over and over and I
never really see my efforts amounting to much. New people assigned to projects
come with their own agendas and all that you worked for is now forgotten. The
relationships you built don’t matter anymore.

At this point I think life would have been a lot easier if I did _not_ care
about product - and now I realize many have figured this out sooner than I.

~~~
fogetti
I am sorry to play the devil's advocate but aren't you one of those with their
own agenda's too? It's just matter of perspective how to judge yourself vs
others, and putting yourself into the `good guys` camp seems biased to me.

~~~
jiofih
A few examples: top-rank dev preserving power by slowing down growth for
everyone, designer pairing with executive to sidestep decision-making - and
destroy previous work by the team in the process, new people looking solely
for promotions, new managers caring more about looking good than helping the
product stay on track (i.e. replacing a very well-planned roadmap with vanity
or metrics-hacking features). Most of these result in developers now working
on things that have no real impact or don’t make sense for the product, and it
hurts.

You might be right, and it’s not fair of me to expect everyone to have the
same driving goals, but I simply miss the ability to focus on building
something good (for customers and the business) and everyone being in tune,
instead of catering to an endless stream of personal needs. Worse, in order to
“perform well” it forces you to prioritize saving face and pleasing people
over actual product/design/engineering, since half of your peers don’t care,
or will be gone by next cycle.

------
beaker52
I love product engineering. It's generalist++, and what I believe _most_
software projects need. However it is seen as a forbidden art in many
workplaces with strongly-defined structure.

I thought working at a tech "startup" was a perfect place for a "product
engineer". Trouble was, this startup was born out of a big ol' corporate.
Despite the mantra "we are a startup and have cast away the shackles of our
corporate mothership", acting as a "product engineer" was firmly rejected due
to the company's corporate roots. I'll never forget the conversation with my
(corporate-sourced) boss: "thinking about those kind of things is the job of a
product owner - maybe you should consider switching roles". My heart sank. I
didn't care about my job title.

So it turned out that I was treading on corporate-rooted toes by encroaching
on other people's areas. We weren't all tending to the same garden - people
had carved out their sections. It was how they added value and they weren't
prepared for someone else getting involved in their areas. It sucked. And it's
all too common, especially as organisations grow. Since then, I've made the
way teams work a bit of a special interest of mine.

Culture, or the way things are done, is the primary factor that leads to
declining performance of teams over time.

I'm also on the lookout for high quality jobs where I can stretch my legs. I'm
a fullstack dev who gets involved in _everything_. I'll lead your team whilst
you're not watching. I'm often hired to do stuff for which I have no
experience. Do get in touch if you need someone like me.

~~~
z3t4
I'm like you (and also looking for a job) and I think companies are scared to
hire someone that can do everyones work better. But as its very tempting to
dip into evey jar I appreciate that the others are there so that I can
concentrate on what Im most productive at.

------
quantified
I hope this article raises visibility of this mindset in engineering
management. I’ve always found product management very appreciative of the
product-minded engineer, but engineering management to be apathetic at best.
Engineering management is responsible for the engineer’s career, so their
ability to make the politics work out is critical. For example, minimum viable
needs to be viable, which costs more than the minimum that engineering was
incented to deliver.

~~~
LegitGandalf
Agreed. Most organizations I've been involved in will reward engineers for
creating 20k lines of code that don't solve a relevant problem over the
Product Engineer who creates 5k lines that solves valuable problems. The
Product Engineer Genba'd out of the building to see what was needed and
created the right thing, but since engineering management is often myopically
focused on metrics disconnected from value the Product Engineer is
significantly undervalued.

Combining ability with domain knowledge is extremely valuable, and a
significant portion of domain knowledge is gained by stepping away from the
keyboard.

Lean borrows the Japanese word Genba to describe this, which means 'actual
place' or 'scene of the crime' and this Product Minded Engineer is somebody
who is willing to Genba!

~~~
quelltext
Why did they have to use 現場?

Wouldn't "in the field" suffice as a term here?

[https://www.dictionary.com/e/slang/in-the-
field/](https://www.dictionary.com/e/slang/in-the-field/)

~~~
LegitGandalf
From my understanding lean came out of Japan, so some language seeped in.

I like to use it because sadly in-the-field has negative connations to a lot
of software engineers from being deployed on site via white hot angry customer
escalation.

Tldr; Genba's got no ptsd!

------
riantogo
Product Manager here with computer science background. In my 10+ yrs as PM I
have encountered engineers that I broadly classify in 3 buckets.

A) Product/business concerned eng as described in the article

B)"Know it all" product defensive eng

C) Pure technical focused eng

Working with #A is a great experience where not only do you move the product
forward but learn a ton yourself.

Working with #C is great especially for products that are driven by well
defined roadmap.

Working with #B is pure hell that I don't wish even on people I hate.

~~~
giancarlostoro
> B)"Know it all" product defensive eng

This is why I say often the best trait of a developer is humility. If you cant
handle someone telling you where you are wrong you are slowing everyone else
down with your dumb ego. Software bugs happen. To. Every. Single. Developer.

~~~
LegitGandalf
Amen, we're human developers, not compilers. A long time ago a colleague was
reviewing some code I wrote and he noticed I was uncomfortable with all the
stuff he was finding and he said "listen, we all miss stuff"

He's still right all these years of experience later.

~~~
giancarlostoro
Yeah, I used to have this problem myself, and now if I ever do the whole
egotistical thing it's between friends joking around, or against someone on a
forum whose being egotistical and I usually add references against their
programming urban legend logic. I think some of us enjoy programming so much
and it's like such a magical thing finding one thing you enjoy and are capable
of doing that you forget you're _always_ going to learn something new. I meet
great programmers who have no idea about front-end web dev or even the
opposite, amazing front-end developers who have no idea about back-end, and
nowadays mobile that dont touch either! Then there's other niches altogether
that dont care about any of the aforementioned disciplines / branches of
programming (heck, systems engineering and such).

------
Ozzie_osman
I have found that, very roughly, some engineers are driven mostly by solving
technical challenges and some are driven by building product ("product
engineers"). Neither is superior or more capable. Different teams need
different types.

Ask yourself what work you've done you're most proud of and why, and you can
know your rough archetype. Then find a place where you will be rewarded for
that type of work.

------
surprisedcat
To me "Product-minded" engineers defined here are mostly engineers who has the
willingness to go "above and beyond".

Some may have this willingness because of their intrinsic nature. Some may
have had this willingness but it slowly eroded because of many external
factors (i.e. not getting recognized or compensated for their "above and
beyond" work). Some simply have other priorities in their life (which I
understand 100%, I suspect I'll be in the same boat if I had kids).

I've always seen myself as a "product-minded engineer". However, recently I'm
struggling with keeping that mindset. Part of it is because of external
factors and part of it is because I've also started to prioritize my personal
life more. I do recognize that this is not black and white but rather a
spectrum but it is so much harder to be fully engaged to a product when you
are not giving it your 110%. :P

That being said I also believe it's also up to the company to foster and
reward this kind of engineers, instead of just asking engineers to be a
"product engineers"

~~~
ThalesX
I relate to your point of view and vented my frustration at the article.

You mention companies fostering and rewarding and I wholeheartedly agree. But
not just engineers, _anything_ that creates value for the customer.

I believe that the best products have the whole mission aligned and going to
the process of analyzing, testing, implementing, monitoring... then you don’t
need superstars, you just need good people with a clear positioning and
direction. I think it’s a simpler recipe than fishing for diamonds.

Getting an ‘awesome product guy’ cause you read it in a post is not going to
create a magical unicorn that you can ride to VC-Land.

You need a clear positioning of your company towards the product and the users
and then you don’t need John Carmack, Steve Jobs and Carnegie in your tram to
launch your new CRM, you just need to listen to your users and perhaps
disregard a lot of blog posts along the way.

------
29athrowaway
The ghostwriter software engineer: Do all the thinking, planning and work,
receive no credit for it.

~~~
ilrwbwrkhv
indeed... that is what majority of good software engineers are. they have
spent their lives sticking to computers and therefore are not good at
schmoozing people... hence they are often not credited at all.

------
jimbob45
I hate this line of thinking. If you're the kind of boss that makes your devs
jump through hoops before you're willing to empower them on product-level
decisions, your devs hates you and your product is suffering from your
micromanagement.

Empower your devs right from the start and stop pretending that you know
better than the devs who live and breathe the product every day.

------
jv22222
> "minimum lovable product"

I love that quote, and idea. Going to use it moving forward.

------
sanj
One question I have when I see articles like this is: what are the _downsides_
of this sort of person on a team? What kind of projects should they _not_ be
involved in? When are they the wrong person for the situation?

~~~
todayispotato
They will probably not be an extremely deep expert into specific technologies,
and they will burn out on doing work that does not involve improving the
product for actual users.

They want to deliver a feature, and sure they want to make sure it's being
used well, but they won't want to stick around to endlessly tweak it.

~~~
nevertoolate
I don't necessarily agree. Being a responsible product person both means
tweaking good features, sunsetting bad features and introducing new ones.

------
drngdds
>minimum lovable product

If I ever hear anyone say that in real life, I will die on the spot.

~~~
fizwhiz
That was pure cringe.

------
hughguiney
This advice might work at Uber or as a consultant but for FTEs it sounds like
a great way to get fired. I consider myself a product-minded software
engineer, but trying to be this person has been a sisyphean task pretty much
anywhere I’ve worked. In fact I have come to view that impulse to challenge
assumptions, to strive to do work I’m proud of, as an example of my naïveté as
a junior developer. Executives are not too interested in quality software;
they are interested in shipping whatever is in their head, whether it’s good
for customers or not. In startups they are interested in shipping literally
anything at all to meet insane growth targets so they don’t lose funding or
get replaced by the board. IME the only time interest in the product actually
helps engineers is during the initial interview where you need to demonstrate
your interest in the company’s mission. The reality is that despite how brainy
the job happens to be, employers do not pay developers to think; they pay us
to do the geek stuff they don’t understand. They view us, if you will, as pure
functions that take a set of orders as input and produce a functioning app as
output—no side effects please. This is why we’re going to be replaced by AI as
soon as it’s good enough, and are currently being replaced by no-code
products: we are already robots to management.

------
luord
Anyone having or willing to practice all of that should probably just create
his own product... Or at the very least should be paid quite a bit more than
the managers. Sure, I think that about engineers in general, but even more in
this case.

> minimum lovable product

Wow, had never seen that one. I feel like we have reached peak "elevator
pitch" speak.

------
dyeje
I've been calling myself a Product-focused Engineer the past couple years and
found it has been an effective way to express what kind of position I'm
looking for and skills I bring to the table when job searching. Glad to see
this topic proliferating more.

------
nevertoolate
I was soul searching for a while after reading the article and the comments.
It is not easy to become a person (engineer or not) whose product ideas others
trust in e.g. a single product company. It is doable though as I know one guy
who is described in the article from work.

How I can become one of those guys? That is a relevant question to ask if you
want to change. I think what the article misses as a good advice: have great
engineering skills and then you will have time to learn other things. But
first be really good in tech, that is your foundation. That's why you will be
a product engineer, not a product person.

~~~
r_singh
Depends, I reckon most of the audience here has the opposite problem, i.e.
great engineering skills, but bad feature prioritisation skills—which can be
attributed to relatively poor people skills.

------
ilaksh
It's called requirements analysis. I think it's primarily a social/political
challenge because it means asserting yourself in areas where business people
presume to be expert or may have been (often wrongly) given direct authority.
A big reason some people are more assertive about fixing requirements is that
they may have more social/political standing/skills than others. Often it's
not because they are the only ones who know better.

------
meerita
This article gave me chills of full product manager stack developer: a guy who
will be involved in all things to the point he makes it all.

~~~
quelltext
Indeed.

I'm not close to product development anymore in my dayjob but when I was I
used to be very product focused, often even more so than the product managers
I've worked with.

There often was no spec, no clear vision, and definitely a lack of
understanding of the product details. So, when you are an engineer who cares
about the product/company what do you do? You fill in the blanks, you do the
scoping, you do the project management, you write the documents to explain
everything to other teams. And of course during that time you engage with the
product manager to get signoff.

In the end though you are doing a lot more in total and a lot more work the
product manager should have been doing. And it's not easy because you come to
other teams/stakeholder from a position of less influence than a product
manager. In the end it's still the product manager who reaps a lot of the
reward and ownership for the product.

The benefits of the product focused engineer for product managers and the
company are obvious but what are the benefits for the engineers? Do they get
more compensation? The article mentions they get to become team leads
eventually, but it's not a given that product focused engineers want that.

------
franzwong
I have been working in a company that even developers didn't want to use the
product they built. They couldn't reach the "real" product owner and express
their views, or there were too many product owners, especially in enterprises.
All-hands meeting helped a little but it became politics when this came to
public.

------
afinlayson
At Google this is called UX Engineering. An experienced focused engineer that
works with UX Design to build prototypes of future features, products and
systems. I currently am working on multiple products that only exist because I
straddle UX, Engineering and Product.

~~~
sweetdreamerit
you are right. The goal of the research phase of the ux design process is to
understand the users' goals, needs, values, knowledge and mental models. The
design phase is aimed at identifying solutions that are able to satisfy those
goals and needs (better than the competitors) and, at the same time, the goals
of the stakeholders.

The "Product-Minded Software Engineer" is someone who has the opportunity to
be informed by the analysis of the user research data, and offers his or her
technical support to translate ideas and design in a working product or
service.

------
cryptozeus
Are there roles that target product developers ? What would that be called
when searching? Product engineer, project dev etc ? Would the interview be
different?

------
mherdeg
One great addition to this article would be to propose some pragmatic examples
and explain ways where people with different engineering philosophies would
approach each example.

This can be a risky thing to do because readers in their heads, and people in
the comments section "out loud", may end up debating the minutiae of the
specific example instead of the broader philosophy.

But it's also very pragmatic, which is, like, the point, right.

Give us some worked examples of times where the product-minded engineering
approach becomes relevant and we'll be readers who are more likely to
understand your vision.

Let me pick a few examples, I'm not sure all are good/bad, but they're all
cases where different kinds of engineers might do different things:

(1) We're building a web store. Do we insta-fail all orders that fail a fraud
check, or do we let them go through but cancel within 24 hr (before
fulfillment) if they haven't been manually reviewed, or what? If the fraud
vendor has an outage what do we do with orders we get during the outage?

(2) We're building a feature which mirrors something provided by a direct
competitor and should really exist. The UI the PM has specified is ugly and he
knows it and I know it but we have no design resources committed to the
project and timelines are pretty tight. Should I just build what he specced
and move on, or what? Is it my job to make sure the business has accepted the
limitations of this UI?

(3) I was glancing at a pull request that shipped last week and I found a bug
in our product which could expose user data to third parties. It's not my code
(I used to own this product area on a former team two years ago) and I have
other sprint work to ship. Also it's pretty obscure so I doubt anyone is using
it, but what should I do with this knowledge?

(4) I'm building an internal tool that is supposed to speed up development
work. We wrote a spec for the tool based on what the hard parts of the process
feel like to us, so, great, right? We're just gonna announce it? Does this
feel a little hollow, should we maybe have interviewed some of our peers or
colleagues first, or measured their work, to make sure we're building what
they need? How do we even do that and how much time should we spend getting
good at that before we go full steam ahead on the tooling?

(5) A friend showed me a pretty bad bug in our product where sometimes we show
a blank screen instead of the data you requested. I checked and it turns out
no one is measuring how often that bug happens to anyone, the product is kind
of messy in terms of how we gather customer feedback, and it's not on anyone's
roadmap to fix. Should I do something about that? What?

Just some thoughts.

------
jaequery
Product minded engineers with strong UX/design talent. How common or rare are
they?

------
sabujp
> Build a strong relationship with your product manager.

this x1000

------
celticmusic
oh hey look, the new buzzword. We're no longer paying out the nose of the 10x
programmer. oh no no no no, we're now paying out the nose for the product
minded programmer.

------
colund
In my opinion this kind of engineer sounds great on paper.

I personally much prefer working with people who put data before their ego and
work towards the goals of the team and the business - and challenge only when
there are reasons to do so -and avoid debates and the illusion of knowing
what's best for the user in every situation.

