Your Prototype Works. But Should Anyone Trust It?

How defining objectives and tradeoffs turns automation into a decision system

Intro

When a product starts recommending decisions, the stakes change. You are no longer shipping features. You are encoding tradeoffs into software.

Until recently, I did not have a clear mental model for how optimization techniques actually apply to product work. Then Tim Varelmann walked me through how a planning prototype evolved into a decision system leadership could stand behind.

In this guest post, he shares:

• Why reducing effort is not the same as improving decisions

• How clarifying objectives, constraints, and tradeoffs reshapes review conversations

• What turns a working prototype into decision infrastructure

Tim’s post

I specialize in mathematical optimization and operations research. My work focuses on turning complex business decisions into systems that can be applied consistently and evaluated clearly.

Most product teams can build a convincing prototype.

What I look for is something else: can the team explain why the system’s recommendations should be trusted?

That question rarely surfaces in early demos. It shows up later, when real money is at stake and leadership wants to understand how decisions are being made.

If you are building tools that recommend actions, allocate resources, or automate decisions, usability is only the starting point. The deeper challenge is proving that your system makes sound decisions across thousands of scenarios, not just in a polished walkthrough.

In my experience, trust does not come from automation alone. It comes from clarity about objectives, constraints, and tradeoffs.

When a Prototype Isn’t Enough

Here is what that looked like in practice.

A global sports fashion brand asked me to review planning software that their product team had already prototyped. On paper, it worked. It automated purchasing decisions and reduced hours of spreadsheet analysis.

When I sat down with the planners, the conversation was not about speed.

It was about judgment.

They walked me through how they actually made decisions. Where they hesitated. Where they bent rules. Where experience filled in gaps the system did not recognize. In decision systems, the hardest problems are rarely about implementing rules. They are about defining how tradeoffs should be resolved.

The goal of the tool was clear: improve when and how supplier orders were committed.

• Commit too early and planners rely on long-term forecasts.

• Commit too late and they miss minimum order quantities and bulk discounts.

The prototype encoded the business rules and generated recommendations. It reduced manual effort.

But something was missing.

The rules allowed bundling items to meet supplier minimums. The system rarely bundled. Planners bundled frequently. They were willing to carry some overstock risk to unlock cost savings. The system was following the rules. It was not reflecting how the business weighed tradeoffs.

As we worked through this together, I asked a simple question: What are we optimizing for? That question slowed the room down.

We rewrote the decision logic in plain language and made three elements explicit:

• Objectives

• Constraints

• Tradeoffs

One tradeoff became central:

• The risk of committing early using uncertain forecasts

• The risk of purchasing without confirmed demand to satisfy supplier minimums

Once that tradeoff was defined, bundling was no longer a planner habit. It became part of the objective. The system bundled whenever it improved the agreed goal.

In the early weeks, planners reviewed the recommendations carefully. When results differed from their own instincts, we examined the reasoning together. The system could show how each decision aligned with the stated objective.

Gradually, the conversation changed. Instead of asking, “Would I have done this?” Planners asked, “Does this reflect the objective we agreed on?” That shift built trust.

When Optimization Becomes Product Infrastructure

This is the point where optimization shows up, not as abstract mathematics, but as a way of structuring decisions.

Optimization allows a system to move beyond applying rules or generating options. It enables the product to consistently choose the best decision based on agreed priorities and real constraints.

In decision-heavy products, this shift matters early. Even in a prototype, three elements shape whether trust can grow.

1. Objectives

What are you truly optimizing for? Cost, risk, availability, or a defined balance? Until this is clear, teams are debating outputs without agreeing on what good looks like.

2. Constraints

Minimum order quantities, lead times, service levels. Some limits are fixed. Others can bend at a cost. Naming that distinction changes how the system behaves.

3. Tradeoffs

Every meaningful decision involves tension. Waiting reduces forecast uncertainty but increases supplier risk. Bundling improves unit economics but increases overstock exposure.

When these elements are clearly defined, optimization becomes a way to apply strategy consistently at scale.

That is what turns a working prototype into a system people can stand behind.

Thank you to Tim

If you build products that recommend, allocate, or automate decisions, Tim’s story highlights something we do not discuss enough:

Trust comes from clarity about tradeoffs.

If you would like to connect with Tim directly, you can find him on LinkedIn or at Bluebird Optimization. If you’d like to talk optimization with Tim, you can book time here.

---

Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.