Skip to content
NTPU AI Learn

AD 101 · Module 1

Discover the Problem

Starting from your own work, learn to separate problem from solution, spot work friction, and pin down the user, owner, and a measurable outcome.

Start Section 1
  • Duration90 min
  • LevelApplied
  • PrerequisiteAI 101L recommended first
0 / 3 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor

Info

After you join, your completed lesson numbers are sent to your instructor together with your learner code, so they can see your progress. Use the codes your instructor gave you, and do not enter your name, company secrets or other personal data. Progress is kept with the rest of that session's data.

Learning objectives

  • Recognize solution bias and choose a problem statement that names no tool and is observable.
  • Identify opportunity through frequency, waiting, rework, errors, searching, duplicate entry, and judgment load, while being explicit that high friction does not automatically mean AI is needed.
  • Distinguish the user, the process owner, the decision owner, and a measurable outcome.

Problem vs Solution

25 min

Problem vs Solution

Learning objective: Recognize solution bias and choose a problem statement that names no tool and is observable.

Many AI-adoption conversations start with "we should use AI to do X", but that is already a solution, not a problem. Solution bias means assuming a tool or approach before the problem is confirmed. A good problem statement only describes what work outcome is currently unsatisfactory. It names no tool and is observable enough that a third person could check it.

Solution-bias checklist
FieldMeaning
Does it name a tool or technology?Yes -> remove it, keep only the work outcome
Can a third person observe or verify it?No -> add observable evidence
Is it just a wish for how things should be?Yes -> rewrite as the gap actually happening now
Workplace example

A campus office says: "We should use AI to write our meeting minutes." This already assumes a tool (AI) and an approach (writing minutes). Rewritten as a problem statement: "After cross-department meetings, action items take on average three days to become a written record assigned to an owner, and some items get missed." The rewrite names no tool and only describes an observable gap.

  1. Spot the tool words
    Circle any tool, technology, or product name in the sentence (AI, chatbot, system, app) and strip the whole phrase out.
  2. Write the observable gap
    Describe the gap between "now" and "expected" with numbers or verifiable facts: days to process, item counts, error rates, wait time.
  3. Have a third person check it
    Ask a colleague who was not in the discussion to read it and confirm it assumes no solution and still shows a concrete, checkable gap.
Workplace example (contrast case)

A library front desk says: "We should roll out an AI chatbot to answer patron questions." This is also solution bias, it decides on the tool before stating the problem. Rewritten: "During open hours, front-desk staff field the same borrowing-policy question about 40 times a day, and patrons often wait over 10 minutes for a response during peak periods." This version also names no tool and describes a gap that shift logs could verify.

  • A verb like "adopt", "use", or "roll out" followed by a tool or system name is usually a sign of solution bias.
  • Vague adjectives like "should be more efficient" or "should be smarter" cannot be observed or verified by a third person; always press for concrete numbers.
  • An observable gap can usually answer three questions: what is the current number, what is the target, and how big is the gap.
  • A good problem statement can be solved by more than one kind of approach (process change, staffing, tooling), which is itself a sign it was written well.

Info

Human, AI, Human: a person confirms the problem and judgment first, AI assists only after that, and a person verifies and owns the final result.

Warning

Data safety reminder: every exercise in this course uses course-provided synthetic scenarios only, never real institutional or personal data.
Check yourself

Which sentence best fits a problem statement that names no tool and is observable?

Which sentence best fits a problem statement that names no tool and is observable?

Key takeaway: A good problem statement describes what outcome is bad right now, it does not assume which tool will fix it.

Work Friction & Opportunity

30 min

Work Friction & Opportunity

Learning objective: Identify opportunity through frequency, waiting, rework, errors, searching, duplicate entry, and judgment load, while being explicit that high friction does not automatically mean AI is needed.

Work friction is the part of work that consumes time and effort without being the point of the work itself: waiting for approval, re-entering the same data, spending ten minutes searching for a document, or redoing something because of an error. Seven signals of friction are: high frequency, long waiting, frequent rework, error-proneness, searching, duplicate entry, and high judgment load. But a caution: high friction does not automatically mean AI is the answer, it may be a process-design problem that needs fixing before any tool is added.

Seven friction signals
FieldMeaning
FrequencyHow often does this happen?
WaitingIs someone waiting on the result? How long?
ReworkDoes the same thing get done twice?
ErrorsHow often, and what are the consequences?
SearchingHow much time goes into finding data or documents?
Duplicate entryIs the same data typed in twice?
Judgment loadHow much expert judgment does it take?
Workplace example

