Where it started
An internal IT team needed a better way to handle tickets. The available options were either
enterprise ITSM platforms priced for organisations several times the size, or spreadsheets.
The gap between those two is where a lot of mid-sized operations live.
What began as scoping a ticketing tool turned into a broader observation: ticketing is the
visible symptom. The real problem is that IT operations runs on knowledge that lives in
people's heads — which asset is where, which SLA is about to breach, what is running low,
what is currently down.
InfraCue is the attempt to put that in one place.
What it does
- Ticket management with automatic assignment, so intake stops depending on who is
watching the queue
- SLA management and escalation workflows — the thing that turns a ticket list into an
operations discipline
- Asset inventory with minimum-stock alerts, so consumable shortfalls surface before they
become outages
- Dashboards, analytics and a wallboard for live operational visibility
- Network Pulse — infrastructure monitoring surfaced alongside the tickets it causes
- Role-based administration and operational reporting
My role
I am the product owner, not the engineering team, and the distinction matters.
I own the problem definition and the requirements: translating operational pain into
specified features, prioritising the roadmap, designing the workflows and the states they
move through, directing UI/UX, and taking the commercial decisions — branding, positioning,
pricing concepts, hosting, SaaS packaging and go-to-market. I work with development, test the
builds, and write the product documentation.
I use AI coding assistants throughout — for prototyping, for working through solution
options, and for closing the gap between a requirement I can describe and an implementation
I can evaluate. That has changed how fast a specification can become something clickable,
which in turn changes how early you find out that the specification was wrong.
Why it belongs in a transformation portfolio
Most transformation work is bounded by an existing organisation's systems and appetite.
Building a product from zero removes those constraints and exposes everything else: whether
you can identify a problem worth solving, define a solution precisely enough for someone to
build it, make commercial decisions without a template, and keep scope honest.
It is the same skill as internal transformation work, without anywhere to hide.