Lessons from law-enforcement tech, healthcare, and a kitchen-table art business.

Not every problem needs AI or machine learning. I say that as someone who loves AI, teaches teams how to use it, and has built products where it is the secret sauce. But I have also spent years in environments where accuracy, timing, and compliance matter more than novelty: government systems at REJIS, healthcare at Magellan and Centene, and a handful of startups including my own art businesses. In those worlds, the fastest way to waste time and money is to start with a model instead of a problem.

Here is the process I use to decide if ML belongs at all, and, if it does, how to frame it so the business actually wins.

1) Write the Problem in Plain Language

In the late 90s, I took a physics class at the University of Winnipeg. The professor tossed a “quick” problem on the board and later waved it off as “a little bit of work.” Nine pages of math later, I promised myself: if I cannot explain a problem simply, I do not understand it yet.

Practice: Describe your problem in one sentence a fifth-grader would understand.

  • “We keep approving the wrong claims.”
  • “Investigators cannot find the right case in time.”
  • “Shoppers cannot discover the print they will love.”

If you can’t say it plainly, you are not ready for ML.

2) Name the Ideal Business Outcome

Before models, pick the finish line. When I led accessibility and UX work on large healthcare programs, the outcome was not “a better classifier.” It was things like: fewer rejected submissions, faster review cycles, higher member satisfaction, lower cost per task.

Examples:

  • Law Enforcement: “Reduce entry errors by 80 percent and cut lookup time to under one second.”
  • Healthcare MLR: “Shorten review cycles from 5 business days to 3 without lowering quality.”
  • My art shop: “Increase repeat purchases by 20 percent during Q4.”

No metrics yet ? Define the business change you want in the real world.

3) Define Success Metrics (that the business cares about)

Now put numbers on it. I like a simple SMART framing:

  • Specific/Measurable: “Cut average time-to-find from 7.8s to <1.0s.”
  • Attainable/Realistic: Ambitious but credible.
  • Time-bound: “By December 31.”

Add “guardrails” where necessary (compliance, fairness, privacy). In healthcare it’s critical to never ship a “smarter” thing that worsened accessibility or introduced bias (like the pretty new messaging center that was 100% keyboard inaccessible). If your metric could tempt the system to cheat (optimizing clicks while tanking trust), add a counter-metric.

4) Describe the Ideal Output (not just the outcome)

Outcomes are business results. Outputs are what your system will produce on the way there.

Write the output like a sentence the model can complete:

  • “Given a 911 call record, predict the top three likely incident codes.” (ranking/classification)
  • “Given a member’s document type and topic, flag the probability of MLR rejection and explain why.” (classification + explanation)
  • “Given a shopper’s session, recommend three prints they are likely to save or buy.” (recommendation/ranking)

If you cannot state a crisp, machine-readable output, you do not have an ML problem yet , you have a design problem.

5) Inventory the Data you Have (and what you can create fast)

Candidly, data reality kills more ML fantasies than model choice ever will. In public-sector systems we often had CJIS and HIPAA constraints. Sometimes the “perfect” feature was a privacy risk or legally off-limits. Other times the data existed but only in a monthly batch or inside an excel file or scanned PDFs.

Run a brutally honest audit:

  • Historical labels: Do we have past examples of the output we want to predict?
  • Freshness: How often does new data arrive (real-time, hourly, monthly)?
  • Coverage and quality: Enough rows? Systematic gaps? Known errors?
  • Accessibility and governance: Are we allowed to use it? Who approves?

When the answer is “not yet,” instrument the product first. I have green-lit multiple projects where the first 1–2 sprints were event tracking, consistent IDs, and data contracts so the future model would not be starved.

That said, if you want to POC an idea, feel free to make up some realistic data to explore the possibilities before heavily investing in AI/ML development.

6) Respect Timing: When do inputs arrive? When is the decision needed?

Great models delivered too late are failed projects. The state death file, for example, is received monthly by design. If you need a decision now but your best data arrives later, either:

  • Design a two-stage approach (fast rule first, model later to re-score), or
  • Change the problem to one that matches the clock you actually have.

