Hacker News Reader

> A lack of knowledge hoarding, healthier knowledge transfer and decision making, and reduced waste.

Author here, +100 to this. The role of the PM should be to drive consensus around the problem, not to decree the problem (or requirements) by fiat.

For me, that process is highly collaborative, and engineers (and design, support, etc.) should 100% be involved from the begining. The amount of definition will vary from team to team and even engineer to engineer, but if a PM is hoarding knowledge, their understanding of their own role is the opposite of what it should be.

To paraphrase a famous product manager at Initech, "I talk to the customers so the engineers don't have to". That's not to say the engineers shouldn't talk to customers, but generally speaking, PMs should be the ones conducting qualitative and quantitative research day-to-day so that everyone can focus on what they do best.

At least on my teams, for example, user interviews are recorded and shared with the entire team, along with their raw notes, as are the high-level takeaways, allowing everyone to opt-in to as much or as little context as they'd like. We treat quantitative research the same way, sharing the underlying query, raw data, etc.

While the PM may ultimately drive the discussion, problem definition should be collaborative so that the entire team is aligned around a shared product vision. The PM's role should be to gather, organize, and share knowledge to build consensus, not to hoard it.

Agreed. It's one of the biggest things that drew me to SAFe as well because it fosters more communication and collaboration, empowers more people to make decisions and specifically de-emphasizes the PM as a focal point of all things.

What’s SAFe?

Scaled Agile Framework

>lack of knowledge hoarding, healthier knowledge transfer and decision making, and reduced waste.

This. It is so much more efficient as an engineer to have a clear idea of the values and needs of the users, and to share a clear vision with the pm of where the product should be going.

That said, at most places there is an almost total lack of appreciation for the amount of engineering and planning and effort that goes into providing a competent, professional product when those tasks are not directly providing customer-facing features. But it's part of the engineer's job to educate the pm as well about unappreciated realities.

I've been a product manager for nearly a decade and I'd agree with your premise. I've released several well received products, and have risen through the ranks, probably the most relevant success metrics for my role.

I tend to favor less documentation and more communication overall. My tickets/stories whatever, are generally very light and my focus is on honesty and making sure the team understands the problems we're looking to solve- and why. Sometimes that takes the form of "because my boss's boss says so, and we just gotta do it." I see my role as the PR person for the team, and I do my damnedest to make sure that the work they are doing is known and appreciated. Also, I love a good fight with the PMO and making sure they aren't trying to shove dumb process down our throat.

If I have a team that can do good work, and people in the organization know about it, everything seems to shake out fine from there.

This doesn't work with every team. If they have a history of being blamed/battered by management for "failure" this approach is always rejected and the team wants detailed PRDs for CYA.

PRDs for CYA?

Product requirement docs for covering your a ?

Product requirement docs to cover your ass.

While answering this, I'm wondering if the rejection of that style is also correlated with organizational use of acronyms?

Unfortunately I've been in organizations where this was necessary for exactly that...

Exec Manager (wanting to save face in next exec meeting) - Why did the team do that? It obv didn't work. Who's fault is this?

Product Manger - Remember we all signed off on this PRD saying we would try this approach? We also included a couple of alternative options we can explore in case the primary approach wasn't as effective as we hoped.

Upper Manager - ... (after a moment) Ok then, let's explore those alternatives.

Engineering Manager - whew

PRDs _esp those with sign off_ can cover your ass.

My company is going through a dynamic shift to more closely align to the "best" situation you outline here.

Previously engineers were presented with functional requests, i.e. solutions, and not feature requests or problems.

E.g. a lot of our stories were defined as "set a value on page foo, display it in table bar" without any context. This caused a lot of frustration on the engineering side because we didn't know why we were doing something, and were never given a chance to actually engineer something. It was compounded by the fact that these "solutions" were often reversed or made obsolete a month later by a new "solution" that could have been there from the start.

Thankfully, we've started having the real problems brought to the engineering side and work together with product management to come up with a solution. Yes, this means more meetings, but in the long run we're saving ourselves a ton of time un-doing work and avoiding traps in the code early on.

I firmly believe when you remove the "why" context from the conversation with engineering, you lose time and, more importantly, trust in the product team. I've not once come into contact with a product team/person who can accurately translate the "why" into the "how" seamlessly.

