The four attributes I've identified in the best "product guys" are these:
* They "get it" - they are master analyzers in their field. This lets them critique quickly and effectively. People who don't "get it" are hard to take seriously and those who do are sought after for their thoughts.
* They're passionate - they are clearly energized about their field and its possibilities. When they criticize work, it motivates even better work, rather than throwing a wet blanket on it.
* They have a definite critical opinion - they know what they're looking for and criticize freely. They don't temper their critique to be accepted, to seem friendly, to look sophisticated or to make more money.
* They focus on the right things - they offer specific criticism, picking apart something for its strengths and weaknesses. They aren't satisfied with just telling you their general opinion -- they start in with "Here's what I didn't like..."
It took me a while to realize that PG is not just an insightful thinker but an all-star product guy. Then again, I think that's also because he has focused so intently on developing as one. Maybe he was merely good when he started YC but by now he's a master.
I also think it's amusing how wildly deprecating the title "product guy" is for the tremendously valuable ability displayed by people like Steve Jobs, Walt Disney, John Lasseter or even Paul Erdős.
I think the last thing you mentioned hits it on the head ( wildly deprecating the title "product guy"). Seems to me that were there an engineering discipline that included understanding customers, we'd have some awesome engineers. Right now the current engineer + mba model in education doesn't seem to quite fit that. Maybe product people just are inherently autodidacts.
Defining 'product guy' is hard because doing the role well requires multiple disciplines, and no one product guy is good at every discipline that's useful for the role.
Many entrepreneurial developers have a lot of contempt for product guys - in part because there's a lot of incompetent people out there in product management roles, in part because many of them have enough product skills to make a decent go of it on their own.
Personally, I'm a big believer in specialization and minimizing context-switching - with effective communication, a team where one individual largely focuses on product and the others largely focus on development seems more effective than a team where product responsibilities are divided evenly between the developers. (I suspect that's a minority opinion around here, though.)
I think this is only true with larger teams. On tasks that are't too large, 2 or 3 great "product smart" developers will beat a team of 6 or 7 with divided responsibilities.
It is also a function of how novel the product is. The ability of a team to think and work at multiple levels is invaluable when evolving along a new idea into a usable product. A product leader, would drive his developer team crazy if he changed his mind as often as is typically needed for a novel product.
Since start-ups begin with small teams and typically work on novel products, it makes sense that the HN crowd would be partial to the product smart generalist team approach.
I think a good product person is a good artist. They think of product as art. And they're able to create good art (in some cases Picasso level art), without necessarily knowing how to paint (e.g. Steve Jobs).
As a "product guy" myself, here are some ways that I feel I contribute to my team. To give some background, I started at my current company (a growing consumer internet company) in an interaction design role, but transitioned into product as I and the company grew.
- I keep track of metrics. This includes KPI that I am monitoring on an hourly basis, as well as metrics on new features that we launch. The specific skills that are at play here range from being an Excel jockey, to being able to write sql queries and understanding our DB schema, to being able to analyze data.
- I help figure out what to do. This involves understanding how the product is performing -- at any given time, do we try to improve our user acquisition funnel, our retention or our monetization? Where are our biggest opportunities? Are we more likely to improve our acquisition funnel by 5 percentage points or our 7 day retention by 15 percentage points, and which one would have a bigger impact on long term average revenue per user?
This involves both understanding our product, and spending a lot of time doing competitive analysis on similar products.
- I help develop features by thinking about how they should work. For example, if I figure out that compared to industry benchmarks, our 2 day retention is is about normal, but we see large attrition between day 2 and day 7, how do we address this problem? What makes people come back to our product, how can we measure it, and what levers can we pull to improve that number?
- I also have an interaction design background, so I often wireframe features that address the above point.
- I also translate feature ideas into functional specs, including thinking about and documenting error cases, process flows, various entry points into the feature, any new analytics that need to be built to track the performance of the feature and any new admin tools that need to be built to support the ongoing feature functionality.
- I also then work with engineers and QA to balance the potential feature improvements against the time/effort/risk it would take to build those features, and the help organize the features into actual sprints. When the unexpected happens, I help decide whether to cut scope, delay the sprint or push the entire feature into the next sprint.
- This one is a bit fuzzier, but I also think strategically. Based on where my product fits in with my company's portfolio of products, what kind of risk profile do we need to take on in terms of developing features? Is the team currently in a position to succeed in terms of staffing, support services, etc?
I like to think that I am contributing to my current team by doing these things (and more!), and while product roles differ somewhat from company to company, to me the essence of a product person is someone who uses analytical skills to make sure that the team is working on the things with the greatest chance for success.
The 'product guy' is the former engineer who thinks he knows what the customer wants. Usually they also think they know how to do proper UX design but usually fall back to copying whatever is hot at the moment.
Is he the guy who knows what needs to be done. Knows how to do it, but doesn't do it? Then I think he's the lazy guy. Or maybe he's just above the pain of doing it; ie, the lazy guy.
* They "get it" - they are master analyzers in their field. This lets them critique quickly and effectively. People who don't "get it" are hard to take seriously and those who do are sought after for their thoughts.
* They're passionate - they are clearly energized about their field and its possibilities. When they criticize work, it motivates even better work, rather than throwing a wet blanket on it.
* They have a definite critical opinion - they know what they're looking for and criticize freely. They don't temper their critique to be accepted, to seem friendly, to look sophisticated or to make more money.
* They focus on the right things - they offer specific criticism, picking apart something for its strengths and weaknesses. They aren't satisfied with just telling you their general opinion -- they start in with "Here's what I didn't like..."
It took me a while to realize that PG is not just an insightful thinker but an all-star product guy. Then again, I think that's also because he has focused so intently on developing as one. Maybe he was merely good when he started YC but by now he's a master.
I also think it's amusing how wildly deprecating the title "product guy" is for the tremendously valuable ability displayed by people like Steve Jobs, Walt Disney, John Lasseter or even Paul Erdős.