On July 13, 2024, twenty-four Gangwon Science High School students joined a Working Backwards workshop as part of an AWS office tour and mentoring program. The session received 4.6 out of 5, but the more useful result was seeing students rewrite technology-led ideas in the language of problems they had directly observed.

The Gangwon Science High School AWS Career Insight & Experience Day banner

Begin with a witnessed scene

Student projects often begin with broad topics such as “solve an environmental problem with AI” or “make transportation convenient.” The themes matter, but without a usage scene a team cannot decide what to observe or test.

The first activity temporarily removed the technology. Students wrote recent frictions from classrooms, dormitories, commutes, and club activities. The same phrase—“wasted time”—became different problems once a person, time, and blocked decision were attached.

Observation and interpretation were also separated:

observation: at lunch, students repeatedly search several channels for the menu
interpretation: information is unavailable
hypothesis: one view at the decision moment will shorten choice time

Keeping the observation intact lets a team return to the problem when its first solution is wrong.

Replace praise with refutable questions

Immediate praise can make a first solution feel final. Feedback therefore evaluated the hypothesis through questions:

  • how many times have you seen the scene;
  • what does the person do today;
  • is there a simpler way to reduce the problem without this feature;
  • which customer behavior must change in the demo.

A student presenting artifacts through Listen, Define, Invent, and Refine

The goal was not to make ideas harder. It was to let teams explain the connection between their own observation and proposed solution. A question they could not answer became a research item.

Do not require twenty-four students to move at one speed

When students with different technical experience and presentation confidence share one schedule, fast teams tend to add too many features while slower teams may begin implementation before finishing the problem.

Teams therefore used shared transition conditions rather than identical output:

  • can the first customer be named precisely;
  • are direct observation and assumption separate;
  • can the problem be explained without the solution;
  • has the demo been reduced to one hypothesis.

Teams meeting the condition moved to prototyping. Others refined interview questions or observation scope. Output length could differ while the reasoning behind each transition remained comparable.

A student team presenting its customer problem and solution

Turn an office tour into project questions

An office tour and mentoring session can remain separate career content. Here, students converted descriptions of roles and collaboration into project questions.

“Requirements change in practice” became an FAQ item. “Operators examine several sources during an incident” reopened the usage scene and required data. Career information entered problem definition and architecture assumptions instead of remaining a separate talk.

Leave one small observation after the workshop

A product cannot be completed in one day. Each team instead chose one validation it could perform the next week: ask three classmates about the same scene, measure decision time with a paper prototype, or check whether required data actually existed.

A 4.6 rating describes the session experience, not project continuity. The more durable outcome was moving from “we will build something with AI” to explaining what we observed and what we need to check next in the students’ own words.