Spare Me From “Product Guys”

http://techcrunch.com/2011/12/03/spare-me-from-product-guys/

by ssclafani • 15 years ago

82 60 15 years ago

mathattack2• 15 years ago

"Product Guy" can translate to "non-technical" similar to "Business Analyst". 95% of the so-called Business Analysts I see (many from top schools and top firms) really don't know anything about the businesses they're analyzing - they get the title by a lack of technical background.

Of course the 5% of "Product Guys" and "Business Analysts" that are true talents are worth their weight in gold.

derefr• 15 years ago

> 95% of the so-called Business Analysts I see (many from top schools and top firms) really don't know anything about the businesses they're analyzing

So, what are they paid to... do, then?

notatoad• 15 years ago

They aren't paid to do. They are paid to be. Somebody with hiring authority thinks that business analysts are needed, so business analysts get hired.

As the article says, not all of them are useless. Some business analysts provide very valuable insight, and a manager who has come into contact with one of those will want to hire more of them. By the intangible nature of their value though, it can be hard to judge whether you've hired a good one or a leech.

joshwa• 15 years ago

So, what are they paid to... do, then?

Thrash around trying to understand the business. Some will be more successful than others, depending on how smart they are. Some will gain a superficial understanding and claim to have mastered the domain, but let's just say there's a different kind of "OA5" person who often ends up in the job.

Occasionally, if you're lucky, you'll find ons that has a vague clue about how to write requirements. Or design UI. Or that cares.

(speaking as a Product Manager / UX Designer / Developer, not necessarily in that order)

ericd• 15 years ago

Yeah, that's kind of weird - to be a real product guy, you actually need to have an extremely broad base of technical knowledge, so that you can look at every part of the system and make intelligent decisions about them.

gujk2• 15 years ago

The exact same analysis applies to developers.

mathattack2• 15 years ago

Fair enough. :-) At least with developers, the progress can be more tangible and visible.

dhotson• 15 years ago

Somewhat related:

"What makes someone a great product manager at Google?"

http://www.quora.com/Google/What-makes-someone-a-great-produ...

lucasjake• 15 years ago

Product guy really boils down to Generalist vs Specialist. Maybe it is 'Versatilist.'

The product person can't be an expert in for example, cryptography, and simultaneously be an expert in photo filter technology, and also the 100 other things that the product needs.

The end product might need all these things, and need specialists on maybe 5-10 of the items. The product person needs to be able to understand how all of them work, and make an end product that has market potential.

A product person can build products on their own if they have to. They are just better and faster when they have a team. If you can't do it on your own, you're probably not a real product person.

gujk2• 15 years ago

Your paragraph 4 contradicts paragraph 2.

viscanti• 15 years ago

Only if the only way to build something is by being an expert. It's possibly to "adequately" or "poorly" build something without being an expert.

gatlin2• 15 years ago

Scott Adams, in the back of "The Dilbert Principle," describes the OA5 model of running a company: Out at 5. His main goal was an efficient organization that let everyone out at 5, which meant the product was delivered, which meant everyone did a fantastic job, and other things that we all take for granted as being desirable.

One of his big points was that nobody should be doing anything more than 1 degree removed from the core mission. If you're a web host, you're either directly working on maintaining or supporting the service, or you're optimizing an internal process relating to the first two (as an example).

Otherwise, you're dead weight. The kind of product guy described in this article runs afoul of that OA5 principle.

PakG1• 15 years ago

What I don't like about OA5 is that it assumes everyone is able to work at the same pace at the same time during the day throughout the day. All my best thinking is really in the afternoon and evenings. Always has been.

Maybe I can hack my biological clock to be better in the morning. Dunno. For now, my brain doesn't seem to start focusing until about 10am, and then it doesn't seem to really get into gear until an hour or two later. With that in mind, it's really difficult for me to get my work done with people who want OA5. I suppose it would be fine if they're OA5, but they don't force it on me.

gatlin2• 15 years ago

That was one of my problems with it, too, even though I do get rolling pretty fast in the mornings. I think the real solution is to assume that the meeting time is going to be inconvenient for someone and just try to have a big stupid group sit-down once a week at most. Small agile teams can do a lot with impromptu stand-ups.

