Turning months of infrastructure research into one small product experiment
Over the past few months, I've been researching a problem that keeps appearing across SRE, DevOps, platform engineering, incident management, security, identity, and technology leadership.
The pattern is simple:
Teams can detect that something is wrong, but getting from that signal to coordinated action can require a lot of reconstruction.
What changed?
What is affected?
Which component is involved?
What does it depend on?
Who actually owns it?
What evidence supports that?
And what should happen next?
After dozens of conversations, I didn't want to immediately build a large platform around the idea.
So I'm taking a smaller step.
I'm turning the research into one simple product experiment.
The workflow I'm testing is:
Signal
↓
Context
↓
Component
↓
Dependency
↓
Ownership
↓
Evidence
↓
Action
I built the first version in Bubble.
The prototype starts with a fictional incident:
Checkout failures increasing.
From there, the user moves through the workflow and progressively builds enough context to decide what should happen next.
One of the most important parts of the experiment is the ownership step.
The documented owner might say one thing.
Operational evidence might point somewhere else.
Instead of immediately declaring an owner, the prototype surfaces the ambiguity and asks the user to review the evidence.
I'm deliberately keeping this small.
This isn't a finished product.
It's not a claim that I've found the final solution.
It's a way to test an idea that emerged from the research.
Now I'm interested in finding out:
Does this workflow actually help someone move from a signal to a clearer next action?
Where does it duplicate existing tools?
Where does it create unnecessary friction?
What should be removed?
And where, if anywhere, could something like this fit into an existing engineering workflow?
That's the experiment I'm running next.
I'd rather discover that the workflow is wrong now than build a much larger system around the wrong assumption.
If you're working on infrastructure, SRE, DevOps, incident management, or technical operations, I'd genuinely value your criticism.
What would you remove from this workflow?
Does this actually reduce time-to-action during an incident, or mostly make the existing context easier to visualize?
That's exactly what I'm trying to find out.
The prototype currently makes the context easier to structure and visualize, but I don't want to assume that translates into faster action.
The experiment is really whether reducing the reconstruction work between signal → context → ownership → evidence actually reduces time-to-action.
If it only makes the existing process look clearer without reducing time or effort, that's an important result too.
What would you measure to distinguish the two?
That’s the distinction I’d be watching too. The interesting question is whether the experiment produces enough evidence to show that the workflow changes the underlying operational outcome, rather than simply presenting the same information more clearly.
I think the answer will become much more interesting once you have some actual observations from the experiment.