Solve First, Automate Later: The Methodology Behind Dversi

I wrote an entire chapter of my book around a rule that sounds almost too simple to state: solve the problem first, and only automate once you understand exactly what you're automating. I want to revisit it here, because it's the rule I hold hardest, and I think its logic gets missed even by people who nod along with the title.

The flow everyone defaults to

Picture the last time you signed up for an automation tool. Step one, create an account, verify your email, pick a plan. Step two, grant it OAuth access to your CRM, your email, your accounting software, sensitive systems, before it's done anything for you. Step three, face a blank workflow canvas and try to map your actual process onto the tool's paradigm, which usually requires expertise you don't have. Step four, activate it and hope. Step five, debug it when it quietly does the wrong thing.

Notice what's missing from that entire sequence: any evidence, at any point, that the tool can actually help. You've committed before you've seen a shred of proof.

The flow that inverts it

Now picture something like a VP of Operations I describe in the book, drowning in 47 broken workflows and $40,000 of tooling, still copying data by hand at 10pm. Under the traditional flow she signs up for yet another platform and hopes this one sticks. Under solve first, she opens a chat and types her actual problem in plain language. No account setup, no workflow builder, no permissions grant. The system helps immediately, asks for system access only once it's justified by the help already given, solves the problem manually the first few times, and only then offers to encode the pattern into automation.

The order is the entire point. In the traditional flow you ask for trust, complexity, and commitment before you've earned any of it. In solve first, you earn trust through demonstrated competence, and only then ask for what you need.

Why the order matters more than the tooling

Here's the number that convinced me this isn't just a nicer user experience, it's a real predictor of outcomes. MIT's Project NANDA found that external partners who work alongside a customer before building anything succeed at roughly twice the rate of internal teams who jump straight to building. The difference isn't skill or access. It's that the partner is forced to understand the real workflow first, while the internal team, with full access from day one, often automates the workflow they imagine exists.

That's the root cause behind most of the failed pilots I wrote about last time. Someone in a conference room designs automation based on how they think a process works, builds it, and discovers the real process is different once it ships. The automation doesn't match reality, creates more work than it saves, and gets quietly abandoned.

Why I built this discipline into how Dversi gets used

When we started building Dversi, I insisted on this order as a hard constraint, not a nice-to-have. Before it touches a workflow, the question on the table is never "can we automate this." It's "do we understand this well enough to hand it to a system." Those are different questions, and skipping to the first one is exactly how good demos end up dead six months later.

In practice that means discovery, actually understanding the process and the real pain point, happens before any workflow gets built. It's slower at the start. It saves months later, because you're not unwinding an automated version of a mistake.

The part that never gets automated

Regardless of how capable the underlying model gets, one thing stays fixed: the decision about what "solved" looks like belongs to a person, not a dashboard or a confidence score. Automation gets offered only after a human has watched the system solve the problem manually enough times to trust the pattern, never before.

Solve first, automate later isn't a slogan I picked because it was catchy. It's the rule that kept every serious mistake I've made in twenty years of enterprise IT from happening twice, and it's the same rule the research keeps confirming from angles I didn't expect.