The decision product operating model: How to build AI that actually runs the business

I’ve spent the last two decades building AI systems in environments where “mostly right” isn’t good enough — online security, search, financial risk, supply chains and now product development in CPG.

Across all of it, the pattern is consistent:

Most teams don’t need more AI-generated content. They need better decisions — faster, more consistent and safely repeatable under real constraints.

That’s the difference between an AI demo and an AI product that changes how an industry operates.

A decision product is not a chatbot bolted onto a workflow. It’s a system that takes messy reality — partial data, conflicting priorities, human heuristics, business constraints — and produces actionable choices with:

• Explicit guardrails and constraints (what must be true)
• Measurable outcomes and feedback loops (did it work?)
• Auditability (“why this decision, with what evidence”)
• Clear escalation boundaries (what the system can do vs. what requires approval)

To make this practical across non-tech industries — manufacturing, insurance, healthcare ops, retail, supply chain, CPG — I use what I call the Decision Product Operating Model (DPOM): a mode-based way to choose autonomy, capture SME expertise and scale decision quality without taking on unnecessary risk.

Step 1: Choose the mode before you choose the model

When teams say “we’re building agents,” I pull them back to the first-order product decision:

What mode are you shipping? Autonomy is a product decision before it’s a technical decision.

Mode 1: Manual / Traditional

Humans do the thinking. The product coordinates: data entry, approvals, reporting, dashboards.

Manual is often correct for:

• High-stakes, low-frequency decisions
• Unclear policies (“we’ll know it when we see it”)
• Low reversibility (you can’t undo the action without damage)

Manual breaks down when decision frequency rises — or when outcomes depend on a few people who carry the playbook in their heads.

Mode 2: Assistive (Copilot)

The system proposes options, highlights trade-offs, drafts recommendations and speeds up expert work.

This is where most AI products land — and it can be valuable. But it’s also where many teams accidentally ship persuasive noise.

The failure mode is predictable: users either over-rely on the system or ignore it entirely. That “use/misuse/disuse/abuse” pattern has been studied for decades in human-automation systems and shows up quickly when automation isn’t designed for the actual operating context.

A real copilot doesn’t just generate text. It narrows the decision space using real constraints, communicates uncertainty honestly and makes correction cheap.

Mode 3: Agentic (Autopilot)

The system takes actions: triggers workflows, executes changes, runs checks, routes exceptions — within policy.

Agentic creates a compounding advantage when decisions are:

• Frequent
• Time-sensitive
• Reversible
• Governed by clear rules and thresholds

But agentic is not a branding choice. It’s an operational contract. If the system acts, you need permissions, monitoring, rollback and accountability.

Step 2: Treat SME expertise as a product asset, not “feedback”

Here’s what separates companies that “use AI” from companies that win with AI in non-tech industries:

The model is rarely the moat.

The moat is operationalized expertise.

Every successful decision product I’ve built — or watched succeed — treats SME knowledge as a first-class product artifact, not a collection of tribal tips.

SMEs supply the policy layer that makes decisions safe and repeatable:

• Hard constraints: “Never exceed X.” “Must meet Y spec.”
• Soft preferences: “Prefer A unless B.”
• Escalation triggers: “If variance > threshold, route to QA.”
• Exception playbooks: “When supplier changes, run these checks.”
• Acceptance tests: “This is what ‘good’ looks like.”
• Rollback: “If this goes wrong, here’s how we unwind it safely.”

This is where decision products are born: not in prompting, but in translating judgment into policy, guardrails and measurable tests.

In domains like supply chain or CPG R&D, the decision isn’t a neat closed-form optimization problem. It’s a trade-off across constraints — cost, quality, service levels, regulatory boundaries, sensory performance, variability, supply risk — under imperfect data. If constraints aren’t explicit, the product can’t be trusted. If it can’t be trusted, it won’t be used. And if it isn’t used consistently, it can’t improve.

Step 3: Let user expertise determine the default experience

One of the biggest mistakes I see is designing one “AI experience” for everyone.

In non-tech industries, teams are mixed: a few deep SMEs, many capable operators and leadership demanding speed. Your product must scale expertise without pretending everyone is an expert — or that the AI is.

Novices need a translated mental model

Novices don’t need more features. They need the product to translate intent into structure.

In many industries, people don’t naturally talk in “constraints,” “objectives,” and “trade-offs.” They talk in outcomes, rules of thumb and war stories. Great products turn that into:

• Guided flows that translate intent into constraints
• explanations that show trade-offs (not just recommendations)
• Correction loops that are fast and low-friction

Experts need control, not generic suggestions

Experts don’t want a cheerful answer. They want:

