Choose What to Scale, Not Just What to Demo
OpenAI’s use-case guide treats prioritization as the necessary response to a successful discovery process: once employees learn to spot AI opportunities, the list grows faster than an organization can responsibly build them. This chapter focuses on the guide’s Impact/Effort Framework, a simple way to distinguish momentum-building experiments from initiatives that deserve wider investment. The framework is useful only when “impact” and “effort” remain judgments grounded in scope, evidence, existing tools, and risk—not numbers that create a false sense of precision.
A demonstration answers, “Can this system produce an interesting result?” A portfolio decision asks, “Is this result valuable enough, repeatable enough, and feasible enough to justify attention at the intended scale?” Those are different tests. Treating them as one is how a company ends up scaling a novelty while neglecting a small change that would remove a recurring bottleneck.
What the matrix actually measures
The guide’s two dimensions are company value and the effort required to make a use case useful. Impact is not simply how impressive an output looks. It can involve the number of people or processes affected, the importance of the business outcome, the cost of delay, or the possibility of enabling work that was previously too slow. Effort is not just the time to write a prompt. It can include preparing data, integrating systems, testing behavior, training users, securing access, and maintaining the result as the workflow changes.
OpenAI presents four decision zones. They describe different forms of ownership and timing rather than four permanent classes.
High ROI focus: build momentum where value and feasibility meet
High-impact, low-effort opportunities are the guide’s preferred starting point for building momentum. They may produce a strong return without requiring a large program. A recurring report that can be prepared from stable inputs, a first draft that consistently saves a team time, or a small assistant that removes a common access barrier might belong here.
The attraction is not merely speed. A bounded success can give users a reason to adopt the practice, provide evidence about actual quality, and expose the next constraint. It can also teach the organization what review, data, and ownership look like before a larger investment is attempted. But “low effort” should be measured against the intended outcome. A quick prototype is not a low-effort production workflow if it lacks permissions, reliable inputs, or a person who can check its result.
Self-service: small scope can be the right scope
The guide describes self-service projects as low-effort solutions that a single user might create as a personal assistant for a particular task. Many begin locally and later prove useful across a team. This zone is valuable because the person closest to the work can test an idea without waiting for a central project to be approved.
Self-service is not a lesser version of enterprise work. Its success criterion is different.