Business / 2 min read
How to write an honest build-in-public update
Document real decisions and observations, separate evidence from interpretation, and leave the next question open.
More on founder stories and practical frameworks →
Reading preferences
Applies to book and journal reading areas in this browser. Your browser’s zoom and motion settings still work.
Begin with something that happened
A useful founder update starts with an actual event: a question from a customer, a decision the team made, a test that failed, or a small piece of work that shipped. It does not need a dramatic milestone.
Making the work visible begins with a record you can stand behind. Before choosing a headline, write down the actual event, what you observed, and what remains uncertain. Leave room to check the detail instead of filling gaps with a more impressive story.
Separate observation from interpretation
Describe what happened before explaining what you think it means. If one person struggled with a step, say that one person struggled. Do not convert a single conversation into a claim about all authors.
Explain the decision that followed, including what the observation did not resolve. When information is private, share the general lesson without publishing identifying details. Avoid quoting a customer or displaying their work without permission. An honest boundary can make an update clearer.
Leave the next question open
End with the next thing you want to learn. A useful update might follow four prompts: what happened, what we noticed, what we changed, and what we will check next. If nothing changed yet, say what you are considering.
This practice creates a record that can later support a founder essay or book. It preserves uncertainty instead of rewriting it after the outcome is known. Before publishing, verify every date, metric, product statement, and attributed comment. Consistency comes from documenting real work, not filling a calendar with milestones that never happened.