I think the most important thing, though, is to plan the big stupid group sit-down at one end of the day so that it doesn't interrupt. I've worked in places where they would stop us mid-day and ask what we have been doing and what we will be doing. Surprise surprise, the answers to both are the same 99% of the time. On top of that, they often pull me off something I'm intensely focused on to tell them what I was focused. /rant

mmaunder• 15 years ago

Program manager, product manager and business analyst are 3 roles that make me check that mental "looks busy, does nothing" box. Maybe they're interdependent. Program manager feeds product manager feeds biz analyst who feeds program manager. The devs toil quietly in the corner and don't dare question the symbiosis and CEO is relieved someone is there to do all the work they make.

If I sound grouchy it's because a biz analyst once tried to suggest I wasn't senior enough to attend the meeting we were in. [12 years ago. They'll never find the body.]

BadassFractal• 15 years ago

The PM's job is to clarify whatever questions the engineering team might have about the details of how the user will interact with the system. She has to have it all figured out to be able to pull her weight on that kind of engineer-heavy development team.

Generally speaking it's difficult for everybody on the team to know everything about the little details, and it's good to have someone with that picture in mind.

I hear that Pivotal Labs for example always require there to be an on-call PM when they work on their contracts, to immediately unblock progress.

neutronicus• 15 years ago

Where I worked before I went back into academia, the title "Project Manager" referred to someone whose main job was running interference between engineers and upper management. She was always coming up with answers to questions about how long things would take, etc. so I wouldn't have to and prompting me for various answers that upper management actually cares about. Definitely helped me get things done.

That place was emphatically not Silicon Valley, though, so it makes perfect sense to me that the two positions share little more than a title and not coding.

arctangent• 15 years ago

You forgot about the "technical architect" - another role that often seems suspiciously redundant.

pasbesoin• 15 years ago

I've worked with (exactly) one excellent business analyst. She really pulled the work together and provided both coherence and context. In that, she essentially filled aspects of the project manager role, even if and as there were separate project managers (more than one, for example, an a particularly large and critical endeavor).

In my opinion, formed while observing this and her work, it came down to the person, not the role. She was excellent and conscientious in her work; the role was subsidiary (although useful in giving her the influence she needed to get what she needed -- politely and cooperatively, for the most part -- from people).

(I'll add that communication with her was a genuine two way street; team members could and did use communication with her to push ideas and concerns upstream, where they would actually, genuinely be considered and not infrequently acted upon.)

Most other people filling such roles: More or less what the parent describes, in my experience. The better ones were at least honest about this, not full of themselves, and served as "project memory" and "reminders" for project members juggling so many things that they might otherwise -- rather occasionally, as opposed to regularly -- let something slip through the cracks.

Fortunately, I was on some pretty senior teams, and the "devs" were plently able to plan and coordinate, themselves; they also could and did push back against management mis-steps.

In many cases, the analyst or PM could to some extent become an "interface" to the organization and general management. The dev team mostly planned and got stuff done, and the analyst/PM was the one to spend their time in some of those less than fulfilling higher level... "status" meetings.

sudonim• 15 years ago

I only know being a product guy on small teams.

To me, my role as a "product guy" is to keep the whole product and it's intricate details in my brain. I work with the CEO and the Head of Engineering to set the direction for what we're working on today or next. I take in all the feedback from our metrics, our customers, team members, and the boss to decide what's the next most important thing we should build. I push back on business needs when our scope starts to grow too big. I push back on the engineering team when we don't complete work in a satisfactory way. I'm responsible for the success or failure of the product.

I enjoy the job, but it's not something I would consider easy. It's not something where I spend a lot of time looking busy and doing nothing. I could. That would make me a bad product guy.

There are many ways to skin a cat. The difference between a bad product guy and a good product guy is that the good one finds a better way to skin a cat. A good product guy improves the lives of all the stakeholders in the product.

moocow01• 15 years ago

Not in reference specifically to product roles, I think one of the problems right now in SV and probably in other tech hubs is the migration of finance, law, "other fancy profession" people to the tech industry as the bubble has inflated. You have lots of people who genuinely have no qualifications specific to the tech business and there only drive is to just follow the path to whatever is shiny and looks like the most possible path to extravagant wealth according to Forbes. Usually they are easy to identify because they transform themselves to fit the mold of whatever is hot.. ex. in 2004 they were real estate agents / brokers, in 2008 they were social media consultants, and now they want to be SV product / tech entrepreneurs because it the latest things in the paper. The problem with these folks is they unfortunately add little to no value because they spend all their time running around trying to figure out what is the cool thing rather than trying to understand how they can use their own skills to best help others.

Honestly Im not too big of a fan of the bubble times. I'll be glad when things calm down and the finance, law etc types move onto the next shiny thing and were left with the people who truly enjoy the industry.

jaysonelliot• 15 years ago

I've never thought of myself as a "product guy." I'm a user experience guy.

What was surprising to me about this article was that the three books he recommended are all books I'd consider required reading for anyone who wants to take on user experience as either a skill or a role.

Does that mean I'm on my way to being a product guy?

I kid, I kid.

URSpider94• 15 years ago

Im my mind, the "product gal" or guy brings the voice of the customer into the product team by:

* Writing user stories

* Prioritizing features for development effort

* Weighing in on design decisions that impact user experience

* Interfacing with current and potential customers to collect feedback

Meanwhile, this frees the devs up to, you know, develop.

In an early-stage start-up, one of the founders usually plays this role, in addition to a million other things. As the company grows, you need folks who can work full-time on product management.

A great product manager knows enough about implementation to earn the respect of the rest of the team, but is not afraid to ask the developers to tackle really difficult problems, if it's the right thing to do for the customer.

In my experience, a team without a good product guy runs the risk of delivering a product that nobody wants.

keeptrying• 15 years ago

Its very very hard to find a good/great program/product manager.

I've only known one in my 10 years as a programmer. Some tests to use to figure out if someone is a good product guy:

1. Ask them if you can meet 3 users who are willing to use your product. If he can get you to meet 3 - you've probably got a good product guy.

2. Ask them how people make money now that your product doesn't exist. If they say they've actually tried to do this without your product and show you how they failed, they are probably pretty good.

3. If his documentation that he shares with you is a single prioritized list of features with measures/time built in so he can re-prioritize the list then he's probably a good product guy.

Essentially he will take complete and utter responsibility for the product from upper management.

Very rare to find.

pinaceae4• 15 years ago

Product Manager here. Our software is aimed at field force users in the life science industry.

Without me, developers would not know what to build. It is all industry specific, driven by business as well as compliance requirements - in several distinct regions, worldwide.

When programmers build stuff for that hey will use themselves, yes, a product manager's value is debatable. but there is a lot of stuff out there a normal coder will never use, but still has to build.

doktrin• 15 years ago

This is spot on, and I'm glad someone pointed this out. I'm not a product manager, but can recognize that when working outside of my field of expertise I could probably use some guidance when it comes to building a product for said field.

lucisferre3• 15 years ago

So why not take that guidance directly from the users of that product. Sure if that really isn't an option (though it usually is even when people and business make excuses for why it isn't) having a "user representative" is a distant second that must be accepted. However it is still your job to build some level of shared domain knowledge with the users of the software.

ryanpers• 15 years ago

so you take the requirements from the customers to the developers?

mseebach• 15 years ago

I'm a dev, having moved into product management quite recently.

Essentially, yes. But with a few caveats:

- The customers doesn't communicate in "requirements". They communicate in "I want to achieve X". When they do seem to communicate in requirements, it's always because they want to achieve some X, and there might be a better way of doing that. Uncovering X and mapping it to something that's feasible and coherent with the direction the application is going is an essential part of the job.

- Ensuring consistent communication, including providing a single point of entry for the customers. Making sure that customers always receive either a firm commitment or a firm non-commitment. No "I'll look into that" which is interpreted as "It's done". No playing developers out against each other ("But your colleague promised me, I really need this tomorrow.").

- Responsibility for the big picture. If keeping the big picture is trivial, you probably don't need product guys. But after a certain degree of complexity, being able to tune out everything but the task you're working on is good for developer productivity.

- The buck stops here. A while ago our team wanted to remove a screen from the product because it carried some legacy dead weight. They went to the PMs and got the go ahead. Now, it turned out that PMs were wrong, and the screen had to be put back in after some loud calls from users (which went to client managers and PMs, not developers). Developers were held free of responsibility (and PMs did a root cause analysis). I imagine that if developers were held responsible for this error, it would increase friction as everybody would scramble to make sure they have their back covered whenever something changes.

pinaceae4• 15 years ago

no. i understand what the customer really needs, which is rarely what he wants.

i than build and design product that will a) fit their needs b) be useful for all other customers we have or c) won't disrupt existing customers workflow.