A registrar's office manually cross-checks course-enrollment data across three systems every term, taking about 16 hours and producing frequent input errors. Friction signals: high frequency (every term), duplicate entry, error-prone. But on closer look, the three systems could simply be integrated, fixing the duplicate data at the source is more fundamental than adding an AI comparison tool first.

  • Frequency: a library manually compiles its overdue-reminder list every day, over 300 times a year, a clear high-frequency signal.
  • Waiting: a purchase request waits an average of 4 days before a reviewer even picks it up, with no visibility into its progress in between.
  • Rework: if more than one in five expense reports gets bounced back for correction, that is a clear rework signal.
  • Errors: manually keying grades into two systems turns up 3-5 mismatches every term, an error signal.
  • Searching: a caseworker spends 20 minutes digging through past files before handling each new complaint, a searching signal.
  • Duplicate entry: the same student's basic information gets typed once on a registration form, once on a payment slip, and once on a roster.
  • Judgment load: every scholarship application needs a caseworker to judge an eligibility edge case by hand, a judgment-load signal.
Workplace example (contrast case: a process problem, not an AI problem)

An inter-library loan request has high friction: it takes an average of 5 days to receive the book. The signal looks like "judgment load", but on closer questioning the real cause is that the courier only runs on Tuesdays and Thursdays, which has nothing to do with the request itself. Here, adjusting the courier schedule is more direct and effective than adopting any AI tool.

Info

Human, AI, Human: a person confirms the problem and judgment first, AI assists only after that, and a person verifies and owns the final result.
Check yourself

A unit finds high friction in its "expense reimbursement" process (5-day approval wait, frequent rejections and refiling). Which judgment is most correct?

A unit finds high friction in its "expense reimbursement" process (5-day approval wait, frequent rejections and refiling). Which judgment is most correct?

Key takeaway: Friction signals point you to something worth exploring, but the next step is always to ask why, not to rush toward a tool.

User, Owner, Outcome

35 min

User, Owner, Outcome

Learning objective: Distinguish the user, the process owner, the decision owner, and a measurable outcome.

A work problem usually involves more than one person: the user is the person who actually does the work or is directly affected; the process owner is responsible for how the whole process runs; the decision owner has authority to approve a change or is accountable for the outcome. These may or may not be the same person. Without separating them, Use Case discussions often talk to the wrong person or miss whoever should actually review it. The desired outcome must be a measurable result, not an activity (e.g. "faster replies", not "use AI to reply").

Four fields, separated
FieldMeaning
UserWho actually does this, or is affected by it?
Process ownerWho is responsible for how the process runs?
Decision ownerWho has authority to approve change, and is accountable?
Desired outcomeWhat is the measurable result (not the activity)?
Workplace example

A department's grade-review request process: the user is the student who files the request and the staff who processes it; the process owner is the department office; the decision owner is the academic dean (final approval on grade changes). The desired outcome is written as "average time from request to reply drops to within 5 business days", not "use AI to auto-reply to students".

  1. List everyone involved
    Write down every person or unit touched by this work first, without sorting them into roles yet.
  2. Mark the user
    Who actually does this work, or directly bears the result, such as a student waiting for a reply?
  3. Mark the process owner and decision owner
    Who runs the process day to day? Who has authority to approve a change and is accountable for the result? These are often not the same person.
  4. Write the outcome as a measurable sentence
    Check that the sentence describes a result (time, count, rate), not which tool got used.

Activity-style wording (drifts from outcome)

  • "Adopt an AI system to assist with grade review."
  • "Start using the new review workflow."
  • "Get everyone trained on the new tool."

Outcome-style wording (fits "desired outcome")

  • "Average grade-review turnaround drops from 9 days to within 5."
  • "Review rejection rate drops from 30% to under 10%."
  • "95% of applicants get a status update within 24 hours of applying."

Info

Human, AI, Human: a person confirms the problem and judgment first, AI assists only after that, and a person verifies and owns the final result.
Check yourself

Which of these best fits how a "desired outcome" should be written?

Which of these best fits how a "desired outcome" should be written?

Key takeaway: Separate the user, process owner, and decision owner first, then write the outcome as something measurable, only then does the Use Case hold up.

Save as PDF

What next?