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).
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.
I find that the vast majority of people are not stupid: they have learnt that trying to get things fixed is usually a waste of time. As a developer I truly understand this from when I’ve tried to get others to fix their software, and I am very good at describing problems.
Regularly I am the one that created the software problem, and if I were a better developer I would have avoided making the problem in the first place (or had ways to detect it, or easy ways for my clients to tell me).
I think I'm sensing a bit of anger in your tone, looking how you move the subject on my person.
Sorry if I offended you in any way, it was not my intention to offend anyone.
Me and my career are ok so far, if that's of some relief to you.
We are surely not working in the same area then.
Mine is as a vendor of enterprise stuff, for Big Corps.
In my place, not relying in users' proactive and qualitative feedback is a pretty decent attitude in my eyes, it tends to deploying more reliable software, thus to invoices actually collected, which finally leads to having an actual paycheck.
1. There are many extremely important features that may only be needed once or twice a year. For example I work in developing cost estimating tools. The tools I build are extremely important, but some of them may not be used for 8+ months out of the year and new bugs could go unnoticed for quite a while. Unless you are familiar with the internal processes of customers this could easily be true for your product features as well for reasons that might not make immediate sense and you wouldn't even know.
2.I would argue that being a product focused engineer requires you to go the extra mile and learn about customers business processes. Product Owners should include engineers in some meetings for use case analysis and voice of customer interviews. I also find it extremely valuable to personally provide support directly to some of the highest value customers because you will learn what you need to know in order to implement features better and requiring fewer updates/changes down the road.
As an engineer, I try pushing back to reduce the scope of a product down to a MVP that can be released earlier with analytical data monitoring its usage.
As an engineer, you can identify the features that take the most time to implement and can see about pushing back to a version 2 release. If it is a critical feature, then try to find alternative solutions that can be implemented in less time.
That way if a product is a flop, you didn't waste all your time. Even if it is a success, the MVP is often good enough and they still deprioritized the extra bells and whistles.
PM would hold a monthly sprint planning/refinement, 'senior' engineers would participate in breaking each piece of work into tiny, tiny tasks, and then split them up into streams of designer, developer, tester.
Each tiny task would take an hour-half a day and you wouldn't even necessarily be working on the same code base across tasks, just continually turning out tiny 1-3 point tasks.
That was by far the most soulless job I ever had, weeding these companies out is my number one priority when interviewing.
I often found that features would be requested from product owners/business and developers would implement it no questions asked but at lunch time, developers would rant about the requested feature's value. When asked if it should be brought to the PO's attention, I often saw the attitude of it not being their problem, they're getting paid either way (whether that's a company culture issue, general developer apathy, or burnt by past experience of questioning management is a different question). I think product-engineers feel a bit more invested in the product and have the soft-skills to influence or provide feedback in a manner conducive to business listening.
In my teams, I try to foster this type of communication and I've noticed a lot more developers opening up and providing valuable product-orientated feedback which often has an upward positive spiral of them feeling more appreciated and speaking more. Naturally a lot of engineers still want to just code and go home but team culture can really highlight and encourage engineers who may not be confident to speak up initially.
Ironically, as someone with more engineering experience on paper, it's been tricky to find a job directly as any form of product or engineer manager, I always had to go in as an engineer then be promoted after a year or so which isn't always ideal (or referred via a friend). I feel Product and Technical skills are still often considered mutually exclusive a lot of the time but I think that's inertia from when technical skills were still considered a cost to the business.
I 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.
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.
As an engineer I've always found that knowing why, knowing that there is a real customer out there who really wants what I'm making is very motivating.
So often people just come to me because their boss told them to go get engineering to make this thing. They don't know why, and sadly, their boss doesn't know why either as it was just passed to them from an executive mandate. And there is lots of pressure to get to done ASAP!
I believe this is why some of the best Product Owners I've worked with have some understanding of the technical side so that they can push back at the point of feature request rather than accept everything to please business/the client and lay it at the feet of engineers a few weeks down the line.
For this reason, I think the engineering manager/technical product owner type of role should start becoming a bit more common especially in startups, where I've seen first hand, POs brought in who subsequently drive products into the ground that were initially engineering led (and which raised the investment in the first place).
POs in my recent experience could benefit from listening more to their developers, who often know the domain much better than they do. (Or perhaps the wrong people are becoming POs)
I've stopped giving feedback and I'm nearly at a point where I've stopped being interested. It frees up my mind and motivates me to work on my own projects on nights and weekends so I can actually have a say.
This is often how waterfall projects are/were run in large companies historically but now companies want agile everywhere but they don't implement the right processes to facilitate it. You end up with behind closed door decisions, promises made by PO that it will be done in the next sprint, and at no point has anyone with either the courage or technical know-how stepped in to point out that it's not feasible.
This is true but I find if I can explain why the feedback was overlooked, that can help diminish the negative feeling. It hasn't happened often in my experience but sometimes when it has, if the idea is feasible and won't detract too much from the critical path, I would push the business team a bit harder to allow it so as to avoid the constant ignoring feeling that can happen.
Unsurprisingly, the former tends to get things out on time to huge success, and the latter tends to be late, and it barely scrapes across the finish line.
I haven't lived through a burnout yet, but I can relate to being stuck and unhirable, where your only background is in programming. No one will touch you for work in a different field because they figure you'll flee for a more lucrative dev role. No one will touch you for anything related to software, because they figure something must be wrong with you if you have the slightest gap in related employment. Devs are in such high demand, anyone good can find another job immediately, they'd say. Now you're in a self-perpetuating rut, and if you complain about it in the wrong community (not HN of course!), you just get told you must suck. It's completely demoralizing.
Went through that after graduating during the "Great Recession" and failing to find a dev position within six months of graduating. Ultimately, I clawed my way up (with a lot of help) after years of depression and suicidal ideation.
You may be headed away from programming, not back into like I was, but I really want you to take away the kind of encouragement online that I never received. Best of luck.
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.
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.
At a very micro level, yesterday I was looking at a simple JS object with 6 entries, and 3 different naming conventions. Doing even simple changes without code-completion in the code base is mentally taxing.
Needing to get to market faster doesn't mean skimping on, say, a proper CI setup; it means not trying to do everything, and focusing on delivering and iterating on only those features that are relevant to the market.
(There are also non-binary people.) It's not worth getting offended by, but I do usually try to manage inclusive language.
Clearly, my statements are self evident.
That is a no-brainer.
Come Q time they'll ask about tech stack, code review, 4k screen, could they use their esoteric linux distro (yes).
OTOH you'll have candidates who already know your competitors, and know the tech stack because they registered for invite-only beta the day before the interview.
Put another way, you can get #1 wrong and even if #2 hits that target, you're still wrong. But get #1 right and over a couple iterations you can get the means to support the desired ends.
I've seen projects sink for having PMs too far on the reckless side. Frontend engineers who appear to be developing the day's hot feature end up building a massive platform on platform on (...ad nauseam) on Reactive React just to show a few forms, while the backend engineers get pushback every time they ask a question. The product sinks because it takes three weeks just to move a field from one form to a different form, you have to refactor the whole redux store, ...
These are the teams that go so far in the "manual" direction that they refuse to build support tools of any kind whatsoever, and then when the inevitable fires come nobody knows what's going on.
So product<->reliability might be often mutually exclusive just because that is what people are used to, but really engineers should be able to do both and know when to adjust, and so should the managers.
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.
I beg to differ the article is super generic, as it closes with very engineering specific recommendations to build a “product-muscle” for developer . This is the kind of advice and coaching I give to devs around me who would like to make more product/business impact.
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?
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.
This is mostly in relation to my view that a single person ... would have trouble, with filling all these roles within the 8 hours given per day and under the assumption that he actually understands them all and is not just winging it.
And I do get
Sorry for the sarcasm in the writing, it’s who I am and yes I do feel bad sometimes.
> Product-minded engineers don’t settle for getting a specification and jumping to implement it. They think about other ideas and approach the product manager with these. They often challenge existing specifications, suggesting alternative product approaches, that might work better.
Do you do this for every backlog item? I have assumptions about all tasks I receive and sometimes believe them to be less than ideally researched. Do I challenge all the time? I feel like that would land me in a bad place with multiple people over time.
> When coming with ideas, product-minded engineers don't just get these from thin air. They take the time to understand how the business works, how the product fits in, and what its goals are.
This is just a part of the paragraph, there are more ideas about user preferences and data analytics. Business is constantly changing, the product should ideally pivot based on user needs, goals change at least ocasionally.
In order to keep this loop going I personally feel like I either have to half ass it and pretend like I understand so we can get the release ready by the deadline or actually do this properly and that feels for me like a full time job rather than a bullet point to do on the side as an engineer.
Sure, I can say I look at analytics and talk to users, set up blind interviews and calls all the while following the business moves but in my case I would most likely be an impostor unless this would be a pretty large part of my work.
> Curiosity and a keen interest in "why?"
Just pasting headline from now on as there is a lot of text.
This paragraph encompases the job title of business analyst, project manager and business intelligence.
Let’s just assume I do have time in my workday for developer, business analyst, project manager, business intelligence and business strategy.
So all the points up until now, I can do cause I am amazing. And not just half ass them but fully get the ‘why’ and understand them all.
> They are smooth communicators, making it clear they're interested in learning more about how other disciplines work. I frequently see them grabbing coffee, lunch, or doing a hallway chat with non-engineers.
I know I said I’ll paste the title but this one flows nicely. Also, I am obviously a bad communicator but an amazing marketing and sales guy cause I spend the time talking to them about what they do all the time. But this is just fun chat, understanding new domains of expertise, I can squeeze them in my daily 8 hours.
> They also start making product tradeoffs, evaluating the engineering impact. They often go back to the product manager, suggesting a completely different feature to be built, given the product impact would be similar, but the engineering effort vastly smaller.
Architect, strategy, consultant. EZPZ I am 10x. But it’s doable, probably becomes annoying after awhile but with the time I spent analyzing all my product users and doing reports on them I probably come up with better ideas than my colleagues who work full time on this.
> Because they do it all in their head, using their engineering and product insights, they get to valuable conclusions remarkably quickly.
Oh, I thought this was based on user data, nvm I just do it in my head. I don’t need no data, I read it once and now my trimatrix quantum brain will just curve fit for the optimal solution. I think my colleagues love me for my mental abilities.
> This could be doing hallway testing with colleagues, showing the work-in-progress feature to the product manager, organizing a team bug bash on the beta build, and many other, creative ways.
I love how my whole team always has time for my ad-hoc bug bashings. I thought I was the only one with the time needed to handle ~ 10 roles to perfection.
> They are continuously thinking:"how can we validate that people will use this feature, the way we think they will?"
A little bit of psychology right here, nothing much, will fit right in my schedule, I’m only around 50% filled.
> It can take weeks to get enough reliable data to draw conclusions. Even though they might be working on a new project, they make checking on the results one of their top priorities. It's not a time-consuming activity, but it needs that additional persistence from someone wanting to know: how is my work really doing?
Oh, just some weeks of daily context switches to check on my baby. No boss, I’m also working on the other tasks for which I needed to do all roles, but I also log and audit the feature. Don’t worry, it’s not a time consuming activity, I just need to:
> spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists.
It’s ok, I just need to brush up on my data science. 51% filled.
Alright. What next, I still have 49% of my daily 8 hours. Oh I know, I’m going C-Level!
> What is the business model? How is money made? What parts are most profitable, what parts of the company are expanding the most? Why? How does your team fit into all of this?
I don’t need no CEO, CFO, CIO and / or ang form of c-level. I got this guys.
There’s something missing though, my 8 hours are filled with so many roles and I am still bored. I know!
> Pair with designers, UX people, data scientists, operations people and others, who frequently interact with users.
Can’t wait to brush up on my design and UX, luckily I already know Data Science and Operations from my other roles. I’m sure I won’t bother the UX all that much, he probably doesn’t do a lot of stuff anyway cause he’s not a product engineer.
Anyway, I feel real bad for having you on the end of my stick for what is really not a bad article. Just caught me frustrated with some aspects of it and saturated. I think your insights are valuable, a good guide, but maybe a bit too demanding of the role you are tryint to define.
So again, I am sorry, I know it’s not the easiest thing to get out there and be exposed to unfounded criticism but these were my 2c.
Best of luck!
>This paragraph encompases the job title of business analyst, project manager and business intelligence.
>Let’s just assume I do have time in my workday for developer, business analyst, project manager, business intelligence and business strategy.
>Architect, strategy, consultant. EZPZ I am 10x.
>I thought I was the only one with the time needed to handle ~ 10 roles to perfection.
> It’s ok, I just need to brush up on my data science. 51% filled.
>I don’t need no CEO, CFO, CIO and / or ang form of c-level. I got this guys.
>There’s something missing though, my 8 hours are filled with so many roles and I am still bored. I know!
>Can’t wait to brush up on my design and UX, luckily I already know Data Science and Operations from my other roles.
But I think the point you're missing is that you don't need to do all those jobs fulltime, you just need to have a baseline level of understanding of the underlying principles and needs of those roles. Which isn't that crazy - the "product manager"/"product owner" roles are a smorgasbord of skills and responsibilities, and most people who fill those roles aren't experts in every single skill and responsibility, just like every engineer isn't an expert in both kernel code and frontend frameworks.
The way I see it, the "product engineer" is between a product manager and a full stack engineer - someone with a certain level of understanding of different parts of the code, and different parts of the business, but not an expert at any. A generalist whose generalist skills go beyond just the engineering domain, but that doesn't mean they're specialized in all of those skills.
Is it easy to acquire all of those skills, even to the generalist level needed to be useful even though you're not an expert? No, of course not. But you also don't have to do it all at once. Doing any of the items on this list can add value, and once you get used to doing it, it's part of your daily routine. Then you pick up something else. It adds up over time.
When we talk on HN about managers that have technical competencies and try to get into the development process we bash them for thinking they understand, but we sometimes argue that we need to understand and do all roles and it works...
I could make any list of desirable characterisics and it would make those that follow it better professionals. Does the list of OP not match any other job than product engineer? Would a tester not be a better employee with the same understanding, or an HR person?
I can't speak for every conversation on HN, but personally, I have no problem with technical managers that know what they're talking about, as opposed to non-technical managers that attempt to make technical decisions. If someone is trying to be a 'product engineer' but doesn't have the first idea what they're doing about anything beyond software development, I agree that would be counterproductive.
>I could make any list of desirable characterisics and it would make those that follow it better professionals. Does the list of OP not match any other job than product engineer? Would a tester not be a better employee with the same understanding, or an HR person?
Well, it matches the job of... product. Which hasn't always been a separate job from software development, and in some companies it still isn't.
I think there's a distinction to be drawn here, though. An HR person certainly might benefit from insights into the company's business, talking to customers, etc., and it very well could make them more effective at their job. But for the person building the product, it's more relevant to what they're doing every day, since it directly determines both the input and output of their work. I suspect sales has a similar dynamic - understanding the customers and the product is going to highly relevant. A software engineer who just completes tickets and focuses only on purely technical problems might be effective, just as a salesperson who thinks that selling cars, selling software, and selling biscuits are all the same process might be effective, based purely on talent in the relevant skills (strong technical skills for the dev, strong interpersonal skills for the salesperson), but I'd expect the same person to be much more effective if they added some of these product skills, where the force multiplier isn't quite there for HR or Accounting.
Of course, not every skill is going to be helpful for every role. As a software engineer, interpersonal skills are likely to be very useful, but learning to close a sale probably isn't going to have much benefit. The point of the article is that the author finds that software engineers who have these product skills are much more effective at making good software than software engineers who don't.
If the above is your understanding of the article, then I'm sorry to say, you seriously need to work on your basic reading comprehension skills.
And if you actually understood the real point of the article, that all of the described activities happen spread out over longer periods of time, as the engineers build up a momentum of total product/business knowledge/expertise/rapport with other stakeholders in the org, by actually being curious, asking questions, and offering measured feedback; if you really understood this, then seriously, I have to question why even bother to reply and waste everyone's time? Totally pointless.
Yes, in my work experience, the dynamics of development had us discussing the tasks that we work on... daily, weekly or monthly.
One of my realizations when switching from product development to some of the other roles mentioned in this post is just how much time they actually take... all the discussions, the what ifs, the stakeholder back and forth.
Yes, I do believe that the article mentions characteristics that should be applied in the work context, which is 8hrs per day in hopefully an expert way.
> If the above is your understanding of the article, then I'm sorry to say, you seriously need to work on your basic reading comprehension skills.
> And if you actually understood the real point of the article, that all of the described activities happen spread out over longer periods of time, as the engineers build up a momentum of total product/business knowledge/expertise/rapport with other stakeholders in the org, by actually being curious, asking questions, and offering measured feedback;
I believe I argument my understanding as I read the article in the post you replies to.
> if you really understood this, then seriously, I have to question why even bother to reply and waste everyone's time? Totally pointless.
I was hoping I got my point across. Maybe it made sense to some people, but just because I am dumb and lack reading comprehension means I can’t post here? Am I responsible for your time wasting decision?
If you are hired in a “plain” engineering position it can be difficult to break out as a product engineer. Are you allowed to talk to customers? Is your time zealously measured?
I’ve tried in different projects with varying degrees of success. Fortunately with full success currently.
It would probably be interesting to analyse and write notes on “how to go from plain engineering to product engineering in friendly, neutral and hostile environments”.
And regarding 3: both, of course. But he'll probably care more about users in day to day work, as those are more directly relevant to his goals (making a good product).
However, I do feel like actually being insightful and competent in so many domains of knowledge is a bit too much to ask of a single role.
I’m arguing that there should be separate roles, with different responsabilities, of people that are good in their specific domain and that the process of delivery should take care of mixing their outputs into something meaningful for the customer.
Putting my faith in this magic product engineer role that touches all aspects of the company, and expecting that person to really get good stuff constantly seems like a step in the wrong direction to me.
So what I want to say is that I've worked with this kind of person. It was exactly this type of engineer.
As a team member he is the worst kind of team player. While everyone is focusing on the actual sprint and the important tasks to be done, he keeps going around to other teams and collecting requirements for things:
- which either has been already discussed and estimated before he joined the company but he is ignorant of that fact
- which is supposed to be built on just his assumptions and because he is in no position to make decisions by himself he cannot really test his assumptions, and because he needs constant assistance to test his hypothesis he actually takes everyone's time on the team to work on assumptions that has no merit
At the same time for example he cannot identify the time when bugs need instant attention and need to be solved immediately so he seemingly cannot be bothered by those lowly matters of bugs and high priority things.
And because of his why? why? why? attitude even when the time is short and something has been discussed and written down in details MANY TIMES before, he needs constant repeating of every discussion because he just can't trust anything which was discussed WITHOUT HIM, his ego is too big for that.
Not to mention that he asks about product/engineering tradeoffs all the time when no-one, including him has nooo idea what are those tradeoffs, so the only thing he does is casting doubt and postponing decision making.
Not to mention that when he walks around for example and tries learning how other teams work, he is basically generating a false hope in people that he will actually deliver something soon. And oh man, couldn't be that any wronger?! Especially when he is in no position to make priorities and hiring decisions, etc, he is just basically playing a game, and this game is called politics.
This kind of person many times is just a constant waste of time. And yes, business people love these kind of person because someone finally speaks their language. The problem is that this language and communication is completely broken and misguided. Just like office politics is most of the time.
> They'll often spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists
That's basically correct, and that's also how I would summarize. Let's call it the `Debate-Minded Software Engineer` instead and then I'll have no complaints. But this is not productive!!! You want to have 10 of these people on your team? In a fast moving startup? Good luck for implementing anything EVER.
Also these are the people who can never understand that some people are busier than him. So then they think: OK, instead of waiting a day, they can just go ahead and build something based on their understanding. And then they are watching with horror when somebody tells them to stop it, because there are other higher priority things to do.
Also somehow this post equates the product manager to be some kind of superman. If you ever worked outside of silicon valley you will know that even these days there are many companies, I would even say that's the majority of companies, where projects are built and delivered with big upfront design, and there is no follow-up on the release or anything like that. There is a select number of people in the design process and if you are not invited to the discussion, then you will never have the chance to impact the product even the slightest.
And one more thing. Since this post is just speculation and it's extremely anecdotal, let me share my anecdotal evidence too.
Even when someone looks like the ace that the post describes, my experience is that these people are not that fast! They are either as fast as everyone else, or just mediocre in the technical side of things. So the only way that I saw these people to operate is that they put in extreme hours outside of working hours so that they can get the info, the context, etc which they need to look smart and having insight.
And here is the real problem? Why would you or anyone suggest this kind of modus operandi? Isn't most engineers' life overworked and miserable enough? You guys in Silicon Valley have to understand that people outside that bubble in other countries have shitty salaries and no work-life balance, so the incentive to put in extra hours and be the superhero of the company is almost zero, even though WE HAVE TO DO THE SAME JOB ON THE SAME QUALITY LEVEL as you guys in SV.
I wish we would stop idealizing these kind of imaginary roles and positions in the industry because this is extremely damaging to our profession. Especially to those people who are not that successful then the post's author.
What would be much more preferable to see a post from the same author that he describes in detail why engineers choose not to be like the person he described. That would actually show some humility and actual respect to everyone in the field.
We don't need a bullet point list to become something else that we are. What we need though is scaling back and tuning down the voice of people who think that there is one true shiny way of product development.
I think one of the reasons I found them pleasing to read is if I personally had some of the qualities mentioned in them... validation I guess. But I agree with you that these articles don’t provide much value.
I 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.
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.
Product development should be done on process I think, not on superstar product engineers.
I think the role is new, misunderstood, but I believe throwing bullet points is maybe not the way.
What I’m arguing against mostly is this focus on the person instead of the process and the push that someone can be a master of all those domains of knowledge (as in this article).
I wrote some (mean) thoughts as I was going through the article which I will answer now to the OP post where he answers my question if you are curious to check it out.
I sit in on a lot of meetings, talk to users, etc. and I program enough to know the ins and outs of our codebase. This means when wireframes are being put together I can say "well, that one will take 3 months longer" before anyone can get invested, clarify ambiguity I know the programmers will struggle with, and better translate user requirements to technical ones.
At a high level I'd say I'm sort of a liaison between two very different groups of people with very different realms of expertise. There's a lot of "translation" that necessary for that but anyone who's middling in both fields should be able to perform in the role.
Similarly, you can expect a software engineer to be somewhat product competent so they can push back on bad ideas, proactively suggest better ways of doing things, and even connect the business dots and propose entire classes of new features that the PM maybe didn't even realise were possible / within reach.
It's not two roles in one, it's not working 16 hours / day, it's just having the right mix of experience and intuition such that you're still primarily an engineer but you help guide the product.
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.
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.
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.
> 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).
The results were humbling for all everyone. Sometimes I was right but I often implemented features that I was sure would fail but turned out to be big successes.
Although my ego was initially bruised, the tactic was a big win for the business as now the product is more data driven.
If you're the kind of engineer described in this article, you don't need to read this article. You have always naturally behaved this way and there is a natural trajectory that you're on because of it. You find this article just resonate deeply with you.
If you're not the kind of engineer described in this article, you probably can't become one. You will try to follow advice and wind up falling flat. Thats because the kind of engineer described in this article isn't following advice, they are following instinct. And if you don't have instinct then you have nothing to follow.
I agree that following simple advice probably won't work, but I personally believe intentional practice can actually help people get better at this — only there has to be more than a desire to communicate out, there has to be a desire to put oneself on the line and evaluate oneself honestly based on result.
My mental model on this is that for a given skill/outcome everyone sits somewhere on a continuum of possibility with upper and lower bounds depending on intrinsic factors.
So, in that sense I agree there are those people who could develop a certain aptitude through a clear pathway of study. My model assumes their highest level of aptitude they can attain is capped at that lower than those who are "naturals". Conversely if you are a natural and you never seem to develop your aptitude, you will bumble along likely doing OK or even accidentally doing well, but those who can reach the absolute top of the aptitude spectrum are those who a) realize they are a natural b) seek out a pathway to accelerate their progress and c) actively work really hard at it.
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.
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.
The internal views are important, but the external views, market aspect, user experience of your product is most important.
Even if only one person ever uses it, make it at least a pleasant and good experience.
I like to essentially live in products, get fully invested in it and make it something that somehow, in a way, becomes a 'friend'. Something that helps users and they don't mind revisiting. Find the fun or at least the good experience.
Luckily, making games and interactive projects makes that easier than say an insurance form, but even the latter, make it a pleasant part of the day even if it is low impact internally. Make it functional and fun if possible or at least pleasant and predictable where it needs to be.
I always get a bit annoyed when companies are too focused internally not externally, from the market, from the user perspectives. In fact, self-obsessed internal companies that value the politics internally more valuable than the external products the company produces, those are typically not successful companies or products down the line.
What is particularly bad is when you have to fight to put in quality or features that users want, that make a better product, but it harms your perception because of the production level you want adds time or managers/bizdevs might not see the value when it is very valuable. Internal politics can also discourage workers from attempting to make products better. No one wants to expend all their energy just getting the ability to build. Do it, show it, ask for forgiveness later as permission might not have the full picture to green light it.
Be proud of every product you make, make it quality, make it useful, make it fun, and broadcast it internally but don't get discouraged with the internal focused perception, obsess over the external views including user perception, market perception and it will win the internal perception by default. If you make enough good products and projects, eventually they come around.
You are what you make.
You might be right, and it’s not fair of me to expect everyone to have the same driving goals, but I simply miss the ability to focus on building something good (for customers and the business) and everyone being in tune, instead of catering to an endless stream of personal needs. Worse, in order to “perform well” it forces you to prioritize saving face and pleasing people over actual product/design/engineering, since half of your peers don’t care, or will be gone by next cycle.
Maybe you're good enough to make it clear that your only trying to help, but maybe there is a 3rd person that competes not with you but with the person you're trying to help, that will take advantage and make it look like they're clueless.
Maybe the person you're trying to help will respond positively when you're around, maybe they'll talk behind your back with the right people to shut you down.
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.
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!
Wouldn't "in the field" suffice as a term here?
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!
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.
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.
He's still right all these years of experience later.
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.
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"
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.
It’s about caring and understanding the product, the problem space, and the customers/users.
Why spend one month on an enhancement when an alternative can serve just as well or better, for say a day of effort?
But to even come up with sensible (or better) alternatives require domain knowledge and good relationships.
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.
I love that quote, and idea. Going to use it moving forward.
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.
There are projects where there are multiple sets of 'users' who don't necessarily overlap, and you'll find someone like this championing one set to the detriment of others.
This can be awkward to imagine in the context of internet apps where there's a 'product' and people use it, but in the context of business or government applications where the customer-facing product is not merely the frontend it can be very relevant.
If you're producing software which runs on each customer's own servers, as an independent system instance, the user-stakeholders include:
* The people using it in day-to-day tasks. These are the 'Users' an internet-based application usually considers.
* The ops guys looking after those servers, who have no other power over the software system itself (but will lose their weekends when eg. the vendor-documented backup procedure turns out to be incomplete).
* Other vendors, who probably have to integrate with the system
(and will curse the documentation or lack thereof).
* The customer's internal helpdesk fielding end-user queries about the system (frantically hunting through a content-free manual, if they're new to the job, or escalating without comment, if they're burned out).
* The Administration, who want reports on the behaviour and performance of the Users mentioned above (and often don't care
about usability as long as the reports are pretty).
* And many other groups, with entirely different concerns.
A great many of these articles seem to either champion only the 'User' and/or refer only to systems where all other parties are internal to the company building the software.
The world still relies heavily on a lot of systems which do not conform to the Cloud ideal. It is important for any 'product-minded software engineer' to remember that, sometimes, making eg. the Ops guys' job easier will make life better for All Of The Above, even more than chasing after that shiny report Admin wants.
Of course, if you are building in the Cloud, The Above are largely your coworkers and should make all of this known to you :P
Now, as an engineer I gotta say, we need MOAR speed! :)
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.
If I ever hear anyone say that in real life, I will die on the spot.
> minimum lovable product
Wow, had never seen that one. I feel like we have reached peak "elevator pitch" speak.
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.
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.
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...
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.
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.
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.