Hacker News Reader

Comment by secondcoming | Hacker News Reader

> This is all I really want from a PM. When they set a certain priority to tasks, I want to see market research data, usability studies, customer testimony, a list of sales leads, revenue projections, etc.

Ok, I take it you're not a developer then!

View on HN

Au contraire! I am a developer. As a developer, one of the biggest issues I've seen with product management is a constant shifting in product direction. Each time there are great power point slides defining a new product vision, but rarely ever is any justification for this new vision, nor do I often see evidence that the change increased revenue.

By requiring evidence for a particular prioritization, not only does that increase my confidence that what I'm working on will actually matter, but it makes changing the prioritization harder, and hopefully means that it will happen less often, and that perhaps I can actually ship something before the PM changes the vision (again).

I think if you are building something extremely technical such as products for devs, or Fintech stuff, you have to understand some APIs just to know enough that you know what you are able to deliver.

Some level of technical competence is necessary, but not always as much as you might expect. For example, in designing an API, sequence diagrams and data payload definitions are things you can use to communicate the essential aspects of an API to less-technical PMs.

You're doing the Product Manager's job, in my opinion. They're the ones who have to justify to senior management why something is being done, and when. The devs really should just get on and do it once it's been agreed.

Nope, I'm not doing the PM's job. I'm not doing the market research or coming up with the product roadmap. I want the PM to justify to me the work they are asking me to do. I also want to have a productive conversation about the cost of what they are asking me to do (which I can articulate to some extent) and the value they expect it to return.

Involving devs after the roadmap has been decided is too late.

Why do you expect justifications? This is not the role of the dev.

I would say that as the PM role is one without actual power, you need to convince those who will be working on a problem to be convinced that what you're doing makes sense. With data backing them up, this makes your assumptions more trusted, and the team easier to convince.

I'm curious as to know what your PM's roadmaps look like, because really they shouldn't be listing features/implementation, but objectives and goals.

I agree though with what you're saying, regardless of the technical capacity of the PM, it's not really up for him to decide the capability of the teams, or the proposed technical solution. He should be managing those with the engineering teams, and their thoughts should be reflected on the roadmap.

Reply on news.ycombinator.com