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.
I did a little read through again and noted down my thoughts.
This is mostly in relation to my view that a single person ... would have trouble, with filling all these roles within the 8 hours given per day and under the assumption that he actually understands them all and is not just winging it.
And I do get
Sorry for the sarcasm in the writing, it’s who I am and yes I do feel bad sometimes.
—
> Product-minded engineers don’t settle for getting a specification and jumping to implement it. They think about other ideas and approach the product manager with these. They often challenge existing specifications, suggesting alternative product approaches, that might work better.
Do you do this for every backlog item? I have assumptions about all tasks I receive and sometimes believe them to be less than ideally researched. Do I challenge all the time? I feel like that would land me in a bad place with multiple people over time.
> When coming with ideas, product-minded engineers don't just get these from thin air. They take the time to understand how the business works, how the product fits in, and what its goals are.
This is just a part of the paragraph, there are more ideas about user preferences and data analytics. Business is constantly changing, the product should ideally pivot based on user needs, goals change at least ocasionally.
In order to keep this loop going I personally feel like I either have to half ass it and pretend like I understand so we can get the release ready by the deadline or actually do this properly and that feels for me like a full time job rather than a bullet point to do on the side as an engineer.
Sure, I can say I look at analytics and talk to users, set up blind interviews and calls all the while following the business moves but in my case I would most likely be an impostor unless this would be a pretty large part of my work.
> Curiosity and a keen interest in "why?"
Just pasting headline from now on as there is a lot of text.
This paragraph encompases the job title of business analyst, project manager and business intelligence.
Let’s just assume I do have time in my workday for developer, business analyst, project manager, business intelligence and business strategy.
So all the points up until now, I can do cause I am amazing. And not just half ass them but fully get the ‘why’ and understand them all.
> They are smooth communicators, making it clear they're interested in learning more about how other disciplines work. I frequently see them grabbing coffee, lunch, or doing a hallway chat with non-engineers.
I know I said I’ll paste the title but this one flows nicely. Also, I am obviously a bad communicator but an amazing marketing and sales guy cause I spend the time talking to them about what they do all the time. But this is just fun chat, understanding new domains of expertise, I can squeeze them in my daily 8 hours.
> They also start making product tradeoffs, evaluating the engineering impact. They often go back to the product manager, suggesting a completely different feature to be built, given the product impact would be similar, but the engineering effort vastly smaller.
Architect, strategy, consultant. EZPZ I am 10x. But it’s doable, probably becomes annoying after awhile but with the time I spent analyzing all my product users and doing reports on them I probably come up with better ideas than my colleagues who work full time on this.
> Because they do it all in their head, using their engineering and product insights, they get to valuable conclusions remarkably quickly.
Oh, I thought this was based on user data, nvm I just do it in my head. I don’t need no data, I read it once and now my trimatrix quantum brain will just curve fit for the optimal solution. I think my colleagues love me for my mental abilities.
> This could be doing hallway testing with colleagues, showing the work-in-progress feature to the product manager, organizing a team bug bash on the beta build, and many other, creative ways.
I love how my whole team always has time for my ad-hoc bug bashings. I thought I was the only one with the time needed to handle ~ 10 roles to perfection.
> They are continuously thinking:"how can we validate that people will use this feature, the way we think they will?"
A little bit of psychology right here, nothing much, will fit right in my schedule, I’m only around 50% filled.
> It can take weeks to get enough reliable data to draw conclusions. Even though they might be working on a new project, they make checking on the results one of their top priorities. It's not a time-consuming activity, but it needs that additional persistence from someone wanting to know: how is my work really doing?
Oh, just some weeks of daily context switches to check on my baby. No boss, I’m also working on the other tasks for which I needed to do all roles, but I also log and audit the feature. Don’t worry, it’s not a time consuming activity, I just need to:
> spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists.
It’s ok, I just need to brush up on my data science. 51% filled.
Alright. What next, I still have 49% of my daily 8 hours. Oh I know, I’m going C-Level!
> What is the business model? How is money made? What parts are most profitable, what parts of the company are expanding the most? Why? How does your team fit into all of this?
I don’t need no CEO, CFO, CIO and / or ang form of c-level. I got this guys.
There’s something missing though, my 8 hours are filled with so many roles and I am still bored. I know!
> Pair with designers, UX people, data scientists, operations people and others, who frequently interact with users.
Can’t wait to brush up on my design and UX, luckily I already know Data Science and Operations from my other roles. I’m sure I won’t bother the UX all that much, he probably doesn’t do a lot of stuff anyway cause he’s not a product engineer.
—
Anyway, I feel real bad for having you on the end of my stick for what is really not a bad article. Just caught me frustrated with some aspects of it and saturated. I think your insights are valuable, a good guide, but maybe a bit too demanding of the role you are tryint to define.
So again, I am sorry, I know it’s not the easiest thing to get out there and be exposed to unfounded criticism but these were my 2c.
There are several points here where you assume that as an engineer, you need to learn to do another job entirely, here:
>This paragraph encompases the job title of business analyst, project manager and business intelligence.
>Let’s just assume I do have time in my workday for developer, business analyst, project manager, business intelligence and business strategy.
Here:
>Architect, strategy, consultant. EZPZ I am 10x.
Here:
>I thought I was the only one with the time needed to handle ~ 10 roles to perfection.
Here:
> It’s ok, I just need to brush up on my data science. 51% filled.
Here:
>I don’t need no CEO, CFO, CIO and / or ang form of c-level. I got this guys.
>There’s something missing though, my 8 hours are filled with so many roles and I am still bored. I know!
And here:
>Can’t wait to brush up on my design and UX, luckily I already know Data Science and Operations from my other roles.
But I think the point you're missing is that you don't need to do all those jobs fulltime, you just need to have a baseline level of understanding of the underlying principles and needs of those roles. Which isn't that crazy - the "product manager"/"product owner" roles are a smorgasbord of skills and responsibilities, and most people who fill those roles aren't experts in every single skill and responsibility, just like every engineer isn't an expert in both kernel code and frontend frameworks.
The way I see it, the "product engineer" is between a product manager and a full stack engineer - someone with a certain level of understanding of different parts of the code, and different parts of the business, but not an expert at any. A generalist whose generalist skills go beyond just the engineering domain, but that doesn't mean they're specialized in all of those skills.
Is it easy to acquire all of those skills, even to the generalist level needed to be useful even though you're not an expert? No, of course not. But you also don't have to do it all at once. Doing any of the items on this list can add value, and once you get used to doing it, it's part of your daily routine. Then you pick up something else. It adds up over time.
When we talk on HN about managers that have technical competencies and try to get into the development process we bash them for thinking they understand, but we sometimes argue that we need to understand and do all roles and it works...
I could make any list of desirable characterisics and it would make those that follow it better professionals. Does the list of OP not match any other job than product engineer? Would a tester not be a better employee with the same understanding, or an HR person?
>When we talk on HN about managers that have technical competencies and try to get into the development process we bash them for thinking they understand, but we sometimes argue that we need to understand and do all roles and it works...
I can't speak for every conversation on HN, but personally, I have no problem with technical managers that know what they're talking about, as opposed to non-technical managers that attempt to make technical decisions. If someone is trying to be a 'product engineer' but doesn't have the first idea what they're doing about anything beyond software development, I agree that would be counterproductive.
>I could make any list of desirable characterisics and it would make those that follow it better professionals. Does the list of OP not match any other job than product engineer? Would a tester not be a better employee with the same understanding, or an HR person?
Well, it matches the job of... product. Which hasn't always been a separate job from software development, and in some companies it still isn't.
I think there's a distinction to be drawn here, though. An HR person certainly might benefit from insights into the company's business, talking to customers, etc., and it very well could make them more effective at their job. But for the person building the product, it's more relevant to what they're doing every day, since it directly determines both the input and output of their work. I suspect sales has a similar dynamic - understanding the customers and the product is going to highly relevant. A software engineer who just completes tickets and focuses only on purely technical problems might be effective, just as a salesperson who thinks that selling cars, selling software, and selling biscuits are all the same process might be effective, based purely on talent in the relevant skills (strong technical skills for the dev, strong interpersonal skills for the salesperson), but I'd expect the same person to be much more effective if they added some of these product skills, where the force multiplier isn't quite there for HR or Accounting.
Of course, not every skill is going to be helpful for every role. As a software engineer, interpersonal skills are likely to be very useful, but learning to close a sale probably isn't going to have much benefit. The point of the article is that the author finds that software engineers who have these product skills are much more effective at making good software than software engineers who don't.
Maybe this can be abstracted into being focused or being a generalist. I think OP is arguing that there is value in being a generalist and you are resisting that. I sympathize with OP, I've seen a lot of managers appreciate generalists and I've gotten a lot of value out of them myself. Maybe not everyone needs or wants to be one, but it's fair enough to outline it as a way of operating that provides a lot of value.
So to clarify–your understanding of the article is that, it says that a product engineer should be working at an expert level (or at least same level as full-timers of those roles) in about 10 different roles in addition to developer? And they should be doing this during 8 hours of every single day, context switching between different roles in small time slices?
If the above is your understanding of the article, then I'm sorry to say, you seriously need to work on your basic reading comprehension skills.
And if you actually understood the real point of the article, that all of the described activities happen spread out over longer periods of time, as the engineers build up a momentum of total product/business knowledge/expertise/rapport with other stakeholders in the org, by actually being curious, asking questions, and offering measured feedback; if you really understood this, then seriously, I have to question why even bother to reply and waste everyone's time? Totally pointless.
> So to clarify–your understanding of the article is that, it says that a product engineer should be working at an expert level (or at least same level as full-timers of those roles) in about 10 different roles in addition to developer? And they should be doing this during 8 hours of every single day, context switching between different roles in small time slices?
Yes, in my work experience, the dynamics of development had us discussing the tasks that we work on... daily, weekly or monthly.
One of my realizations when switching from product development to some of the other roles mentioned in this post is just how much time they actually take... all the discussions, the what ifs, the stakeholder back and forth.
Yes, I do believe that the article mentions characteristics that should be applied in the work context, which is 8hrs per day in hopefully an expert way.
> If the above is your understanding of the article, then I'm sorry to say, you seriously need to work on your basic reading comprehension skills.
Perhaps...
> And if you actually understood the real point of the article, that all of the described activities happen spread out over longer periods of time, as the engineers build up a momentum of total product/business knowledge/expertise/rapport with other stakeholders in the org, by actually being curious, asking questions, and offering measured feedback;
I believe I argument my understanding as I read the article in the post you replies to.
> if you really understood this, then seriously, I have to question why even bother to reply and waste everyone's time? Totally pointless.
I was hoping I got my point across. Maybe it made sense to some people, but just because I am dumb and lack reading comprehension means I can’t post here? Am I responsible for your time wasting decision?
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”.
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.