Write it down: “Inputs available every 15 minutes; decision must be returned in <500ms; explanations must be human-readable.”

7) Try to Solve it without ML First

This is my favorite part. When we rebuilt accessibility across a design system, simple rules and guardrails (color contrast tokens, semantic components, preflight checks) got us 80 percent of the win, no models required. In law enforcement systems, carefully designed search, better indexing, and a few decision rules often beat fancy modeling for day-to-day use.

Litmus test: If a clean rule-based approach plus UX improvements meets your success metrics, do that. Save ML for where patterns are real but rules are brittle.

8) If ML Still Makes Sense, Cast it in the Simplest Form First

Resist the siren song of “state of the art.” Start with the gentlest framing that matches your output:

  • Regression: “Predict the time-to-review in hours.”
  • Binary classification: “Will this be rejected? yes/no.”
  • Multiclass classification: “Which incident code?”
  • Ranking/recommendation: “Top 3 items for this user.”
  • Clustering: “Group similar cases for triage.”

In my consulting work, I grew a department’s revenue from ~$1M to $15M in four months not by deploying something on day one, but by asking questions, understanding the company and its users, understanding their customers, reviewing data, setting business-first metrics, and creating a pipeline that included phases of increasing complexity with a human-in-the-loop workflow. The sophistication comes later, once you have proof the loop works, expand on it. This iterative development workflow also allows you to pivot quickly as new advances are available.

A Worked Mini-Example Kitchen Table Edition (okay, lap desk in the living room edition)

Problem (plain): Shoppers cannot find a portrait style they instantly love.
Ideal outcome: Increase Q4 repeat purchases by 20 percent and raise average order value by 10 percent. Success metrics:

  1. Repeat purchase rate: +20 percent by Dec 31.
  2. AOV: +10 percent by Dec 31.
  3. Guardrail: Maintain five-star rating average and on-time shipping.
  • Ideal output: For each session, recommend three prints (size and colorway) most likely to be added to cart.
  • Data: Orders, color selections, device, referrer, search terms, time-to-purchase; limited user history for guests.
  • Timing: Decision needed in less than 300ms on product pages; batch model refresh nightly.
  • Non-ML baseline: Curate bestsellers by season, improve filters (size, palette), add “compare colorways.”
  • ML framing: Start with a simple ranking model using popularity-by-segment plus a naïve content matcher on color palette; upgrade to matrix factorization when we have enough data.
  • Workflow: Show “reason tags” (“Trending for night-sky lovers”), collect one-click feedback, keep a rules escape hatch for holidays and stock.

That is a real-world path that ships, learns, and stays honest about constraints. And one that I can easily modify as I learn more about my customers.

One-Page ML Worksheet

  1. Plain problem statement
    What is going wrong, in one sentence?
  2. Ideal business outcome
    What changes in the real world, for whom, by when?
  3. Success metrics + guardrails
    Primary KPI, target value, date; counter-metrics for quality, fairness, compliance.
  4. Ideal model output
    Exact, machine-readable output the system must produce.
  5. Data reality
    What labels exist? How fresh? Coverage and quality? Legal and privacy constraints?
  6. Timing and SLOs
    When do inputs arrive? How fast must decisions return? Uptime and latency?
  7. Non-ML baseline
    What can good product, rules, and UX achieve today? Ship it first if it wins.
  8. ML formulation (v1)
    Pick the simplest task type. Note training cadence, features, and who reviews outputs.
  9. Human in the loop
    Who corrects mistakes? How is feedback captured? Where do explanations appear?
  10. Rollout and learning plan
    A/B ramp, monitoring, alerts, model health, retraining schedule.

Let’s Wrap it Up

Formulating a machine learning problem isn’t about proving you know models, it’s about proving you know the business, the user, and the constraints, and then choosing the smallest technical hammer that reliably swings the nail.

The wins I am proudest of, from one-second lookups in law enforcement systems to measurable improvements in healthcare review cycles to profitable, human-centered recommendation loops, all started the same way: with a plain sentence, an honest metric, and a ruthless respect for reality, user experience, and accessibility.

You can do a lot with that, sometimes nine pages less work than you think.