nupark22• 15 years ago

This is actually why product managers drive me batty; they're neither a software engineer OR a UX engineer, so they don't actually know how to build the product, nor do they have the design skills to create a great UX.

The job you describe here would be infinitely better suited to a UX engineer that has experience and knowledge necessary to build great user experiences, and a lead technical engineering architect.

The idea that engineers/UX designers can't translate business/compliance requirements into engineering/UX requirements is laughable. The truth is that they're the ones best suited to do so, because they're entirely capable of understanding both the business/compliance requirements and the constraints under which they must be implemented in UX/engineering.

rprasad• 15 years ago

It's not at all laughable that most engineers can't translate business or compliance requirements into engineering or UX requirements. It's a different language to them. It's like asking an American to translate Swahili into English. It's possible that a few could do it, but the vast majority would be unable to do so. In this respect, having a domain-experienced programmer is just as "rare" (or even rarer) than a "great" PM.

The programmers are the ones least suited to figuring out what the product should do because they aren't the ones who are going to use it. They approach the problem from a programmer's perspective on the technical requirements of implementation, not on the user's functionality (PM) or usability (UX) requirements. Product Managers design the product from a standpoint of actual domain experience for the end customer to use.

(I say this as someone who has been both a PM and a SE.)

pinaceae4• 15 years ago

