How to Write a Project Update That Builds Credibility

Direct answer

A good project update is regular, specific enough to verify, and honest about what did not happen. Publish on a fixed cadence you can sustain, report misses alongside progress, and prefer "we do not know yet" to a confident non-answer. Credibility comes from the updates published during difficulty, not the ones published during success.

Step 1 — Pick a cadence you can sustain

Predictability matters more than frequency. Monthly delivered reliably beats weekly abandoned after six weeks.

Choose based on what you can maintain during a bad month, not an enthusiastic one — because the bad month is when going quiet does the most damage.

Silence is itself a message, and the one your community receives is that something is wrong and you are not saying.

Step 2 — Use a consistent structure

Consistency lets readers find what they care about, and makes it obvious when something is missing:

1. Since last time     — what actually shipped
2. Did not happen      — what slipped, and why
3. Next period         — what you are working on
4. Numbers             — verifiable metrics
5. Open questions      — what you do not yet know

Section 2 is the one that builds credibility. Almost nobody includes it, which is precisely why including it works.

Step 3 — Be specific enough to verify

Apply the transparency test: could someone check this without asking you?

Vague claims are treated as filler because they usually are. Specific ones can be checked, which is what makes them worth something.

Step 4 — Report misses properly

When something slipped:

1. State it plainly. "The audit did not start in July as planned."
2. Give the reason, briefly and without drama.
3. Give a revised expectation, or say you do not have one.
4. Do not bury it under good news.

A project that reports its own misses is believed when it reports progress. A project that only reports progress is read as marketing, and its good news is discounted accordingly.

Step 5 — Write the numbers honestly

Include metrics that can go down as well as up, and use the same ones every time.

Changing which metrics you report is a signal, and an alert audience reads it correctly: you switched from holder count to social followers because holder count fell.

Avoid metrics that are trivially inflated — follower counts, impressions, "engagement". Prefer on-chain figures with dates: holders, liquidity depth, treasury balance, contract activity.

Step 6 — The incident update

The hardest one, and the one worth preparing in advance.

Structure:

1. What happened, factually.
2. Impact — who is affected, and how.
3. What we are doing now.
4. What we do not yet know.
5. When the next update will come, and then publish it on time.

Rules:

• Publish before you have all the answers. Speed matters more than completeness; a holder learning about it elsewhere first is much worse.
• Do not minimise. "Small issue affecting a limited number of users" reads as evasion when it is not true, and often when it is.
• Do not blame the community for noticing.
• "We do not know yet" is a complete answer. Far better received than a confident wrong one, which you will have to retract.
• Say what changes so it does not recur.

Projects that handle one incident well often emerge with more credibility than before, because the community has now seen how they behave under pressure. Projects that go quiet rarely recover.

Step 7 — Say nothing about price

Updates report on the project, not the market. No price commentary, no targets, no explanations of why the price moved.

Beyond the exposure this creates — see how to promote responsibly — it trains the community to read updates as price signals, which is exactly the community you do not want.

If asked about price, the honest answer is that you do not control it and will not speculate.

Common mistakes

• Only updating when there is good news. The pattern is obvious and read correctly.
• Vague progress claims nobody can verify.
• Announcing unsigned partnerships.
• Quietly changing which metrics you report.
• Going quiet during difficulty — the period that decides whether anyone stays.
• Promising a date you cannot commit to rather than saying you do not have one.

Related

• Project Transparency Guide
• Transparency FAQ
• Token Announcement Strategy