One of the most significant gaps I see in #documentation is failing to document anything other than the happy path the company built it for.

Engineers and product owners like to only document the perfect happy path a user is supposed to take.

They subconsciously forget to document certain things because they are used to the one primary use case.

It's common not to consider that what's already written, such as product messaging, marketing, etc., might have already planted specific expectations in a user's mind about the product or service.

Only once I play with the product as a user do I spot all these inconsistencies and gaps.

- What happens if you try this path?

- As a user, I expected it to do X, but you're blocked at Y.

- The UI said such and such, so I assumed it could this and that, but it can't.

You must tell the users what the product or version should not be doing.

If workarounds exist for known issues, provide them, especially in an #MVP product where early documentation versions are necessary. If the public should refrain from implementing those workarounds, instruct them not to take the actions that lead to the problem.