13 ms·

The Product-Minded Software Engineer

616 points by turingbook 7y ago

ThalesX 7y ago
This might sound like a rant, it probably is but I’m sick and tired of articles that create this perfect personna, meddle in theory but behave like they’re sprouting truths. The ninja rockstar developer, the amazing product guy... I could write an article right now about any profession. The reason you need the CPD (Coal/People/Dreaming) focused worker in your coal mine is bacause he will: 1. Understand that coal is an important product. He will give himself to this quest and personal mission to understand how people use coal and just how much society depends on it. This will push him to better himself in its exploitation. 2. Be a dreamer. Most people will just wave their hand and dismiss the possibility that coal extraction is a flatbed for innovation. Your coal focused worker will spend all his time thinking about new ways to work with coal. That will increase the creative output of the whole operation thus raising the bottom line. 3. Be a people person. Coal mines are dreary places that’s why your 10x coal worker will have social skills. He’ll need to keep the people around him entertained and challenged so that he may create friction value. Anyway, turns out I can’t write a proper article in one go but I will end this unsubstantiates comment by saying that most of these articles target the management type that makes ill informed decisions based on blog aricles, and the fact that this kind of feedback loop exists in the world infuriates me. Later edit: just reread the article and got angry again. What’s the value in this? Can we really throw such absolutes right now? I’m sorry if the post author is somehow seeing this comment, it’s not a bad post, it’s a bad post type in my opinion as it brings nothing new to the table. Actually, it might make the reader feel like product developing is this weird arcane science and that unless he has those attributes he’s not this unicorn product engineer, when the reality is that most product engineers can’t become what is described in this article because the work they do is tied to reality, not to the rainbows and clouds world of our imaginations.
- gregdoesit 7y ago
  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-engineer/#tips-to-become-a-more-product-minded-engineer https://blog.pragmaticengineer.com/the-product-minded-engine...
  - ThalesX 7y ago
    Of course I am not going to argue with the person behind the article as the simplest explanation is that I misread, misunderstood, misjudged etc. However, I will ask you three questions to clarify this for me, of course optional: 1 - Do you think it’s possible for one person to do half of the things you listed? 2 - Do you think it’s possible for most product people to do most of the things you talk about outside of companies such as Microsoft, Uber and similar? 3 - Should the product minded engineer be interested in users or the stakeholders?
    - gregdoesit 7y ago
      And I’m also not going to argue with people who have different experiences - I can speak for my own experience, and generalise it, finding others who might think similarly, which is what I’ve done here. This is to say YMMV. But to your questions. 1 - Doing half the things I listed. I hope this is not a loaded question, but I’ve seen people do all of them. It usually starts with people who are both good communicators, are curious about the “why” on things, being interested in how the business works. Then they bring product ideas. The nice you bring product ideas to the table, as an engineer, making pragmatic trade-offs is pretty straightforward (if we build a slightly modified feature, we can get the same business impact, but a lot less eng complexity). The rest is about looking out ways to get early feedback (prototyping, hallway testing etc) and challenging weird edge cases. The first few of these I’m seeing a lot around me. 2 - I don’t fully get the question about product people. Also, I spent a good deal of my career working at Skype/Microsoft and Uber, so I don’t think I can give a definite answer. If it helps, at Skyscanner, a smaller startup, I had even more product say as an engineer, than I did at Uber or Microsoft. I suspect everything I wrote assumes an environment where engineers are empowered and close to the product, and data about the product usage/revenue generated. 3 - I’d say have a lot of curiosity on how the product works and how users use it, and generate value for the company. Then you need good communication skills to build trust with the product stakeholders - to understand more about the business, how they think, and to be able to showcase your ideas, prototypes and accommodate feedback for them.
      - ThalesX 7y ago
- pm90 7y ago
  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.
  - ThalesX 7y ago
    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.
- naavis 7y ago
  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.
  - ThalesX 7y ago
    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.
