The Product Engineer

http://essays.davidchouinard.com/product-engineer

by patch45 • 11 years ago

166 82 11 years ago

essays.davidchouinard.com

patch45• 11 years 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• 11 years 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• 11 years 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.

DavidChouinard7• 11 years ago

There definitely exists organizations lead by smart non-product people who recognize their shortcoming and are enthralled to support it.

k__• 11 years 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• 11 years 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.

DavidChouinard7• 11 years 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.

jonathanpeterwu• 11 years 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.

holman2• 11 years 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• 11 years ago

What should we be asking/looking for/testing?

noir_lord2• 11 years 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.

holman2• 11 years ago

It depends on the company, but I'm a big fan of pairing with a developer on something they're working on for an hour or so. The dynamics of the interview completely changes from "I need to figure out hidden knowledge that the interviewer knows already" to "I need to work with this person to find out a solution together", which I think is quite a bit less stressful. You're also working on real problems that — though they might not be a glamorous interview question — will be much closer to what "real" work at the company will be.

Put another way: I've probably done a dozen or two product interviews this year, and have still never seen a full stack web request. I mean, I haven't seen a controller action, or a view, or even a model for that matter. And that's the area that's my entire job, really: I build screens and hook things together and make things work for users. As much as feasible, I'd like to be able to demonstrate those types of talents in the interview process.

bsimpson• 11 years ago

I interviewed at many of the large tech firms this fall, and I've found that Google's UX Engineer ladder did the best job of asking questions I should reasonably be expected to know without getting too hung up on an "algorithms" or "CS fundamentals" screening.

DavidChouinard7• 11 years ago

This is a very strong feeling of mine and early reviewers of the essay railed at that frustration. It's striking how much the hiring dance feels full of misplaced energy.

There's no doubt hiring for product engineers is horribly broken, and in a way that holds back the entire ecosystem.

The essay is not about interviewing, because I don't have strong alternatives to suggest.

First we need vocabulary, then we'll need process. I'm in a quest to understand how to hire for this role: I'll write a new essay once I understand it.

tokipin2• 11 years ago

When it comes to these things people are going to reinvent a vocabulary that already exists: Jung's psychological functions.

What Jung called extraverted intuition (Ne) is going to be the main "product" function in tech, with extraverted sensing not as common in the industry. Ne appears in Ti-Ne/Fi-Ne/Ne-Ti/Ne-Fi (what MBTI calls resp. INTP/INFP/ENTP/ENFP). In other words, the xxxP types are going to correlate with being product people. Steve Jobs was practically raw Ne.

The stereotyped "Silicon Valley Programmer" that every company wants to hire is introverted intuition primary and extraverted thinking secondary (Ni-Te, what MBTI calls INTJ). This archetype is quick-witted and naturally good at verbal/logic challenges.

To really, really, really simplify things, with xxxJ vs xxxP, you essentially have a dichotomy between speed on the one hand and (external) depth on the other. External depth being advantageous because the world itself is external. The current standard for interviews is essentially to judge speed, so of course this has the appropriate consequences. Which, by the nature of the particular elements involved, rapidly runaway.

Speed is quite easy to see and understand. Depth on the other hand is harder to pin down. But it is depth, and the vision that often carries it, that can render fine details onto a product. Those details can be so small that most people don't see them, so general appreciation of this power is rarer, and by its nature harder to test on top of it requiring a longer time horizon to work in.

Many people will think that you can get both qualities in a single person, but it doesn't work that way. Evolution would have done that long ago if it was possible. Instead, what we're dealing with are fundamentally different brain topologies/strategies, essentially characteristics that species can min-max in individuals because of the survivability allowances afforded by their ancestors having been social. Or who knows. Regardless, these are the same types of trade offs you have in data structures/algorithms.

danenania• 11 years 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

mpdehaan22• 11 years 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.

palakchokshi6• 11 years ago

A technical Product Manager would be a Product Engineer but the inverse might not be true. In my mind a good Product Manager is also responsible for guiding the product roadmap in the direction that addresses user's wants rather than features that are cool to implement but don't really address a user's wants or needs.

shalmanese• 11 years ago

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.

Customers tell you what their problems are but they're not trained in telling you the solution. The mistake that's often made is that customers tell you their problem in the form of a solution. The role of the PM is to then take the solution, reverse engineer the problem out of it and then work with the team to figure out the true solution.

Where the technical/non-technical split lies between the PM and the engineers can vary. Ideally, the PM is technical enough to come up with new possibilities on their own and understand the technical implications and tradeoffs of each possibility but not every PM has the background or inclination towards that. The next best thing is that the PM works closely with the engineers to communicate the user goals and trusts engineering to find clever solutions to those goals. But the worst is a PM who thinks they're technical enough to come up with features and then steamrolls over engineering objections over the implementation.

rrrx3• 11 years ago

I love this. What a great idea.

palakchokshi6• 11 years 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• 11 years 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/

tonystubblebine• 11 years 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• 11 years ago

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

10dpd• 11 years ago

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

palakchokshi6• 11 years 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• 11 years 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.

keepitsurreal2• 11 years 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?

pcunite2• 11 years 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• 11 years 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.

pcunite2• 11 years 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.

guelo2• 11 years 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• 11 years 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• 11 years 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.

guelo2• 11 years 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• 11 years 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-...

t3hprogrammer• 11 years ago

I recently wrote about the gap between product-motivated and technically-motivated engineers: 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.

gonyea2• 11 years 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• 11 years ago

So... isn't that an architect, or UX guy (if front end)? Why do we have to invent a new job title?

gomox2• 11 years 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.

gonyea2• 11 years 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• 11 years 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• 11 years 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• 11 years 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'

matrix2• 11 years 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• 11 years 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.

matrix2• 11 years 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!

DavidChouinard7• 11 years ago

The clearest way to see the difference is how natural the product engineering phenomena is — it's been happening and we just need a name.

lewisl9029• 11 years 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).

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.

hosh5• 11 years 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-programm...

The Product Engineer

Related Stories