Why is it so hard to define what it means to be a 'product 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.

- 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.

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.)

The software guy writes the code to interpret user input, get the data from its source, do calculations and present it to user.

The UI guy decides the layout of how to present the info.

The product guy decides whether you're going to build "Stocks" app or "Bloomberg Terminal".