- todayispotato 7y ago
  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.
  - ThalesX 7y ago
    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.
    - andreigheorghe 7y ago
surprisedcat 7y ago
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"
- pm90 7y ago
  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.
- ThalesX 7y ago
  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.
- nobodyandproud 7y ago
daguar 7y ago
The spectrum of (product engineer) <---> ($NEEDS_A_NAME) has been one I've encountered a lot and which I find is underappreciated in hiring and team-building. The way I think about it is that you're giving weights to one of two different goals: 1. Building the right thing 2. Building the thing right I've found that in early-stage work, you really really need to have engineers who are more interested in (1) than (2). I'd probably say a product engineer who's a good fit for early stage work probably has an 70%/30% mix of what motivates them between these two goals. The strongest product engineers also have a keen sense of the power of MANUALLY handling some cases as a way to learn. At small scale, the cost of manually handling something can be way lower than building for that case. So another attribute I've seen is that strong product engineers are either okay with or even actively enjoy supporting users in those edge cases, talking with them as a way to learn. I'd be curious to know how companies most effectively hire for and/or cultivate these kinds of behaviors in eng teams.
- ebiester 7y ago
  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.
  - crimsonalucard 7y ago
    If you write "Crafts[man,woman]" and place the "man" before the "woman" you are implying the "man" is better than the "woman." To make things more gender neutral and less sexist you need to write "Craftspeople." For example I never use sexist or offensive words like "Mankind" anymore, I write "Peoplekind." Also my chrome highlights "Peoplekind" as a spelling error which shows you how far we are from living in a society that isn't sexist.
    - natalyarostova 7y ago
sanj 7y ago
One question I have when I see articles like this is: what are the downsides of this sort of person on a team? What kind of projects should they not be involved in? When are they the wrong person for the situation?
- todayispotato 7y ago
  They will probably not be an extremely deep expert into specific technologies, and they will burn out on doing work that does not involve improving the product for actual users. They want to deliver a feature, and sure they want to make sure it's being used well, but they won't want to stick around to endlessly tweak it.
  - nevertoolate 7y ago
    I don't necessarily agree. Being a responsible product person both means tweaking good features, sunsetting bad features and introducing new ones.
- jasonbourne1901 7y ago
  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.
- koreth1 7y ago
  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.
jv22222 7y ago
> "minimum lovable product" I love that quote, and idea. Going to use it moving forward.
quantified 7y ago
I hope this article raises visibility of this mindset in engineering management. I’ve always found product management very appreciative of the product-minded engineer, but engineering management to be apathetic at best. Engineering management is responsible for the engineer’s career, so their ability to make the politics work out is critical. For example, minimum viable needs to be viable, which costs more than the minimum that engineering was incented to deliver.
- LegitGandalf 7y ago
  Agreed. Most organizations I've been involved in will reward engineers for creating 20k lines of code that don't solve a relevant problem over the Product Engineer who creates 5k lines that solves valuable problems. The Product Engineer Genba'd out of the building to see what was needed and created the right thing, but since engineering management is often myopically focused on metrics disconnected from value the Product Engineer is significantly undervalued. Combining ability with domain knowledge is extremely valuable, and a significant portion of domain knowledge is gained by stepping away from the keyboard. Lean borrows the Japanese word Genba to describe this, which means 'actual place' or 'scene of the crime' and this Product Minded Engineer is somebody who is willing to Genba!
  - quelltext 7y ago
    Why did they have to use 現場? Wouldn't "in the field" suffice as a term here? https://www.dictionary.com/e/slang/in-the-field/ https://www.dictionary.com/e/slang/in-the-field/
    - LegitGandalf 7y ago
      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!
