[NorthOf33rd]

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.

[cocoflunchy]

PRDs for CYA?

[NorthOf33rd]

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?

[dadarepublic]

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.

[makapuf]

Product requirement docs for covering your a ?