I'm moving from “is this a problem?” to “would teams actually adopt a solution?”

For the past several weeks, I've been researching operational problems across engineering organizations.

I've spoken with people working across SRE, DevOps, platform engineering, infrastructure, incident management, architecture, security, and product.

The first question was straightforward:

Does the problem actually exist in practice?

That research has produced some interesting evidence.

For example, in complex incidents, teams can sometimes understand the general problem relatively quickly but still lose significant time determining the right owner, establishing accountability, or reconstructing the context needed to act.

I've also heard variations of the same underlying issue in different domains:

The documented state of a system can eventually stop matching operational reality.

Ownership changes.

Dependencies change.

Teams change.

Controls change.

Systems evolve.

The research has made me less interested in simply proving that operational friction exists.

Now I'm moving into a different question:

Would teams actually adopt a solution?

Because a real problem does not automatically create a viable product.

A team might experience the problem frequently and still decide:

• "We already have a tool for this."
• "Our existing process is good enough."
• "It's not painful enough to justify changing our workflow."
• "Integration would cost more than the problem."
• "Nobody clearly owns fixing this."
• "Leadership doesn't see it as a priority."

So I'm now trying to understand the conditions that turn operational friction into something an organization is willing to invest in solving.

I'm particularly interested in five things:

1. Frequency
   How often does the problem need to occur before it becomes significant?

2. Severity
   Does it need to cause major incidents, or can repeated smaller losses create enough impact?

3. Economic cost
   What actually gets leadership's attention — engineering hours, incident duration, customer impact, risk, delayed delivery, or something else?

4. Existing alternatives
   What makes an organization decide that its current combination of tools, processes, documentation, and people is no longer enough?

5. Willingness to change
   Even when the problem is real, what makes a team willing to introduce something new into an existing workflow?

This is where I'm deliberately slowing down.

I have a prototype around the broader Gnobu direction, but I'm not trying to convince myself that the product should exist simply because the problem is interesting.

I'd rather find out whether the problem is:

real → recurring → costly → insufficiently solved → and important enough for organizations to change their behavior.

That's the product-validation question I'm exploring now.

For founders and builders:

What was the evidence that finally convinced you that people would actually adopt your solution — rather than simply agree that the problem existed?

And for people inside organizations:

What usually has to be true before your team is willing to change an established workflow and adopt a new system?

I'm particularly interested in real examples rather than general startup advice.