Ozzie_osman 7y ago
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.
gatherhunterer 7y ago
> They're someone who would likely make a good product manager if they ever decide to give up the joy of engineering. Read: If they ever decided to stop working and start siphoning funds to start their own company. When companies are small the engineering managers are the product managers and the product is good. When a company reaches the point of over-reaching they divide their concerns and hire managers who don’t know how to build the product and are paid to act like they are doing so while whipping engineers who have no interest in the product. Big companies that make good products do so by provisioning small teams with personnel who are essential to their collective goal. They mimic the small company.
- encoderer 7y ago
  Accurate
- Grzegrzolka 7y ago
  So true
keyP 7y ago
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.
- LegitGandalf 7y ago
  >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.
  - keyP 7y ago
    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.
celticmusic 7y ago
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.
meerita 7y ago
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.
- ThalesX 7y ago
  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...
- quelltext 7y ago
  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.
29athrowaway 7y ago
The ghostwriter software engineer: Do all the thinking, planning and work, receive no credit for it.
- ilrwbwrkhv 7y ago
  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 7y ago
    [deleted]
ilaksh 7y ago
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.
cryptozeus 7y ago
Are there roles that target product developers ? What would that be called when searching? Product engineer, project dev etc ? Would the interview be different?
colund 7y ago
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.
dyeje 7y ago
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.
riantogo 7y ago
Product Manager here with computer science background. In my 10+ yrs as PM I have encountered engineers that I broadly classify in 3 buckets. A) Product/business concerned eng as described in the article B)"Know it all" product defensive eng C) Pure technical focused eng Working with #A is a great experience where not only do you move the product forward but learn a ton yourself. Working with #C is great especially for products that are driven by well defined roadmap. Working with #B is pure hell that I don't wish even on people I hate.
- giancarlostoro 7y ago
  > B)"Know it all" product defensive eng This is why I say often the best trait of a developer is humility. If you cant handle someone telling you where you are wrong you are slowing everyone else down with your dumb ego. Software bugs happen. To. Every. Single. Developer.
  - LegitGandalf 7y ago
    Amen, we're human developers, not compilers. A long time ago a colleague was reviewing some code I wrote and he noticed I was uncomfortable with all the stuff he was finding and he said "listen, we all miss stuff" He's still right all these years of experience later.
    - giancarlostoro 7y ago
      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).
afinlayson 7y ago
At Google this is called UX Engineering. An experienced focused engineer that works with UX Design to build prototypes of future features, products and systems. I currently am working on multiple products that only exist because I straddle UX, Engineering and Product.
- sweetdreamerit 7y ago
  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.
jiofih 7y ago
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.
- xixixao 7y ago
  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.
  - ridaj 7y ago
    Unfortunately Europe doesn't have that many great tech options depending on where you live...
    - majewsky 7y ago
      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).
      - ridaj 7y ago
        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.
- fogetti 7y ago
  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.
sabujp 7y ago
> Build a strong relationship with your product manager. this x1000
franzwong 7y ago
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.
mherdeg 7y ago
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.
ridaj 7y ago
As a PM I would agree that some of these traits are really able to increase team effectiveness. For example, just in a recent project, we saved weeks of work after asking the developer to be more upfront about tradeoffs. However a big, big caveat on #1 "proactive with ideas/opinions" and #3 "curiosity and keen interest in 'why'". These are also traits of a different kind of engineer — the opinionated one with poor product insights and who isn't interested in feedback and constantly derails the team by sharing their thoughts on what we should and shouldn't do. Of course I prefer working with an engineer with product opinions and who asks why than one who doesn't, but if you're an engineer who's looking at this article and thinking "oh, this says I should start blurting my opinions out about the product more often and asking people why they are doing things the way they are", well that doesn't work well. To be really efficient I think you need to look at it more as "I should share and be curious about whether my insights on product and strategy are valuable to the team", then listen to the feedback about it.
- tgtweak 7y ago
  As a product manager you should not be asking anyone to build you anything without properly explaining the why. It starts with the why, and a good engineering team will offer how+when. If you get overly involved in the how you'll end up with ignoring that insight and the responsability that comes with it. Being on both the side of product and engineering, more often than not it's a lack of collaboration and trust between the two that leads to poor products and frustrated engineers. Your last paragraph hints at this. Poor product insights - some of the most competitive features I've seen make it into a product found themselves there because an engineer decided to build it to fix a pain point of their own (often after having that feature request ignored by product owner) Humor your engineers and give them creative ownership over a feature (from suggestion to implementation)- you'll be surprised how effortlessly it comes out. "I should share and be curious about whether my insights on product and strategy are valuable to the team" Good advice for everyone in the team, wish it was followed unilaterally.
  - ridaj 7y ago
    > "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).
