See the Friction Before You Choose the Tool
OpenAI’s use-case guide begins with a diagnosis, not a product recommendation: where does work lose time, access to expertise, or momentum? This chapter develops that first lens by separating repetitive low-value work, skill bottlenecks, and ambiguity. The practical result is a better candidate description—one that explains what is getting in the way and what kind of help might matter, without pretending that a workshop idea is already a validated business case.
That distinction is easy to miss. “We should use AI in finance” or “marketing needs an assistant” names a department and a technology, but not a problem. A useful opportunity statement names the work, the friction inside it, the consequence of leaving it unchanged, and the person who can judge whether a proposed result is good enough.
Three kinds of friction, three different diagnoses
The guide groups promising starting points into three forms of workplace difficulty. They can appear in the same job, but they are not interchangeable. Each points to a different mechanism of assistance and a different question about quality.
Repetition consumes attention without adding much judgment
Every job contains manual tasks that are necessary but tedious. The guide gives examples such as summarizing meeting notes, looking for trends in spreadsheet data, generating product-requirements documents, and answering the same questions repeatedly. These activities are not necessarily unimportant; the point is that their repeated execution can draw people away from work that requires more strategy, context, or accountability.
A useful diagnosis asks what the repetition actually consists of. Is someone converting a meeting conversation into a standard summary? Is a person searching the same set of data for a familiar pattern? Is a team rewriting an established message for several audiences? The more stable the input, expected structure, and review standard, the clearer the candidate for assistance becomes. But “repetitive” does not mean “safe to hand over.” A summary can omit a commitment, a spreadsheet trend can be misread, and a draft requirements document can quietly encode the wrong assumption.
The likely benefit is recovered attention and faster first passes. The remaining responsibility is to inspect the result and own the decision that follows. OpenAI’s “super-assistant” framing is useful precisely because it describes a system that extends a worker’s capacity rather than erasing the need for a worker. An assistant can take on the first transformation of information; a person still needs to decide whether the transformation preserved what matters.
A skill bottleneck makes progress wait for another person
A different symptom appears when work stalls until a specialist or another department can intervene. The guide describes employees reaching the limits of their expertise and waiting for help with data analysis, trend visualization, coding, design, on-brand writing, or web development. The delay is not caused by repetition. It is caused by a dependency between the person who understands the business question and the person who has the technical skill to produce the next artifact.
AI can change that dependency in two ways. It can help the original worker create a rough artifact—an interactive prototype, a SQL query, a visualization, or a draft in the organization’s style. It can also help that worker communicate with the specialist in a more useful vocabulary. In both cases, the first effect is to move the starting line closer to the person who owns the problem.
That shift can improve speed and participation, but it does not make expertise irrelevant. A prototype can expose a product idea sooner while still needing design and engineering review. A generated query can answer a question quickly while still requiring someone to check joins, permissions, and interpretation. The candidate should therefore record not only which bottleneck might be shortened, but also which expert remains responsible for verification. Otherwise, the organization may replace a visible waiting period with an invisible quality problem.
The second-order effect matters as well. If many people can now create preliminary analyses, the scarce resource may move from production to review. That is not a reason to reject the use case; it is a reason to design the handoff explicitly. A good opportunity statement says what the employee can do independently, when specialist review is triggered, and what evidence the reviewer needs to accept or correct the result.
Ambiguity blocks the first move
Ambiguous knowledge work has a third shape. The worker may have data, tools, and authority but still struggle to begin because the problem is open-ended. OpenAI reports teams using AI to brainstorm campaign ideas, inspect raw data for quick insights, analyze trends, and work out next steps when they are unsure what to do.
Here the value is not simply faster repetition or access to a missing skill. AI acts as a catalyst: it offers possible angles, questions, structures, or next actions that give a person something concrete to examine. A marketing team can ask for several campaign directions and use the differences to clarify a brief. A product team can ask what a requirements document leaves unresolved before an executive review. The useful output is often a better starting point, not a final answer.
That difference changes the review question. For a repetitive summary, the reviewer may check completeness and fidelity. For an ambiguous strategy prompt, the reviewer must judge whether the suggestions fit goals, constraints, evidence, and stakeholders. The first draft can be valuable even when none of its proposals is adopted, because it makes assumptions visible. But the guide does not establish that AI suggestions are accurate, safe, or economically superior in every such situation. They remain material for human judgment, not a substitute for it.
Do not confuse the symptom with the intervention
The three categories describe where work is difficult; they do not prescribe one technical remedy. A repetitive task might be handled by a reusable instruction, a conventional script, or an AI-assisted draft. A skill bottleneck might call for training, a better interface, or an AI tool. An ambiguous task might benefit from brainstorming support while still requiring a human decision process. The diagnosis should come before the remedy because the same visible complaint—“this takes too long”—can have different causes.
For example, suppose a team says that producing a weekly customer update is slow. The delay might come from copying information between systems, from disagreement about what the update should contain, from a lack of analysis skill, or from uncertainty about which customers matter most. AI could help with the first three in different ways, but it cannot decide the right intervention until the team separates them. Automating a template will not resolve unclear ownership. Generating more prose will not fix missing data.
The diagram’s final step is deliberately not “deploy.” A diagnosis becomes a candidate when the team can describe the work and the proposed assistance clearly enough for someone to investigate it. That candidate still needs evidence about value, effort, data, risk, and fit with existing tools.
Turn lived frustration into a candidate worth testing
OpenAI suggests starting with the people who perform the work. One practical device is an “anti-to-do list”: a record of tasks someone would gladly stop doing because they are tedious, repetitive, or a poor use of attention. Claire Vo of LaunchDarkly described such a list with items including monitoring key performance indicators, tracking competitors, and sharing customer stories and anecdotes over Slack. Her guiding question was simple: when she encounters something annoying, how can she avoid having to do it again?
The value of an anti-to-do list is observational. It captures frequency and frustration that may not appear in a formal process map. It can reveal small tasks repeated across many roles, or a recurring handoff that no one has treated as a project. It is especially useful at the beginning of a workshop or hackathon, when participants need a concrete place to start instead of being asked to imagine “innovative” AI applications from scratch.
But frustration is not proof of impact. A task may be annoying and still have little effect on an important outcome. It may also be annoying because the organization has not agreed on a policy, because the source data is unreliable, or because a control is intentionally slowing a risky action. The list should generate questions, not settle them. Ask how often the task occurs, what it delays, who depends on the result, what happens when the result is wrong, and whether a trusted tool already performs part of it.
Team workshops and hackathons widen the search beyond one person’s routine. OpenAI recommends asking employees to identify situations where they spend time on manual work, wait for another team’s skills, or struggle to get started. A finance example from Fanatics Betting and Gaming describes an AI automation task force asking finance employees to detail processes that might benefit from AI, then using the responses to create a project roadmap. The mechanism is organizational visibility: local knowledge is gathered into a shared set of possibilities that leaders can compare and support.
A workshop can also reveal disagreement, which is useful evidence. One employee may describe a process as routine; another may know that its exceptions consume most of the time. A manager may value faster reporting, while a compliance reviewer cares more about traceability. Recording these differences prevents a polished idea from hiding the conditions under which it would succeed or fail.
A candidate record need not become a large inventory. It should be specific enough to support the next decision. At minimum, capture:
- the task and its trigger;
- the inputs available and the output expected;
- the dominant friction—repetition, dependency, ambiguity, or a combination;
- the downstream decision or workflow affected;
- the person who can review the result and the failure that review must catch; and
- any existing tool, permission, data-quality issue, or policy that constrains the idea.
This is still discovery, not validation. It does not establish a return on investment, demonstrate model accuracy, or prove that employees will adopt the result. It makes the claim smaller and therefore more testable: “If this system can transform these inputs into this reviewed output under these conditions, it may reduce this particular source of delay.”
The distinction is important when customer stories are used for inspiration. OpenAI’s use-case guide reports that Promega saved 135 hours in its first six months using ChatGPT for first-draft email campaigns, and describes teams at other companies using AI for prototypes, analyses, or focus-group simulations. These accounts can show what a candidate looks like in practice, but they are OpenAI-selected customer stories, not independent audits. Their value is illustrative: they help a team imagine a mechanism, while local evidence must establish whether the mechanism transfers.
A disciplined discovery conversation therefore ends with a question about verification. If the candidate concerns meeting summaries, what would a responsible owner check before the summary becomes a record? If it concerns a prototype, which expert decides whether it is technically or visually sound? If it concerns brainstorming, which goals and constraints determine whether an idea is worth pursuing? These questions do not slow discovery; they prevent the organization from confusing an attractive output with a useful outcome.
The three frictions also interact. A task can be repetitive for an expert but ambiguous for a new employee. A skill bottleneck can create repetition when specialists must answer the same basic request. Ambiguity can generate a queue if every uncertain question is escalated to a manager. Naming the dominant friction is still useful, but the team should note the secondary one because it may determine the eventual workflow design and review burden.
The payoff of this lens is modest but foundational. Instead of starting with “What can this AI product do?”, a team can start with “Where does this work lose attention, expertise, or momentum, and what would a good result need to preserve?” That question produces candidates grounded in actual work. The next challenge is to describe the kind of assistance each candidate needs in a shared language, so that different ideas can be compared without flattening their differences.