There is a con to being a product minded software engineer. When you are in organizations that do checkbox driven development (i.e. build features so it looks like your product has the widest feature set), it can be disheartening. You will ask why build this? and will get a believable answer. However, once it get's built you will notice that no one pays attention to the feature (no analytics, no reports, no iteration, etc.). At some point in the future, maybe a year or two down the line, you will notice a huge bug raised with the feature. Whoops for 20% of the users, it didn't work. You feel bad at first for your bug, but then realize, that no users even noticed the feature gone. Your suspicions that you were building something that didn't even matter are confirmed.<p>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.<p>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).
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.<p>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.<p>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.<p>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.
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.<p>The way I think about it is that you're giving weights to one of two different goals:<p>1. Building the right thing<p>2. Building the thing right<p>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.<p>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.<p>I'd be curious to know how companies most effectively hire for and/or cultivate these kinds of behaviors in eng teams.
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.<p>The reason you need the CPD (Coal/People/Dreaming) focused worker in your coal mine is bacause he will:<p>1. Understand that coal is an important product.<p>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.<p>2. Be a dreamer.<p>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.<p>3. Be a people person.<p>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.<p>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.<p>Later edit: just reread the article and got angry again. What’s the value in this? Can we really throw such absolutes right now?<p>I’m sorry if the post author is somehow seeing this comment, it’s not a bad post, it’s a bad post type <i>in my opinion</i> as it brings nothing new to the table.<p>Actually, it might make the reader feel like product developing is this weird arcane <i>science</i> and that unless he has those attributes he’s not this unicorn product engineer, when the reality is that <i>most</i> 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.
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.<p>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 <i>with poor product insights</i> and who <i>isn't interested in feedback</i> and constantly derails the team by sharing their thoughts on what we should and shouldn't do.<p>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.
> They're someone who would likely make a good product manager if they ever decide to give up the joy of engineering.<p>Read: If they ever decided to stop working and start siphoning funds to start their own company.<p>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.
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.<p>At this point I think life would have been a lot easier if I did <i>not</i> care about product - and now I realize many have figured this out sooner than I.
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.<p>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.<p>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.<p>Culture, or the way things are done, is the primary factor that leads to declining performance of teams over time.<p>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 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.
Product Manager here with computer science background. In my 10+ yrs as PM I have encountered engineers that I broadly classify in 3 buckets.<p>A) Product/business concerned eng as described in the article<p>B)"Know it all" product defensive eng<p>C) Pure technical focused eng<p>Working with #A is a great experience where not only do you move the product forward but learn a ton yourself.<p>Working with #C is great especially for products that are driven by well defined roadmap.<p>Working with #B is pure hell that I don't wish even on people I hate.
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.<p>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".<p>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).<p>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<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 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.<p>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.
One question I have when I see articles like this is: what are the <i>downsides</i> of this sort of person on a team? What kind of projects should they <i>not</i> be involved in? When are they the wrong person for the 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.<p>> minimum lovable product<p>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.<p>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.
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.
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.
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.<p>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.<p>But it's also very pragmatic, which is, like, the point, right.<p>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.<p>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:<p>(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?<p>(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?<p>(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?<p>(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?<p>(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?<p>Just some thoughts.
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.
In my opinion this kind of engineer sounds great on paper.<p>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.