jaequery 7y ago
Product minded engineers with strong UX/design talent. How common or rare are they?
drngdds 7y ago
>minimum lovable product If I ever hear anyone say that in real life, I will die on the spot.
- fizwhiz 7y ago
  That was pure cringe.
jimbob45 7y ago
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.
sdnlafkjh34rw 7y ago
There is a con to being a product minded software engineer. When you are in organizations that do checkbox driven development (i.e. build features so it looks like your product has the widest feature set), it can be disheartening. You will ask why build this? and will get a believable answer. However, once it get's built you will notice that no one pays attention to the feature (no analytics, no reports, no iteration, etc.). At some point in the future, maybe a year or two down the line, you will notice a huge bug raised with the feature. Whoops for 20% of the users, it didn't work. You feel bad at first for your bug, but then realize, that no users even noticed the feature gone. Your suspicions that you were building something that didn't even matter are confirmed. This has happened to me a lot. I was on a team that was on one of the "most important" projects to the company. We had the CTOs daily attention. You felt important and we had a large team who worked hard to ship it in one year. It was deemed a success by the CEO and myself and many of the team members got staffed on other teams (basically the next highest priority project for the company). Some other engineers got put on legacy duty for maintaining the project. After a year, I barely heard about the project (we had so many new projects) but we still maintained it and it was still on our website. 1.5 years later, I get a p2 bug that basically shows the whole product had stopped working for 3 months due to a front end bug. I got pulled to fix the bug and worked hard to find it and fix, but at the end I was demoralized because I realized my team had wasted a year on a feature no customer cared about enough to complain until 3 months after it stopped working. Basically, it can be really demoralizing to be product minded engineer if your organization is not. This happened in an org that heavily talked the talk about product market fit and testing, but the truth was we were checkbox driven. We just wanted the widest feature set among competitors (even if they didn't always work).
- jcelerier 7y ago
  > 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.
deleted 7y ago
[deleted]
nevertoolate 7y ago
I was soul searching for a while after reading the article and the comments. It is not easy to become a person (engineer or not) whose product ideas others trust in e.g. a single product company. It is doable though as I know one guy who is described in the article from work. How I can become one of those guys? That is a relevant question to ask if you want to change. I think what the article misses as a good advice: have great engineering skills and then you will have time to learn other things. But first be really good in tech, that is your foundation. That's why you will be a product engineer, not a product person.
- r_singh 7y ago
  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.
deleted 7y ago
[deleted]
beaker52 7y ago
I love product engineering. It's generalist++, and what I believe _most_ software projects need. However it is seen as a forbidden art in many workplaces with strongly-defined structure. I thought working at a tech "startup" was a perfect place for a "product engineer". Trouble was, this startup was born out of a big ol' corporate. Despite the mantra "we are a startup and have cast away the shackles of our corporate mothership", acting as a "product engineer" was firmly rejected due to the company's corporate roots. I'll never forget the conversation with my (corporate-sourced) boss: "thinking about those kind of things is the job of a product owner - maybe you should consider switching roles". My heart sank. I didn't care about my job title. So it turned out that I was treading on corporate-rooted toes by encroaching on other people's areas. We weren't all tending to the same garden - people had carved out their sections. It was how they added value and they weren't prepared for someone else getting involved in their areas. It sucked. And it's all too common, especially as organisations grow. Since then, I've made the way teams work a bit of a special interest of mine. Culture, or the way things are done, is the primary factor that leads to declining performance of teams over time. I'm also on the lookout for high quality jobs where I can stretch my legs. I'm a fullstack dev who gets involved in _everything_. I'll lead your team whilst you're not watching. I'm often hired to do stuff for which I have no experience. Do get in touch if you need someone like me.
- z3t4 7y ago
  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.
