Communication is 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 fundamental to building products that actually work.
There’s another vital 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
I've mostly worked on complex services in the public sector. That means you’re not building for customers who can churn and try out a competitor: there is simply no other way for people to get their driving license, or pay their taxes, or apply for probate.
Rather than product market fit driving adoption, there are a whole host of different vectors defining product success. In these contexts, a lack of communication becomes clear incredibly quickly.
Communication debt compounds like technical debt.
It has serious downstream consequences. 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.
Arata Isozaki, concert hall sketch, 1992
Chief Clarity Officer
A useful frame is to 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:
What you're building and for who. The single parent accessing support they're 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.
The path forward (and why you’re taking it). You should have a clear understanding of the ‘why’ driving the strategy and what it'll mean when it's real.
The tradeoffs you're making to get there. Particularly with taxpayer-funded services, tradeoffs must be made visible. A service could go live for a particular cohort of people sooner, but risk confusion with existing users, or make data migration harder. Which is the right move? Why?
How this makes things better. Can you articulate the real value of your product or service? Can you do it so clearly that a Minister and an engineer on your team "get it" straight away?
If you can't communicate these things, you don't understand them. And if you don't understand them, how can you expect your team, your stakeholders or your users to?
Lay the pipes
Where do you start?
Begin with a stakeholder map. Not a static list of names and titles, but a living articulation of the context your product or service exists in. Then think about how best to build shared understanding with those people. Reliable rhythms, proactive check-ins, tailored approaches. Some people read documents, some need face to face time, some just need the elevator pitch.
Then write things down. Business cases, decision papers, requirements docs - instead of moaning, use them as an opportunity to make your thinking visible, auditable and accessible. Ask yourself if you can clearly articulate:
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
Sit with how uncomfortable writing this stuff down makes you feel. That's a sign you don't understand it as well as you thought. Vague can stay vague in your head, but it won't survive a blank page. Writing forces precision, which can only help your team.
Make it visible. Visuals are the best way of getting abstract and complicated things into a discussable, comprehensible format. Map your service boundaries across departmental handoffs. Sketch your system architecture in a stakeholder workshop. When people see how things connect, they ask different questions.
This is the work
Your roadmap is useless if nobody understands it. Your user research is useless if the findings aren't clear. Your strategy is useless if it lives in your head.
Many of the things we instinctively think of as the work - the roadmap, the backlog, your sprint reviews - just won't work without communication. Communication isn't what supports product delivery. It's what makes delivery possible at all.
This article was originally posted on Product Speak. It's since been tightened up.