Announcing versus educating, a product-comms pivot
Why we moved from launch-day announcements to continuous smaller posts about how the product works. The shape of the shift, what we gave up, and what we gained as a team.
Early on we ran launch-day announcements. “We shipped X.” We made a banner. We wrote a launch post that was mostly product copy. We emailed the launch post to the list. Some feature launches got a small volume of signups on the day. Most got nothing measurable.
A few months in we stopped doing that. We moved to continuous, smaller posts about how the product actually works — the build-log posts you see on this blog, the engineering teardowns, the small shipped-X changelogs. This post is about why the shift happened and what we gave up and gained.
The wrong question
In the early months we were asking “how do we announce this well.” The question presupposed that announcing was the goal. It wasn’t. The goal was for someone to understand the product well enough to trust it with a real RFP. Announcements did not produce that understanding. They produced impressions.
At some point I noticed that the posts where a prospect converted into a serious evaluation — a real upload, a real draft, a real back-and-forth with our team — were never the launch posts. They were the how-it-works posts. The teardowns. The ones that showed, in detail, what the product does when it meets a real document. The launch posts got retweets. The teardowns got customers.
That gap between retweets and customers is what shifted the editorial strategy.
What educating looks like
A launch post asks the reader to take the vendor’s word for it. “We’ve revolutionized compliance extraction” (not a sentence we would write, but a fair caricature) is a claim the reader has no instrument to evaluate. They either believe it or they do not.
An educating post shows the mechanism. “Here is how compliance extraction works: here is the grammar we use to identify ‘shall’ statements, here is the false-positive rate on a test set of 40 federal RFPs, here is where the grammar breaks on state and local documents.” The reader has an instrument now. They can judge whether the mechanism matches a problem they have.
Most B2B vendors do not publish mechanism. They publish outcome claims (“save 40% on proposal time”) and feature lists. Mechanism publication is a specific discipline — it requires technical writing capacity, it requires the confidence to show what the product does wrong, and it requires an audience sophisticated enough to read it. For proposal tools aimed at enterprises with technical buyers, the audience is there.
What we gave up
Three things, and I’ll own each.
Launch-day hype. Every time we ship something, we used to get a small wave of attention. A few retweets, a few LinkedIn shares. That is gone. The mechanism posts do not produce a wave; they produce a trickle of qualified reads over months.
Easy sales collateral. Launch announcements are easy to share in sales conversations. “Look, we just shipped this.” Mechanism posts are harder — they require the prospect to read them to extract the value. Sales team had to adjust. Some did easily, some did not.
A forcing function for shipping cadence. When you announce, you have to ship by a date. We lost some of that pressure when we moved to continuous comms. We now ship when the work is done, not when the comms calendar says so. This is mostly good. It is sometimes bad — I have caught myself delaying a ship because the build-log post wasn’t finished. That is the wrong trade, and I correct for it deliberately.
What we gained
Compound-reading effects. Posts published months ago are still being read today. The build-log posts get linked from inside the product, from sales conversations, from internal documents at prospective customers. A launch post decays in 72 hours; a mechanism post compounds for months.
Sharper product thinking. Writing mechanism publicly forces a rigor on the engineering work that is its own reward. If you have to explain how a retrieval pipeline works to a skeptical reader, you discover the shortcuts you took. We have fixed real bugs because someone on the team wrote a how-it-works post and realized the real behavior did not match the intended behavior.
Hiring signal. Candidates who read the blog come in calibrated. They know how we work, they know what we care about, and they self-select. The volume of applications went down when we stopped announcing; the fit of applications went up.
Less hype, more trust. The cumulative reputation signal of publishing mechanism for the better part of a year is that this company thinks in mechanism. That signal is hard to buy with ads and harder to fake.
What does not work about this
Two real weaknesses in the continuous-educating approach.
It is slower to generate demand. A launch gets you a Tuesday spike. Continuous publishing gets you a rising baseline over quarters. For a company trying to hit a quarterly plan, the launch spike is sometimes the right tactic even when the mechanism post is the right content. We have had to accept longer feedback loops on marketing investment.
Not every product change deserves a post. Some fixes are just fixes. Writing mechanism posts about every code change would exhaust the team and bore the reader. We pick the ones that teach something — about the product, about the category, about the work. Most ship without a post.
Mechanism is not a substitute for a demo. Some prospects want to see the product running, not read about it. The blog is a demand-generation instrument; it is not a sales artifact. We still do demos. We still do POCs. The blog shortens the time between a prospect hearing about us and being ready for a demo, but it does not replace the demo.
The posture shift
Early posture: “We built a great thing; you should hear about it.”
Current posture: “This category has specific problems; here is how we are solving them, mechanism by mechanism. Decide for yourself.”
The second posture is harder to write. It is also the only one that compounds.
See also stop announcing features — announce outcomes, which made a narrower version of this argument a year ago, and grounded AI is not a feature for the related argument about how positioning shifts when you commit to mechanism.
Takeaway
Announcing is what you do when you do not trust the reader to evaluate the work on its own terms. Educating is what you do when you do. The readership for proposal software in 2026 is technical enough to evaluate mechanism, and the market is noisy enough that hype no longer differentiates. The shift from launch-day announcements to continuous teardowns is the shift from a vendor voice to a builder’s voice. We like being the second kind of company better. The blog is where that choice is visible.