9 ms·

Spare Me From “Product Guys”

82 points by ssclafani 15y ago

mathattack 15y 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 15y 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 15y 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 15y 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)
    - deleted 15y ago
      [deleted]
- ericd 15y 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.
- gujk 15y ago
  The exact same analysis applies to developers.
  - mathattack 15y ago
    Fair enough. :-) At least with developers, the progress can be more tangible and visible.
dhotson 15y ago
Somewhat related: "What makes someone a great product manager at Google?" http://www.quora.com/Google/What-makes-someone-a-great-product-manager-at-Google/answer/Edward-Ho-1 http://www.quora.com/Google/What-makes-someone-a-great-produ...
lucasjake 15y 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.
- gujk 15y ago
  Your paragraph 4 contradicts paragraph 2.
  - viscanti 15y 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.
alsomike 15y ago
Going off this 'starter guide', a Product Guy is basically taking your most junior, inexperienced designer/developer and putting them in charge?
gatlin 15y 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 15y 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.
  - gatlin 15y 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 15y 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 15y 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 15y 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.
    - mattmanser 15y ago
      I'd just like to point out to both you and the parent mmaunder said Program manager/product manager, not Project Manager. But if he means a PM, then fair enough. Anyone who thinks a good PM isn't worth their weight in gold is seriously la-la and probably hasn't worked with one.
sudonim 15y 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 15y 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 15y 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 15y 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 15y 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.
pinaceae 15y 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 15y 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.
  - lucisferre 15y 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 15y ago
  so you take the requirements from the customers to the developers?
  - mseebach 15y 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.
georgieporgie 15y 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 15y 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 15y 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 15y ago
Whenever I hear the phrase "push back" I reach for my resume.
- viandante 15y ago
  Why?
code_duck 15y 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 15y 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 15y 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.
  - nupark2 15y 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 15y 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.
viandante 15y ago
I am amazed by seeing developers, people with great attention to details, generalizing at this levels.
ahoyhere 15y 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 15y 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.
- lucisferre 15y 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.
  - ahoyhere 15y 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.
baddspellar 15y 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 15y 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?
- devs1010 15y 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.
  - brettinlj 15y ago
    Recipe for disaster. Spoken from a product manager.
    - devs1010 15y ago
      I agree to an extent but they do need someone to basically take all the crap from the "stakeholders" and it may be better to not waste that on someone with technical knowledge
- brettinlj 15y 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.

82 points by ssclafani 15y 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 15y 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 15y 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 15y 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)
  - deleted 15y ago
    [deleted]
ericd 15y 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.
gujk 15y ago
The exact same analysis applies to developers.
- mathattack 15y ago
  Fair enough. :-) At least with developers, the progress can be more tangible and visible.

dhotson 15y ago

Somewhat related: "What makes someone a great product manager at Google?" http://www.quora.com/Google/What-makes-someone-a-great-product-manager-at-Google/answer/Edward-Ho-1 http://www.quora.com/Google/What-makes-someone-a-great-produ...

lucasjake 15y 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.

gujk 15y ago
Your paragraph 4 contradicts paragraph 2.
- viscanti 15y 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.

alsomike 15y ago

Going off this 'starter guide', a Product Guy is basically taking your most junior, inexperienced designer/developer and putting them in charge?

gatlin 15y 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 15y 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.
- gatlin 15y 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 15y 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 15y 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 15y 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.
  - mattmanser 15y ago
    I'd just like to point out to both you and the parent mmaunder said Program manager/product manager, not Project Manager. But if he means a PM, then fair enough. Anyone who thinks a good PM isn't worth their weight in gold is seriously la-la and probably hasn't worked with one.

sudonim 15y 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 15y 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 15y 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 15y 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 15y 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.

pinaceae 15y 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 15y 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.
- lucisferre 15y 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 15y ago
so you take the requirements from the customers to the developers?
- mseebach 15y 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.

georgieporgie 15y 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 15y 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 15y 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 15y ago

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

viandante 15y ago
Why?

code_duck 15y 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 15y 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 15y 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.
- nupark2 15y 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 15y 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.

viandante 15y ago

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

ahoyhere 15y 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 15y 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.
lucisferre 15y 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.
- ahoyhere 15y 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.

baddspellar 15y 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 15y 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?

devs1010 15y 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.
- brettinlj 15y ago
  Recipe for disaster. Spoken from a product manager.
  - devs1010 15y ago
    I agree to an extent but they do need someone to basically take all the crap from the "stakeholders" and it may be better to not waste that on someone with technical knowledge
brettinlj 15y 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.