Writing Not Too Long, Not Too Short, Product Documentation (But I can't help you with articles titles!)
When creating documentation for a product, each product and company will be different. Some will require a very quick 2-3 pages document, others might ask for detailed information on every aspect/section. But what goes into "product documentation"?
Every product manager has his or her preference, as clear from the many different product documents and templates found online. Here is an example of a short product requirements document for Product Hunt.
I don't like long documents as no one reads them and it is a hassle to keep them up to date. In contrast, very short documents might skip important details that should be considered before developing the product. What I have created in my last project:
A business case.
A product requirements document (PRD).
The business case deals with things like:
Executive summary: Summarize the document in two paragraphs for the busy CEO.
Background, business need & opportunity, product description.
Market landscape: Details on the current market for the product and the competition.
Financial analysis: Things like cost, expected sales and profit, unit price ... etc.
Development plan: Project management details and timeline.
Risk and contingency plans: What could jeopardize the product success or launch, and what can be done about it.
Assumptions: What assumptions were made when making this case and why. It gives context to some of the decisions made in the previous sections.
Recommendation: Give your recommendation. Could be "Go Ahead!", "Only if done this way", or "This is a bad idea Chief!".
The business case goes to the upper management and/or other parties to describe the business side of the product (Duh! yes I know). It gives everyone the product context and why it is a good idea to build it (or not). If the product was not already decided, this document has to be good to gain approval to build the product.
For the PRD, here you describe the features of the product (high level) based on how you will compete in the market and against the competitors you have presented in the business case. Sections can be:
Background: Give a quick summary of the business case to give context to the dev/designer who won't read the business case.
Vision and goals: Where is this product going? And what goals do you want to achieve to consider the product a success? These guide many of your product decisions.
Personas: Who will use the product? Who is affected by it? Detail their wants and their tasks, and don't mix between the "product buyer" and the "product user".
Features: What does the product provide/do? This section makes most of the document. How many details are needed depends on your situation and judgment.
UX and design: Show what it will look like. Wireframes, mockups, or mood boards, whatever you think is needed, but wireframes are usually the minimum, as this is a 'show don't tell' section of the document.
Nonfunctional requirements: What doesn't fit in the previous sections as a requirement.
Timeline: Get the engineering team rough estimation on building the above.
There are other things you can add to the documents and other documents that can be created (like a Marketing Requirements Document). In the end, the goal of these documents is to keep everyone on the same page in terms of what are we building and why.