Constructing an Opportunity-Solution Tree for Logistics Workflows

Hello! Last lesson, you identified beliefs that the proposed customs-filing integration depends on—especially whether manufacturer information causes delays and whether source systems can provide useful, timely data. An opportunity-solution tree gives those assumptions a place in a larger decision: which customer need are we trying to address, and what other ways might address it?

This is the final lesson in the outcome-led strategy module. You will build a first-pass tree for the hypothetical ISF workflow, starting with a product outcome, branching into customer opportunities, and then comparing solutions and their assumptions. The aim is a usable discovery map, not a polished diagram that makes uncertain claims look settled.

See what each part of the tree is for

An opportunity-solution tree keeps four different questions from collapsing into “Should we build the integration?”

• Outcome: What result are we trying to improve?
• Opportunities: What unmet needs, pains, or desires might stand between customers and that result?
• Solutions: What could we offer to address a chosen opportunity?
• Assumption tests: What do we need to learn to judge the competing solutions?

Watch Teresa Torres explain the distinction between the opportunity and solution spaces. Her example uses entertainment rather than logistics; pay attention to how the customer’s journey organizes the opportunities.

The diagram below shows the layout: one desired outcome sits above branching opportunities; solutions and their assumption tests appear beneath a selected opportunity. The branches are possible paths to investigate, not a claim that every branch works.

Product Talk’s Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes provides the definitions you will use while building your own.

Put an outcome—not an integration—at the top

For our continuing hypothetical case, a useful root is:

Increase the proportion of in-scope ISF drafts that are supportable and ready for internal review by the cutoff.

“Supportable” needs an operational definition. For this working tree, it means required values have identifiable supporting sources and known conflicts have been resolved or explicitly handled for review. The team would still need to agree on eligibility, a baseline, and a target before using the measure to judge progress.

This is a product outcome: it concerns the value delivered in the filing workflow. “Launch a source-system integration” is an output, and “increase integration usage” measures traction for one possible feature. Customer retention might be a downstream business impact, but this tree should not assume that faster, more supportable drafts will necessarily improve retention.

Recall the illustrative finding that 31 of 120 drafts were paused. It makes draft readiness worth investigating; it does not establish how many were paused because of manufacturer information. Placing an outcome at the top prevents that unproven explanation—or the proposed connection—from becoming the tree’s starting fact.

Map needs before choosing a remedy

A filing specialist’s work has distinct moments: gathering required facts, reconciling information from different sources, and obtaining review before the cutoff. Each moment could contain an opportunity. The opportunity is the customer’s difficulty in that moment, not the feature you intend to deliver.

Compare these formulations:

“Specialists need an API connection to manufacturer data.”

“While assembling an ISF draft, specialists cannot tell which of two conflicting manufacturer values they can support before the cutoff.”

The first specifies a solution. The second names a person, moment, and unmet need. It leaves room for several responses: better source visibility, a comparison workflow, or a timely decision from someone authorized to resolve the conflict. That room for alternatives is a practical check on whether you have written an opportunity rather than a solution in disguise.

Evidence matters here. We have not been given a specialist’s account of a recent conflicting-value case or a breakdown of pause reasons. The opportunities in the tree below are therefore hypotheses to investigate, not customer findings. Product Talk recommends building and revising the opportunity space from specific customer stories rather than generating needs solely from team intuition. The next module will develop that discovery work.

Before assembling the example, read the practical portions of the same guide. Notice the change in focus: compare opportunities before evaluating the effort of particular solutions.

Build a focused first-pass tree

Here is a working tree, using the ISF case. Indentation shows which opportunities sit under a broader need and which solutions compete to address the selected, narrower opportunity.

• Desired outcome: Increase the proportion of in-scope ISF drafts that are supportable and ready for internal review by the cutoff.
  • Opportunity during input gathering: Filing specialists cannot obtain required shipment facts early enough to prepare the draft.
  • Opportunity during fact reconciliation: Filing specialists cannot resolve source discrepancies confidently while assembling the draft.
    • Target sub-opportunity: When two manufacturer values conflict, a specialist cannot determine which value can be supported before the cutoff.
      • Solution A — Source-system connection: Retrieve manufacturer values with their sources and flag disagreements in the draft.
        • Assumption to examine: Authorized source systems provide attributable values early enough to help the specialist.
        • Possible check: Inspect permitted sample records and connection responses for source information and timing.
      • Solution B — Export comparison: Let a specialist place existing source exports side by side and record the evidence for the chosen value.
        • Assumption to examine: The necessary exports are available and interpretable within the available time.
        • Possible check: Walk through a recent, suitably sanitized discrepancy using the exports specialists actually have.
      • Solution C — Discrepancy review handoff: Route the conflicting values and supporting evidence to a designated reviewer.
        • Assumption to examine: A reviewer can give a usable decision before the cutoff.
        • Possible check: Trace the handoff in a representative case, including reviewer availability and decision time.
  • Opportunity during final review: Specialists cannot obtain a review decision before the cutoff when a draft is otherwise ready.

The parent–child relationship is deliberate. “Cannot resolve source discrepancies” is broader than the specific manufacturer-value conflict beneath it. Input gathering and final review remain visible as alternative areas to investigate, but they do not need solution branches yet. Focusing solution exploration on one target opportunity keeps the tree from becoming a catalogue of unrelated feature ideas.

Why target the manufacturer-value conflict? It connects to the earlier integration proposal and could plausibly affect supportable drafts. That is a reason to investigate, not proof it is the highest-value opportunity. Before committing, you would look for its frequency, its effect on the cutoff, customers’ current workarounds, and how it compares with the other branches. A large number of paused drafts alone cannot rank those opportunities without knowing their causes.

The three solutions also expose a useful trade-off. A connection might reduce manual retrieval but depend on accessible, trustworthy source data. Export comparison may require less integration work but more specialist effort. A review handoff may help when evidence is ambiguous but depends on timely human decisions. Solution effort belongs in this comparison, not in the initial judgment that the customer need is unimportant.

Keep the tree honest as evidence arrives

Last lesson’s assumption map identified a more basic uncertainty: Do missing or conflicting manufacturer values explain a meaningful share of preventable pauses for the target customers? That question concerns whether this opportunity branch merits attention at all. Examine pause reasons and recent customer cases before interpreting a successful technical check as evidence that the integration solves a significant problem.

The checks attached to solutions answer narrower questions. An API response with source information could support Solution A’s feasibility; it would not show that specialists trust the display, resolve conflicts correctly, or get more drafts ready by the cutoff. Likewise, an export walkthrough might reveal effort without proving that Solution B improves the product outcome. Keep each piece of evidence attached to the claim it actually addresses.

A useful tree changes when the evidence changes. If recent cases show that manufacturer conflicts are rare but late input gathering is common, shift attention to the gathering branch. If the conflict is important but source systems cannot provide attributable values in time, retain the opportunity and reconsider the solutions. If one approach looks promising, investigate its remaining assumptions before treating it as delivery-ready. The tree’s value is that you can revise one branch or connection without losing sight of the desired outcome.

Takeaway

To construct an opportunity-solution tree, begin with a measurable product outcome; organize specific customer needs by where they arise in the workflow; choose one promising opportunity; compare multiple ways to address it; and attach the assumptions that could change your decision. In the ISF example, the proposed integration is one solution beneath a hypothesized customer need, not the root of the tree or a proven answer.

You now have a first-pass strategy map, with its evidence gaps visible. The next module begins customer discovery: you will learn to write a non-leading interview guide that can uncover what actually happens in filing workflows and improve—or overturn—the opportunity branches drawn here.