How to Share Progress Updates Without Revealing Your Roadmap

Keep progress posts to five components and under 120 words. The length limit is not decoration. It forces you to pick one shipped thing and one question, which is exactly the shape that shows momentum without leaking plans.

1. Headline the thing that shipped. Past tense. The feature, the fix, the page, the integration. Not "next up."
2. One sentence on the change a user will notice. Describe the experience, not the implementation. "Exports now finish in one click" beats a paragraph about your queue architecture.
3. One qualitative result. Direction plus unit of change, plus who observed it. No absolute numbers unless they are already public elsewhere.
4. Exactly one open question you need answered. Real, specific, answerable in a sentence by the people you want to hear from.
5. A one-line boundary. Say plainly that you are not sharing dates or internal numbers yet.

A worked example, at 84 words:

Shipped: bulk import for contacts.

What changed for you: drop a CSV and the column matching now
happens automatically, so the step where you mapped fields by
hand is gone.

What we saw: in the first round of testing, import setup time
dropped by roughly half, measured across the test group only.

One question: when a column is ambiguous, should we guess and
let you correct it, or stop and ask every time?

I am not sharing release dates or internal numbers yet, but I
will post again when the next piece is live.

Note what the third line does. "Dropped by roughly half, measured across the test group only" communicates movement and scope without giving a baseline anyone can extrapolate from. If someone replies asking for the actual numbers, you have already answered: the boundary line covers it.

The template also handles the problem that most build-in-public accounts fail at. As one practitioner's playbook on growing a personal brand on X puts it, most founders treat the format as a milestone feed, which is "a changelog with extra steps." A changelog announces; a progress post recruits. The open question in part four is what makes the difference.

This is the hard part, so make it a checklist you run before publishing rather than a judgment call in the moment.

Two rows deserve more than a table cell.

Numbers. The temptation is to publish a metric because it is the fastest way to signal traction. The cost is that a published number becomes a benchmark you are expected to beat next time, and a slowdown becomes a public story. Tommy Clark makes the point in his analysis of building in public for SaaS founders that the strategy works well when the company is doing well and falls apart when growth slows. Directional language gives you the same signal without the ratchet.

Dates. A date is the single most quoted sentence in any progress post, and the least likely to survive contact with reality. Roadmap practitioners have converged on the same answer from the other direction: the now-next-later format exists precisely because it drops fixed dates when scope shifts, and honest roadmaps use rough windows with an explicit note that they are approximate, as WishKit's survey of public roadmap examples documents, including AWS Containers explaining that it cannot provide specific target dates.

You will get the question. Have the reply ready before you post, because improvising it is how roadmaps leak.

A three-sentence pattern works: acknowledge, name the next milestone, decline the date.

Fair question. The next thing I will announce is the beta opening to the waitlist, and that is the only checkpoint I am putting a name on. I am not sharing a date for it, because the last two estimates I gave myself were wrong and I would rather under-promise in public.

Three properties make this work. It gives the asker real information (there is a next checkpoint, and it has a name). It explains the policy without apologizing for it. And it does not leave a gap someone can fill with their own guess.

If the same person asks twice, do not elaborate. Repeat the milestone name and move on. Elaboration is where people accidentally describe scope, and scope plus a rough sense of your team size is enough for a reader to reverse-engineer a timeline.

The same discipline applies to your own posts. Even the qualitative result in part three of the template should name the population it came from, because "halved" without context invites the reader to assume it applies to everyone.

The question is the engine of the post. A bad one produces replies you cannot use, and a good one produces the kind of specific input that changes what you build.

Decision posts and work-in-progress questions both generate replies because readers have opinions and experience with the same kinds of decisions, as the build-in-public playbook on Dev.to notes. The failure mode is the generic ending: "Thoughts?" "What do you think?" "Let me know below."

Good questions share three traits. They are answerable in one sentence. They have two or three plausible answers, not infinite ones. And the answer would actually change something you do.

Compare:

• Weak: "What do you think of the new import flow?"
• Strong: "When a column is ambiguous, should we guess and let you correct it, or stop and ask every time?"

The second question names a real fork you have not resolved, which is what makes it credible. The practitioner guidance on publishing questions you genuinely have not figured out is blunt about why this works: a refreshing amount of transparency combined with storytelling is what earns attention, and the vulnerability of admitting you have not decided yet is what makes readers invested. Answering your own question in the replies is the fastest way to prove the question was theater.

One question, not three. Three questions split the replies, and the one you actually care about gets a third of the attention.

The practical rhythm most build-in-public writers settle on is one update per weekday, with the observation noted during the day and written up at the end of it, as described in the Dev.to playbook. That advice is about volume, though. For a progress post that has to avoid the roadmap, cadence is a constraint on honesty, not on frequency.

Two traps follow.

The empty week. Some weeks nothing ships. Do not manufacture a roadmap item to fill the slot. Publish a decision post instead: the fork you are facing, the options, the weight you gave each. It fits the same five-part template (the "shipped" line becomes "the decision I made this week") and leaks nothing, because a decision you have already made is not a plan you have committed to.

The accountability trap. Publishing targets is a known build-in-public pattern, and it is the one most likely to convert a progress post into a roadmap. A public to-do list is a schedule with the dates filed off. If you want accountability, make it private and report on completions, not intentions.

One more discipline: keep the boundary line in every post, not just the first one. Readers arrive mid-stream. The people who saw your boundary three months ago are not the people reading today, and someone who only sees the current post has no way to know a policy exists.

If writing and maintaining this kind of post is competing with the actual work, or if you want a specialist to build the intake form, the changelog page or the waitlist the post points to, Quanta is the route: describe the site, app or plan you need and a specialist picks it up with you.