The most value I, as an engineer, get from the product team is their help in prioritizing work and coordinating across teams. Let us solve problems together.

This comment is aligned very much with my current thinking. Hiring highly paid engineers but not maximizing their problem solving ability is a significant problem in large companies.

Empowering bottoms-up problem solving by sharing customer pains and feedback broadly is the exactly problem I am trying to solve with my current project/startup [1].

I am gonna shoot you an email later today to see if you have any further thoughts on how do this effectively within an org.

If anyone has ideas on good implementing this, would love to learn so we can incorporate this within our offering. My email is in my profile.

[1] https://www.heraldhq.com

A relatively small number of individuals are required to act as conduits of information – they should be good at collecting, analyzing, organizing and sharing information. They should be good facilitators to anchor a problem/solution across multiple teams/systems/skill-disciplines. These individuals are the PMs. As long as we don't let it go to their heads that they own the product and they are the deciders or some such notion that basically reduces everyone else's problem solving ability, PMs can be very useful.

"Product Manager" means everything from project manager (organizer / scrum master) to client relations manager to product designer (like a game designer who isn't the programmer). This confusion is problematic.

IMO there are a lot of good ideas how to solve such problems out there and that's not the blocker at all.

The real problem are the managers who only do lip service to better policies but never actually implement them. They prefer to distrust people by default and to play internal politics games so they never get fired. Thinking how the customer can succeed better and thus bring more revenue is practically one of the last points in their priority list. Not even sure that "let the creative people figure out solutions, you just give them the problems" even exists in their philosophy.

To me those are the real issues. And they are extremely hard to solve because those people are usually deeply entrenched in the organisation, they have the ear of the CEO and are being listened to during board meetings. And when those people sabotage the implementation of a policy that can improve the company's culture, well, there's basically almost nothing that can be done.

I might be too pessimistic but I've seen this scenario several times and have grown quite cynical about the ability of companies to change their DNA at all.

I agree with this entirely. I'm a PM at a company which is under 300 employees where we were founded by engineers, and nearly every member of management from the executive team down to the ICs has an engineering background. I have an engineering background of 13 years before becoming a PM. Everybody at this company is looking at and trying to understand the customer's problem and identify the best solution, and internally we have very high knowledge transparency.

I have been in large organizations before as an engineer where the PMs were separated and basically set marching orders, but that's not the way smaller organizations operate.

High knowledge transparency directly translates to consensus building over dictatorial decision making and ensures that the engineers know why they're making a specific choice. I think our high-quality software clearly comes from this advantage.

Totally agree. I've been both an engineer and a PM at companies large and small. This sharp line distinction between what PMs think about and what engineers do is never productive in my experience.

I agree, and that's why I'm a huge fan of Hypothesis Driven Development, which enables the whole team to know whether they're adding real value to the end-user. Usually, it's embraced by, using the term you coined, “engineering-minded pm”s, who understand the importance of developer happiness and thinking in terms of problems.

> And, while I’ve not seen it coined, I’ll introduce “engineering-minded pm”.

You might enjoy Inspired by Marty Cagan: an engineer evolves to a new role that we later come to call Product Manager. A core tenet I remember is that Product is greatly served by having engineering acumen.

The concepts of "product-minded engineer" and "engineering-minded pm" make a lot of sense. But what do you mean by "reduced waste" in the context of software development?

Engineering builds the wrong thing, or more likely builds things in such a way that they are harder to adapt to features further out the roadmap.

I've also seen this waste when a PM micromanages aspects of the engineering they are not familiar with, and forbids more senior engineers from thinking about the future (e.g. by refusing to allocate time for obvious foundational engineering).

Thank you. I'm a product manager / engineer at a small logistics company, considering the future. I'm good at product management and I'm okay at programming but I really like doing both. I was worried there weren't a lot of opportunities for me to do both, but it sounds like there are. Thanks for the insight.

Developer tools is an especially great place for technical PMs who want to continue coding. It lets you design interfaces and test implementations (building sample apps, live-coding demos, etc.) without I would consider the daily grind of software engineering.

Lots of dev tools companies getting funding now as well, so plenty of opportunities!