AI use case discovery is only as good as the frame you put around it. Without a clear North Star, teams will generate ideas that are clever but irrelevant to the business outcomes leadership is trying to move. Without a defined scope, discovery becomes a magnet for every pain point in the enterprise, and the effort collapses under stakeholder sprawl, competing priorities, and inconsistent assumptions. This chapter shows you how to set the “rules of the game” up front so the rest of the playbook moves faster and produces a roadmap that can actually be funded and executed.
The North Star is the outcome your AI portfolio exists to drive, expressed in measurable business terms. Scope is where you will search for use cases and what boundaries apply: domains, processes, users, geographies, systems, and constraints. Together, they do two things at once. They focus creativity on the highest-leverage areas, and they establish shared assumptions about value, feasibility, risk, and timing. When those assumptions are explicit, teams can disagree productively about trade-offs without relitigating fundamentals in every workshop.
3.1 Tie to strategy, value pools, and executive priorities
Most organizations do not need more AI ideas; they need fewer, better ideas that line up with strategy. Your first job is to translate strategy into a small set of measurable outcomes and then define the value pools where AI can plausibly create leverage within your planning horizon. If you cannot draw a straight line from a use case to a strategic outcome and a value pool, it will struggle to survive budget scrutiny and will compete poorly for change capacity.
North Star: a concise statement that specifies (1) the business outcome to improve, (2) the time horizon, and (3) the primary value mechanisms you will use to get there. A strong North Star is not a slogan about technology adoption. It is a statement about business performance. For example, “Improve operating margin by 1–2 points over 18 months by reducing cost-to-serve and loss rates while protecting customer experience” provides direction without predetermining specific solutions.
North Star statement template: “Over [time horizon], we will improve [portfolio KPI] by [value range] by strengthening [two to three value mechanisms] in [in-scope domains]. We will protect [guardrails] and invest in [foundational enablers] required to scale.” Use ranges and plain language. If the statement cannot be understood by a frontline leader, it is too abstract to guide discovery.
Start from the steering metrics leaders already use. Collect the strategic themes, the annual plan targets, and the KPIs that show up in executive operating reviews. Then ask a simple question: where are the biggest gaps between target and current performance, and which gaps are driven by decisions and workflows that could be improved with better prediction, better information access, or faster execution? AI is rarely the strategy; it is a lever inside a strategy. Your North Star should name the gap you intend to close and the primary ways you expect to close it.
Value pool: a portion of the P&L or risk profile where performance improvement translates into material business value. Value pools are useful because they prevent “pet use cases” from taking over discovery. When you anchor on value pools, you can ask, “Which workflows sit on this pool, and where do decisions create leakage?” In most enterprises, the largest pools tend to cluster in revenue (conversion, retention, pricing), cost (labor productivity, rework, external spend), and risk (fraud, credit, compliance losses).
Do not overcomplicate the value pool view at this stage. You are aiming for directional magnitude and ownership, not a full financial model. A practical approach is to build a one-page mapping that links strategy to value pools, KPIs, and candidate domains. Use it as a filter: if a proposed use case cannot attach to one of these mapped outcomes, it is out of scope for this cycle or needs a stronger rationale.
Strategic priority | Value pool | Portfolio KPI | Candidate domains |
Grow net revenue | Conversion and retention | Win rate, churn, CLV | Sales, marketing, customer success |
Reduce cost-to-serve | Productivity and rework | Cost per case, cycle time | Support, operations, back office |
Lower loss rates | Fraud and leakage | Loss rate, leakage rate | Payments, claims, risk operations |
Next, make executive priorities explicit as trade-offs. Leaders may say they want “impact and speed,” but discovery will force choices: near-term wins versus foundational investments, internal productivity versus customer experience, conservative risk posture versus higher autonomy. Capture these as clear prioritization principles, ideally in the sponsor’s own language, and socialize them before workshops begin. When participants know the trade-offs, they bring ideas that fit the moment instead of debating what matters.
Executive priority principles: a small set (typically three to five) of statements that describe what to favor when choices are unavoidable. Examples include “prioritize measurable impact in 90 days,” “favor reuse and shared components over one-off builds,” or “avoid customer-facing generation without grounding in approved sources.” The purpose is not to eliminate debate; it is to ensure debates happen inside agreed boundaries.
Finally, define the portfolio’s intended shape. A North Star does not require a single “best” use case; it requires a coherent portfolio. Most organizations benefit from explicitly balancing three types of work: quick wins that build credibility, foundations that reduce friction and enable reuse, and a small number of bigger bets that justify the program economically. If you do not name this balance early, discovery tends to overproduce one category—usually quick wins—because they are easiest to imagine and easiest to approve.
- Quick wins: narrow use cases with high evidence confidence and short time-to-impact.
- Foundations: shared enablers (data products, platforms, controls) that unlock multiple use cases.
- Big bets: high-value opportunities that require staged investment and significant workflow change.
When 3.1 is done, you should be able to answer one question crisply: “If we execute this AI roadmap well, what will be materially better for the business, and which value pools will show it?” If you cannot answer that in one or two sentences, slow down and fix it. Every hour spent clarifying the North Star will save days of misaligned discovery later.
3.2 Select domains and processes in-scope (and explicitly out-of-scope)
Scope is where strategy becomes operational. Even with a clear North Star, you can still fail by trying to cover too much. “Enterprise-wide discovery” often produces shallow ideas, fragmented ownership, and conflicting constraints. A better goal is focused depth: select a small number of domains where you can go deep enough to understand workflows, data realities, and adoption barriers, while still producing a portfolio with meaningful value and reuse. When in doubt, narrow first; widen once the engine proves itself.
Domain: a business area with shared objectives, data, systems, and accountable leadership (for example, customer support, claims, procurement, sales operations). Process: an end-to-end flow of work and decisions that produces an outcome (for example, resolve a customer issue, adjudicate a claim, approve an invoice, price a quote). Your scope should be set at a level where ownership is unambiguous and measurement is feasible. If a process crosses too many organizational boundaries, you can still include it, but you must define the segment you will work on in this cycle.
Use three filters to select domains. Value concentration: the domain sits on a value pool tied to the North Star and has enough scale to matter. Feasibility: the domain has accessible data and systems, or at least a realistic path to access them within the cycle. Change capacity: the domain leadership can absorb change and has incentives aligned to adopt new ways of working. The third filter is often the deciding factor. A technically feasible use case will still fail if the domain does not have the appetite to change workflows, train people, and enforce new controls.
Once domains are chosen, narrow to processes by looking for repeatability and decision density. AI creates leverage when similar decisions are made repeatedly and when small improvements compound over volume. High-friction processes—those with long cycle times, heavy rework, frequent escalations, or high exception rates—are also good candidates because there is a visible “pain signal” and usually a baseline to measure against.
Be concrete about boundaries. Instead of “customer service,” specify channels and tiers: “live chat and email support for tier-1 products” or “claims intake and triage for auto claims under $10,000.” These boundaries help in three ways. They keep workshops grounded in real workflows. They make data requirements clearer. And they make measurement feasible because you can define cohorts and baselines.
Equally important is what you exclude. People often avoid out-of-scope statements because they fear resistance, but ambiguity is worse. Out-of-scope is how you protect focus, prevent scope creep, and set expectations about what will and will not be evaluated in the current cycle.
Out-of-scope list: a short set of exclusions that clarifies boundaries and provides a “parking lot” for ideas that are valuable but not feasible or not aligned right now.
- Excluded domains: business areas not included in this cycle, with a brief reason.
- Excluded use case types: categories you will not pursue now (for example, fully automated high-stakes decisions).
- Excluded data types: data classes that cannot be used given current privacy or contractual constraints.
- Excluded geographies or segments: regions, products, or tiers outside the discovery and pilot scope.
Translate scope into a single-page artifact that can be shared with every participant. This prevents each workshop from starting with a debate about what the group is allowed to discuss.
Scope canvas: a one-page statement of in-scope domains, in-scope processes, target users, key systems, and explicit exclusions, with the rationale for each boundary.
Finally, operationalize scope with simple tagging. Every idea that enters the backlog should be tagged as in-scope or out-of-scope with a reason. Maintain a visible “parking lot” of out-of-scope ideas and commit to revisiting them in the next quarterly refresh. This is a small step, but it changes behavior: stakeholders feel heard, while your team stays focused on the work you can actually deliver.
3.3 Set constraints: risk appetite, privacy/regulatory guardrails, time horizon
Constraints are the difference between an inspiring backlog and an executable roadmap. They define what is allowed, what is responsible, and what is realistic within a given period. If you do not set constraints early, discovery will drift toward ideas that look great on a slide but collapse when risk, legal, and security partners review them. The goal is not to eliminate ambition. The goal is to make the boundaries explicit so teams design inside them.
Risk appetite: how much downside risk the organization is willing to accept and manage in pursuit of value. Risk appetite should be defined by workflow type, not as a single blanket statement. Many companies are comfortable with employee-facing assistants that summarize documents, but far more cautious about customer-facing generation or automated decisions that affect credit, pricing, or eligibility.
A practical approach is to define tiers for this discovery cycle. Tier 1 (low risk): employee assist with human judgment retained and strong logging. Tier 2 (medium risk): recommendations and bounded automation with controls, monitoring, and exception handling. Tier 3 (high risk): automated decisions in regulated or high-impact contexts, requiring strict governance, validation, and explainability. The exact labels matter less than the shared understanding they create: different tiers imply different design requirements, approval gates, and maturity targets.
Privacy and regulatory guardrails: the non-negotiable rules for data use, processing, retention, and disclosure. In discovery, the most useful lens is data classification and movement. Identify which data types are restricted, where data is allowed to be processed (including third-party services), and what approvals are required to access and use data. For GenAI use cases, common guardrails include limits on sensitive data in prompts, requirements for grounding outputs in approved sources, and restrictions on storing prompts and outputs. For predictive ML, guardrails often emphasize fairness, documentation, and validation standards for certain decision types.
Time horizon: the window in which you expect to show meaningful results and the period you will plan for in the roadmap. The time horizon shapes feasibility. If leadership expects visible impact in 90 days, prioritize use cases that require minimal integration and can be deployed as assistive tools or lightweight augmentations. If you have 12–24 months, you can include foundational investments such as new data products, shared orchestration layers, and stronger monitoring and governance capabilities.
Make constraints usable by capturing them in a short register owned jointly by the program team and risk partners. The register should translate policy into practitioner-friendly guidance: what is prohibited, what is allowed with controls, and what requires special approval.
- Data rules: restricted data types, approved processing environments, retention requirements, and access approval pathways.
- Control requirements: logging, audit trails, human oversight expectations, and red-teaming or validation standards by tier.
- Security requirements: identity, access control, vendor security checks, and incident response expectations.
- Regulatory requirements: disclosure, auditability, and explainability expectations for regulated workflows.
When constraints are clear, they speed up ideation and reduce rework. Participants propose more realistic use cases, solution teams design with the right control patterns, and approval pathways can be planned rather than discovered during delivery. In mature programs, constraints are not a brake; they are the rails that let you move faster safely.
3.4 Agree success metrics, baselines, and decision criteria
North Star and scope tell you what to work on. Success metrics and decision criteria tell you how to judge progress and where to invest. Without them, prioritization becomes subjective, and pilots become arguments about whether results “count.” Your objective is to agree, up front, what will be measured, how it will be measured, and what evidence is sufficient to move from concept to MVP, pilot, and scale.
Success metrics: the KPIs and guardrails that define whether the portfolio and each use case are delivering intended outcomes. Define metrics at two levels. At the portfolio level, select a small set tied to the North Star (for example, cost-to-serve, loss rate, net retention). At the use case level, require a primary KPI, a mechanism metric (the operational lever the AI changes), and guardrails (metrics that prevent harmful optimization, such as compliance exceptions or customer satisfaction).
Baseline: the current performance level against which improvements will be measured. Baselines should be segmented to match scope whenever possible because averages hide reality. For example, handle time differs by channel and case type; fraud rates differ by product and region. If baseline data is imperfect, document the limitation and create a plan to improve measurement as part of the MVP. An imperfect baseline with a clear improvement plan is far better than a precise-sounding number no one trusts.
Agree on the evaluation method early. If an A/B test is feasible, prefer it because it reduces debate. If operational constraints make randomization unrealistic, choose an alternative deliberately: phased rollouts, matched cohorts, or before/after comparisons with seasonality adjustments. Finance and analytics partners should agree to the method so results will be accepted when they arrive.
Decision criteria: the rules used to prioritize use cases and the minimum bar required to pass stage gates. Decision criteria should cover value, feasibility, risk, strategic fit, and evidence strength. Evidence strength is often missing, and its absence causes predictable mistakes: high-value ideas with weak evidence crowd out smaller, more certain opportunities. A simple fix is to include confidence or evidence quality as an explicit dimension in scoring and to require validation plans for assumptions that drive the value model.
Define “ready” standards for stage gates so teams know what must be true before additional investment is approved.
- Ready for MVP: clear use case card, named owners, baseline defined, data access path identified, constraints mapped, and a measurable hypothesis.
- Ready for pilot: MVP improves the mechanism metric, controls are designed for pilot scope, integration plan is defined, and training/change plan exists.
- Ready for scale: pilot demonstrates KPI impact within confidence bounds, monitoring is operational, ownership is established, and run cost is acceptable.
Close by clarifying decision rights. Who decides the portfolio? Who can veto on risk or compliance? Who owns delivery commitments and benefit commitments? When these are unclear, prioritization becomes politics and execution stalls. Make it explicit: the sponsor owns the portfolio call; finance validates value logic; risk and legal validate constraints and controls; technology owns feasibility commitments; and business leaders own benefit realization in operations. Document this division of responsibility as part of the North Star and scope sign-off.
By the end of this chapter, you should have a small set of artifacts that make the rest of discovery dramatically easier: a North Star statement, a strategy-to-value-pool map, an in-scope/out-of-scope scope canvas, a constraints register, and an agreed measurement and decision framework. They are not paperwork. They are how you buy speed, credibility, and alignment for everything that comes next.
