Hacker News new | comments | show | ask | jobs | submit login

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.




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.


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.


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


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


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.


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.


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


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.


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.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: