Lessons from working with internal consumers
I lead the strategy and delivery of products and systems that solve real problems, support commercial goals and scale across teams and markets. My work spans platform foundations, user-facing experiences, commercial tools and developer products, and I adapt my approach to the needs of each domain. I focus on maturing complex systems, improving the experience for both users and developers and strengthening the foundations that make products reliable, scalable and easy to build on. I care about clarity, good judgement and creating the processes and environments that help teams deliver consistent, long-term impact. My experience covers early-stage, scale-up and enterprise product environments, combining hands-on delivery with team leadership and award-winning work recognised across several innovation competitions.
Working with internal consumers changes how you think about product work.
On paper, internal users should be easier. They're accessible, aligned to the same company goals, and more forgiving than external customers.
In reality, the dynamics are often more complex.
The first lesson is that internal consumers still have incentives.
They're optimizing for their own delivery speed, reliability, and success metrics, not for the health of the platform they depend on. When your system slows them down, they'll work around it. That's rational, not hostile.
The second lesson is that proximity can mask systemic pain.
Because internal consumers can message you directly, individual issues feel manageable. But that accessibility often hides the real cost: repeated questions, one-off fixes, undocumented assumptions, and workarounds that multiply silently across teams.
What feels like good support is often just band-aids hiding a broken experience.
Another lesson is that empathy must be paired with boundaries.
Treating internal teams as customers doesn't mean saying yes to everything. It means being clear about what's supported, what isn't, and why. Ambiguous flexibility feels generous but creates more friction than clear constraints.
In one case, internal teams kept requesting custom endpoints for edge cases. Each request felt reasonable in isolation. But we had 15 variations of similar functionality.
The shift was saying: "We support these three patterns well. If your use case doesn't fit, let's talk about whether it should become a fourth pattern or if there's a different approach."
Clear boundaries, not infinite flexibility, made the platform more useful.
The most effective shift I've seen is treating internal consumption as a product relationship:
Clear contracts
Predictable change processes
Feedback loops that go beyond anecdotes
When internal consumers trust the platform, they stop hedging. They build with confidence. That's when reuse actually happens.
Working with internal consumers taught me that internal doesn't mean informal.
It means the cost of getting it wrong is paid repeatedly, by people who can't opt out.
Clarity isn't rigidity, it's the best form of support you can offer.