--- name: use-case-portfolio description: Choose what to fund, test or build first among AI and workflow opportunities. Use for investment recommendations, pilot selection, use-case portfolios, shared-capability decisions and sequencing work against available delivery and operating capacity. license: MIT --- # Use-case portfolio Turn a collection of ideas into an investment view of how the enterprise could work differently. A useful portfolio explains what each opportunity changes, why it matters, how the opportunities relate, and which commitment should come next. Use the customer's existing library and format when they help; choose the representation around the decision rather than forcing every engagement into a common schema. ## Develop opportunities before scoring them Describe the changed operation with enough substance to assess it. Identify the person or service being enabled, the recurring situation, the judgment or coordination involved, the actions that reach an outcome and the value mechanism. “AI for procurement” is an area to explore. A service that interprets a supply disruption, constructs feasible substitution plans and coordinates the accepted change across purchasing, engineering and production is a candidate capability. Separate an opportunity from its component features. Document extraction, search, drafting and case routing might be parts of one valuable service. Conversely, two ideas called “customer assistant” can be different investments because their business decisions, users and operating environments differ. Merge overlaps without erasing these distinctions. Develop promising ideas beyond what people happened to request. Look for work currently omitted, offered only to selected customers, performed too late or restricted by scarce expertise. Use discovery and current capability exploration to form stronger options. Keep the difference between an interview finding and the solution you propose clear in the working material; avoid making provenance labels the portfolio's organizing concept. ## Understand the portfolio as a system Map dependencies at the level that changes a choice. Several opportunities may share customer identity, a maintained domain view, an action interface or an evaluation capability. Another may need a distinct permission, specialist or operational owner. Distinguish a genuine prerequisite from a convenient implementation sequence: an offline experiment can often use representative records before a production integration is complete. Consider investment bundles. A shared capability can be worthwhile because it unlocks several valuable workflows even when its standalone score is low. Equally, do not fund a broad platform on the promise of hypothetical future reuse. Identify the first consumers and what variation the shared component must support. Count shared costs and overlapping benefits once. Examine capacity where work will accumulate. A portfolio of individually attractive assistants can create an unaffordable queue of human review or overwhelm the same integration team. An opportunity with modest direct savings may release the expert capacity that makes a larger service possible. Sequence against these constraints, not just nominal benefit-to-effort ratios. For example, claims triage has the larger projected benefit, while renewal preparation has demonstrated useful behavior and an agreed campaign deadline. Both need customer identity data, and the source team can support only one interface build this quarter. Claims triage still has untested exception handling. Allocate the build to renewal preparation and run a bounded claims experiment on representative records; defer the claims production commitment until that uncertainty is resolved. The forgone claims benefit is visible, but funding two builds would promise capacity that does not exist. Reverse the sequence if the campaign moves and the claims experiment establishes a stronger deployable case. A shared interface changes the constraint only if its identity semantics and support effort serve both workflows. ## Make a choice the business can understand Begin with the objective and the available commitment: growth, service quality, scarce capacity, cost, speed, resilience or another concrete outcome. Compare the credible opportunities on the dimensions that distinguish them. Develop enough architecture and economics to avoid comparing a vague ambition with a fully costed narrow solution. Keep different decisions separate. Selecting an experiment is a decision about the value of learning. Selecting a deployment is a decision about a useful operating capability. Funding shared infrastructure is a decision about several deployments and their ongoing costs. The most uncertain opportunity may be the best experiment without being the next production commitment. Use numbers where they illuminate a tradeoff. Estimates, ranges and explicit scenarios can support a decision before all inputs are measured. When preference weights are consequential, make their basis visible and show whether plausible changes reverse the choice. A qualitative comparison is better than an elaborate score built from arbitrary scales. A ranking is a tool for judgment, not the conclusion by itself. When several attractive options compete for shared resources, [the constrained-allocation example](references/constrained-allocation.md) shows how a small program can reconcile shared costs, delivery time and ongoing review capacity. It also separates the production choice from a useful experiment and identifies what would reverse the sequence. Recommend a coherent program: what to pursue, what to learn, what to combine, what to defer and what to stop. For the first deployment, preserve the defining mechanism of the larger opportunity and cross the enterprise seams that could defeat it. Choosing only the easiest adjacent automation can spend the first budget without establishing whether the valuable concept works. ## Keep the portfolio useful as the work changes Update the investment view when a capability experiment, customer response, integration finding or operational result changes it. Explain the consequence: a native product feature may collapse build effort, a shared domain service may enable a second workflow, or review burden may make expansion unattractive. Preserve the reasoning behind changed choices without creating a new reporting ritual. Deliver a library, investment comparison, roadmap or interactive portfolio suited to the user's task. Let a decision-maker inspect the changed work, economic mechanism, dependencies and recommendation. Keep technical detail and source material accessible behind that view. A portfolio succeeds when it directs resources toward a more valuable operation, not when every cell is populated.