This points to a fundamental question: what value does an intermediary add? This question is not unique to product work. Intermediaries are everywhere – brokers, agents, editors, middle management – and they must ask what value they bring beyond carrying messages from one party to another.

Let me use a pair of deliberately extreme stereotypes to help sharpen the question: the postman and the architect.

The postman

The postman's virtue is that he changes nothing. The message arrives exactly as sent – that is the point. In our context, it could mean capturing what business users expect in a certain scenario, relaying it to tech, then carrying clarifications and edge cases back and forth.

This work is not trivial; it is necessary. Reliable transmission of information can be important when decisions need to be documented precisely, when ambiguity must be avoided in translating concepts to implementation, and when coordination between multiple parties is needed.

Nevertheless, the value-add from a postman is thin. And thin value-add carries the risk of disintermediation. If a faster or cheaper way is found to transmit the message – a shared channel, a direct conversation, or an AI tool – then the postman is no longer needed.

A role built on message transmission alone is not only unsatisfying, it could well disappear as methods evolve to carry the message better than we could.

The architect

The architect's virtue is the opposite: everything changes between the request and the blueprint, and the outcome is better for it. The architect translates a client’s wish – an open, airy kitchen – into a design that serves the need behind it: flow of movement, a place to gather. She weighs it against cost and timeline, and against what the contractor can actually build. The architect’s work begins before the message exists – she understands the underlying need, the supply-side constraints, and the trade-offs, before proposing a way forward.

In our product context, when stakeholders share requirements or make demands, an architect does not take the words at face value. She tries to understand the underlying problem being surfaced and proposes solutions to that problem – which may look different from what was initially asked for. The architect’s influence lies not in making every decision, but in holding the larger picture and shaping the trade-offs that determine the outcome.

• When business teams request a new field on a form, an architect probes why the request is made and seeks to understand what decision that field will inform – and sometimes discovers that the real issue lies elsewhere and the field is not needed at all.

• When developers flag an edge case, the architect does not simply forward it. She considers whether the edge case reveals something about the design that ought to change.

In a real-world example, business indicated that our eService needed to cater to an additional user group that had not been earlier identified. This presented as a significant shift and increase in scope for the eService, because new access controls and workflows would need to be designed for the additional user group. If we were in postman mode, we might have concluded that the only options were to take in the request and delay the release timeline, or deprioritise it to a future incremental release.

But after probing the request further, we realised the underlying need was actually for this newly-identified user group to have continued access to certain functions even after the legacy system was decommissioned. Understanding the core of the problem statement enabled us to explore the solution space to identify a more efficient approach – granting these agencies access to the necessary functions in another system. This met the need without compromising the new eService’s architecture, and in fact yielded the proper governance by right-siting the user group to use the appropriate IT system.

The difference between the postman and architect is not the tasks performed. Both attend meetings, write things down, and communicate between parties. The difference is in the thickness of value creation. The postman moves information. The architect, with her deep understanding of the business needs and adept command of technical solutions, frames better choices and enables outcomes that would not otherwise emerge.

From postman to architect

Moving from postman to architect is not easy. This is true even where the product owner has formal autonomy to drive product decisions. Ownership on paper does not necessarily translate to ownership in practice. Stakeholders may see us as coordinators and may not welcome our opinions. Under delivery pressure, probing the problem behind the requirement can come across as obstruction. Similarly, a decision we try to push through without buy-in gets escalated or quietly worked around.

The space to architect – to question requirements, weigh the trade-offs, examine solutions, and put real weight behind the eventual call – is earned rather than conferred. It grows through trust, credibility, and visible value.

• Deepen stakeholder understanding – what are the problems business wants to solve, what are the challenges tech is facing. Put in the self-work: read archived files, meeting notes, technical documentation, and publicly available material. Show that you understand their context and are not starting from scratch.

• Build trust through usefulness. Help stakeholders unblock issues, clarify decisions, or remove recurring friction. Small, quick wins create permission to ask bigger questions later.

Postman versus architect is a spectrum rather than a dichotomy. If architecting seems a far stretch from your current reality, aim first for the middle rung: the editor. An editor does more than relay a message, but stops short of architecting the solution. When passing a message, add the context the recipient lacks. Flag out if a new request contradicts an earlier decision. Reframe a technical constraint in a way that business teams can understand the impact and respond concretely. This is message transmission with judgment attached, and stakeholders will notice that you are doing more than transmitting messages.

The aim here is to cultivate a mindset, not prescribe a posture for every task. Faithful relaying of information is sometimes exactly what is needed – we don’t need to add interpretation to every small task. What we want to avoid is defaulting to a position where we are simply a postman.

Adding value creates a virtuous cycle. The more value you visibly add, the thicker your role becomes, and the more room you are given to shape direction rather than follow it. Eventually you find yourself trusted to do the architect's work – to hold the whole picture, and to help everyone achieve better outcomes than they would have achieved without you.

Conclusion

The intermediary position is not inherently disempowering. It is a vantage point from which a greater outcome can be constructed – a more customer-friendly product, a more accurate processing system, a more maintainable technical backbone. Structures, culture, and leadership matter, and are key drivers of the type of role we are able to occupy in our organisation. But regardless of those, we always have some room to expand our influence – and that room is claimed by thickening the value that we add.