AWS Cloud School Cohort 9 ran on June 21–22, 2025. Day one included career conversations and mock interviews that surfaced individual questions. Day two moved into team-based Working Backwards.
The second day did not need more methodology. It needed to convert technology and role interests from the first day into team-level customer and implementation decisions.
Turn individual interests into a team-testable problem
Participants brought different interests: DevOps, Kubernetes, AI, and cloud architecture. Starting directly from a technology can hide multiple purposes. “Use Kubernetes” may refer to automation, learning, cost, deployment, or operations.
Teams first removed the technology name and wrote one customer scene. They then connected each technical interest to a friction in that scene. An unconnected technology was not unimportant; it was outside this test.
A day-one question such as “which skill should my project demonstrate?” became “which technical judgment will this project actually prove?” A problem, constraint, choice, and result communicate more than a list of services.
Repeat four questions in a short session
A full document template can become the task in a short workshop. Team work repeated four questions:
- who is the first customer;
- in which specific moment do they fail;
- what observable change follows the solution;
- which features are essential to showing that change.
Every new feature returned to the final question. If customer change remained visible without it, it was deferred. The demo became the implementation scope guard rather than merely the final output.
Return decision criteria instead of answers
In a session with many participant questions, reusable judgment mattered more than isolated solutions.
“Can we add this feature?” returned as “which customer action fails without it?” “Which cloud service should we use?” began with whether the unmet requirement was consistency, latency, cost, or authority.
Not deciding for the team can briefly slow it down. It also enables the team to explain its own feature and architecture choices in the final presentation.
Use the presentation as the two-day integration test
Presentations followed customer scene → promised change → demo evidence → technology choice → remaining assumption. A project with this chain can name its next iteration even when implementation is incomplete.
Architecture-first presentations make it difficult to tell which component matters. Teams that connected technology to customer problem and validation communicated similar implementation much more clearly.
At AWS Cloud School Cohort 9, Working Backwards was not an isolated lecture. It connected individual questions from day one to team decisions on day two, then tested those decisions through the presentation.
Comments