The Product-Minded Software Engineer(blog.pragmaticengineer.com)
blog.pragmaticengineer.com
The Product-Minded Software Engineer
https://blog.pragmaticengineer.com/the-product-minded-engineer/
150 comments
> 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.
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.
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.
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'.
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.
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.
> 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.
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.
Which would have been sufficient, probably. But they think it's so obvious that someone must have reported it already.
I usually try to make a point of educating the users that, when it comes to software, there is no such thing as "it is not working". Software always works; it might work incorrectly, unexpectedly or confusingly, but the only way for software to "not work" is that the hardware never switches on at all.
Says a lot about people tbh. I've had frontend dev's work around backend issues instead of reporting them.
[deleted]
I have two points for you.
1. There are many extremely important features that may only be needed once or twice a year. For example I work in developing cost estimating tools. The tools I build are extremely important, but some of them may not be used for 8+ months out of the year and new bugs could go unnoticed for quite a while. Unless you are familiar with the internal processes of customers this could easily be true for your product features as well for reasons that might not make immediate sense and you wouldn't even know.
2.I would argue that being a product focused engineer requires you to go the extra mile and learn about customers business processes. Product Owners should include engineers in some meetings for use case analysis and voice of customer interviews. I also find it extremely valuable to personally provide support directly to some of the highest value customers because you will learn what you need to know in order to implement features better and requiring fewer updates/changes down the road.
1. There are many extremely important features that may only be needed once or twice a year. For example I work in developing cost estimating tools. The tools I build are extremely important, but some of them may not be used for 8+ months out of the year and new bugs could go unnoticed for quite a while. Unless you are familiar with the internal processes of customers this could easily be true for your product features as well for reasons that might not make immediate sense and you wouldn't even know.
2.I would argue that being a product focused engineer requires you to go the extra mile and learn about customers business processes. Product Owners should include engineers in some meetings for use case analysis and voice of customer interviews. I also find it extremely valuable to personally provide support directly to some of the highest value customers because you will learn what you need to know in order to implement features better and requiring fewer updates/changes down the road.
That scenario is common even at product driven environment.
As an engineer, I try pushing back to reduce the scope of a product down to a MVP that can be released earlier with analytical data monitoring its usage.
As an engineer, you can identify the features that take the most time to implement and can see about pushing back to a version 2 release. If it is a critical feature, then try to find alternative solutions that can be implemented in less time.
That way if a product is a flop, you didn't waste all your time. Even if it is a success, the MVP is often good enough and they still deprioritized the extra bells and whistles.
As an engineer, I try pushing back to reduce the scope of a product down to a MVP that can be released earlier with analytical data monitoring its usage.
As an engineer, you can identify the features that take the most time to implement and can see about pushing back to a version 2 release. If it is a critical feature, then try to find alternative solutions that can be implemented in less time.
That way if a product is a flop, you didn't waste all your time. Even if it is a success, the MVP is often good enough and they still deprioritized the extra bells and whistles.
I relate to this hard. I joined a company a while back where everyone below a product manager (there was little real 'engineering' management) was a line on the factory floor to delivering features, and fixes.
PM would hold a monthly sprint planning/refinement, 'senior' engineers would participate in breaking each piece of work into tiny, tiny tasks, and then split them up into streams of designer, developer, tester.
Each tiny task would take an hour-half a day and you wouldn't even necessarily be working on the same code base across tasks, just continually turning out tiny 1-3 point tasks.
That was by far the most soulless job I ever had, weeding these companies out is my number one priority when interviewing.
PM would hold a monthly sprint planning/refinement, 'senior' engineers would participate in breaking each piece of work into tiny, tiny tasks, and then split them up into streams of designer, developer, tester.
Each tiny task would take an hour-half a day and you wouldn't even necessarily be working on the same code base across tasks, just continually turning out tiny 1-3 point tasks.
That was by far the most soulless job I ever had, weeding these companies out is my number one priority when interviewing.
What are some questions or flags you use to weed those out? How well have they worked?
Would a UI test have cought the bug?
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.
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.
>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
I guarantee engineers love working for you because of this. If you look at Maslow's hierarchy of needs you are filling that esteem portion that is really lacking for a lot of software engineering teams in the wild.
I guarantee engineers love working for you because of this. If you look at Maslow's hierarchy of needs you are filling that esteem portion that is really lacking for a lot of software engineering teams in the wild.
Thank you, I like to think so. A lot of how I manage my teams come from my experience as an engineer and seeing all the approaches that demoralised my friends and colleagues.
A lot of it isn't a complex secret, it's really doing what you pointed out - make people feel appreciated, listened to, and actually part of the company as a whole as opposed to just a resource. This can be as simple as being more transparent as to why a feature has been requested, even if it's counter-intuitive to reason, or giving context as to where the roadmap is heading so that they're aware on why they're working on something.
A lot of it isn't a complex secret, it's really doing what you pointed out - make people feel appreciated, listened to, and actually part of the company as a whole as opposed to just a resource. This can be as simple as being more transparent as to why a feature has been requested, even if it's counter-intuitive to reason, or giving context as to where the roadmap is heading so that they're aware on why they're working on something.
I've run into so many people in organizations who look at me like I'm from another planet when I start asking "why".
As an engineer I've always found that knowing why, knowing that there is a real customer out there who really wants what I'm making is very motivating.
So often people just come to me because their boss told them to go get engineering to make this thing. They don't know why, and sadly, their boss doesn't know why either as it was just passed to them from an executive mandate. And there is lots of pressure to get to done ASAP!
As an engineer I've always found that knowing why, knowing that there is a real customer out there who really wants what I'm making is very motivating.
So often people just come to me because their boss told them to go get engineering to make this thing. They don't know why, and sadly, their boss doesn't know why either as it was just passed to them from an executive mandate. And there is lots of pressure to get to done ASAP!
Agreed, same experience for me as an engineer and it's often the engineers who get the blame as their output is the most tangible in that chain of command.
I believe this is why some of the best Product Owners I've worked with have some understanding of the technical side so that they can push back at the point of feature request rather than accept everything to please business/the client and lay it at the feet of engineers a few weeks down the line.
For this reason, I think the engineering manager/technical product owner type of role should start becoming a bit more common especially in startups, where I've seen first hand, POs brought in who subsequently drive products into the ground that were initially engineering led (and which raised the investment in the first place).
I believe this is why some of the best Product Owners I've worked with have some understanding of the technical side so that they can push back at the point of feature request rather than accept everything to please business/the client and lay it at the feet of engineers a few weeks down the line.
For this reason, I think the engineering manager/technical product owner type of role should start becoming a bit more common especially in startups, where I've seen first hand, POs brought in who subsequently drive products into the ground that were initially engineering led (and which raised the investment in the first place).
I don't understand this at all. The first 18 years of my career I never saw any boundaries between those who spoke to customers and designed the software and those who wrot it and I those who tested it. It was always encouraged to fill all those rolls. People who were good at the why got helped up to speed on c++ and the stock programmers got a crash course in domain knowledge an a refresher on the bits of relevant math. Only in the last couple year have I started meeting programmer that didn't wan to learn the domain, and started feeling pressure that because I do (now) uderstand the domain, I shouldn't waste my time programming. We made better software when we were all expected to be multi discipline.
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)
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)
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.
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.
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.
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.
I bet that at the same time they also complain that devs aren't "engaged" enough!
> Conversely, when such feedback and communication is overlooked or ignored, over and over, engineers often stop giving it even when they are interested.
This is true but I find if I can explain why the feedback was overlooked, that can help diminish the negative feeling. It hasn't happened often in my experience but sometimes when it has, if the idea is feasible and won't detract too much from the critical path, I would push the business team a bit harder to allow it so as to avoid the constant ignoring feeling that can happen.
This is true but I find if I can explain why the feedback was overlooked, that can help diminish the negative feeling. It hasn't happened often in my experience but sometimes when it has, if the idea is feasible and won't detract too much from the critical path, I would push the business team a bit harder to allow it so as to avoid the constant ignoring feeling that can happen.
Yes. I've had both, in the same company. One PO that listens and encourages input, valuing it as highly as their own opinions...and another who actively pushes back on any input, who will dig in any time a suggestion is made, etc. The latter I just stop trying.
Unsurprisingly, the former tends to get things out on time to huge success, and the latter tends to be late, and it barely scrapes across the finish line.
Unsurprisingly, the former tends to get things out on time to huge success, and the latter tends to be late, and it barely scrapes across the finish line.
I've been trying to get out of development for the last month. I've sent 180 CVs for business analyst roles. I've had 2 recruiters call me back, otherwise dead. This is the CV that the CTO of my last company helped me write. You don't get many ex technical product managers or business analysts because it's pretty much impossible to transition.
This was my experience too, and after speaking with recruiter friends, often the company doesn't know where this person would sit. The title is still quite new and whilst the job spec may imply technical, the reality often is that they still just want a full on Product person who happens to know some coding (as opposed to a full on coder who happens to be involved in product). I've generally just had to go in as an engineer and be promoted by showing them what TPM's value is first hand.
Yeah that was my plan over the last 10 years at 4 different companies. No dice. Now I'm so burned out on programming I can't bear to try it all again. I can't go back to programming, last job I became so depressed that I was regularly thinking about suicide. Now in stuck because I can't program and no one will take me for another job. I might end up working in a super market at this rate.
Hang in there.
I haven't lived through a burnout yet, but I can relate to being stuck and unhirable, where your only background is in programming. No one will touch you for work in a different field because they figure you'll flee for a more lucrative dev role. No one will touch you for anything related to software, because they figure something must be wrong with you if you have the slightest gap in related employment. Devs are in such high demand, anyone good can find another job immediately, they'd say. Now you're in a self-perpetuating rut, and if you complain about it in the wrong community (not HN of course!), you just get told you must suck. It's completely demoralizing.
Went through that after graduating during the "Great Recession" and failing to find a dev position within six months of graduating. Ultimately, I clawed my way up (with a lot of help) after years of depression and suicidal ideation.
You may be headed away from programming, not back into like I was, but I really want you to take away the kind of encouragement online that I never received. Best of luck.
I haven't lived through a burnout yet, but I can relate to being stuck and unhirable, where your only background is in programming. No one will touch you for work in a different field because they figure you'll flee for a more lucrative dev role. No one will touch you for anything related to software, because they figure something must be wrong with you if you have the slightest gap in related employment. Devs are in such high demand, anyone good can find another job immediately, they'd say. Now you're in a self-perpetuating rut, and if you complain about it in the wrong community (not HN of course!), you just get told you must suck. It's completely demoralizing.
Went through that after graduating during the "Great Recession" and failing to find a dev position within six months of graduating. Ultimately, I clawed my way up (with a lot of help) after years of depression and suicidal ideation.
You may be headed away from programming, not back into like I was, but I really want you to take away the kind of encouragement online that I never received. Best of luck.
Thanks so much. I needed some kind words :)
I'm travelling at the moment so please bear with me with the timings but email me at thekeyboardp "at" gmail "." com and please lets talk mate
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.
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.
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.
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.
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.
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.
Very much agreed. In fact, I'd say that "building the right thing" often enables "building the thing right": by not spending time building things that are unimportant, you can spend time making the things that are work better.
Needing to get to market faster doesn't mean skimping on, say, a proper CI setup; it means not trying to do everything, and focusing on delivering and iterating on only those features that are relevant to the market.
Needing to get to market faster doesn't mean skimping on, say, a proper CI setup; it means not trying to do everything, and focusing on delivering and iterating on only those features that are relevant to the market.
The "hire for" part is pretty straightforward - when you interview, you'll have candidates with zero idea what your company is building. They won't care either.
Come Q time they'll ask about tech stack, code review, 4k screen, could they use their esoteric linux distro (yes).
OTOH you'll have candidates who already know your competitors, and know the tech stack because they registered for invite-only beta the day before the interview.
Come Q time they'll ask about tech stack, code review, 4k screen, could they use their esoteric linux distro (yes).
OTOH you'll have candidates who already know your competitors, and know the tech stack because they registered for invite-only beta the day before the interview.
Eh. I lean towards the former; in an interview I ask tech/process related questions and don't care about product (unless the interviewer mentions something that piques my interest). But when I start the job I give above-average energy to product-engineering. I'm looking for a tech fit, and I can apply my product-engineering energy anywhere.
In my experience, #1 is relatively the (very) hard part. #2 is relatively easy as it's finite in scope and push come to shove you pay a bounty (to a one-off consultant) to architect the direction of a solution.
Put another way, you can get #1 wrong and even if #2 hits that target, you're still wrong. But get #1 right and over a couple iterations you can get the means to support the desired ends.
Put another way, you can get #1 wrong and even if #2 hits that target, you're still wrong. But get #1 right and over a couple iterations you can get the means to support the desired ends.
One possible value for $NEEDS_A_NAME is Infrastructure Engineer ... not to say that infra isn't always productized, because it sometimes is, but the instincts required just aren't the same when your customer is the team that works down the hall. Maybe Systems Engineer if you consider the type of engineer that optimizes for speed and other factors. Idk, names are hard.
SRE sort of fits that box, though I have to point out w.r.t. the OP's post that there is being scrappy (not building for edge cases that don't have confirmed ROI) and being reckless (ignoring any engineering concern whatsoever).
I've seen projects sink for having PMs too far on the reckless side. Frontend engineers who appear to be developing the day's hot feature end up building a massive platform on platform on (...ad nauseam) on Reactive React just to show a few forms, while the backend engineers get pushback every time they ask a question. The product sinks because it takes three weeks just to move a field from one form to a different form, you have to refactor the whole redux store, ...
These are the teams that go so far in the "manual" direction that they refuse to build support tools of any kind whatsoever, and then when the inevitable fires come nobody knows what's going on.
So product<->reliability might be often mutually exclusive just because that is what people are used to, but really engineers should be able to do both and know when to adjust, and so should the managers.
I've seen projects sink for having PMs too far on the reckless side. Frontend engineers who appear to be developing the day's hot feature end up building a massive platform on platform on (...ad nauseam) on Reactive React just to show a few forms, while the backend engineers get pushback every time they ask a question. The product sinks because it takes three weeks just to move a field from one form to a different form, you have to refactor the whole redux store, ...
These are the teams that go so far in the "manual" direction that they refuse to build support tools of any kind whatsoever, and then when the inevitable fires come nobody knows what's going on.
So product<->reliability might be often mutually exclusive just because that is what people are used to, but really engineers should be able to do both and know when to adjust, and so should the managers.
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.
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.
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...
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...
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?
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?
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.
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.
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!
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!
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.
>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.
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?
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?
>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.
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.
Maybe this can be abstracted into being focused or being a generalist. I think OP is arguing that there is value in being a generalist and you are resisting that. I sympathize with OP, I've seen a lot of managers appreciate generalists and I've gotten a lot of value out of them myself. Maybe not everyone needs or wants to be one, but it's fair enough to outline it as a way of operating that provides a lot of value.
So to clarify–your understanding of the article is that, it says that a product engineer should be working at an expert level (or at least same level as full-timers of those roles) in about 10 different roles in addition to developer? And they should be doing this during 8 hours of every single day, context switching between different roles in small time slices?
If the above is your understanding of the article, then I'm sorry to say, you seriously need to work on your basic reading comprehension skills.
And if you actually understood the real point of the article, that all of the described activities happen spread out over longer periods of time, as the engineers build up a momentum of total product/business knowledge/expertise/rapport with other stakeholders in the org, by actually being curious, asking questions, and offering measured feedback; if you really understood this, then seriously, I have to question why even bother to reply and waste everyone's time? Totally pointless.
If the above is your understanding of the article, then I'm sorry to say, you seriously need to work on your basic reading comprehension skills.
And if you actually understood the real point of the article, that all of the described activities happen spread out over longer periods of time, as the engineers build up a momentum of total product/business knowledge/expertise/rapport with other stakeholders in the org, by actually being curious, asking questions, and offering measured feedback; if you really understood this, then seriously, I have to question why even bother to reply and waste everyone's time? Totally pointless.
> So to clarify–your understanding of the article is that, it says that a product engineer should be working at an expert level (or at least same level as full-timers of those roles) in about 10 different roles in addition to developer? And they should be doing this during 8 hours of every single day, context switching between different roles in small time slices?
Yes, in my work experience, the dynamics of development had us discussing the tasks that we work on... daily, weekly or monthly.
One of my realizations when switching from product development to some of the other roles mentioned in this post is just how much time they actually take... all the discussions, the what ifs, the stakeholder back and forth.
Yes, I do believe that the article mentions characteristics that should be applied in the work context, which is 8hrs per day in hopefully an expert way.
> If the above is your understanding of the article, then I'm sorry to say, you seriously need to work on your basic reading comprehension skills.
Perhaps...
> And if you actually understood the real point of the article, that all of the described activities happen spread out over longer periods of time, as the engineers build up a momentum of total product/business knowledge/expertise/rapport with other stakeholders in the org, by actually being curious, asking questions, and offering measured feedback;
I believe I argument my understanding as I read the article in the post you replies to.
> if you really understood this, then seriously, I have to question why even bother to reply and waste everyone's time? Totally pointless.
I was hoping I got my point across. Maybe it made sense to some people, but just because I am dumb and lack reading comprehension means I can’t post here? Am I responsible for your time wasting decision?
Yes, in my work experience, the dynamics of development had us discussing the tasks that we work on... daily, weekly or monthly.
One of my realizations when switching from product development to some of the other roles mentioned in this post is just how much time they actually take... all the discussions, the what ifs, the stakeholder back and forth.
Yes, I do believe that the article mentions characteristics that should be applied in the work context, which is 8hrs per day in hopefully an expert way.
> If the above is your understanding of the article, then I'm sorry to say, you seriously need to work on your basic reading comprehension skills.
Perhaps...
> And if you actually understood the real point of the article, that all of the described activities happen spread out over longer periods of time, as the engineers build up a momentum of total product/business knowledge/expertise/rapport with other stakeholders in the org, by actually being curious, asking questions, and offering measured feedback;
I believe I argument my understanding as I read the article in the post you replies to.
> if you really understood this, then seriously, I have to question why even bother to reply and waste everyone's time? Totally pointless.
I was hoping I got my point across. Maybe it made sense to some people, but just because I am dumb and lack reading comprehension means I can’t post here? Am I responsible for your time wasting decision?
Maybe I understand what you are referring to.
If you are hired in a “plain” engineering position it can be difficult to break out as a product engineer. Are you allowed to talk to customers? Is your time zealously measured?
I’ve tried in different projects with varying degrees of success. Fortunately with full success currently.
It would probably be interesting to analyse and write notes on “how to go from plain engineering to product engineering in friendly, neutral and hostile environments”.
If you are hired in a “plain” engineering position it can be difficult to break out as a product engineer. Are you allowed to talk to customers? Is your time zealously measured?
I’ve tried in different projects with varying degrees of success. Fortunately with full success currently.
It would probably be interesting to analyse and write notes on “how to go from plain engineering to product engineering in friendly, neutral and hostile environments”.
Not OP, but I do all those things at a company with 4 engineers. I have only met a couple (as in 2 or 3) engineers that I estimate would be capable of doing most of those things, but it's not impossible.
And regarding 3: both, of course. But he'll probably care more about users in day to day work, as those are more directly relevant to his goals (making a good product).
And regarding 3: both, of course. But he'll probably care more about users in day to day work, as those are more directly relevant to his goals (making a good product).
I don’t think it’s impossible either. I think most early stage startup people do a mix of everything there and it doesn’t have to stop early stage.
However, I do feel like actually being insightful and competent in so many domains of knowledge is a bit too much to ask of a single role.
I’m arguing that there should be separate roles, with different responsabilities, of people that are good in their specific domain and that the process of delivery should take care of mixing their outputs into something meaningful for the customer.
Putting my faith in this magic product engineer role that touches all aspects of the company, and expecting that person to really get good stuff constantly seems like a step in the wrong direction to me.
However, I do feel like actually being insightful and competent in so many domains of knowledge is a bit too much to ask of a single role.
I’m arguing that there should be separate roles, with different responsabilities, of people that are good in their specific domain and that the process of delivery should take care of mixing their outputs into something meaningful for the customer.
Putting my faith in this magic product engineer role that touches all aspects of the company, and expecting that person to really get good stuff constantly seems like a step in the wrong direction to me.
I’d suggest you read the article through the “what if it is true” glasses and start asking questions on HOW you can get there.
Thank you for being negative though, it helped me to be positive as I also started soul searching why I couldn’t become one of the great product engineers who tick all the boxes. We have to trust others and be positive, and self confident, not thinking about ticking boxes to prove things to others but with the desire to genuinely help.
Product people, regardless of primary background, have to be competent in a variety of skills and experts at one or two to be extremely effective. The job simply requires it. It is possible to be an expert in engineering and be competent in business, design, etc. The blog post is simply describing an engineer who probably could be a product manager/owner if they had the desire.
Sorry, but this is gonna be a kind of rant, so it's very subjective and highly anecdotal. But the post is also very subjective and highly anecdotal so meh I guess.
So what I want to say is that I've worked with this kind of person. It was exactly this type of engineer.
As a team member he is the worst kind of team player. While everyone is focusing on the actual sprint and the important tasks to be done, he keeps going around to other teams and collecting requirements for things: - which either has been already discussed and estimated before he joined the company but he is ignorant of that fact - which is supposed to be built on just his assumptions and because he is in no position to make decisions by himself he cannot really test his assumptions, and because he needs constant assistance to test his hypothesis he actually takes everyone's time on the team to work on assumptions that has no merit
At the same time for example he cannot identify the time when bugs need instant attention and need to be solved immediately so he seemingly cannot be bothered by those lowly matters of bugs and high priority things.
And because of his why? why? why? attitude even when the time is short and something has been discussed and written down in details MANY TIMES before, he needs constant repeating of every discussion because he just can't trust anything which was discussed WITHOUT HIM, his ego is too big for that.
Not to mention that he asks about product/engineering tradeoffs all the time when no-one, including him has nooo idea what are those tradeoffs, so the only thing he does is casting doubt and postponing decision making.
Not to mention that when he walks around for example and tries learning how other teams work, he is basically generating a false hope in people that he will actually deliver something soon. And oh man, couldn't be that any wronger?! Especially when he is in no position to make priorities and hiring decisions, etc, he is just basically playing a game, and this game is called politics.
This kind of person many times is just a constant waste of time. And yes, business people love these kind of person because someone finally speaks their language. The problem is that this language and communication is completely broken and misguided. Just like office politics is most of the time.
> They'll often spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists
That's basically correct, and that's also how I would summarize. Let's call it the `Debate-Minded Software Engineer` instead and then I'll have no complaints. But this is not productive!!! You want to have 10 of these people on your team? In a fast moving startup? Good luck for implementing anything EVER.
Also these are the people who can never understand that some people are busier than him. So then they think: OK, instead of waiting a day, they can just go ahead and build something based on their understanding. And then they are watching with horror when somebody tells them to stop it, because there are other higher priority things to do.
Also somehow this post equates the product manager to be some kind of superman. If you ever worked outside of silicon valley you will know that even these days there are many companies, I would even say that's the majority of companies, where projects are built and delivered with big upfront design, and there is no follow-up on the release or anything like that. There is a select number of people in the design process and if you are not invited to the discussion, then you will never have the chance to impact the product even the slightest.
And one more thing. Since this post is just speculation and it's extremely anecdotal, let me share my anecdotal evidence too.
Even when someone looks like the ace that the post describes, my experience is that these people are not that fast! They are either as fast as everyone else, or just mediocre in the technical side of things. So the only way that I saw these people to operate is that they put in extreme hours outside of working hours so that they can get the info, the context, etc which they need to look smart and having insight.
And here is the real problem? Why would you or anyone suggest this kind of modus operandi? Isn't most engineers' life overworked and miserable enough? You guys in Silicon Valley have to understand that people outside that bubble in other countries have shitty salaries and no work-life balance, so the incentive to put in extra hours and be the superhero of the company is almost zero, even though WE HAVE TO DO THE SAME JOB ON THE SAME QUALITY LEVEL as you guys in SV.
I wish we would stop idealizing these kind of imaginary roles and positions in the industry because this is extremely damaging to our profession. Especially to those people who are not that successful then the post's author.
What would be much more preferable to see a post from the same author that he describes in detail why engineers choose not to be like the person he described. That would actually show some humility and actual respect to everyone in the field.
We don't need a bullet point list to become something else that we are. What we need though is scaling back and tuning down the voice of people who think that there is one true shiny way of product development.
So what I want to say is that I've worked with this kind of person. It was exactly this type of engineer.
As a team member he is the worst kind of team player. While everyone is focusing on the actual sprint and the important tasks to be done, he keeps going around to other teams and collecting requirements for things: - which either has been already discussed and estimated before he joined the company but he is ignorant of that fact - which is supposed to be built on just his assumptions and because he is in no position to make decisions by himself he cannot really test his assumptions, and because he needs constant assistance to test his hypothesis he actually takes everyone's time on the team to work on assumptions that has no merit
At the same time for example he cannot identify the time when bugs need instant attention and need to be solved immediately so he seemingly cannot be bothered by those lowly matters of bugs and high priority things.
And because of his why? why? why? attitude even when the time is short and something has been discussed and written down in details MANY TIMES before, he needs constant repeating of every discussion because he just can't trust anything which was discussed WITHOUT HIM, his ego is too big for that.
Not to mention that he asks about product/engineering tradeoffs all the time when no-one, including him has nooo idea what are those tradeoffs, so the only thing he does is casting doubt and postponing decision making.
Not to mention that when he walks around for example and tries learning how other teams work, he is basically generating a false hope in people that he will actually deliver something soon. And oh man, couldn't be that any wronger?! Especially when he is in no position to make priorities and hiring decisions, etc, he is just basically playing a game, and this game is called politics.
This kind of person many times is just a constant waste of time. And yes, business people love these kind of person because someone finally speaks their language. The problem is that this language and communication is completely broken and misguided. Just like office politics is most of the time.
> They'll often spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists
That's basically correct, and that's also how I would summarize. Let's call it the `Debate-Minded Software Engineer` instead and then I'll have no complaints. But this is not productive!!! You want to have 10 of these people on your team? In a fast moving startup? Good luck for implementing anything EVER.
Also these are the people who can never understand that some people are busier than him. So then they think: OK, instead of waiting a day, they can just go ahead and build something based on their understanding. And then they are watching with horror when somebody tells them to stop it, because there are other higher priority things to do.
Also somehow this post equates the product manager to be some kind of superman. If you ever worked outside of silicon valley you will know that even these days there are many companies, I would even say that's the majority of companies, where projects are built and delivered with big upfront design, and there is no follow-up on the release or anything like that. There is a select number of people in the design process and if you are not invited to the discussion, then you will never have the chance to impact the product even the slightest.
And one more thing. Since this post is just speculation and it's extremely anecdotal, let me share my anecdotal evidence too.
Even when someone looks like the ace that the post describes, my experience is that these people are not that fast! They are either as fast as everyone else, or just mediocre in the technical side of things. So the only way that I saw these people to operate is that they put in extreme hours outside of working hours so that they can get the info, the context, etc which they need to look smart and having insight.
And here is the real problem? Why would you or anyone suggest this kind of modus operandi? Isn't most engineers' life overworked and miserable enough? You guys in Silicon Valley have to understand that people outside that bubble in other countries have shitty salaries and no work-life balance, so the incentive to put in extra hours and be the superhero of the company is almost zero, even though WE HAVE TO DO THE SAME JOB ON THE SAME QUALITY LEVEL as you guys in SV.
I wish we would stop idealizing these kind of imaginary roles and positions in the industry because this is extremely damaging to our profession. Especially to those people who are not that successful then the post's author.
What would be much more preferable to see a post from the same author that he describes in detail why engineers choose not to be like the person he described. That would actually show some humility and actual respect to everyone in the field.
We don't need a bullet point list to become something else that we are. What we need though is scaling back and tuning down the voice of people who think that there is one true shiny way of product development.
Wow. This sounds like you work on shitty projects in a shitty work environment.
What is YOUR persona? Are you successful?
Damn, perfect example of a 'tu quoque' discussion killer.
Thank you for saying this. I will admit that I did find these kinds of blog posts interesting at first, but the core of the thing just seems to be to have better social skills and listen more.
I think one of the reasons I found them pleasing to read is if I personally had some of the qualities mentioned in them... validation I guess. But I agree with you that these articles don’t provide much value.
I think one of the reasons I found them pleasing to read is if I personally had some of the qualities mentioned in them... validation I guess. But I agree with you that these articles don’t provide much value.
Oh, here’s the recipe, I read some more blog articles on how to talk to people, and some more on how to pester people on the hallway to ask about stuff they might not care about, sprinkle some salt and pepper and this is me, the 10x product engineer.
I only have about 10 bullet points separating me from the Product Gods!
I think you’re right, validation is probably the #1 factor why these type of articles propagate.
Like those ads where they tell you only geniuses can solve this: 2 + 2 * 2, and you click because you want to see who the morons are that arent’t a genius like yourself.
I only have about 10 bullet points separating me from the Product Gods!
I think you’re right, validation is probably the #1 factor why these type of articles propagate.
Like those ads where they tell you only geniuses can solve this: 2 + 2 * 2, and you click because you want to see who the morons are that arent’t a genius like yourself.
While I see what you're saying, there is a reason why these articles keep popping up, and that's because this "product-minded engineer" IS an actual role that is essential to developing good products. However, it has no name we can agree on so it doesn't exist in an organization.
We have software engineers that are supposed to be craftsmen, but everyone who can code uses the function title without any requirement on education or skillset. And then there's a huge gap to project and product managers, who often have no or limited technical experience and skills. Bridging that gap is what all these articles are all about, because they observe either a skilled product manager with technical chops or a developer with soft skills filling it.
Regardless, the point is that nobody hires for this role. Someone picks up the slack if you're lucky, or your product crashes and burns. Now these articles do seem to portray this person as a Messiah, but that's because he/she kind of is; an extraordinary person who saves your product, while it wasn't even in the job description!
Well no shit Sherlock, if you open a restaurant but didn't hire a cook of course you'd deify the waiter who whips up a mean lasagna. But how about you just hire a damn cook instead.
Anyway, now I've started to rant. The point is that we should see these articles as a sign that we (collectively as the software industry) are missing a role in our teams and should hire for it. Sure it's nice if this person is a genius, but hard work can replace a lot of geniuses.
We have software engineers that are supposed to be craftsmen, but everyone who can code uses the function title without any requirement on education or skillset. And then there's a huge gap to project and product managers, who often have no or limited technical experience and skills. Bridging that gap is what all these articles are all about, because they observe either a skilled product manager with technical chops or a developer with soft skills filling it.
Regardless, the point is that nobody hires for this role. Someone picks up the slack if you're lucky, or your product crashes and burns. Now these articles do seem to portray this person as a Messiah, but that's because he/she kind of is; an extraordinary person who saves your product, while it wasn't even in the job description!
Well no shit Sherlock, if you open a restaurant but didn't hire a cook of course you'd deify the waiter who whips up a mean lasagna. But how about you just hire a damn cook instead.
Anyway, now I've started to rant. The point is that we should see these articles as a sign that we (collectively as the software industry) are missing a role in our teams and should hire for it. Sure it's nice if this person is a genius, but hard work can replace a lot of geniuses.
All the startups I have worked with in the recent years have had a product person. It was a full time job that was mostly focused on the customers and how to deliver value within the constraints given by engineering and business.
Product development should be done on process I think, not on superstar product engineers.
I think the role is new, misunderstood, but I believe throwing bullet points is maybe not the way.
What I’m arguing against mostly is this focus on the person instead of the process and the push that someone can be a master of all those domains of knowledge (as in this article).
I wrote some (mean) thoughts as I was going through the article which I will answer now to the OP post where he answers my question if you are curious to check it out.
Product development should be done on process I think, not on superstar product engineers.
I think the role is new, misunderstood, but I believe throwing bullet points is maybe not the way.
What I’m arguing against mostly is this focus on the person instead of the process and the push that someone can be a master of all those domains of knowledge (as in this article).
I wrote some (mean) thoughts as I was going through the article which I will answer now to the OP post where he answers my question if you are curious to check it out.
I'm currently a product/engineer person on a team that has a fulltime product person. The split works well and I don't think it requires me to be a superstar in any way.
I sit in on a lot of meetings, talk to users, etc. and I program enough to know the ins and outs of our codebase. This means when wireframes are being put together I can say "well, that one will take 3 months longer" before anyone can get invested, clarify ambiguity I know the programmers will struggle with, and better translate user requirements to technical ones.
At a high level I'd say I'm sort of a liaison between two very different groups of people with very different realms of expertise. There's a lot of "translation" that necessary for that but anyone who's middling in both fields should be able to perform in the role.
I sit in on a lot of meetings, talk to users, etc. and I program enough to know the ins and outs of our codebase. This means when wireframes are being put together I can say "well, that one will take 3 months longer" before anyone can get invested, clarify ambiguity I know the programmers will struggle with, and better translate user requirements to technical ones.
At a high level I'd say I'm sort of a liaison between two very different groups of people with very different realms of expertise. There's a lot of "translation" that necessary for that but anyone who's middling in both fields should be able to perform in the role.
You expect a (good) product manager to be reasonably technically competent so that they can carry a conversation with business/customers without having to go back to engineering every time to ask "Is this possible?".
Similarly, you can expect a software engineer to be somewhat product competent so they can push back on bad ideas, proactively suggest better ways of doing things, and even connect the business dots and propose entire classes of new features that the PM maybe didn't even realise were possible / within reach.
It's not two roles in one, it's not working 16 hours / day, it's just having the right mix of experience and intuition such that you're still primarily an engineer but you help guide the product.
Similarly, you can expect a software engineer to be somewhat product competent so they can push back on bad ideas, proactively suggest better ways of doing things, and even connect the business dots and propose entire classes of new features that the PM maybe didn't even realise were possible / within reach.
It's not two roles in one, it's not working 16 hours / day, it's just having the right mix of experience and intuition such that you're still primarily an engineer but you help guide the product.
I felt more like the post is aimed for engineers looking to improve their game and not for management. The post pointed out several things I recognize from my own working life as valuable skills.
I’m just going to be nasty now and say that those managers I’m talking about don’t read management blogs, they read <insert other role here> blogs so they can ‘stay on top of things’.
The article is exposing some very good traits for anyone to have or to hope for, but let’s keep it realistic if we want it to be valuable.
You could do a space ship launch by hand ignoring for example wind resistence. It would be awsome in theory, less fuel, easier to stabilize, but it probably won’t get where you expect.
The article is exposing some very good traits for anyone to have or to hope for, but let’s keep it realistic if we want it to be valuable.
You could do a space ship launch by hand ignoring for example wind resistence. It would be awsome in theory, less fuel, easier to stabilize, but it probably won’t get where you expect.
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.
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.
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.
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.
> "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).
> 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).
I fought off the urge to endlessly debate my product managers by encourage them to A/B test their "bad" ideas.
The results were humbling for all everyone. Sometimes I was right but I often implemented features that I was sure would fail but turned out to be big successes.
Although my ego was initially bruised, the tactic was a big win for the business as now the product is more data driven.
The results were humbling for all everyone. Sometimes I was right but I often implemented features that I was sure would fail but turned out to be big successes.
Although my ego was initially bruised, the tactic was a big win for the business as now the product is more data driven.
I think I can see your point.
If you're the kind of engineer described in this article, you don't need to read this article. You have always naturally behaved this way and there is a natural trajectory that you're on because of it. You find this article just resonate deeply with you.
If you're not the kind of engineer described in this article, you probably can't become one. You will try to follow advice and wind up falling flat. Thats because the kind of engineer described in this article isn't following advice, they are following instinct. And if you don't have instinct then you have nothing to follow.
If you're the kind of engineer described in this article, you don't need to read this article. You have always naturally behaved this way and there is a natural trajectory that you're on because of it. You find this article just resonate deeply with you.
If you're not the kind of engineer described in this article, you probably can't become one. You will try to follow advice and wind up falling flat. Thats because the kind of engineer described in this article isn't following advice, they are following instinct. And if you don't have instinct then you have nothing to follow.
That's one way of looking at it. The question of whether there is a path that someone who doesn't have good product insights can follow and learn to have some, or if it's all "instinct", is an interesting one. No one was born with those skills out of the womb, so it's obviously a learned skill, but it's one that we haven't quite broken down to a teachable course.
I agree that following simple advice probably won't work, but I personally believe intentional practice can actually help people get better at this — only there has to be more than a desire to communicate out, there has to be a desire to put oneself on the line and evaluate oneself honestly based on result.
I agree that following simple advice probably won't work, but I personally believe intentional practice can actually help people get better at this — only there has to be more than a desire to communicate out, there has to be a desire to put oneself on the line and evaluate oneself honestly based on result.
I sort of half agree half disagree.
My mental model on this is that for a given skill/outcome everyone sits somewhere on a continuum of possibility with upper and lower bounds depending on intrinsic factors.
So, in that sense I agree there are those people who could develop a certain aptitude through a clear pathway of study. My model assumes their highest level of aptitude they can attain is capped at that lower than those who are "naturals". Conversely if you are a natural and you never seem to develop your aptitude, you will bumble along likely doing OK or even accidentally doing well, but those who can reach the absolute top of the aptitude spectrum are those who a) realize they are a natural b) seek out a pathway to accelerate their progress and c) actively work really hard at it.
My mental model on this is that for a given skill/outcome everyone sits somewhere on a continuum of possibility with upper and lower bounds depending on intrinsic factors.
So, in that sense I agree there are those people who could develop a certain aptitude through a clear pathway of study. My model assumes their highest level of aptitude they can attain is capped at that lower than those who are "naturals". Conversely if you are a natural and you never seem to develop your aptitude, you will bumble along likely doing OK or even accidentally doing well, but those who can reach the absolute top of the aptitude spectrum are those who a) realize they are a natural b) seek out a pathway to accelerate their progress and c) actively work really hard at it.
> 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.
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.
Accurate
So true
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.
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.
Don't get too caught up in the internal views and politics/machinations of day to day.
The internal views are important, but the external views, market aspect, user experience of your product is most important.
Even if only one person ever uses it, make it at least a pleasant and good experience.
I like to essentially live in products, get fully invested in it and make it something that somehow, in a way, becomes a 'friend'. Something that helps users and they don't mind revisiting. Find the fun or at least the good experience.
Luckily, making games and interactive projects makes that easier than say an insurance form, but even the latter, make it a pleasant part of the day even if it is low impact internally. Make it functional and fun if possible or at least pleasant and predictable where it needs to be.
I always get a bit annoyed when companies are too focused internally not externally, from the market, from the user perspectives. In fact, self-obsessed internal companies that value the politics internally more valuable than the external products the company produces, those are typically not successful companies or products down the line.
What is particularly bad is when you have to fight to put in quality or features that users want, that make a better product, but it harms your perception because of the production level you want adds time or managers/bizdevs might not see the value when it is very valuable. Internal politics can also discourage workers from attempting to make products better. No one wants to expend all their energy just getting the ability to build. Do it, show it, ask for forgiveness later as permission might not have the full picture to green light it.
Be proud of every product you make, make it quality, make it useful, make it fun, and broadcast it internally but don't get discouraged with the internal focused perception, obsess over the external views including user perception, market perception and it will win the internal perception by default. If you make enough good products and projects, eventually they come around.
You are what you make.
The internal views are important, but the external views, market aspect, user experience of your product is most important.
Even if only one person ever uses it, make it at least a pleasant and good experience.
I like to essentially live in products, get fully invested in it and make it something that somehow, in a way, becomes a 'friend'. Something that helps users and they don't mind revisiting. Find the fun or at least the good experience.
Luckily, making games and interactive projects makes that easier than say an insurance form, but even the latter, make it a pleasant part of the day even if it is low impact internally. Make it functional and fun if possible or at least pleasant and predictable where it needs to be.
I always get a bit annoyed when companies are too focused internally not externally, from the market, from the user perspectives. In fact, self-obsessed internal companies that value the politics internally more valuable than the external products the company produces, those are typically not successful companies or products down the line.
What is particularly bad is when you have to fight to put in quality or features that users want, that make a better product, but it harms your perception because of the production level you want adds time or managers/bizdevs might not see the value when it is very valuable. Internal politics can also discourage workers from attempting to make products better. No one wants to expend all their energy just getting the ability to build. Do it, show it, ask for forgiveness later as permission might not have the full picture to green light it.
Be proud of every product you make, make it quality, make it useful, make it fun, and broadcast it internally but don't get discouraged with the internal focused perception, obsess over the external views including user perception, market perception and it will win the internal perception by default. If you make enough good products and projects, eventually they come around.
You are what you make.
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.
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.
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.
You have to be conscious that you are playing the game of power and politics. You subtly invade other people's responsibilities, and question their capabilities.
Maybe you're good enough to make it clear that your only trying to help, but maybe there is a 3rd person that competes not with you but with the person you're trying to help, that will take advantage and make it look like they're clueless.
Maybe the person you're trying to help will respond positively when you're around, maybe they'll talk behind your back with the right people to shut you down.
Maybe you're good enough to make it clear that your only trying to help, but maybe there is a 3rd person that competes not with you but with the person you're trying to help, that will take advantage and make it look like they're clueless.
Maybe the person you're trying to help will respond positively when you're around, maybe they'll talk behind your back with the right people to shut you down.
While I can’t vouch for every org at my company, it sounds like you’re in a bad place and might benefit from switching orgs/companies.
Unfortunately Europe doesn't have that many great tech options depending on where you live...
That's true of basically every country or continent. If you're in the USA, but you're stuck in a small village in the Midwest for a personal reason, your options aren't going to be as good compared to someone living in the Bay Area (or one of the tech hubs in Europe, for that matter).
Yes, though practically speaking, moving within the USA is much easier than moving within Europe (different languages, work authorization may be required, incompatible retail banking systems, vastly different school systems, etc) and then there's no silicon valley type concentration anywhere.
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.
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.
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.
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.
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!
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!
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/
Wouldn't "in the field" suffice as a term here?
https://www.dictionary.com/e/slang/in-the-field/
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!
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!
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.
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.
> 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.
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.
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.
He's still right all these years of experience later.
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).
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.
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.
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"
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"
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.
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.
Not exactly.
It’s about caring and understanding the product, the problem space, and the customers/users.
Why spend one month on an enhancement when an alternative can serve just as well or better, for say a day of effort?
But to even come up with sensible (or better) alternatives require domain knowledge and good relationships.
It’s about caring and understanding the product, the problem space, and the customers/users.
Why spend one month on an enhancement when an alternative can serve just as well or better, for say a day of effort?
But to even come up with sensible (or better) alternatives require domain knowledge and good relationships.
You can go above and beyond and still build something nobody wants. It can be a perfectly architected software unicorn and it will hurt even more when nobody uses it.... because they don’t need it.
The ghostwriter software engineer: Do all the thinking, planning and work, receive no credit for it.
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.
[deleted]
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.
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.
> "minimum lovable product"
I love that quote, and idea. Going to use it moving forward.
I love that quote, and idea. Going to use it moving forward.
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?
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.
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.
I don't necessarily agree. Being a responsible product person both means tweaking good features, sunsetting bad features and introducing new ones.
This, very much.
There are projects where there are multiple sets of 'users' who don't necessarily overlap, and you'll find someone like this championing one set to the detriment of others.
This can be awkward to imagine in the context of internet apps where there's a 'product' and people use it, but in the context of business or government applications where the customer-facing product is not merely the frontend it can be very relevant.
If you're producing software which runs on each customer's own servers, as an independent system instance, the user-stakeholders include:
* The people using it in day-to-day tasks. These are the 'Users' an internet-based application usually considers.
* The ops guys looking after those servers, who have no other power over the software system itself (but will lose their weekends when eg. the vendor-documented backup procedure turns out to be incomplete).
* Other vendors, who probably have to integrate with the system (and will curse the documentation or lack thereof).
* The customer's internal helpdesk fielding end-user queries about the system (frantically hunting through a content-free manual, if they're new to the job, or escalating without comment, if they're burned out).
* The Administration, who want reports on the behaviour and performance of the Users mentioned above (and often don't care about usability as long as the reports are pretty).
* And many other groups, with entirely different concerns.
A great many of these articles seem to either champion only the 'User' and/or refer only to systems where all other parties are internal to the company building the software.
The world still relies heavily on a lot of systems which do not conform to the Cloud ideal. It is important for any 'product-minded software engineer' to remember that, sometimes, making eg. the Ops guys' job easier will make life better for All Of The Above, even more than chasing after that shiny report Admin wants.
Of course, if you are building in the Cloud, The Above are largely your coworkers and should make all of this known to you :P
There are projects where there are multiple sets of 'users' who don't necessarily overlap, and you'll find someone like this championing one set to the detriment of others.
This can be awkward to imagine in the context of internet apps where there's a 'product' and people use it, but in the context of business or government applications where the customer-facing product is not merely the frontend it can be very relevant.
If you're producing software which runs on each customer's own servers, as an independent system instance, the user-stakeholders include:
* The people using it in day-to-day tasks. These are the 'Users' an internet-based application usually considers.
* The ops guys looking after those servers, who have no other power over the software system itself (but will lose their weekends when eg. the vendor-documented backup procedure turns out to be incomplete).
* Other vendors, who probably have to integrate with the system (and will curse the documentation or lack thereof).
* The customer's internal helpdesk fielding end-user queries about the system (frantically hunting through a content-free manual, if they're new to the job, or escalating without comment, if they're burned out).
* The Administration, who want reports on the behaviour and performance of the Users mentioned above (and often don't care about usability as long as the reports are pretty).
* And many other groups, with entirely different concerns.
A great many of these articles seem to either champion only the 'User' and/or refer only to systems where all other parties are internal to the company building the software.
The world still relies heavily on a lot of systems which do not conform to the Cloud ideal. It is important for any 'product-minded software engineer' to remember that, sometimes, making eg. the Ops guys' job easier will make life better for All Of The Above, even more than chasing after that shiny report Admin wants.
Of course, if you are building in the Cloud, The Above are largely your coworkers and should make all of this known to you :P
At a guess: Any team that's working on substrate rather than on code that customers directly interact with won't be a good fit, unless the person has a very flexible view of "customer" and "product." Like, if your team is working on performance improvements for your company's data storage layer, the mindset described in the article won't bring a lot of benefit, I think.
If the storage layers are plenty fast enough and they ask the question that gets their effort redirected to the right thing - that's gold!
Now, as an engineer I gotta say, we need MOAR speed! :)
Now, as an engineer I gotta say, we need MOAR speed! :)
This type of engineer probably isn't a good fit for some software projects are heavily replication based - think of replicating a bunch of canned reports with slightly different sort orders, filters, etc. The scope of the project is very well known, there is zero discovery work to be done, they just need to poop out a pile of reports quickly and move on.
Also consider if you are an off-shore provider of software engineers to customers who value having remote engineers who will "just do what they are told" This sort of person is likely not going to be actualized in that kind of a situation.
Also consider if you are an off-shore provider of software engineers to customers who value having remote engineers who will "just do what they are told" This sort of person is likely not going to be actualized in that kind of a situation.
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.
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.
> minimum lovable product
Wow, had never seen that one. I feel like we have reached peak "elevator pitch" speak.
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.
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.
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.
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.
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.
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.
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.
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.
Company Stack Engineer. I’m coining the term here and now! It’s an engineer that’s a company!
It’s when you just do it all, business, accounting, sales, customer success, analysis, development, testing, devops, monitoring, ui, ux, visual design, maybe even be your own manager and the user of what you build. We can just make a git repo for the responsabilities and anyone can chime in.
Bonus: 10x Company Stack Engineer is that person you hire cheap, no need to train him and he does the work of 10 companies...
It’s when you just do it all, business, accounting, sales, customer success, analysis, development, testing, devops, monitoring, ui, ux, visual design, maybe even be your own manager and the user of what you build. We can just make a git repo for the responsabilities and anyone can chime in.
Bonus: 10x Company Stack Engineer is that person you hire cheap, no need to train him and he does the work of 10 companies...
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.
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.
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.
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.
[deleted]
Are there roles that target product developers ? What would that be called when searching? Product engineer, project dev etc ? Would the interview be different?
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.
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.
Product minded engineers with strong UX/design talent. How common or rare are they?
> Build a strong relationship with your product manager.
this x1000
this x1000
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.
[deleted]
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.
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.
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).