On June 22–23, 2024, the Capital ICT Innovation Square Cloud Job Mastery Challenge brought forty participants to the AWS Seoul office for a two-day program connecting project work with role preparation.

The main problem was not a lack of ideas. Teams often named users, administrators, companies, and job seekers as customers at the same time, causing scope to expand with every conversation. The shared task became choosing one first customer rather than receiving the same feature advice.

Participants at the Capital ICT Innovation Square Cloud Job Mastery Challenge

Turn a broad topic into one scene

Initial statements included broad topics such as “a cloud service for small businesses” and “an AI platform for job seekers.” They could not determine a core feature because both customer and problem were plural.

Each team selected the customer scene it had observed most clearly. It recorded when the person struggled, which information they had, and which decision they could not make.

a platform that is convenient for everyone
→ a junior developer responsible for a first cloud deployment
   cannot explain cost and system state immediately after an incident

The discussion moved from “which feature looks impressive?” to “which information changes this moment?”

A team organizing its Today statement and customer problem

Deferring other customers is also a deliverable

Choosing the first customer does not abandon everyone else. It decides whose problem this iteration will test. Administrator analytics and enterprise permissions can remain important while moving to a separate backlog when the first demo is validating a job seeker’s choice.

Deferred items included the condition that would make the team revisit them. Features not implemented became part of the decision record instead of silently disappearing.

The choice also changed architecture. Real-time pipelines, complex authorization, and multiple cloud integrations could leave the first version when they did not help prove the first customer’s one action. Fewer services were not the goal; each component needed a customer reason.

The demo verified one promise

Teams working through the Working Backwards artifacts

Demo scope was set by a change in customer behavior rather than a number of screens. One path from input through essential processing to a faster or better decision was enough.

The midpoint review checked whether three sentences connected:

  • the customer fails today because of this friction;
  • the service provides this information at this moment;
  • the demo shows the customer making this decision differently.

When the chain broke, the team rewrote the problem or demo instead of adding more features. Presentations followed customer scene → promise → verified flow → remaining risk rather than beginning with an architecture tour.

Replace a technology list with a decision record

Bootcamp projects often become portfolio material. A list of services and features, however, hides which uncertainty the team handled.

The workshop record instead answered:

  • why this customer came first;
  • which observation narrowed the problem;
  • what was removed from the first demo and why;
  • which technical assumption remained unverified;
  • which measure the next iteration should observe.

Presentation and feedback at the Capital ICT Innovation Square workshop

Working Backwards did not make every team build the same service. It gave different projects the same structure for explaining a first customer, first promise, and first test.