if you think this is just UX, you have simply no clue about business processes. once you have a large number of customers, corprations, which are truly global, your nice and simple approach will not scale.

our devs are centralized, whereas our product management is out there, on the ground, from the US to china, europe, japan, etc.

wanna understand sampling compliance in Italy? expense reporting in Germany? order management in Spain? EPPV in Japan? do you know what EPPV means?

there are no coders out there to cover this broad level of business knowledge.

i started in consulting, with a background in coding as well as business. worked myself up the ladder, was a system architect for global systems. then became a "product guy" - because I have all this knowledge and experience now, in my head. which you can't simply learn or read up. only years of experience can give you that.

lucisferre3• 15 years ago

"Without me, developers would not know what to build."

If that is true for your team (and I'm highly dubious) then I'd have to say you have mediocre to downright incompetent developers (being able to code does not immediately qualify someone to design and build good software). Understanding the use cases, business requirements and the user are all part of designing great software. If none the developers can manage to accomplish this, then they are going to build mediocre software regardless of what BA or PM they have on the team.

For my part I've met very few good developers who were not capable of developing a fairly deep domain understanding even in complex domains.

pinaceae4• 15 years ago

doesn't scale on a global level. we have 40+ coders. serve a global audience, big pharma. product management is there to translate and manage a huge number incoming requests, ideas, etc.

product management does not interfere in technical decisions. that's what the coders do. pm acts as the one, single client to the devs. they build for us.

georgieporgie• 15 years ago

In my experience, the role of a PM is to 1) make everyone sit around in a 1+ hour daily meeting, during a ridiculous crunch cycle, instead of discreetly coordinating as necessary, and 2) make horrible UI changes and yell (literally) at developers when they push back out of simple common sense.

blrgeek• 15 years ago

Guy from finance background who has no idea what 'product guys' do in non-consumer tech companies, talking about self-styled product guys.

In a non-consumer company, where the engineers are not the end-users, there has to be someone who creates and keeps the vision alive.

And normally the product guy comes through after many years of engg. or engg + mktg experience.

mikeleeorg• 15 years ago

I was a software developer, then technical manager for several years before deciding I wanted to become a product manager. This was at a large corporation where coming up with product specs, marketing plans, and business models were out of the purview of a technical manager.

I met with several product VPs I respected and asked for their advice on making the transition. One of them, also a former software developer, pointed me to the books, "Crossing the Chasm" and "The Innovator's Dilemma". They opened my eyes to a new way of looking at products and helped me successfully become a PM.