• Assumptions and bounds
• Counterfactuals
• Sensitivity (“if cost rises 3%, what breaks?”)
• A precise record of “why”

This is exactly why human-AI interaction design matters. Amershi et al.’s Guidelines for Human-AI Interaction is one of the most usable, practitioner-friendly synthesis of what these systems must do: make status visible, set expectations, support efficient correction and plan for when the system is wrong.

Mixed teams need progressive autonomy

The same decision can — and should — run in different modes depending on role and risk:

• A novice gets guided assistive flows
• An operator gets constrained recommendations with quick correction
• An SME gets full control, diagnostics and policy authoring

This is how you scale decision quality without asking everyone to become a data scientist.

Step 4: Use urgency correctly — reduce ambiguity, don’t add theater

Business urgency is the other major variable, and most teams get it backwards.

When urgency is high, organizations don’t just need speed. They need clarity:

• Fewer meetings
• Fewer debates
• Fewer conflicting spreadsheets
• Fewer “depends”

A weak copilot often increases ambiguity under pressure — because it introduces another opinion without accountability.

Urgency changes the goal

When urgency is low, optimize for trust-building and learning:

• Instrument decisions and outcomes
• Capture exceptions
• Build the SME policy layer
• Prove lift vs. baseline

When urgency is high, optimize for speed with safety:

• Automate reversible steps
• Require approvals for irreversible actions
• Escalate anomalies aggressively
• Make rollback a product feature, not an ops scramble

This is why I’m allergic to “agentic” as a vague aspiration. Under pressure, autonomous theater is worse than manual discipline. The right move is often guarded autonomy — small reversible actions, tight bounds, aggressive escalation.

Step 5: The mode selector that holds up across industries

If you want a rule that works across domains, use DPOM’s mode selector:

Risk × Frequency × Reversibility

• High risk + low reversibility → Manual or Assistive
• Medium risk + reversible actions → Assistive + approvals + automation hooks
• Low risk + high frequency + reversible → Guarded agentic → Agentic

This avoids the two expensive failure modes:

1. Shipping “agents” that require constant babysitting
2. Staying manual while competitors compound speed

The autonomy ladder: How decision products should evolve

The path that consistently works is progressive autonomy:

1. Observe (Instrumented manual+). Capture decisions, outcomes, context. Build the decision dataset.
2. Recommend (Assistive). Provide options and trade-offs. Improve consistency. Make correction effortless.
3. Constrain (Guarded agentic). Execute within SME-defined policy. Escalate anything outside bounds.
4. Delegate (Agentic). Automate routine decisions; humans manage exceptions and evolve policy.

The key is that autonomy is earned, not declared.

And the target isn’t “trust” as a vibe. It’s appropriate reliance — users follow the system when it’s right and override it when it’s wrong. That distinction is central to the classic work by Lee & See on designing automation, so reliance matches capability.

A real-world pattern I’ve seen repeatedly

In every high-stakes domain I’ve worked in — security, risk, supply chain and product development — the inflection point wasn’t a better model. It was turning SME judgment into an executable policy layer.

One common scenario: a team ships “assistive AI” that generates recommendations quickly, but outcomes remain inconsistent because the real rules live in three senior people’s heads. The fix is almost never “prompt harder.” It’s:

• Capture constraints, escalation triggers and exception playbooks
• Instrument reversals (when humans override the system)
• Treat those reversals as the learning signal
• Only then automate small, reversible actions under tight bounds

That’s when the system stops behaving like a suggestion engine and starts behaving like a decision product: fewer meetings, faster decisions and a measurable reduction in exceptions that require senior review.

DPOM toolkit: What I implement in practice

If you want to operationalize DPOM, start with three artifacts and three metrics:

Artifacts

• Mode selector worksheet: Risk × Frequency × Reversibility per decision
• SME policy layer template: constraints, thresholds, escalations, exceptions, acceptance tests, rollback
• Autonomy ladder criteria: explicit gates for moving Observe → Recommend → Constrain → Delegate

Metrics (the executive scoreboard)

1. Time-to-decision (median + P90)
2. Exception rate (% escalated to SMEs)
3. Reversal rate (% overridden by humans after recommendation/action)

Reversal rate is especially powerful because it converts “human disagreement” from politics into a measurable signal the product can learn from.

The question that reveals where to start

If you’re leading AI product strategy in a non-tech industry, here’s the most diagnostic question I know:

What is the highest-frequency decision in your business that still depends on a handful of experts — and what would it take to make it safe, consistent and scalable?

That’s where decision products create compounding advantage.

And it’s how you move from “we added AI” to “we changed the operating system of the business.”

This article is published as part of the Foundry Expert Contributor Network.
Want to join?