Why Communication is Product Infrastructure

These days, we monitor technical infrastructure obsessively - service uptime, deployment frequency, how healthy your pipelines are looking. There’s a collective understanding that while this sort of infrastructure isn't glamorous, it is foundational to building and running good products that work for our users.

But there’s another fundamentally important bit of infrastructure that too often gets overlooked: communication.

When your CI/CD pipeline breaks, a bleary-eyed engineer gets invited to an emergency Teams meeting at 2am. When your communication infrastructure breaks, you can’t immediately tell - but the impact is just as real.

A load-bearing beam

My product experience has largely been working on complex services in the public sector. You’re not building for customers who can simply churn and try out a competitor: there is simply no other way to get your driving license, or pay your taxes, or apply for probate.

Rather than product market fit driving adoption, there are a whole host of different vectors defining product success.

Ministers think in terms of their manifesto commitments and the impact on the next election cycle. Civil servants think in procedure. Technologists think in systems. Legal thinks in liability and risk. And citizens and businesses think about whether this solves their problem (or not).

In that sort of environment, a lack of communication becomes clear incredibly quickly.

Communication debt compounds like technical debt: misaligned scopes, ineffective meetings, delayed design decisions, unmet dependencies, an apathetic team, frustrated stakeholders, and unhappy users.

Given that, my view is that communication isn’t a ‘nice to have’ soft skill: it’s a load-bearing beam for the whole product.

Your job is to build the communication infrastructure that makes effective collaboration and product delivery possible.

“Communication debt compounds like technical debt.”

Joe Hart, Senior Product Manager @ Netcompany

Chief Clarity Officer

Think of yourself as the Chief Clarity Officer for your product or service.

It’s your responsibility to build, maintain and reflect a coherent picture of four things:

1. What you're building and for who. The single mother accessing support she’s entitled to digitally for the first time. The small business owner drowning in compliance. The caseworker just about handling an enormous backlog with systems that don't talk to each other.
2. The path forward (and why you’re taking it). This isn’t about being defensive: it’s about having a clear understanding of the ‘why’ driving the strategy.
3. The tradeoffs you're making to get there. Particularly with taxpayer-funded services, its imperative tradeoffs are visible, owned and understood: a service could go live for a particular cohort of people sooner, but risk confusion or make migration harder. Which is the right move?
4. How this makes things better. The mandate that trumps everything. Can you articulate the value of your product or service so clearly that everyone from the minister to your developers knows why it matters?

If you can't communicate these four things clearly, you don't properly understand them. And if you don't understand them, how can you expect your team, your stakeholders or your users to?

Three techniques

So, what can you do to start building your communication infrastructure?

1. Build a communication strategy

Many PMs treat communication as reactive. Someone asks a question, you answer in Slack. Someone needs an update, you send it over email.

This is like deploying to production "whenever someone remembers." Why should your communication strategy have any less rigour?

Create a stakeholder map. Not just names and titles, but a living document tracking your view of who understands what.

“Cold” stakeholders are risks: the senior leader who skipped six months of sprint reviews could show up during a governance board with no context for your decisions.

Design your communication to prevent anyone going cold:

• Regular rhythms: weekly delivery updates, fortnightly sprint reviews, quarterly strategy reviews and so on.
• Proactive check-ins: don’t rely on being prompted, reach out - even a quick exchange over Teams can do wonders for fostering effective conversations
• Think multi-channel: some read documents, some need face to face time, some want data, some just need the elevator pitch. Adapt accordingly!

This might feel like an unnecessary overhead at first. But in my experience, it’s never failed to ultimately save time, make product delivery less stressful and more effective.

2. Write to think

Business cases, requirements docs, decision papers… rather than moan about documentation, use it as an opportunity to make your thinking visible, auditable and accessible.

“Writing is thinking. To write well is to think clearly. That's why it's so hard.”

David McCullough

Write your strategy on one page first. Not a fancy slide, not a spreadsheet or a whiteboard or “in the roadmap”. Write out (in full sentences):

• The problem in terms anyone can understand
• Who experiences it and what it costs them
• What you're proposing
• Why this versus alternatives
• What success looks like
• What you're not doing

Everything else flows from this, because writing forces precision. Vague can stay vague in your head, but writing exposes the gaps. With this approach, when the minister's office calls, your answer is consistent - whether you're talking to them or your development team.

Your writing also becomes institutional memory: your input to the business case will be referenced in the audit. A decision paper will be cited when someone questions the approach in a Select Committee. You're building understanding that survives beyond you.

3. Use visuals to build shared understanding

You're making tradeoffs with public money and data. These need to be seen and discussed in the open. Visual communication in product isn't about pretty graphics: it's about getting abstract and complicated things into a ‘discussable’ format.

Surface service boundaries. You could work with a service designer to quickly map your service across departmental boundaries in Excalidraw or on a whiteboard: everyone sees where handoffs don’t work, where citizens fall through cracks, where data gets lost. The visual forces collective honesty about systemic problems that exist between teams.

Sketch a simple view of your system architecture in a non-technical stakeholder workshop. When legal or security people see how data flows, they ask different questions. When PMO understand tech debt, they understand why certain delays aren’t optional.

Put a simple priority matrix on the wall or in your slides at a governance panel. Watch the conversation shift from "why can't we do everything" to "given these constraints, what matters most?"

The power isn't the visual itself, it's the conversation it enables, the questions they invite, and the shared understanding they can create.

What really matters

Communication infrastructure is a massive determining factor in whether your product succeeds or fails.

Your technical stack, your roadmap, your user research - none of it matters if you can't maintain shared understanding across stakeholders. So build it deliberately: that's the job.