Teaching the Product We Already Had

The platform could automate agency workflows through JSON-based configuration rules — a genuinely powerful capability. The support queue told the real story: agencies kept asking for automation the product already had, because they couldn't write the rules.

The documentation existed and was accurate. It was also written for developers. Our users were city clerks and county administrators — smart, motivated, and completely unserved by reference docs that assumed programming fluency.

Nobody asked me to fix this; there was no ticket that said "the docs are for the wrong audience." I built a six-part video series that decomposed the configuration workflow into steps a nontechnical administrator could follow — starting from what they wanted to accomplish, not from the syntax.

The design principle: teach the workflow, not the format. Each part ended with a working rule the viewer had built themselves, because in adoption, a small early win beats a complete reference.

An existing capability became adoptable. The product didn't change — its audience did.

What I learned: adoption gaps are often education-product gaps, and the cheapest item on a roadmap can be teaching the product you already have. It's also my standing answer to a question I care about: what did you do that nobody asked for? Watching a support queue closely enough to see the pattern behind the tickets is a product skill, not a support task.