Hacker News Reader

Comment by hankchinaski | Hacker News Reader

problem i have with PMs as an engineer is that very often they are both clueless about domain knowledge and about technology (or the state of the system they are working with). this is a very horrendous situation to be in both as PM and as an engineer working with a PM.

>5. Decisions, and what you prioritize, need evidence

This. In my experience PMs' features are driven by not evidence but "lets try this stuff out" and "hypothesis" causing a ball of mud on the engineering side to ship stuff fast to impress the stakeholders.

I don't generalise and I also have seen PMs to be brilliant - but is more an exception than the rule - some PMs I've worked with they had very strong analytical skills, engineering knowledge and domain knowledge + skin in the game - if a feature has turned out to be crap they have the guts to kill it

View on HN

I think biggest problem is: not killing enough features. It goes let's try that stuff or some customer "really really needs this" but then no one uses that feature for 2 years. If I would have some PM that looks into stats and kills not used stuff it would be better.

Unfortunately mostly it looks that removing feature is negative value, firstly you already spend time/money building it, second removing is not free where leaving feature there seems like it is free. It is hard to explain that application maintenance costs more when we have bs features in code.

Removing a feature can be a really negative experience for the users. If literally no one uses it, then that's ok, but if even just 0.01% use it, then removing it can break their faith in the product.

If instead you can spin the feature out into a plug-in/extension and possibly even open-source it, you'll do much better by your users.

> problem i have with PMs as an engineer is that very often they are both clueless about domain knowledge and about technology (or the state of the system they are working with). this is a very horrendous situation to be in both as PM and as an engineer working with a PM.

I don't think the PM needs to be particularly knowledgeable about technology so long as they sanity check their ideas with engineering first. The roadmap needs to be the result of a conversation.

> >5. Decisions, and what you prioritize, need evidence

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.

> 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!

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.

Personally, I haven't got the time or energy to question the decisions or expertise of fellow team members. Nor do I have the interest to wade though sales projections and market research any more than they would want to wade through our codebase. An efficient organization is based on trust. I should trust in my PM's skills and diligence to do their research, and they should trust me to build what is needed. When it comes to prioritizing tasks, we can have an adult conversation about what should come first based on technical and non-technical considerations. If you don't trust your peers to do their job, the end result is micromanagement - which can work both ways.

> When it comes to prioritizing tasks, we can have an adult conversation about what should come first based on technical and non-technical considerations. If you don't trust your peers to do their job, the end result is micromanagement - which can work both ways.

Expecting people to be able to justify their decisions isn't micro-management. It's a perfectly adult, rational way to work together. If I want to (for example) change the underlying technology used to build a product or set aside some time to clean up technical debt, I need to justify (or at least be prepared to justify) that decision to my colleagues.

Expecting that I can rely on my positional authority over "technical" decisions to deflect questions or criticisms of my decision is a sign of a low-trust organization.

Reply on news.ycombinator.com