Nowadays, I try to make sure everyone on my team (in a startup environment) has read or knows the content of books like these. In a startup, everyone has a huge role in how the product is defined. However, someone who can take ultimate responsibility in prioritizing the product's features based on customer feedback, business metrics, market trends, etc., is still necessary. That person might be the CEO or cofounder or whomever, but they essentially have "product management" responsibilities.

ChristianMarks• 15 years ago

Whenever I hear the phrase "push back" I reach for my resume.

viandante2• 15 years ago

Why?

code_duck• 15 years ago

When 'product people' are good, they're what makes the product a success. When they're note good, they're worse than useless. My impression is that it's not an aptitude you can learn from books. Being good at product design takes an ability to see the whole picture while also taking details seriously.

skeptical• 15 years ago

I'm surprised so many people here at HN buys the 'Product Guy' crap. My opinion is even more radical than Aaron Harris'.

I'm sick of guys that think they are more important than developers because they use a suit and tie or master some extremely subjective skill while I sit all day and do actual tangible work.

I will not give credibility to anybody to criticize my work if that person haven't been in my shoes. As a developer, the only product guy I would respect is the one that has once been a developer and that would have the skills to sit down and discuss my work from a technical point of view if that would ever be necessary. Otherwise I reserve myself the right to think that some of the decisions are stupid. Why wouldn't I?

Paul Graham , Bill Gates, John Carmack, Joel Spolsky and many others were (are) programmers they didn't reach their status by 'knowing how to manage people'.

alexanderberman• 15 years ago

This misses the point of what a product manager actually does, though. A PM isn't there to criticize your work or even to manage developers - that's more the project manager's job (or perhaps a lead developer's).

PM's at most companies translate customer feedback into concrete specs that devs can execute on. PMs usually do not have any authority over developers, but instead try to work alongside them.

I really don't understand why devs hate on PMs - they exist to let devs focus on code. PMs create customer personas, user stories, UI/UX specs, and business reports, which are all things that the majority of devs don't want to have to deal with.

nupark22• 15 years ago

> I really don't understand why devs hate on PMs - they exist to let devs focus on code. PMs create customer personas, user stories, UI/UX specs, and business reports, which are all things that the majority of devs don't want to have to deal with.

My issue with this is that most PMs do an exceptionally bad job of this.

Understanding the user is a task as complex as developing the application, and it's something that is best suited to a dialog between an actual UX designer and the software engineers.

Blindly implementing what the PM tells you to implement is an awful position to be in, and results in terrible UX and bored/annoyed engineers.

The engineers and UX designers should be driving the product boat. The PM (if there is one) should be relaying business priorities, and relaying back the technical/design context necessary to choose those business priorities.

If given the choice, I'd ditch a product manager every single time and replace them with:

* A UX/UI designer.

* Engineers interested in user experience

* Lead engineering architects

* A project manager to keep tabs on priorities and scheduling.

pacemkr• 15 years ago

I've always thought of a "product guy" as a competent hacker who can can switch hats as he's working to think about business, the users, the design, the ease of use, the infrastructure, etc. A jack of all trades, one step away from entrepreneur. Never did it occur to me that "product guy" means something entirely different to others.

viandante2• 15 years ago

I am amazed by seeing developers, people with great attention to details, generalizing at this levels.

ahoyhere2• 15 years ago

Being the "product guy" is a shitload of work. I know, that's the role I serve in the company that I founded. Customer interaction, roadmaps, design, prioritization of features, plans for growth -- it's hard and it's a lot of work.

It's so much work that I don't even have time to code any more, because it's so much more than 1 job.

Seems like developers just like to hate on anyone who's not a developer because the developers can't see the work they don't have to do.

Whether or not many Product Managers in bigcos are full of shit doesn't say anything about the profession whatsoever. What it says is that most people are incompetent at their jobs, and lazy. Which is also true of most developers.

It's sad for me to see HN continuing to leap to confirm its own biases instead of questioning them.

adambrault• 15 years ago

Agree.

As the guy who generally plays this role on our team, I'm quite certain none of our developers would say they outwork me.

It's easy to see how someone without practical boots-on-the-ground, neck-on-the-line experience in design, development, or business could be utterly horrible to work with as a product manager.

But in that case, you're just working with someone who's unqualified and propped up by authority. Forget role or job title. That's painful under any circumstances.

lucisferre3• 15 years ago

