Spare Me From “Product Guys”
techcrunch.com
techcrunch.com
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.]
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.
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.
Anyone who thinks a good PM isn't worth their weight in gold is seriously la-la and probably hasn't worked with one.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
"What makes someone a great product manager at Google?"
http://www.quora.com/Google/What-makes-someone-a-great-produ...
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.
Of course the 5% of "Product Guys" and "Business Analysts" that are true talents are worth their weight in gold.
So, what are they paid to... do, then?
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.
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)
* 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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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'.
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.
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.
The developer is responsible for defining what is technically possible.
The PM has to analyze the tradeoffs and negotiate a compromise that best suits the product, time available, and company objectives.
When the three collaborate, you have ONE product team. No party is superior or can stand alone effectively.