AI Made Building Cheap. It Made Judgment Expensive.

I built an initial per-drug pipeline that reduced a custom dashboard workflow from four to eight weeks of analyst work to roughly 45 seconds.

It generated an authenticated dashboard with light customization and let us respond to requests much faster. It also made one-off variations cheap enough to approve without much scrutiny. We gave customers slightly different cuts of the same product while learning little about which versions deserved to exist.

The queue moved faster. Our understanding of the problem did not.

I already knew what that mistake could cost.

An earlier dashboard project at a massive health system cost roughly $2 million to build. Its first iteration pulled together information that users had been assembling manually for years from several Excel files pulled from a clunky EHR reporting interface. It showed performance, comparisons, and the descriptive signals people had requested.

Users still faced a wall of interpretation. The dashboard did not prioritize what deserved attention, recommend what to do next, or explain the workflow context behind the numbers. They still had to gather anecdotes and reconcile several signals before they could act.

The first version went unused. We spent roughly another year redesigning it, and the product eventually became valuable. We lost the first year because we built the requested information before we understood the decision it needed to support.

AI makes that sequence easier to repeat. A team can now produce a plausible dashboard, workflow, or prototype before it has earned confidence in the problem. Execution gets cheaper while weak judgment gets more expensive.

Speed moves the work upstream

AI removes friction from SQL, requirements, documentation, design, and code. That creates real capacity. It also removes the natural pause that once forced a team to defend a request before spending weeks on it.

Hilary Gridley described the same shift at Whoop. Product managers could turn ideas into prototypes in an afternoon, but the team had no consistent way to decide which prototypes should advance, die, or teach them something useful. Faster prototyping overwhelmed the decision process around it. Read Gridley's account in Every.

A faster build system forces a team to choose more often. It must decide which problem deserves attention, whose behavior should change, what evidence earns more investment, and what result stops the work. Without a decision system, speed creates more artifacts to maintain.

A request arrives downstream of the real need

Most dashboard requests already contain a solution. Someone asks for a filter, a metric, an AI summary, or a new view. The team receives the request as a requirement and starts working down the implementation tree.

Jason Gorman treats product choices as a decision tree. Teams move down by asking how to implement a choice, sideways by comparing alternatives, and up by asking why the choice exists. Moving up recovers the purpose hidden inside an apparent requirement. Read Gorman's decision-tree explanation.

For the $2 million dashboard, the request lived several levels below the real work. Users asked for descriptive signals and customer comparisons. The team needed to ask what those people were trying to decide, why recurring ad hoc questions existed, and what prevented action inside their workflow.

Moving up opens other solutions. The team might need a recommendation, service, workflow change, alert, clearer ownership, or no new product at all.

A request is evidence. It is not yet a requirement.

Find value before choosing the product

Healthcare data products often serve two people with different incentives. One uses the output. Another controls the budget. A clinically useful view can fail if the buyer has no urgent reason to fund it. A buyer can also demand a polished dashboard that adds work for the user.

Rob Snyder's PULL framework offers an upstream test: identify the person's Project, why it is Unavoidable now, the List of options already available, and the Limitations of those options. A product earns attention when it helps a real person complete an urgent project that current options cannot handle. Read Snyder's PULL Quickstart Guide.

For a healthcare data leader, use these five discovery prompts before choosing the product form:

1. What is the user trying to accomplish in a real workflow?
2. Why does the work need to change now?
3. Which alternatives do they use today?
4. Where do those alternatives fail?
5. Who uses the solution, who buys it, and what does each person value?

Those answers establish a value hypothesis. Data evidence determines whether it holds.

The Value-and-Evidence Gate

I use a Value-and-Evidence Gate to join product judgment with data discipline before a team funds the build.

This is a funding gate. It does not replace privacy, security, clinical-safety, or data-governance review.

The value side identifies an urgent project, the user, the buyer, and the action that should change. The evidence side defines the signals, thresholds, context, and feedback loop that will show whether the change produced value.

The discovery prompts above become a funding record in the gate below.

Execution can take 45 seconds. The gate determines whether the work earns another cycle.

The team leaves the gate with one of three calls.

• Fund the build when the project is urgent, the user and buyer are clear, and the evidence plan can distinguish value from activity.
• Run a smaller test when the value looks plausible but the evidence remains weak.
• Stop when nobody owns the decision, urgency is missing, or the team cannot name a result that would change its plan.

This gate would have changed both dashboard stories. The $2 million product needed a clear action and feedback loop before the team built the descriptive layer. The 45-second pipeline needed a stronger threshold for approving variations after production became cheap.

Make evidence part of the product

Data teams often produce evidence for other people. Product teams test value during discovery. AI-enabled products need both disciplines throughout the lifecycle.

Before building, the team needs evidence that the problem is urgent and current options fail. During a test, it needs evidence that users can act on the output. After release, it needs evidence that behavior and outcomes changed. Qualitative context belongs beside the metrics because a clean utilization number rarely explains why someone trusted, ignored, or worked around a product.

This changes the definition of speed. A team that ships in a day and waits six months to learn that nobody changed behavior moved slowly. A team that tests its riskiest assumption in a week preserves more time and money, even when production takes longer.

An AI workflow should shorten the distance between a decision and trustworthy feedback. It should not maximize the number of things a team can generate.

What I help teams build

Through DPOS, I help small healthcare data teams put this decision layer into practice. My earlier piece on the dashboard factory pattern shows the operating failure this addresses. My guide to healthcare data governance in the agent era covers the governed data layer beneath it.

AI gives data teams more capacity to build. Leaders have to spend it on work that changes a decision and produces evidence of value.

Build the 45-second dashboard after you can name the decision, the buyer, and the evidence. Otherwise, you have made waste cheaper.