For a while I thought the hard part was shipping the thing.
That was the part I spent the most time on, so it felt like that had to be the bottleneck. I would work through the product problem, ship a feature, merge the PR, and move on to whatever was next on the list. Then a few weeks later I would look back and realize that almost nobody outside my own head knew that the feature existed. Customers did not know. Prospects definitely did not know. Sometimes even the people around me who should have been talking about it did not really know what changed or why it mattered.
That kept happening often enough that I stopped seeing it as a one-off discipline problem. It was a workflow problem.
We keep pretending the work ends at shipping
It doesn’t, and I think that is where a lot of small SaaS teams get themselves into trouble.
I wrote about this before in the post on how SaaS companies have to become media companies. The point there was not that every company suddenly needs to act like a publisher in some abstract branding sense. It was much simpler than that. If you are building a SaaS product, you need a repeatable way to keep putting useful things into the market: ideas, lessons, updates, and proof that the product is moving. Otherwise you end up doing the work without getting much leverage from it.
The exact same issue shows up at the feature level too. You can ship a genuinely useful improvement and still get almost no business value from it if nobody hears about it. The feature ends up sitting in commit history, in Slack, in a half-finished doc, or in a release checklist that nobody opens again. The work is done, but it stays internal.
That’s the part that always bothered me. Not because the feature was bad, and not because the product was not improving. It was the opposite. The value was already there, but nobody was hearing about it.
What this looked like in practice
I ran into this in a very boring, familiar way.
I would ship something on a Thursday or Friday, usually after spending a good amount of time getting the details right. Then I’d tell myself I’d write the release note over the weekend, or I’d turn it into an email on Monday, or I’d at least mention it in a post once I had a bit of breathing room. Then Monday would come, there would be a support issue, another feature to finish, something else that felt more urgent, and that earlier update would just slide down the stack.
Two or three weeks later I’d be looking through old commits and thinking, this actually was a meaningful improvement, why did nobody hear about it?
That loop repeated enough times that I stopped trusting “I’ll announce it later” as a real plan. It usually just meant the update was on its way to being buried.
The pattern kept repeating
Once I started noticing it, the pattern was pretty obvious.
Something real gets shipped. Someone says it should be announced later. The next thing takes priority. The update gets buried. The market never hears about it.
If you are a founder or on a small team, you probably know exactly what that feels like.
You do not have a full PMM function sitting around waiting to turn every shipped change into a proper launch. Most of the time the same people doing the building are also doing some version of positioning, support, sales, onboarding, and marketing. So communication becomes the thing that happens if there is leftover energy.
There usually isn’t.
And that has a cost. Customers do not see momentum. Prospects do not see progress. Your own team has a fuzzier picture of what is new and how to talk about it. Good work disappears because nobody put it in front of the people who needed to see it.
Why the shareability post still matters here
In the post I wrote about shareability, I was really talking about built-in distribution. If something is easy to share by design, it has a much better chance of creating its own growth loop. You are not starting from zero every single time. The product, or the experience around it, helps carry some of the load.
I started thinking about shipped updates the same way. A commit on its own is not shareable. A PR on its own is not shareable. A cleaned-up release note, a useful announcement, a short customer-facing explanation of what changed and why it matters, that is much closer to something people can actually use, forward, or react to.
So the question for me became: how do I make the path from “I shipped this” to “someone can actually see and use this update” much shorter?
That was the real gap for me. Not shipping. What happened after shipping.
What changed for me
The main insight was pretty simple: I did not need more reminders. I needed a better workflow.
I was already writing commits. I was already shipping work. I was already producing the raw material. What I did not have was a reliable bridge between that raw material and something customer-facing.
That is why I built UpdateBerry.
The point is not to replace judgment or pretend every commit deserves a campaign. The point is to make it easier to take the work that already shipped and turn it into something usable: release notes, launch copy, email drafts, changelog updates, social posts. The bottleneck for me was never “can I build the feature?” It was “can I turn the feature into communication before it disappears under the next week of work?”
That is the part I wanted to solve.
Why owned media matters
I still believe what I wrote in the owned media post. If you are building a SaaS company today, you need some form of owned media around the product. You need a place and a habit for publishing what you are learning, what you are shipping, and why it matters.
I do not mean that in a trendy content-marketing way. I mean it in the very practical sense that if you do not build your own habit and place for publishing updates, the work stays trapped in internal systems and invisible context. It does not help you sell better, onboard better, support better, or build more trust with the people watching your product.
That is expensive in a way that is easy to miss, because it does not show up as a single obvious failure. It just shows up as slower momentum than you should have had.
Why I kept UpdateBerry simple
I did not want another tool that creates even more process.
I wanted the opposite. I wanted the handoff from shipping to publishing to feel lighter, not heavier. That is why I kept the scope tight. Identify the update. Figure out what matters. Turn it into something publishable. Get it out the door quickly.
What I want this site to feel like
I want this site to reflect how I actually work. I build tools I would use myself. I care about practical product work. I like systems that remove friction. I prefer clear execution over clever positioning.
UpdateBerry fits that pattern pretty closely. It is not some abstract startup idea I thought sounded good. It is just a response to a problem I kept running into over and over again: shipping faster than I could communicate.
If that sounds familiar
If you are a founder, PMM, or product team and you keep saying “we should announce that later,” you probably already know the problem. It is not just time, and it is not just discipline. It is the gap between what shipped and what the market hears.
That is the gap UpdateBerry is built to close.
If you want to keep shipping good work without letting it disappear, start there.