luord 7y ago
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.
hughguiney 7y ago
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.

616 points by turingbook 7y ago

This might sound like a rant, it probably is but I’m sick and tired of articles that create this perfect personna, meddle in theory but behave like they’re sprouting truths. The ninja rockstar developer, the amazing product guy... I could write an article right now about any profession. The reason you need the CPD (Coal/People/Dreaming) focused worker in your coal mine is bacause he will: 1. Understand that coal is an important product. He will give himself to this quest and personal mission to understand how people use coal and just how much society depends on it. This will push him to better himself in its exploitation. 2. Be a dreamer. Most people will just wave their hand and dismiss the possibility that coal extraction is a flatbed for innovation. Your coal focused worker will spend all his time thinking about new ways to work with coal. That will increase the creative output of the whole operation thus raising the bottom line. 3. Be a people person. Coal mines are dreary places that’s why your 10x coal worker will have social skills. He’ll need to keep the people around him entertained and challenged so that he may create friction value. Anyway, turns out I can’t write a proper article in one go but I will end this unsubstantiates comment by saying that most of these articles target the management type that makes ill informed decisions based on blog aricles, and the fact that this kind of feedback loop exists in the world infuriates me. Later edit: just reread the article and got angry again. What’s the value in this? Can we really throw such absolutes right now? I’m sorry if the post author is somehow seeing this comment, it’s not a bad post, it’s a bad post type in my opinion as it brings nothing new to the table. Actually, it might make the reader feel like product developing is this weird arcane science and that unless he has those attributes he’s not this unicorn product engineer, when the reality is that most product engineers can’t become what is described in this article because the work they do is tied to reality, not to the rainbows and clouds world of our imaginations.

gregdoesit 7y ago
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-engineer/#tips-to-become-a-more-product-minded-engineer https://blog.pragmaticengineer.com/the-product-minded-engine...
- ThalesX 7y ago
  Of course I am not going to argue with the person behind the article as the simplest explanation is that I misread, misunderstood, misjudged etc. However, I will ask you three questions to clarify this for me, of course optional: 1 - Do you think it’s possible for one person to do half of the things you listed? 2 - Do you think it’s possible for most product people to do most of the things you talk about outside of companies such as Microsoft, Uber and similar? 3 - Should the product minded engineer be interested in users or the stakeholders?
  - gregdoesit 7y ago
    And I’m also not going to argue with people who have different experiences - I can speak for my own experience, and generalise it, finding others who might think similarly, which is what I’ve done here. This is to say YMMV. But to your questions. 1 - Doing half the things I listed. I hope this is not a loaded question, but I’ve seen people do all of them. It usually starts with people who are both good communicators, are curious about the “why” on things, being interested in how the business works. Then they bring product ideas. The nice you bring product ideas to the table, as an engineer, making pragmatic trade-offs is pretty straightforward (if we build a slightly modified feature, we can get the same business impact, but a lot less eng complexity). The rest is about looking out ways to get early feedback (prototyping, hallway testing etc) and challenging weird edge cases. The first few of these I’m seeing a lot around me. 2 - I don’t fully get the question about product people. Also, I spent a good deal of my career working at Skype/Microsoft and Uber, so I don’t think I can give a definite answer. If it helps, at Skyscanner, a smaller startup, I had even more product say as an engineer, than I did at Uber or Microsoft. I suspect everything I wrote assumes an environment where engineers are empowered and close to the product, and data about the product usage/revenue generated. 3 - I’d say have a lot of curiosity on how the product works and how users use it, and generate value for the company. Then you need good communication skills to build trust with the product stakeholders - to understand more about the business, how they think, and to be able to showcase your ideas, prototypes and accommodate feedback for them.
    - ThalesX 7y ago
