19 ms·

The Product Engineer

166 points by patch45 11y ago

patch45 11y ago
This really hit home for me. I was recently looking for a job so these ideas are fresh on my mind. What I have been trying to figure out, is it better to work for a company that has a good product strategy, or an other wise good company without a product strategy? At the time, my thoughts were to find a company that needs a product minded developer. A company that has everything else figured out but product.
- codingdave 11y ago
  A solid product with a sketchy tech team will result in a solid company that needs some internal work to truly take off. A solid tech company without a product is just some devs congratulating themselves on how smart they all are while they pour money out.
- natrius 11y ago
  A company that hasn't prioritized product strategy isn't going to suddenly start prioritizing it once you get there. You are more likely to be ignored. Go somewhere that does product well, especially if you're early in your career.
  - deleted 11y ago
    [deleted]
  - DavidChouinard 11y ago
    There definitely exists organizations lead by smart non-product people who recognize their shortcoming and are enthralled to support it.
k__ 11y ago
Nice. For me it always seemed as if there are consulting engineers and product engineers. A few of my friends are devs at agencies, who worked at different projects for many clients, those were the consulting engineers to me. I always worked for companies who sold software products, so I considered myself a product engineer.
11thEarlOfMar 11y ago
Product Engineering as a role is also critical in hardware companies, where discipline-focused engineers such as mechanical, electrical, firmware, etc. need to implement the features of the product. Many times, they fall into the trap of making an impressive feature set work and then thinking they can start selling the product. What is missed are critical design elements such as: - Cost of materials/assembly - Power consumption and distribution - Reliability of the system - Durability of the system - Supply chain integrity and robustness - ... It seems that a lot of the new robotics companies and many KickStarter projects fall into this trap: under-budget the product development, both in time and resourcing, and release their product prematurely. This is all quite obvious to people who have participated in successful consumer or enterprise hardware companies, but young companies are still vulnerable. Advice would be to get it all working as a prototype, then, expect another major project of turning it into a Product before releasing.
- DavidChouinard 11y ago
  Hardware teams have been explicit about this role for a long time. I wish I had first-hand experience of hardware product engineering, but it's certainly an inspiration for this essay.
deleted 11y ago
[deleted]
jonathanpeterwu 11y ago
Kudos on hitting the ethos behind product first engineers who build w/ code for the love of creating things rather than just the code. Code is the tool you wield to build great things, not the only source of beauty.
holman 11y ago
Was hoping this would be about hiring, because I've been thinking a lot recently about how shitty hiring is for these people. I've been interviewed for a lot of these ostensibly "product" positions this year. A lot of it has to do with the company not even understanding what they're hiring for. Initial screeners would be all about product, product, product, but then they'd give me a new grad programming trivia test about rearranging chars in a string. Such a weird mismatch of aspirations vs. reality on the interviewer's part, and, most importantly, I've never come away from these interviews feeling the interviewer has a solid understanding of what I might bring to the table. I'd push more for it before leaving the interview, but by that point the interview itself has soured me on the company overall. I think this is exacerbated in the startup world in particular, because even "straight technological" roles in a sub-10 person team will inevitably include a ton of product decisions throughout the course of fast-paced development, and I worry too many startups focus on these type of algorithmic hiring tests being some sort of qualifier for these people when it's not.
- BillinghamJ 11y ago
  What should we be asking/looking for/testing?
  - noir_lord 11y ago
    I'd hand them a piece of paper and ask them to sketch out a profile page that's user friendly. Then I'd ask them how they'd design the schema for that. Then I'd ask them to sketch out the admin interface for managing users and how they'd implement that. If they start asking questions about permissions and roles and such I'd be really impressed. Essentially I'd act like a client/end user who kinda knows what they want to see if they can ask the right questions. I'm not looking for a UX expert but more someone who thinks about the process and end result as well as a nice way to implement the code side. I'd ask programming related questions as well but if (when) I hire I want someone who thinks about the end user experience while they are developing, I don't live in a world where a job comes with a 400 page spec and neither would they. I take the view that I'd rather have someone who can think about how the end system will work than someone who knows ever single API for whatever language I'm hiring for, one of those you can find on google in 30 seconds the other not so much.