It's not HN confirming the biases it's real world "PM"s who are often completely unqualified as well as the many businesses out there who encourage this because they can't seem to understand what the role is or what would qualify someone to do it well.

Management, in general, gets a lot of flak from "makers" because of how convenient it is to (as one friend of mine put it) "hide from the work". That isn't to say there isn't incredibly important stuff management needs to be doing, just that there are more people not doing it than there are doing it well and it's the makers who often suffer for it, or worse are blamed for poor team performance.

Basically, until that reality changes I'd expect to see a lot more people slogging on "PM"s.

ahoyhere2• 15 years ago

It's not Manager Quarterly confirming biases it's real world "coders" who are often completely unqualified as well as the many businesses out ther who encourage this because they can't seem to understand what the role is or what would qualify someone to do it well.

Developers, in general, get a lot of flak from "bosses" because of how convenient it is to (as one friend of mine put it) "hide from the work". That isn't to say there isn't incredibly important stuff programming needs to be doing, just that there are more people not doing it than there are doing it well and it's the makers who often suffer for it, or worse are blamed for poor team performance.

Basically, until that reality changes I'd expect to see a lot more people slogging on "coder"s.

rwhitman• 15 years ago

I concur. I made a leap from developer to fulltime Product Manager about 6 months ago, thinking it would be some sort of 'vacation' that would allow me more time to code in my free time...

I quickly discovered product work is so, so much more demanding a position than writing code that I barely have time to do anything else but work.

baddspellar• 15 years ago

I've run software projects on the technical side for going on 20 years now.

In all those years, I've been lucky enough to have exactly 2 good product managers. The rest have ranged from useless to downright harmful

Here's what made the 2 good ones good: They knew their limitations. They didn't imagine themselves to be programmers, architects, or user experience experts, regardless of how many books they read. They never, ever, specified requirements in terms of architecture or implementation. They might give a sketch to clarify what they're talking about, but they'd never defend it as the required (or even a good) approach. They trusted the rest of the team in their areas of expertise. In turn, we trusted them in their area of expertise.

Their focus was on talking to real customers about the problems they faced, finding out why current products (ours and competitors) didn't solve those problems, and getting that information to the people who had skills in building products. When we had something to show, they'd give us feedback based on how well it met the customers' needs, and they'd use their relationships with customers to get some customers to give us feedback on intermediate results. They did research. If they didn't know something, they'd say so, and find out.

They trusted us to give them fair estimates. If something was going to take so long it would miss a market opportunity, they'd work with us to figure out alternatives.

They'd prioritize, and stick to these priorities unless significant new information came along, in which case they'd sit with us to make tradeoffs.

What did the rest of them do?

They'd specify requirements in terms of implementation. They'd tell us how they wanted something architected. They'd attempt to design a UI and tell us the requirement was to implement that UI. They'd trust their gut without doing actual research. They'd promise features in a specific timeframe before getting estimates from engineering.

ebun• 15 years ago

Product Manager here. Are most PM's really that non-technical?

I have a B.S. in Computer Engineering and worked as a dev for 3 years before becoming a PM. I thought that my path into product management was a common one. Is this not the case?

devs10102• 15 years ago

The product manager at my job is completely non-technical, and this seems to have been by design (they just filled it from an internal candidate a couple months ago), basically she is supposed to be the bridge between engineering and the "stakeholders", so to speak and make sure their vision matches what is happening. To handle the technical side of things we have another manager that does have a technical background, loosely termed the "project architect". All technical decision go through him or the CTO, the fluff stuff and touchy feel stuff goes through the product manager.

brettinlj2• 15 years ago

Recipe for disaster. Spoken from a product manager.

brettinlj2• 15 years ago

Depends on the company sometimes. I happen to come from a strong engineering background (good school, worked as an engineer at companies from Qualcomm, to small startups to Disney) and got into product after working with a good one.

I am the minority at my current place of work but given the companies most of us reading this are interested in, I think having an engineering background is an advantage. It can be substituted for other analytical backgrounds, but you really need a strong product lead that can spend the time to be the voice of the customer (and their unmet needs) while also getting into the gritty details (ex. hey, have you thought about how Hadoop could be helpful here?).

Most on here that are badmouthing product managers have worked with bad ones. I was there once.

Spare Me From “Product Guys”

Related Stories