pm90 7y ago
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.
- ThalesX 7y ago
  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.
naavis 7y ago
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.
- ThalesX 7y ago
  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.
todayispotato 7y ago
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.
- ThalesX 7y ago
  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.
  - andreigheorghe 7y ago

surprisedcat 7y ago

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"

pm90 7y ago
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.
ThalesX 7y ago
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.
nobodyandproud 7y ago

daguar 7y ago

The spectrum of (product engineer) <---> ($NEEDS_A_NAME) has been one I've encountered a lot and which I find is underappreciated in hiring and team-building. The way I think about it is that you're giving weights to one of two different goals: 1. Building the right thing 2. Building the thing right I've found that in early-stage work, you really really need to have engineers who are more interested in (1) than (2). I'd probably say a product engineer who's a good fit for early stage work probably has an 70%/30% mix of what motivates them between these two goals. The strongest product engineers also have a keen sense of the power of MANUALLY handling some cases as a way to learn. At small scale, the cost of manually handling something can be way lower than building for that case. So another attribute I've seen is that strong product engineers are either okay with or even actively enjoy supporting users in those edge cases, talking with them as a way to learn. I'd be curious to know how companies most effectively hire for and/or cultivate these kinds of behaviors in eng teams.

ebiester 7y ago
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.
- crimsonalucard 7y ago
  If you write "Crafts[man,woman]" and place the "man" before the "woman" you are implying the "man" is better than the "woman." To make things more gender neutral and less sexist you need to write "Craftspeople." For example I never use sexist or offensive words like "Mankind" anymore, I write "Peoplekind." Also my chrome highlights "Peoplekind" as a spelling error which shows you how far we are from living in a society that isn't sexist.
  - natalyarostova 7y ago

sanj 7y ago

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

todayispotato 7y ago
They will probably not be an extremely deep expert into specific technologies, and they will burn out on doing work that does not involve improving the product for actual users. They want to deliver a feature, and sure they want to make sure it's being used well, but they won't want to stick around to endlessly tweak it.
- nevertoolate 7y ago
  I don't necessarily agree. Being a responsible product person both means tweaking good features, sunsetting bad features and introducing new ones.
jasonbourne1901 7y ago
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.
koreth1 7y ago
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.

jv22222 7y ago

> "minimum lovable product" I love that quote, and idea. Going to use it moving forward.

quantified 7y ago

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

LegitGandalf 7y ago
Agreed. Most organizations I've been involved in will reward engineers for creating 20k lines of code that don't solve a relevant problem over the Product Engineer who creates 5k lines that solves valuable problems. The Product Engineer Genba'd out of the building to see what was needed and created the right thing, but since engineering management is often myopically focused on metrics disconnected from value the Product Engineer is significantly undervalued. Combining ability with domain knowledge is extremely valuable, and a significant portion of domain knowledge is gained by stepping away from the keyboard. Lean borrows the Japanese word Genba to describe this, which means 'actual place' or 'scene of the crime' and this Product Minded Engineer is somebody who is willing to Genba!
- quelltext 7y ago
  Why did they have to use 現場? Wouldn't "in the field" suffice as a term here? https://www.dictionary.com/e/slang/in-the-field/ https://www.dictionary.com/e/slang/in-the-field/
  - LegitGandalf 7y ago
    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!

Ozzie_osman 7y ago

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.

gatherhunterer 7y ago

