A written description of a product to give a development team overall guidance to the project architecture.

Structure:

1. Context and scope—rough overview of the landscape and what is being built.
2. Goals and non-goals—bulleted list of requirements.
3. Design—design overview and details.
4. Alternatives—alternative designs that would’ve achieved similar outcomes.
5. Cross-cutting concerns—how the design impacts security, privacy, observability.

Lifecycle:

1. Creation; rapid iteration—write the doc, share with the project team, drive to a first stable version.
2. Review—share and discuss with a wider range of colleagues.
3. Implementation; iteration—begin implementation.
4. Maintenance; learning—update the doc and re-read over time to find uncertainties.

Accelerate prioritization with a well-established process.

Principles:

1. Proper task description—state problem/result/comments.
2. Clear criteria—customize framework criteria to be unequivocal to the team.
3. Automation—use spreadsheets/tools to reduce manual work.
4. Collaboration—involve the whole team in the evaluation to collect diverse opinions.
5. Regularity—evaluate weekly, re-evaluate monthly.

Optimize operating hours, reduce a human factor during implementation, and accelerate decision-making with proper task description.

Principles:

• Clear and brief—comprehensible to anybody on the team.
• Specific and supported—with existing files and links attached.
• Readable—with paragraphs, bullets, bold, italics, highlights.
• Reasonable—with subtasks or clear checkpoints.

Structure: 

• Problem: detailed description of the problem to solve. 
• Result: detailed description of the expected result. 
• Solution/Comments: known info on solutions or obstacles.