Visibility is Velocity

Once upon a time, I worked with a Product Manager, Bob. Bob's team worked with incoming data pipelines, and transformed and augmented a variety of disparate data sources in to a consistent data model. It was a tough job, as you didn't actually know what data you were going to receive from our providers until it arrived.

Bob’s team also had a reputation for being slow. On average, onboarding a new data source took about three months. When the work shipped, though, it was excellent: reliable, well-instrumented, and easy to maintain.

But when they shipped, they didn't get any accolades. The team heard "Finally! Why did it take so long?". Worse, they heard "I wish you'd have warned us - we haven't implemented the new data source in the billing system". So not only did the project feel late, the business couldn’t even use what had been delivered.

A few months later, Bob was no longer with the company. The feedback was that he “wasn’t compatible with how the business needed to operate.” We hired Alice as his replacement.

The perceived change was immediate. Alice shipped something in her first two weeks. People were impressed. It didn’t even seem plausible that Bob’s team could ship anything in two weeks, let alone within two weeks of a new PM starting.

But Alice didn’t actually make the team faster. New data sources still took three months to fully integrate. The work was the same. The complexity was the same. What changed was that progress became visible.

And suddenly, everyone believed the team had become fast.

The Dangers of Silence

Humans hate ambiguity. When there’s no signal, people invent their own story.

Bob's lack of updates created its own narrative: the work had stalled, or it wasn’t a priority. The project lost momentum. Other teams postponed their related work. Leaders delayed decisions tied to the project. Everyone just kind of "forgot" about the ongoing work.

The lack of communication usually comes from a good place:

“I didn’t want to distract people until I had something solid.”

But updates aren't a distraction. Surprises are. And surprises are expensive for everyone.

Each and every time I've found myself surprising an executive, I've ended up on calls where they're trying to figure out what's going on. Those calls take a lot of time.

We need to re-establish context for those that aren't deep in the project, then explain what's happening and why. The conversation inevitably turns to re-litigation of a decision that was already made.

Before you know it, the engineering team is frustrated that we're revisiting old decisions and the execs are frustrated that things are taking even longer. Surprises don't serve anyone.

The Power of Updates

Sending regular updates doesn't make you go any faster - in fact, it slows you down slightly as writing the updates takes time. You don't want them to be a torrent of useless information ("We added 14 new tests and added support for the FlubJam"). Instead, focus on what's useful ("We added tests to ensure that URL mapping works consistently, and integrated FlubJam so that the billing team can get started with their work").

These small, regular updates build trust and predictability for your audience. They know what's happening, and that the project is still on track. And if there is something that isn't quite right, these regular updates allows people to raise concerns, build alignment and course correct while the cost of doing so is cheap.

How to Ship Incrementally

Let's go back to Bob and Alice. Alice didn’t deliver results any faster. She just made progress visible.

Instead of waiting for everything to be solid, she shared updates like these:

• Week 2: Great news! We've connected to the third party system. Here's a video of us ingesting a piece of data (no mapping, no augmentation)
• Week 4: We've figured out what data is available. Here's a link to our proposed data mapping, and a demo video with the mapping added
• Week 6: The pipeline is running well, and we've managed to add some augmentations. Here's a video of URL extraction from text working. Look how it augments the data with the page title from the URL
• Week 8: Slow progress this week. We realised that the data isn't guaranteed to arrive in order, so it turns out that we were missing some data. We're reworking our pipeline to use the deduplication service so that we don't have to rely on timestamps. I'm still optimistic that we'll be done next month
• Week 10: All solved! I've shared the data size/volume information with the billing team so that they can load it into the rate card system. We're working on additional test cases to give us confidence that we haven't missed anything.
• Week 12: Tada! The project is done. Here's a list of sample configurations and test cases that we run. Thank you for all the feedback along the way.

We still couldn't ship the new data source to customers until week 12, but all of the stakeholders were clear what was happening every step of the way.

Compare that to Bob's updates:

• Week 12: The integration is complete. Here’s the final implementation - let me know if you have feedback.

The engineering team did the same work on the same timeline, but the leadership team had a very different perception.

Alice wasn’t seen as faster because she did more. She was seen as faster because progress showed up continuously. Risks were surfaced early, course corrections happened when needed, and no one was surprised at the end.

Your updates don’t need to be long. Fifteen minutes to produce. Two minutes to consume. That's all it takes.