> They're someone who would likely make a good product manager if they ever decide to give up the joy of engineering. Read: If they ever decided to stop working and start siphoning funds to start their own company. When companies are small the engineering managers are the product managers and the product is good. When a company reaches the point of over-reaching they divide their concerns and hire managers who don’t know how to build the product and are paid to act like they are doing so while whipping engineers who have no interest in the product. Big companies that make good products do so by provisioning small teams with personnel who are essential to their collective goal. They mimic the small company.

encoderer 7y ago
Accurate
Grzegrzolka 7y ago
So true

keyP 7y ago

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.

LegitGandalf 7y ago
>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.
- keyP 7y ago
  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.

celticmusic 7y ago

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.

meerita 7y ago

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.

ThalesX 7y ago
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...
quelltext 7y ago
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.

29athrowaway 7y ago

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

ilrwbwrkhv 7y ago
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 7y ago
  [deleted]

ilaksh 7y ago

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.

cryptozeus 7y ago

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

colund 7y ago

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.

dyeje 7y ago

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.

riantogo 7y ago

Product Manager here with computer science background. In my 10+ yrs as PM I have encountered engineers that I broadly classify in 3 buckets. A) Product/business concerned eng as described in the article B)"Know it all" product defensive eng C) Pure technical focused eng Working with #A is a great experience where not only do you move the product forward but learn a ton yourself. Working with #C is great especially for products that are driven by well defined roadmap. Working with #B is pure hell that I don't wish even on people I hate.

giancarlostoro 7y ago
> B)"Know it all" product defensive eng This is why I say often the best trait of a developer is humility. If you cant handle someone telling you where you are wrong you are slowing everyone else down with your dumb ego. Software bugs happen. To. Every. Single. Developer.
- LegitGandalf 7y ago
  Amen, we're human developers, not compilers. A long time ago a colleague was reviewing some code I wrote and he noticed I was uncomfortable with all the stuff he was finding and he said "listen, we all miss stuff" He's still right all these years of experience later.
  - giancarlostoro 7y ago
    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).

afinlayson 7y ago

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

sweetdreamerit 7y ago
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.

jiofih 7y ago

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.

xixixao 7y ago
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.
- ridaj 7y ago
  Unfortunately Europe doesn't have that many great tech options depending on where you live...
  - majewsky 7y ago
    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).
    - ridaj 7y ago
      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.
fogetti 7y ago
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.

sabujp 7y ago

> Build a strong relationship with your product manager. this x1000

franzwong 7y ago

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.

mherdeg 7y ago

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.

ridaj 7y ago

As a PM I would agree that some of these traits are really able to increase team effectiveness. For example, just in a recent project, we saved weeks of work after asking the developer to be more upfront about tradeoffs. However a big, big caveat on #1 "proactive with ideas/opinions" and #3 "curiosity and keen interest in 'why'". These are also traits of a different kind of engineer — the opinionated one with poor product insights and who isn't interested in feedback and constantly derails the team by sharing their thoughts on what we should and shouldn't do. Of course I prefer working with an engineer with product opinions and who asks why than one who doesn't, but if you're an engineer who's looking at this article and thinking "oh, this says I should start blurting my opinions out about the product more often and asking people why they are doing things the way they are", well that doesn't work well. To be really efficient I think you need to look at it more as "I should share and be curious about whether my insights on product and strategy are valuable to the team", then listen to the feedback about it.

tgtweak 7y ago
As a product manager you should not be asking anyone to build you anything without properly explaining the why. It starts with the why, and a good engineering team will offer how+when. If you get overly involved in the how you'll end up with ignoring that insight and the responsability that comes with it. Being on both the side of product and engineering, more often than not it's a lack of collaboration and trust between the two that leads to poor products and frustrated engineers. Your last paragraph hints at this. Poor product insights - some of the most competitive features I've seen make it into a product found themselves there because an engineer decided to build it to fix a pain point of their own (often after having that feature request ignored by product owner) Humor your engineers and give them creative ownership over a feature (from suggestion to implementation)- you'll be surprised how effortlessly it comes out. "I should share and be curious about whether my insights on product and strategy are valuable to the team" Good advice for everyone in the team, wish it was followed unilaterally.
- ridaj 7y ago
  > "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).

