TLDR: Redesign the product until its description makes sense.
I've done some technical writing. It's hard work. One open source tool I made, I spent more time on the docs than on the actual code.
Press releases, manuals, installation instructions, etc can be great QA/QC tools. If something is hard to communicate, then the subject itself is probably too complicated. Or just badly designed. Go back and simplify.
One stretch, I was also the engineering manager for a handful of products. So I had the juice to compel improvement.
The manuals and installation instructions were, um, challenging. I made the teams reengineer installers, UIs, workflows, whatever until the technical writing made sense. Other benefits included greatly reducing defects and technical support calls.
--
I also put the QA Test team members in charge of our releases. To great effect. Which I haven't seen any one else do before and since. But that's another story.
I only mention it to acknowledge that most orgs treat writers and testers like crap. Like you experienced. Which is unfortunate, wasteful, and rude.
This was mid to late 90s. I don't know if execution would apply today. But the notions of designing the organization are evergreen.
I riffed on a notion from Ford's idea of quality circles, where engr, mfg, and QA made decisions jointly. And the USA Constitution's notion of balance of powers (trilemma).
My company was engineering driven. Our releases were always late. Way too many defects. QA/Test were demoralized. Sales and marketing weren't even part of the convo.
So I split responsibilities into three roles. Marketing determined feature set and price point. Engineering determined how and schedule. QA/Test controlled the release.
The first release cycle was VERY HARD. People hate change. I was an asshole and burned a lot of goodwill. Thereafter, our releases were always on time, we hit our P&L numbers, reduced our costs (eg tech support burden), and were given ever increasing amount of responsibility.
Later, I expanded the organizational triangle into a star by adding tech support, sales, and writing roles, each with their own responsibilities and authority.
We survived Y2K just fine. But 9/11 crashed our industry and we didn't survive not having customers.
I've done some technical writing. It's hard work. One open source tool I made, I spent more time on the docs than on the actual code.
Press releases, manuals, installation instructions, etc can be great QA/QC tools. If something is hard to communicate, then the subject itself is probably too complicated. Or just badly designed. Go back and simplify.
One stretch, I was also the engineering manager for a handful of products. So I had the juice to compel improvement.
The manuals and installation instructions were, um, challenging. I made the teams reengineer installers, UIs, workflows, whatever until the technical writing made sense. Other benefits included greatly reducing defects and technical support calls.
--
I also put the QA Test team members in charge of our releases. To great effect. Which I haven't seen any one else do before and since. But that's another story.
I only mention it to acknowledge that most orgs treat writers and testers like crap. Like you experienced. Which is unfortunate, wasteful, and rude.