project-descriptionlisted

# Writing a project description that survives implementation A description written once and used everywhere beats four documents that disagree. The shape below is the one that held up from ideation through submission. ## The section spine 1. **TL;DR** — the elevator pitch in a paragraph. 2. **The problem, and why now** — real stakes, a named audience, and what changed recently. "Why now" is what separates a product from a project. 3. **The insight** — framed as two extremes and the underserved middle between them. Clinical software is built for institutions; generic organisers have no concept of the domain; the middle is unclaimed. This framing does more work than any feature list. 4. **Personas** — a table. Who they are, what they need. 5. **What it does** — features grouped by pillar, never a flat list. 6. **A day in the life** — a narrative with named characters. 7. **Product principles** — the design philosophy that makes it unmistakably for this audience rather than a generic dashboard. 8. **Limitations and out of scope** — mandatory. ## Named characters are load-bearing The names you invent in "a day in the life" are not decoration. Reuse them as your **seeded demo data**, your **demo video script**, and your **submission narrative**. One decision, three deliverables, and a judge who reads the description then opens the demo sees the same family. So: name them once, deliberately, with a plausible geography that carries the point of the product. Then re