The thing is, documentation isn't a monolithic thing --- it really needs to be sub-divided/categorized into subsets which are useful to specific categories of folks working on, or working with, a project:

https://diataxis.fr/

(originally developed at: https://docs.divio.com/documentation-system/)

divides into 4 types of documentation:

- Tutorials

- Explanation

- How-to Guides

- Reference

My own documentation got much better when I broke it up along those lines.

That does make a huge difference, though I have found you also need to divide by the audiences. There are usually two main audiences that need addressing:

1. The new user. They typically know nothing about the product, not even why it exists. The CTO/CIO bought it and now you have to use it. They need lots of hand-holding and needs concrete instruction. Tutorials and explanations are focused on them so they can build accurate mental models of how the software work.

2. The experienced user. They have a pretty good idea of how the product works, but business requirements have changed in some way and know needs to make adjustments to their processes. Or just needs reminders of less used features. Good how-tos and reference material is vital.

If you don't take care of these things the customer will abandon your product sooner than later.

Agreed, but IMHO it should be layered so one can enter at the highest conceptual level and drill down and back up so there's a continuous flow of understanding.