3 ms·

I've hired a number of PMs for my startup over the last 12months,and by far the most important thing that is overlooked (imo) is the ability to write good specs

I've hired a number of PMs for my startup over the last 12months,and by far the most important thing that is overlooked (imo) is the ability to write good specs that are helpful for engineering. You can think of that as a sign that a PM can think like an engineer and communicate with engineers. For people with PM experience, I'll ask them about the things they considered and documented in their last spec. If they think a spec is a list of bullet points, that's instant fail. If they considered all user flows in and out of the features, edge cases, user education, analytics/success metrics, release plan and time vs cost tradeoffs that's a win.

anotherhacker 14y ago
On writing specs: I disagree with this. I believe the author left that out because writing 'good' specs is inconsequential. I used to think I had to write good specs, but then I realized that I was better off spending time with the team to make sure they understood the motivation behind making a change. If an organization told me that I was gonna be writing specs - I wouldn't want to work there. It's a waste of time. In brief: it's a waste of time because it assumes that one knows all the variables when creating something. If you are truly creating something, then by definition it's not be done before; thus, no one can know all the consequences of implementation. You're better off having an open mind and be quick to experiment and learn.
nicw 14y ago
Along with good specs, I would add having an open line of communication with your engineers about what to do when the specs aren't clear. I've worked with some engineers that their personality caused them to think it was their fault they didn't understand the spec - and they spent unnecessary time and frustration trying to puzzle something out. Raising your hand and asking, "Is this what you meant?" can save a lot of hassles, especially with remote teams.
- sardonicbryan 14y ago
  Yeah, our teams are pretty small (about 20 between eng, art, product, qa, etc) and sit by each other in open plan floor space, so the lines of communication are definitely open, as long as no one is an asshole. I guess implicit in our interview process is that we're screening for a minimum of communication skills.
pifflesnort 14y ago
If engineers are best suited to architect code, and user-experience designers are best suited to architect product design, and visual designers are best suited to architect product visual design ... what is left for a PM to specify, and how are they qualified to be doing it?
- sardonicbryan 14y ago
  In my org, PMs have the responsibility for owning product metrics and business goals. So that means they are responsible for both pulling and analyzing user behavior data, and deeply understanding the impact of each of our feature releases from both a metrics and business goal standpoint. We also select heavily for quant analysis background, so our PMs are way better at pulling and analyzing data than our engineers or designers. As a result, they are typically the closest to really knowing what has worked and what hasn't and why, which makes them uniquely positioned to decide what to do next/prioritize upcoming features, make tradeoffs. It doesn't mean the decision making is perfect, but I like to think that if you ask our engineers and designers whether our PMs are adding value, they would agree. Our 12 month engineer retention and internal survey data indicate that that's at least directionally accurate.
- enraged_camel 14y ago
  PM is a mix of all those roles - engineering, UX, design - plus business. A good way to think about it is that the role ties the product to the company's business goals. A good PM will be able to talk to all four teams intelligently and help them channel their skills into a product that's successful.
SatvikBeri 14y ago
I'm an Analyst/Engineer turned PM. Back when I started coding, I often found that only about 30% of my effort would actually be used-the rest was wasted because of vague requirements or miscommunication. So I started creating light prototypes to make sure my "customers" (internal parties) and I were thinking of the same thing, and got that up to about 70%. Now as a PM, I try to use specs as a way to iterate faster. If you're working on a prototype of a completely experimental product, then at the beginning the important part is to make sure everyone just has an understanding of what the overall product will be-which is already quite difficult! Sometimes the best document here is literally just an annotated flow-chart. On the other hand, when you're adding user-based features to an existing product, it helps to have stories, mockups, and in general include a lot more detail. There's never going to be a perfect spec, but well-written (and iterated!) specs can make the development process much faster.

anotherhacker 14y ago

On writing specs: I disagree with this. I believe the author left that out because writing 'good' specs is inconsequential. I used to think I had to write good specs, but then I realized that I was better off spending time with the team to make sure they understood the motivation behind making a change. If an organization told me that I was gonna be writing specs - I wouldn't want to work there. It's a waste of time. In brief: it's a waste of time because it assumes that one knows all the variables when creating something. If you are truly creating something, then by definition it's not be done before; thus, no one can know all the consequences of implementation. You're better off having an open mind and be quick to experiment and learn.

nicw 14y ago

Along with good specs, I would add having an open line of communication with your engineers about what to do when the specs aren't clear. I've worked with some engineers that their personality caused them to think it was their fault they didn't understand the spec - and they spent unnecessary time and frustration trying to puzzle something out. Raising your hand and asking, "Is this what you meant?" can save a lot of hassles, especially with remote teams.

sardonicbryan 14y ago
Yeah, our teams are pretty small (about 20 between eng, art, product, qa, etc) and sit by each other in open plan floor space, so the lines of communication are definitely open, as long as no one is an asshole. I guess implicit in our interview process is that we're screening for a minimum of communication skills.

pifflesnort 14y ago

If engineers are best suited to architect code, and user-experience designers are best suited to architect product design, and visual designers are best suited to architect product visual design ... what is left for a PM to specify, and how are they qualified to be doing it?

sardonicbryan 14y ago
In my org, PMs have the responsibility for owning product metrics and business goals. So that means they are responsible for both pulling and analyzing user behavior data, and deeply understanding the impact of each of our feature releases from both a metrics and business goal standpoint. We also select heavily for quant analysis background, so our PMs are way better at pulling and analyzing data than our engineers or designers. As a result, they are typically the closest to really knowing what has worked and what hasn't and why, which makes them uniquely positioned to decide what to do next/prioritize upcoming features, make tradeoffs. It doesn't mean the decision making is perfect, but I like to think that if you ask our engineers and designers whether our PMs are adding value, they would agree. Our 12 month engineer retention and internal survey data indicate that that's at least directionally accurate.
enraged_camel 14y ago
PM is a mix of all those roles - engineering, UX, design - plus business. A good way to think about it is that the role ties the product to the company's business goals. A good PM will be able to talk to all four teams intelligently and help them channel their skills into a product that's successful.

SatvikBeri 14y ago

I'm an Analyst/Engineer turned PM. Back when I started coding, I often found that only about 30% of my effort would actually be used-the rest was wasted because of vague requirements or miscommunication. So I started creating light prototypes to make sure my "customers" (internal parties) and I were thinking of the same thing, and got that up to about 70%. Now as a PM, I try to use specs as a way to iterate faster. If you're working on a prototype of a completely experimental product, then at the beginning the important part is to make sure everyone just has an understanding of what the overall product will be-which is already quite difficult! Sometimes the best document here is literally just an annotated flow-chart. On the other hand, when you're adding user-based features to an existing product, it helps to have stories, mockups, and in general include a lot more detail. There's never going to be a perfect spec, but well-written (and iterated!) specs can make the development process much faster.