DesigningROI

Worked Example

This walkthrough follows a hypothetical team through the DesigningROI framework. It shows how the evidence assessment determines which phase to investigate first — and why the answer depends on what you already know, not just how the work started.

Start A business goal — “Increase sales 10%.”

The team has a revenue target from leadership but no prescribed solution. In most frameworks, this would immediately route to problem-definition work. DesigningROI does not assume that. It asks what evidence already exists.

The value argument

Every product investment rests on a chain of claims. The team maps what they already know to each element.

Human Need justifies Proposed Solution changes? User Behavior contributes to? Business Result
Customer need Existing customers struggle to reorder. Support tickets confirm friction in the reorder flow, and funnel data shows that customers encountering it abandon reorders at a higher rate. Supported
Solution hypothesis The team hypothesized that reducing reorder friction would increase completed reorders and repeat-purchase revenue. Prototype testing showed returning customers could reorder with fewer steps and fewer errors. The redesign shipped two months ago. Supported
Observed change No structured measurement is in place. The team does not know whether reorder behavior actually changed. Gap
Meaning of the results Without outcome data, the team cannot assess whether the redesign contributed to the sales goal or whether something else explains current numbers. Gap

Two parts of the argument have evidence behind them. Two do not. The tool will walk the connections in order to find where to start.

Diagnostic

The tool walks each connection in dependency order, asking whether evidence supports it.

✓ Evidence of a customer need the product could address
✓ A testable hypothesis linking product change to user behavior and sales
✗ Measured what changed when the solution was put into use — start with Observe

The need is supported and the hypothesis is testable, but the expected changes have not been measured. The tool routes directly to Observe.

Route

Frame Change Observe Interpret

A business goal routed to Observe, not Frame. The team already understands the problem and built a solution. What they lack is evidence of what happened next.

Phase work: Observe

The Observe phase asks the team to record what actually changed after the solution was introduced.

Create a record of observed changes.

The team instruments the reorder flow, compares customers exposed to the redesign with a comparable cohort, and checks for promotions, seasonality, and other changes that could explain the numbers. They find: reorder completion rate increased 18%, support tickets about reordering dropped 40%, and repeat-purchase revenue increased 2% — but overall sales growth reached only 3%, well below the 10% target.

Decision

With observed results in hand, the team reaches the phase decision.

Is the record complete enough to interpret?

Gather more evidence The record is not complete yet
Interpret the evidence The record is complete enough

The team has evidence now: reorder behavior improved, but the evidence suggests that the redesign explains only a small portion of the desired sales growth. They choose “Interpret the evidence” to assess what the data actually supports. The framework advances to the Interpret phase.

Phase work: Interpret

Frame Change Observe Interpret

The Interpret phase asks what the observed changes mean for the investment.

Create an evidence-based value assessment.

The team assesses what they learned. Reorder completion improved 18%, support tickets dropped 40%, and repeat-purchase revenue rose 2%. The results are consistent with the redesign contributing to repeat-purchase revenue, but the overall sales growth of 3% falls far short of the 10% target. The redesign improved reorder conversion, but the evidence does not support treating it as the primary mechanism for a 10% sales increase.

Decision

With the value assessment complete, the team reaches the Interpret phase decision.

What decision does the evidence support?

Reconsider the need The evidence challenges the original problem
Revise the hypothesis The evidence suggests a different approach
Gather additional evidence Need more data to decide
Make the decision The evidence is sufficient to act on

The team selects “Make the decision.” The evidence is sufficient: the redesign improved reorder conversion, but it does not explain the full sales target. Continuing to gather evidence or revising the hypothesis would not change this conclusion.

Investment decision

The redesign reduced reorder friction, and repeat-purchase revenue rose 2% among customers exposed to it. But the evidence does not show that this mechanism can produce the full 10% sales increase. Continue optimizing the reorder flow as a reorder-conversion initiative, but do not scale it as the primary sales-growth strategy.

The framework produced a specific, evidence-backed conclusion. The diagnostic walked each connection in order: the customer need was supported and the hypothesis was testable, so the tool routed directly to Observe. Observe and Interpret filled the remaining gaps. The investment decision followed from the evidence — not from the starting point, and not from intuition.

In practice

The example above is hypothetical. The same reasoning shaped my work on AI-assisted photo curation for Kodak Alaris. Professional photographers were reviewing thousands of images by hand, and the existing automation gave them no way to correct it. The assumption worth testing was that photographers would hand off decisions to the AI. The evidence pointed the other way. They wanted AI to speed up their own judgment, not replace it. The product became recommendations they could calibrate, override, and reverse, with confidence signals showing how sure the system was. Review time dropped from about 18.5 hours to about 1 hour per project. Read the case study →