danenania 11y ago
This really resonates with me. There seems to be a trend of frowning on these types as 'generalists' who don't have sufficiently hard tech skills, but 'creates great products from the ground up' is a specialization in itself, and an extremely critical one. Someone who will do (and learn) whatever it takes to put out high quality work is someone who will be a top performer at almost any company, regardless of how they would do on a Google algorithms quiz. This mismatch was part of what motivated me to build MakerSlate [1], a résumé optimized for just this type of creator. 1: https://makerslate.io https://makerslate.io
- mpdehaan2 11y ago
  It's a good post and a good thought. Software is a giant LEGO set with no instructions, and it takes a good mixture of how to build things and knowing what you can build. A lot of times people want to reduce product management to "visit customers, ask what they want, make a spreadsheet", but I think it's more than that. To do it well, you have to know the possibilities the existing stack could grow into, and also what it can't easily grow into, and set a vision that is well beyond what the masses point at. And you also have to know the industry enough to know how to build things that make sense to end users. In maybe 80% of the jobs I've had, non-technical product managers have been probably the single most powerful force to get me to leave an organization, because I always get very invested in a product and want to see it do the right thing, and I want to work on and design the right things. Working on the wrong things - features nobody is going to use, features that won't work, features that don't take advantage of a great opportunity or make a product great to use - can be demoralizing. I want to work on the thing that will make the most difference -- and then be able to witness that difference in hearing those stories from userland. And the second you take the design out of it (and reduce software down to implementation), for me, the fun parts are gone (unless there's some heavy C.S. or architecture parts, which in CRUD stuff is rare) and it's just implementation. Also - I will say, having done it, product management is always one of the most misdefined and potentially most disliked positions from the outside. It's the easiest to please no one while still trying incredibly hard to do the right thing, and probably the most important make or break function - because a company is totally viewed by what it decides to create. Further, a good PM can be made powerless if he can't get engineering do anything, and frequently organizational lines are set up so that he cannot. It's a position that needs to be elevated because it's so important, but instead almost gets lumped in with project management and viewed as easily interchangeable; the result is bad PMs make it hard for good PMs to get any respect. There's a huge standard deviation. Product management can also get in a bad spot when you give a few people absolute product control, and you ignore the ideas from developers and others throughout the company. So even if you are in this spot, and it's respected, you have to give voice to the entire company and try to focus sometimes hundreds of laser beams all pointed in different directions. The C.S. I majored in was about designing things, a lot of software engineering is about implementing features out of canned components other people have already designed. I think there's a lot of lost possibility in that, and we should encourage everyone to be more creative and blur the lines more in how we define software positions.
palakchokshi 11y ago
I consider myself as a product engineer too and the traditional interview process is definitely broken for someone like me. I think @holman nailed the current interview process with this statement "I need to figure out hidden knowledge that the interviewer knows already". I'm glad to know there are others who share my frustrations. Having said that, I think for my next interview I am going to go in telling them who I am. I will own the Product engineer title and let them know what a Product Engineer is and what we excel at. If that is something they are interested in then we can continue otherwise it will be a waste of time for everyone. If I were to design an interview process for someone like me I would come up with a simple product. It can be something as simple as a List web app ala Trello. Then have them design the product for individual use, then layer on collaboration requirements and then layer on sharing requirements, if time permits. This will allow me to know how they think about the product. If they suggest collaboration when designing for individual use then that's awesome because it tells me they are already thinking about where the product can go.
chejazi 11y ago
As a candidate you might have better luck with companies that embrace Holacracy [0]. On the recruiting side, I have a hunch that the best way to get more Product Engineers is to have the Product Engineers in your org conduct interviews in addition to the pure technical ones. A requirement for this is that the Product Engineer's title is made explicit, otherwise "wtf, why is this person always doing the interviewing." [0] http://www.holacracy.org/how-it-works/ http://www.holacracy.org/how-it-works/
tonystubblebine 11y ago
Do people think the product engineer can be trained? One issue I run into is one of expectations. I think product engineers are treated like some sort of unicorn (a designer/coder). I can see why that might have been true in 2000. But a lot has changed since then. For one, being a product engineer could be considered a hack for picking up tech skills quickly. It's often much easier to learn by doing and product engineers define themselves by the product they're trying to build. Plus, software got so much easier to build. What is your reaction to that? Do you go deeper and more esoteric than you used to be able to go? Or do you go broader? Broader makes sense to me--that's the product engineer. But to what end? Do you go broader in order to save on team size? An engineer/designer means you can skip a design hire. Or do you go broader because you can have more autonomy? To me, product engineers are the natural outcome of software getting easier (and design to some extent). People can have more autonomy because you can develop the skills to get more done on your own. But I don't think management has caught up. There's still an assumption that these skill sets don't go together. Autonomy is killed when you have specialist designers and specialist engineers. And that's why I led with the idea about training product engineers. I want to be able to create a culture at my company that assumes that you're a product engineer. Junior product engineers just work on smaller problems.
pteredactyl 11y ago
Thanks for making this a 'thing' as I figure out how best to position myself.
10dpd 11y ago
Reading this I'm wondering what the difference is between a "Product engineer" and a "UX Engineer"?
- palakchokshi 11y ago
  I would differentiate them in the following way: Product Engineer: Focused on creating something that fulfills users' need or want UX Engineer: Focused on polishing the product to make sure the user's need or want is fulfilled with the least amount of friction.
  - reverius42 11y ago
    UX is not about polish. UX is the product -- literally, from the user's perspective. I don't think there is a meaningful difference between Product Engineer and UX Engineer.
    - palakchokshi 11y ago
      The X in UX is Experience so indeed a UX Engineer's role would be to improve the user's experience of the product not necessarily define what the product should be. It's unfortunate that UX is being confused with Product. Let me illustrate with an example: Consider a product with 20 features, 10 of which will be helpful to the user once they have been using the product for a while. The UX engineer's job is to identify this and provide a user flow of progressive disclosure of those 10 features based on user's actions. This improves the Experience for a user by not overwhelming them with all 20 features when they are just starting to use the product. A Product Engineer's job is to identify the 20 features because they are useful for users.
      - gomox 11y ago
        In terms of conventional job titles, that's the job of the Product Manager.
        11y ago
keepitsurreal 11y ago
Does anyone have any advice finding these roles? Most of my main projects have included me building products up from the ground up with successful releases. I've been cramming technical interview questions because its seems like the only foot in the door, but this kind of position is where I know I'll thrive. Where do I look for Production Engineering positions? How does a new grad w/ a CS background move into one of these roles with relevant experience?
- pcunite 11y ago
  I'm in the throes of this right now, but I think product manager is close. Read the job description to see if it errors on the side of programming.
- johns 11y ago
  If you want to work at a startup, the earlier they are they more likely that every engineer is a product engineer. The bigger companies get, the less generalists are relied upon.
pcunite 11y ago
This is me! Feels so good to be understood. I'm currently identifying myself with product management & user experience because I recently came to this conclusion.
guelo 11y ago
Everyone that walks around with a touch screen computer in their pocket thinks they are a genius of product design. But if you actually want to design products the first step is to become an expert in the code. So stop day dreaming that you're the new Steve Jobs and get coding.
- sweezyjeezy 11y ago
  > if you actually want to design products the first step is to become an expert in the code I'd say the first step in designing a good product is understanding what the client/customer actually wants. That is where a position like product engineer/product manager are invaluable. It doesn't matter how good you are at coding, if no one wants the thing you're working on.
- kovacs 11y ago
  Everyone that has a car thinks they're a great race car driver. But if you actually want to be a great race car driver the first step is to become an expert in building the car. So stop day dreaming that you're the new Mario Andretti and grab a wrench. That sounds as silly to me as your assertion. And yes I can code and have for a very long time. I'll take the person that can figure out what will resonate with users and doesn't know a line of code over a guy that can code but isn't good with products. The skill sets are orthogonal in many products. Sometimes being able to code may give you important insights that a non-coding product person won't have, but I wouldn't count on it as a sustainable advantage for all but the most complex of products (e.g. enterprise/plumbing software), and even then a great product person will figure out what they need in order to arrive at the salient product decisions. Sometimes having the ability to code is a hinderance to building a great product.
  - guelo 11y ago
    Yes, everyone, including coders, thinks they are the best product designers. The difference is that top-level coders actually have the influence to implement their ideas, whether they're good or bad. That's how you get your foot in the door. Walking in to a startup wanting to be the one that tells everybody else what ideas they should be implementing is not going to get you far. I'm not saying that product managers are not useful, but good product managers are data driven and their main job is to gather and summarize the available data and enable a conversation within the company about the product direction, not to be the grand visionary that hands down ideas from on top.
jaunkst 11y ago
Product engineers are sought after, and for companies that build flag-ship products they should be core to development. Product developers are often founders and should guide the vision as they have the product itself at heart and mind. https://data.triplebyte.com/who-y-combinator-companies-want-c1880a08ac88#.zdwdvsa5j https://data.triplebyte.com/who-y-combinator-companies-want-...
t3hprogrammer 11y ago
I recently wrote about the gap between product-motivated and technically-motivated engineers: https://medium.com/@ericwleong/the-product-technical-spectrum-d3e76aa8bff7#.5x6avaz8l https://medium.com/@ericwleong/the-product-technical-spectru... Certainly startups are interested in hiring engineers motivated by product, but technical interviews obviously don't look for that.
gonyea 11y ago
Bingo. I'm a product engineer as well. I build products in 1/4 the time of an entire team, with unit/integration tests. It's also technically correct--that is, as technically correct as it needs to be to ship, scale, and see if it gains traction. Waste my time white boarding a sorting algorithm and I'll turn down the job (well, unless the money is insane). But designing the flow/architecture of a new product idea? That's my catnip. I'll white board THAT.
- AznHisoka 11y ago
  So... isn't that an architect, or UX guy (if front end)? Why do we have to invent a new job title?
  - gomox 11y ago
    Software Architect in general implies a high-level (in terms of abstraction) technical position within an engineering team. This person is usually in charge of the design of the software, as in "use a queue here instead of a database", "this data should not go to the UI, but instead be requested on demand", "here's what the API should be for these 2 components to interact". You wouldn't expect a software architect to be particularly knowledgeable about business needs and users. UX positions are usually design centric (people in these positions usually hold HCI or Design degrees). These people usually lack the engineering knowledge to be able to quickly assess the viability and cost of the solutions they propose, and therefore work very frequently with people that have complementary skills. I am one of those types with a mixed business/engineering skillset and work in Product Management these days. The "Product Engineer" as described in the article seems like a great position for a small company, or for a small team within a company. It's what a founding CTO would usually do at the early stages of a company. In my experience, as companies grow, it's hard to know both the customers, the users, and the technical details in intimate detail, so the position seems slightly doomed unless the product is very technical (say, mostly an API). That being said, broad skillsets can be a blessing when things need to move rapidly.
  - gonyea 11y ago
    It's a lot of things. "Product Developer" captures it quite well. You're going from 0 to ShipIt with minimal bottlenecks. "Isn't that just an architect?" Except you're not a silo'd backseat driver–ahem! Architecture Review Committee Member–meddling with various teams. "UX guy?" No, you're building the API, deploying the infrastructure, setting up the DB, and then consuming all of that on the front-end. "A full-stack developer?" Except full-stack developers are usually weighted heavily to one side, or they get pigeon-holed on Day 1 wherever the team is lacking (usually Ops. Sigh). But "Sr. Actually-Full-Stack Developer" would be an alternate job title to "Product Developer." You need a lot of discipline (and experience) to not over-engineer a new product to death.
wellpast 11y ago
> And the technical interview falls flat. The product engineer isn't intrisincally interested in software — programming is merely the tool for maximal leverage on the world. Yes... but we can't let you off the hook too much. I consider myself a Product Engineer as well, but to be able to creatively evolve a product you need to have some serious professional tools under your belt and many of these are technical, I'm afraid. To use his analogy: "Song designers are musicians first." I wouldn't trust a song designer that couldn't answer some of the relevant technical questions. There is a very real question as to how to recruit and interview well. This self-proclaimed "Product Engineer" claims "I'm the test case you want to turn green," but the real question is: how can we tell he's the real deal from the next guy? (Hint: it isn't JUST take his word for it.)
zeeshanm 11y ago
I wholeheartedly feel product engineers are best suited to start their own companies. I literally do not know any company that can give them the kind of experience they seek.
jorgecurio 11y ago
I've had plenty of product based experience but found the person interviewing doesn't seem to realize that he should be pitching why I need to be there. As an illustration of how clueless these recruiters are they start off by asking technical interview questions. I just say 'im sorry didn't know you relied on rote memorization to build your product'
matrix 11y ago
The core point of the essay, that product design is a different skill to software development, is obviously true, but to me this feels a bit like the title "Software Architect" was 10 years ago; i.e. people who want to design software products without the pesky whole writing software part. Like being a dev manager, defining the vision, design, etc requires a different set of skills from development. However, a person can do those jobs much better if they have spent time in the trenches. They understand costs and tradeoffs better, can better sell the ideas to the team, and so on.
- pedalpete 11y ago
  Let me give you a counter-point. I was hired by my current employer as a software engineer. I love writing software. Unfortunately, in our team, we didn't have anybody who was good at managing product development. Features where thrown in willy-nilly, design often not well thought through because designers weren't given enough time and developers could just go develop. I was/am the worst Software Engineer in the group (these guys are seriously awesome), so they had me take over product management and only spend part of my time coding. I'm not an 'architect', I don't design the technical systems. I design the product systems, and implement features along with the rest of the engineers, but my time is split between managing the product and doing the development. I fell into the role because I like considering the user/marketing/etc as well as doing the software development. I've been putting "Product Manager/Software Engineer" on my email signature because I didn't know that "Product Engineer" existed.. As I work for a technical organization, I think they'll appreciate the product engineer label more.
  - matrix 11y ago
    I agree with you. A product manager doesn't need to be a great developer - they just need sufficient experience with development to assess the impact and complexity of changes, and to better understand where there might be opportunities. You have that plus passion for the role, which is a rare combination. Hopefully your employer recognizes the value of it!
- DavidChouinard 11y ago
lewisl9029 11y ago
I'm in a bit of a similar position as the author. I've been interviewing for a while now, and have had the fortune of many companies approaching me for positions after coming across my profile on HN/AngelList/LinkedIn or discovering Toc Messenger (http://toc.im http://toc.im). Without exception, the next steps in the interview process for all these companies included some kind of an hour long technical interview that grilled me on my ability to solve, under severe pressure (time and otherwise), abstract algorithms and data structure problems that had no relevance to the product engineering positions they contacted me for. I haven't spent nearly as much time as some of my new grad peers on solving these types of problems, as I generally prefer to spend my time actually building things and learning new technologies and approaches to help me build things in a better way, and the difference is really starting to show. In my experience, any half-decent developer with a proper CS education can usually solve these problems (So far, I've never encountered a single problem I couldn't solve within an hour or two in the zero-pressure setting of my own dev environment at home, including the ones I had trouble finishing during actual technical interviews). Solving these problems quickly, however, is a skill that tends to come with practice. [1] Practice is unfortunately something I sorely lack at the moment, but that's been improving lately due to the sheer number of these interviews I've done so far. However, I still don't plan on spending any time outside of actual interviews to begrudgingly improve a skill that I'll maybe get to use a handful of times throughout my career when I need to switch jobs. Software development is a seller's market right now, and there is no shortage of companies that want to hire great developers. To those who want to interview me in the traditional way, I'll gladly play along with your flawed process, but please note that this process is very good at weeding out product-focused developers like me. And if you do weed me out this way, no hard feelings, because I'd at least gotten the extra practice I needed to beat this flawed system. [1] There are exceptions, of course. I have a few friends who seem to have a natural gift and interest for these types of problems, and most of them are working at Google/Facebook right now after acing all of their interviews and receiving multiple offers. But in the large majority of cases, the people who ace your traditional technical interviews are the ones who have spent countless hours reading books like "Cracking the Coding Interview" and practicing solving technical problems to the point that they can probably solve any problem you can throw at them in no time. I don't mean to belittle the talent/efforts of these kinds of developers or their potential value to your company, especially if you really need someone to tackle the hard technical problems in your field of business. However, I do want to question the wisdom of assuming these same technical developers will be the ones who are best able to iterate on and improve your product.
hosh 11y ago
A friend had sent this link. It dawned on me later, there is an interesting intersection between that article and this one about the Product Engineer: http://amasad.me/2016/01/03/overcoming-intuition-in-programming/ http://amasad.me/2016/01/03/overcoming-intuition-in-programm...

166 points by patch45 11y ago

This really hit home for me. I was recently looking for a job so these ideas are fresh on my mind. What I have been trying to figure out, is it better to work for a company that has a good product strategy, or an other wise good company without a product strategy? At the time, my thoughts were to find a company that needs a product minded developer. A company that has everything else figured out but product.

codingdave 11y ago
A solid product with a sketchy tech team will result in a solid company that needs some internal work to truly take off. A solid tech company without a product is just some devs congratulating themselves on how smart they all are while they pour money out.
natrius 11y ago
A company that hasn't prioritized product strategy isn't going to suddenly start prioritizing it once you get there. You are more likely to be ignored. Go somewhere that does product well, especially if you're early in your career.
- deleted 11y ago
  [deleted]
- DavidChouinard 11y ago
  There definitely exists organizations lead by smart non-product people who recognize their shortcoming and are enthralled to support it.

k__ 11y ago

Nice. For me it always seemed as if there are consulting engineers and product engineers. A few of my friends are devs at agencies, who worked at different projects for many clients, those were the consulting engineers to me. I always worked for companies who sold software products, so I considered myself a product engineer.

11thEarlOfMar 11y ago

Product Engineering as a role is also critical in hardware companies, where discipline-focused engineers such as mechanical, electrical, firmware, etc. need to implement the features of the product. Many times, they fall into the trap of making an impressive feature set work and then thinking they can start selling the product. What is missed are critical design elements such as: - Cost of materials/assembly - Power consumption and distribution - Reliability of the system - Durability of the system - Supply chain integrity and robustness - ... It seems that a lot of the new robotics companies and many KickStarter projects fall into this trap: under-budget the product development, both in time and resourcing, and release their product prematurely. This is all quite obvious to people who have participated in successful consumer or enterprise hardware companies, but young companies are still vulnerable. Advice would be to get it all working as a prototype, then, expect another major project of turning it into a Product before releasing.

DavidChouinard 11y ago
Hardware teams have been explicit about this role for a long time. I wish I had first-hand experience of hardware product engineering, but it's certainly an inspiration for this essay.

deleted 11y ago

[deleted]

jonathanpeterwu 11y ago

Kudos on hitting the ethos behind product first engineers who build w/ code for the love of creating things rather than just the code. Code is the tool you wield to build great things, not the only source of beauty.

holman 11y ago

Was hoping this would be about hiring, because I've been thinking a lot recently about how shitty hiring is for these people. I've been interviewed for a lot of these ostensibly "product" positions this year. A lot of it has to do with the company not even understanding what they're hiring for. Initial screeners would be all about product, product, product, but then they'd give me a new grad programming trivia test about rearranging chars in a string. Such a weird mismatch of aspirations vs. reality on the interviewer's part, and, most importantly, I've never come away from these interviews feeling the interviewer has a solid understanding of what I might bring to the table. I'd push more for it before leaving the interview, but by that point the interview itself has soured me on the company overall. I think this is exacerbated in the startup world in particular, because even "straight technological" roles in a sub-10 person team will inevitably include a ton of product decisions throughout the course of fast-paced development, and I worry too many startups focus on these type of algorithmic hiring tests being some sort of qualifier for these people when it's not.

BillinghamJ 11y ago
What should we be asking/looking for/testing?
- noir_lord 11y ago
  I'd hand them a piece of paper and ask them to sketch out a profile page that's user friendly. Then I'd ask them how they'd design the schema for that. Then I'd ask them to sketch out the admin interface for managing users and how they'd implement that. If they start asking questions about permissions and roles and such I'd be really impressed. Essentially I'd act like a client/end user who kinda knows what they want to see if they can ask the right questions. I'm not looking for a UX expert but more someone who thinks about the process and end result as well as a nice way to implement the code side. I'd ask programming related questions as well but if (when) I hire I want someone who thinks about the end user experience while they are developing, I don't live in a world where a job comes with a 400 page spec and neither would they. I take the view that I'd rather have someone who can think about how the end system will work than someone who knows ever single API for whatever language I'm hiring for, one of those you can find on google in 30 seconds the other not so much.

danenania 11y ago

This really resonates with me. There seems to be a trend of frowning on these types as 'generalists' who don't have sufficiently hard tech skills, but 'creates great products from the ground up' is a specialization in itself, and an extremely critical one. Someone who will do (and learn) whatever it takes to put out high quality work is someone who will be a top performer at almost any company, regardless of how they would do on a Google algorithms quiz. This mismatch was part of what motivated me to build MakerSlate [1], a résumé optimized for just this type of creator. 1: https://makerslate.io https://makerslate.io

mpdehaan2 11y ago
It's a good post and a good thought. Software is a giant LEGO set with no instructions, and it takes a good mixture of how to build things and knowing what you can build. A lot of times people want to reduce product management to "visit customers, ask what they want, make a spreadsheet", but I think it's more than that. To do it well, you have to know the possibilities the existing stack could grow into, and also what it can't easily grow into, and set a vision that is well beyond what the masses point at. And you also have to know the industry enough to know how to build things that make sense to end users. In maybe 80% of the jobs I've had, non-technical product managers have been probably the single most powerful force to get me to leave an organization, because I always get very invested in a product and want to see it do the right thing, and I want to work on and design the right things. Working on the wrong things - features nobody is going to use, features that won't work, features that don't take advantage of a great opportunity or make a product great to use - can be demoralizing. I want to work on the thing that will make the most difference -- and then be able to witness that difference in hearing those stories from userland. And the second you take the design out of it (and reduce software down to implementation), for me, the fun parts are gone (unless there's some heavy C.S. or architecture parts, which in CRUD stuff is rare) and it's just implementation. Also - I will say, having done it, product management is always one of the most misdefined and potentially most disliked positions from the outside. It's the easiest to please no one while still trying incredibly hard to do the right thing, and probably the most important make or break function - because a company is totally viewed by what it decides to create. Further, a good PM can be made powerless if he can't get engineering do anything, and frequently organizational lines are set up so that he cannot. It's a position that needs to be elevated because it's so important, but instead almost gets lumped in with project management and viewed as easily interchangeable; the result is bad PMs make it hard for good PMs to get any respect. There's a huge standard deviation. Product management can also get in a bad spot when you give a few people absolute product control, and you ignore the ideas from developers and others throughout the company. So even if you are in this spot, and it's respected, you have to give voice to the entire company and try to focus sometimes hundreds of laser beams all pointed in different directions. The C.S. I majored in was about designing things, a lot of software engineering is about implementing features out of canned components other people have already designed. I think there's a lot of lost possibility in that, and we should encourage everyone to be more creative and blur the lines more in how we define software positions.

palakchokshi 11y ago

I consider myself as a product engineer too and the traditional interview process is definitely broken for someone like me. I think @holman nailed the current interview process with this statement "I need to figure out hidden knowledge that the interviewer knows already". I'm glad to know there are others who share my frustrations. Having said that, I think for my next interview I am going to go in telling them who I am. I will own the Product engineer title and let them know what a Product Engineer is and what we excel at. If that is something they are interested in then we can continue otherwise it will be a waste of time for everyone. If I were to design an interview process for someone like me I would come up with a simple product. It can be something as simple as a List web app ala Trello. Then have them design the product for individual use, then layer on collaboration requirements and then layer on sharing requirements, if time permits. This will allow me to know how they think about the product. If they suggest collaboration when designing for individual use then that's awesome because it tells me they are already thinking about where the product can go.

chejazi 11y ago

As a candidate you might have better luck with companies that embrace Holacracy [0]. On the recruiting side, I have a hunch that the best way to get more Product Engineers is to have the Product Engineers in your org conduct interviews in addition to the pure technical ones. A requirement for this is that the Product Engineer's title is made explicit, otherwise "wtf, why is this person always doing the interviewing." [0] http://www.holacracy.org/how-it-works/ http://www.holacracy.org/how-it-works/

tonystubblebine 11y ago

Do people think the product engineer can be trained? One issue I run into is one of expectations. I think product engineers are treated like some sort of unicorn (a designer/coder). I can see why that might have been true in 2000. But a lot has changed since then. For one, being a product engineer could be considered a hack for picking up tech skills quickly. It's often much easier to learn by doing and product engineers define themselves by the product they're trying to build. Plus, software got so much easier to build. What is your reaction to that? Do you go deeper and more esoteric than you used to be able to go? Or do you go broader? Broader makes sense to me--that's the product engineer. But to what end? Do you go broader in order to save on team size? An engineer/designer means you can skip a design hire. Or do you go broader because you can have more autonomy? To me, product engineers are the natural outcome of software getting easier (and design to some extent). People can have more autonomy because you can develop the skills to get more done on your own. But I don't think management has caught up. There's still an assumption that these skill sets don't go together. Autonomy is killed when you have specialist designers and specialist engineers. And that's why I led with the idea about training product engineers. I want to be able to create a culture at my company that assumes that you're a product engineer. Junior product engineers just work on smaller problems.

pteredactyl 11y ago

Thanks for making this a 'thing' as I figure out how best to position myself.

10dpd 11y ago

Reading this I'm wondering what the difference is between a "Product engineer" and a "UX Engineer"?

palakchokshi 11y ago
I would differentiate them in the following way: Product Engineer: Focused on creating something that fulfills users' need or want UX Engineer: Focused on polishing the product to make sure the user's need or want is fulfilled with the least amount of friction.
- reverius42 11y ago
  UX is not about polish. UX is the product -- literally, from the user's perspective. I don't think there is a meaningful difference between Product Engineer and UX Engineer.
  - palakchokshi 11y ago
    The X in UX is Experience so indeed a UX Engineer's role would be to improve the user's experience of the product not necessarily define what the product should be. It's unfortunate that UX is being confused with Product. Let me illustrate with an example: Consider a product with 20 features, 10 of which will be helpful to the user once they have been using the product for a while. The UX engineer's job is to identify this and provide a user flow of progressive disclosure of those 10 features based on user's actions. This improves the Experience for a user by not overwhelming them with all 20 features when they are just starting to use the product. A Product Engineer's job is to identify the 20 features because they are useful for users.
    - gomox 11y ago
      In terms of conventional job titles, that's the job of the Product Manager.
      - 11y ago

keepitsurreal 11y ago

Does anyone have any advice finding these roles? Most of my main projects have included me building products up from the ground up with successful releases. I've been cramming technical interview questions because its seems like the only foot in the door, but this kind of position is where I know I'll thrive. Where do I look for Production Engineering positions? How does a new grad w/ a CS background move into one of these roles with relevant experience?

pcunite 11y ago
I'm in the throes of this right now, but I think product manager is close. Read the job description to see if it errors on the side of programming.
johns 11y ago
If you want to work at a startup, the earlier they are they more likely that every engineer is a product engineer. The bigger companies get, the less generalists are relied upon.

pcunite 11y ago

This is me! Feels so good to be understood. I'm currently identifying myself with product management & user experience because I recently came to this conclusion.

guelo 11y ago

Everyone that walks around with a touch screen computer in their pocket thinks they are a genius of product design. But if you actually want to design products the first step is to become an expert in the code. So stop day dreaming that you're the new Steve Jobs and get coding.

sweezyjeezy 11y ago
> if you actually want to design products the first step is to become an expert in the code I'd say the first step in designing a good product is understanding what the client/customer actually wants. That is where a position like product engineer/product manager are invaluable. It doesn't matter how good you are at coding, if no one wants the thing you're working on.
kovacs 11y ago
Everyone that has a car thinks they're a great race car driver. But if you actually want to be a great race car driver the first step is to become an expert in building the car. So stop day dreaming that you're the new Mario Andretti and grab a wrench. That sounds as silly to me as your assertion. And yes I can code and have for a very long time. I'll take the person that can figure out what will resonate with users and doesn't know a line of code over a guy that can code but isn't good with products. The skill sets are orthogonal in many products. Sometimes being able to code may give you important insights that a non-coding product person won't have, but I wouldn't count on it as a sustainable advantage for all but the most complex of products (e.g. enterprise/plumbing software), and even then a great product person will figure out what they need in order to arrive at the salient product decisions. Sometimes having the ability to code is a hinderance to building a great product.
- guelo 11y ago
  Yes, everyone, including coders, thinks they are the best product designers. The difference is that top-level coders actually have the influence to implement their ideas, whether they're good or bad. That's how you get your foot in the door. Walking in to a startup wanting to be the one that tells everybody else what ideas they should be implementing is not going to get you far. I'm not saying that product managers are not useful, but good product managers are data driven and their main job is to gather and summarize the available data and enable a conversation within the company about the product direction, not to be the grand visionary that hands down ideas from on top.

jaunkst 11y ago

Product engineers are sought after, and for companies that build flag-ship products they should be core to development. Product developers are often founders and should guide the vision as they have the product itself at heart and mind. https://data.triplebyte.com/who-y-combinator-companies-want-c1880a08ac88#.zdwdvsa5j https://data.triplebyte.com/who-y-combinator-companies-want-...

t3hprogrammer 11y ago

I recently wrote about the gap between product-motivated and technically-motivated engineers: https://medium.com/@ericwleong/the-product-technical-spectrum-d3e76aa8bff7#.5x6avaz8l https://medium.com/@ericwleong/the-product-technical-spectru... Certainly startups are interested in hiring engineers motivated by product, but technical interviews obviously don't look for that.

gonyea 11y ago

Bingo. I'm a product engineer as well. I build products in 1/4 the time of an entire team, with unit/integration tests. It's also technically correct--that is, as technically correct as it needs to be to ship, scale, and see if it gains traction. Waste my time white boarding a sorting algorithm and I'll turn down the job (well, unless the money is insane). But designing the flow/architecture of a new product idea? That's my catnip. I'll white board THAT.

AznHisoka 11y ago
So... isn't that an architect, or UX guy (if front end)? Why do we have to invent a new job title?
- gomox 11y ago
  Software Architect in general implies a high-level (in terms of abstraction) technical position within an engineering team. This person is usually in charge of the design of the software, as in "use a queue here instead of a database", "this data should not go to the UI, but instead be requested on demand", "here's what the API should be for these 2 components to interact". You wouldn't expect a software architect to be particularly knowledgeable about business needs and users. UX positions are usually design centric (people in these positions usually hold HCI or Design degrees). These people usually lack the engineering knowledge to be able to quickly assess the viability and cost of the solutions they propose, and therefore work very frequently with people that have complementary skills. I am one of those types with a mixed business/engineering skillset and work in Product Management these days. The "Product Engineer" as described in the article seems like a great position for a small company, or for a small team within a company. It's what a founding CTO would usually do at the early stages of a company. In my experience, as companies grow, it's hard to know both the customers, the users, and the technical details in intimate detail, so the position seems slightly doomed unless the product is very technical (say, mostly an API). That being said, broad skillsets can be a blessing when things need to move rapidly.
- gonyea 11y ago
  It's a lot of things. "Product Developer" captures it quite well. You're going from 0 to ShipIt with minimal bottlenecks. "Isn't that just an architect?" Except you're not a silo'd backseat driver–ahem! Architecture Review Committee Member–meddling with various teams. "UX guy?" No, you're building the API, deploying the infrastructure, setting up the DB, and then consuming all of that on the front-end. "A full-stack developer?" Except full-stack developers are usually weighted heavily to one side, or they get pigeon-holed on Day 1 wherever the team is lacking (usually Ops. Sigh). But "Sr. Actually-Full-Stack Developer" would be an alternate job title to "Product Developer." You need a lot of discipline (and experience) to not over-engineer a new product to death.

wellpast 11y ago

> And the technical interview falls flat. The product engineer isn't intrisincally interested in software — programming is merely the tool for maximal leverage on the world. Yes... but we can't let you off the hook too much. I consider myself a Product Engineer as well, but to be able to creatively evolve a product you need to have some serious professional tools under your belt and many of these are technical, I'm afraid. To use his analogy: "Song designers are musicians first." I wouldn't trust a song designer that couldn't answer some of the relevant technical questions. There is a very real question as to how to recruit and interview well. This self-proclaimed "Product Engineer" claims "I'm the test case you want to turn green," but the real question is: how can we tell he's the real deal from the next guy? (Hint: it isn't JUST take his word for it.)

zeeshanm 11y ago

I wholeheartedly feel product engineers are best suited to start their own companies. I literally do not know any company that can give them the kind of experience they seek.

jorgecurio 11y ago

I've had plenty of product based experience but found the person interviewing doesn't seem to realize that he should be pitching why I need to be there. As an illustration of how clueless these recruiters are they start off by asking technical interview questions. I just say 'im sorry didn't know you relied on rote memorization to build your product'

matrix 11y ago

The core point of the essay, that product design is a different skill to software development, is obviously true, but to me this feels a bit like the title "Software Architect" was 10 years ago; i.e. people who want to design software products without the pesky whole writing software part. Like being a dev manager, defining the vision, design, etc requires a different set of skills from development. However, a person can do those jobs much better if they have spent time in the trenches. They understand costs and tradeoffs better, can better sell the ideas to the team, and so on.

pedalpete 11y ago
Let me give you a counter-point. I was hired by my current employer as a software engineer. I love writing software. Unfortunately, in our team, we didn't have anybody who was good at managing product development. Features where thrown in willy-nilly, design often not well thought through because designers weren't given enough time and developers could just go develop. I was/am the worst Software Engineer in the group (these guys are seriously awesome), so they had me take over product management and only spend part of my time coding. I'm not an 'architect', I don't design the technical systems. I design the product systems, and implement features along with the rest of the engineers, but my time is split between managing the product and doing the development. I fell into the role because I like considering the user/marketing/etc as well as doing the software development. I've been putting "Product Manager/Software Engineer" on my email signature because I didn't know that "Product Engineer" existed.. As I work for a technical organization, I think they'll appreciate the product engineer label more.
- matrix 11y ago
  I agree with you. A product manager doesn't need to be a great developer - they just need sufficient experience with development to assess the impact and complexity of changes, and to better understand where there might be opportunities. You have that plus passion for the role, which is a rare combination. Hopefully your employer recognizes the value of it!
DavidChouinard 11y ago

lewisl9029 11y ago

I'm in a bit of a similar position as the author. I've been interviewing for a while now, and have had the fortune of many companies approaching me for positions after coming across my profile on HN/AngelList/LinkedIn or discovering Toc Messenger (http://toc.im http://toc.im). Without exception, the next steps in the interview process for all these companies included some kind of an hour long technical interview that grilled me on my ability to solve, under severe pressure (time and otherwise), abstract algorithms and data structure problems that had no relevance to the product engineering positions they contacted me for. I haven't spent nearly as much time as some of my new grad peers on solving these types of problems, as I generally prefer to spend my time actually building things and learning new technologies and approaches to help me build things in a better way, and the difference is really starting to show. In my experience, any half-decent developer with a proper CS education can usually solve these problems (So far, I've never encountered a single problem I couldn't solve within an hour or two in the zero-pressure setting of my own dev environment at home, including the ones I had trouble finishing during actual technical interviews). Solving these problems quickly, however, is a skill that tends to come with practice. [1] Practice is unfortunately something I sorely lack at the moment, but that's been improving lately due to the sheer number of these interviews I've done so far. However, I still don't plan on spending any time outside of actual interviews to begrudgingly improve a skill that I'll maybe get to use a handful of times throughout my career when I need to switch jobs. Software development is a seller's market right now, and there is no shortage of companies that want to hire great developers. To those who want to interview me in the traditional way, I'll gladly play along with your flawed process, but please note that this process is very good at weeding out product-focused developers like me. And if you do weed me out this way, no hard feelings, because I'd at least gotten the extra practice I needed to beat this flawed system. [1] There are exceptions, of course. I have a few friends who seem to have a natural gift and interest for these types of problems, and most of them are working at Google/Facebook right now after acing all of their interviews and receiving multiple offers. But in the large majority of cases, the people who ace your traditional technical interviews are the ones who have spent countless hours reading books like "Cracking the Coding Interview" and practicing solving technical problems to the point that they can probably solve any problem you can throw at them in no time. I don't mean to belittle the talent/efforts of these kinds of developers or their potential value to your company, especially if you really need someone to tackle the hard technical problems in your field of business. However, I do want to question the wisdom of assuming these same technical developers will be the ones who are best able to iterate on and improve your product.

hosh 11y ago

A friend had sent this link. It dawned on me later, there is an interesting intersection between that article and this one about the Product Engineer: http://amasad.me/2016/01/03/overcoming-intuition-in-programming/ http://amasad.me/2016/01/03/overcoming-intuition-in-programm...