To add to your point, I think what they said about technical writing might also apply to product management:
> It introduced a perverse incentive: become an important project and your software engineers won’t need to write documents. Discouraging engineers from writing documents turns out to be the opposite of what you want to do. Because they are a limited resource, technical writers should generally focus on tasks that software engineers don’t need to do as part of their normal duties. Usually, this involves writing documents that cross API boundaries. Project Foo might clearly know what documentation Project Foo needs, but it probably has a less clear idea what Project Bar needs. A technical writer is better able to stand in as a person unfamiliar with the domain. In fact, it’s one of their critical roles: to challenge the assumptions your team makes about the utility of your project. It’s one of the reasons why many, if not most, software engineering technical writers tend to focus on this specific type of API documentation.
PMs are a scarce resource. A lot of eng teams within Google don't have a dedicated PM and need to carve out product-market fit for themselves. When you have a dedicated PM it's easier to offload all PM ideas and responsibilities to that person.
(I'm a technical writer at Google. The boilerplate "all opinions my own" is important in this convo because I think a lot of TWs and PMs will strongly disagree with these ideas.)
> It introduced a perverse incentive: become an important project and your software engineers won’t need to write documents. Discouraging engineers from writing documents turns out to be the opposite of what you want to do. Because they are a limited resource, technical writers should generally focus on tasks that software engineers don’t need to do as part of their normal duties. Usually, this involves writing documents that cross API boundaries. Project Foo might clearly know what documentation Project Foo needs, but it probably has a less clear idea what Project Bar needs. A technical writer is better able to stand in as a person unfamiliar with the domain. In fact, it’s one of their critical roles: to challenge the assumptions your team makes about the utility of your project. It’s one of the reasons why many, if not most, software engineering technical writers tend to focus on this specific type of API documentation.
PMs are a scarce resource. A lot of eng teams within Google don't have a dedicated PM and need to carve out product-market fit for themselves. When you have a dedicated PM it's easier to offload all PM ideas and responsibilities to that person.
(I'm a technical writer at Google. The boilerplate "all opinions my own" is important in this convo because I think a lot of TWs and PMs will strongly disagree with these ideas.)