Operational Scaleability


Often, I see teams working on new products where they don’t address the operations side of whatever it is they’re building. Without thinking about these facets of the system they’re creating, skipping from design phase to build to launch and on to the next thing, these teams often miss the mark in delivering operationally scalable products and the tooling necessary for successful operations.

OK, some of the warning signs I’ve learned to look for in these projects:

  1. UX that ignores the possibility of users being troubled by other users,
  2. Lack of communication between project stakeholders,
  3. Unrealistic or last-second expectations about operational responsibility,
  4. A mismatch between your Rules and Ops’ ability to efficiently enforce those rules,
  5. Lack of admin controls,
  6. Lack of resources.

Because it’s an ugly thing some people can ignore, because it calls out design shortcomings, because it’s an unexpected cost to fix, because it’s a frustrating, ongoing problem, Abuse (and the conversation around it) can be a touchy subject. It should still be addressed, though. Just from a product perspective, it’s a bad user experience to be abused. So I’m a big believer that the tipping point comes right in the design phase of the project, but there are simple ways to patch bad system design, too.

Anyone else have experiences they can share here?