jaequery 7y ago

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

drngdds 7y ago

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

fizwhiz 7y ago
That was pure cringe.

jimbob45 7y ago

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.

sdnlafkjh34rw 7y ago

There is a con to being a product minded software engineer. When you are in organizations that do checkbox driven development (i.e. build features so it looks like your product has the widest feature set), it can be disheartening. You will ask why build this? and will get a believable answer. However, once it get's built you will notice that no one pays attention to the feature (no analytics, no reports, no iteration, etc.). At some point in the future, maybe a year or two down the line, you will notice a huge bug raised with the feature. Whoops for 20% of the users, it didn't work. You feel bad at first for your bug, but then realize, that no users even noticed the feature gone. Your suspicions that you were building something that didn't even matter are confirmed. This has happened to me a lot. I was on a team that was on one of the "most important" projects to the company. We had the CTOs daily attention. You felt important and we had a large team who worked hard to ship it in one year. It was deemed a success by the CEO and myself and many of the team members got staffed on other teams (basically the next highest priority project for the company). Some other engineers got put on legacy duty for maintaining the project. After a year, I barely heard about the project (we had so many new projects) but we still maintained it and it was still on our website. 1.5 years later, I get a p2 bug that basically shows the whole product had stopped working for 3 months due to a front end bug. I got pulled to fix the bug and worked hard to find it and fix, but at the end I was demoralized because I realized my team had wasted a year on a feature no customer cared about enough to complain until 3 months after it stopped working. Basically, it can be really demoralizing to be product minded engineer if your organization is not. This happened in an org that heavily talked the talk about product market fit and testing, but the truth was we were checkbox driven. We just wanted the widest feature set among competitors (even if they didn't always work).

jcelerier 7y ago
> 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.

deleted 7y ago

[deleted]

nevertoolate 7y ago

I was soul searching for a while after reading the article and the comments. It is not easy to become a person (engineer or not) whose product ideas others trust in e.g. a single product company. It is doable though as I know one guy who is described in the article from work. How I can become one of those guys? That is a relevant question to ask if you want to change. I think what the article misses as a good advice: have great engineering skills and then you will have time to learn other things. But first be really good in tech, that is your foundation. That's why you will be a product engineer, not a product person.

r_singh 7y ago
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.

deleted 7y ago

[deleted]

beaker52 7y ago

I love product engineering. It's generalist++, and what I believe _most_ software projects need. However it is seen as a forbidden art in many workplaces with strongly-defined structure. I thought working at a tech "startup" was a perfect place for a "product engineer". Trouble was, this startup was born out of a big ol' corporate. Despite the mantra "we are a startup and have cast away the shackles of our corporate mothership", acting as a "product engineer" was firmly rejected due to the company's corporate roots. I'll never forget the conversation with my (corporate-sourced) boss: "thinking about those kind of things is the job of a product owner - maybe you should consider switching roles". My heart sank. I didn't care about my job title. So it turned out that I was treading on corporate-rooted toes by encroaching on other people's areas. We weren't all tending to the same garden - people had carved out their sections. It was how they added value and they weren't prepared for someone else getting involved in their areas. It sucked. And it's all too common, especially as organisations grow. Since then, I've made the way teams work a bit of a special interest of mine. Culture, or the way things are done, is the primary factor that leads to declining performance of teams over time. I'm also on the lookout for high quality jobs where I can stretch my legs. I'm a fullstack dev who gets involved in _everything_. I'll lead your team whilst you're not watching. I'm often hired to do stuff for which I have no experience. Do get in touch if you need someone like me.

z3t4 7y ago
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.

luord 7y ago

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.

hughguiney 7y ago

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.