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:
-
Frequency
How often does the problem need to occur before it becomes significant? -
Severity
Does it need to cause major incidents, or can repeated smaller losses create enough impact? -
Economic cost
What actually gets leadership's attention — engineering hours, incident duration, customer impact, risk, delayed delivery, or something else? -
Existing alternatives
What makes an organization decide that its current combination of tools, processes, documentation, and people is no longer enough? -
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.
From inside an org rather than the builder side: the thing that has to be true before my team adopts anything is that it removes a chase, not that it adds visibility. I manage a sales team, and every tool that asked my reps to update a status died in three weeks, because the cost of adoption landed on the person with the least incentive. The ones that stuck changed what I had to do — I stopped pinging people for updates, so I defended the tool.
So to your five criteria I'd add a sixth: who does the work of keeping it true? If your ownership map only stays accurate because engineers remember to update it, you're back to documented state drifting from reality, which is the exact problem you're solving. If it stays accurate as a side effect of something they already do, adoption is almost automatic.
A concrete test that beat interviews for me: ask what they did the last time this happened, then offer to do it manually for them once. If they come back the next time it happens and ask you to do it again, that's adoption. Nobody asks twice for something they don't need.
Disclosure, it's my product: Tskflow came out of exactly this — I'd ask for something, then I became the reminder. It ends that chase.
Honest answer from the other side of this: no amount of further interviewing will answer "would they adopt it." Adoption questions get answered by watching behavior, not by asking about it — people are accurate about their pain and terrible at predicting their own purchasing.
The cheapest behavioral test I know is to do the job manually for one team, for free, for two weeks. Reconstruct the ownership map by hand, hand it to them during a real incident, and see whether they come back and ask for it again when you stop. If they chase you for it, you have a product; if the two weeks pass quietly, you have an interesting problem nobody will pay to fix. That single signal is worth more than another twenty conversations.
One thing your five criteria are missing: who signs. Ops friction is often distributed across engineers who feel it but hold no budget, while the person with budget never experiences it. Even a real, frequent, costly problem stays unsold if there's no single owner whose metric improves visibly. Worth adding "whose number moves, and can they see it move" to the list — for stale ownership/documentation problems, that's usually the binding constraint rather than severity.
You're naming the invisible measurement boundary: "people experience this problem" is not the same measurement as "people will change to fix it."
The evidence you're looking for (real → recurring → costly → insufficiently solved) is correct but incomplete. A team can experience all five and still choose to live with it, work around it, or wait for the vendor to fix it. The missing measurement is willingness-to-invest-in-change.
The risky mistake: treating "problem confirmation" as demand signal. A room full of ops teams saying "yeah that's annoying" is research validation, not product validation. But most founders stop researching at that point and build, then get surprised when "people who agreed the problem exists" aren't people who adopt the solution.
The adoption boundary is behavioral - it requires measuring whether they'll change workflow, train teams, or replace a working (if friction-filled) system. That's observable, not just discussable. That's what you're moving toward, and it's the right move.
That shift makes sense. A problem becomes a purchase when someone can see what it costs to leave it alone. I'd look for a recent incident or an upcoming audit, migration, or handoff. Those events usually create both a budget owner and a deadline. "What did this cost the last time it happened?" will probably tell you more than "Would you pay to avoid it?"
Frequency vs willingness to change is the split I keep landing on too. We spent months dogfooding our own analytics tool, and the teams who adopted it weren't the ones with the most incidents — they were the ones already comfortable asking their AI questions. The workflow shift decides everything.
This is the hardest shift. We spent weeks validating the "problem" for our tool, but the real test was: will creators actually open it every day? Turned out the answer was no until we added a daily trigger (morning competitor digest). Problem validation ≠ habit validation. What made you realize adoption was the real bottleneck?
That's a really useful distinction — problem validation versus habit validation.
The daily trigger example is especially interesting because it suggests the problem can be real and still not create enough behavioral pull for adoption.
What made you realize that the bottleneck was actually usage/adoption rather than the problem itself? Was it something you observed in user behavior, retention, interviews, or another signal?
Great question. For me it was retention data. I kept getting "this is useful" in interviews, but 7-day retention was under 5%. The problem was real — creators need thumbnail feedback — but the product wasn't creating a daily trigger. I realized I was solving a "sometimes" problem, not an "every upload" habit. Now rebuilding around a morning digest to force the daily open. Adoption is a harder problem to solve than the core feature itself.
Agreement is cheap. The signal that finally counted for me was someone changing a weekly habit, not nodding on a call. If they still do the workaround after they agree it's broken, they haven't adopted anything. I'd ask: what did they stop doing last Tuesday because of this.
That's a very useful distinction.
I'm increasingly finding the same thing: agreement that a problem exists is a weak signal. The stronger signal is when the problem changes behavior especially when someone actually replaces a workaround or changes an established workflow.
Your question about "what did they stop doing last Tuesday because of this?" is a great way to frame that. I'm going to keep that in mind as I move through the product-validation conversations. Thanks for the perspective.
The shift from “does this problem exist?” to “would someone change their workflow for it?” is an important one.
Curious what evidence you’re finding most convincing so far.
So far, the most convincing evidence isn't simply someone saying the problem is real.
I'm paying more attention to three things:
I'm still collecting evidence, so I'm deliberately trying not to jump from "people experience this" to "there should be a product for it."
Just sent you a quick email on this, Ubong — thought it’d be easier to continue the discussion there.