2025년 11월 3일 온라인 교육으로 시작해 11월 10일 오프라인에서 직업계고 고객중심 문제해결 경진대회를 진행했습니다. 두 일정 사이에는 일주일의 간격이 있었습니다.
이번 사례의 과제는 방법론을 한 번 설명하는 것이 아니라, 온라인에서 만든 질문이 사라지지 않고 오프라인 prototype과 발표의 검증 기준으로 이어지게 하는 것이었습니다.
온라인에서는 아이디어보다 확인할 질문을 남겼다
온라인 세션에서 완성된 해결책을 요구하면 팀은 다음 일주일 동안 처음 아이디어를 구현하는 데만 집중합니다. 대신 첫 고객, 직접 본 문제 장면, 현재 우회 방법과 가장 큰 unknown을 기록했습니다.
각 팀은 오프라인 일정 전까지 확인할 작은 과제를 정했습니다.
- 실제 사용자 두세 명에게 같은 문제가 있는지 묻기
- 필요한 data 또는 sensor가 존재하는지 확인하기
- 종이 화면으로 핵심 흐름을 설명해 보기
- 성공 장면을 한 문장으로 줄이기
일주일은 제품을 완성하는 기간이 아니라 첫 가정을 현실과 부딪히게 하는 기간이 됐습니다.
오프라인에서는 처음 문서와 달라진 이유를 확인했다
경진대회 당일에는 처음 아이디어를 얼마나 충실히 구현했는지만 보지 않았습니다. 온라인 문서와 비교해 고객, 문제, 기능 또는 demo가 달라졌다면 그 이유를 설명하게 했습니다.
사용자에게 물어보니 문제가 다르거나, 필요한 data를 구할 수 없거나, 기술 구현이 예상보다 위험하다는 발견은 좋은 결과였습니다. 중요한 것은 발견을 숨기지 않고 scope와 성공 기준을 수정하는 것이었습니다.
이렇게 하면 pivot이 계획 실패가 아니라 evidence에 따른 결정이 됩니다.
심사 기준을 기능 수에서 연결성으로 바꿨다
경진대회에서는 완성된 화면과 많은 기능이 유리해 보일 수 있습니다. 심사와 피드백은 다음 연결을 중심으로 봤습니다.
- 관찰한 고객 문제와 제안한 해결책이 맞는가
- demo가 문제의 핵심 변화를 보여 주는가
- 기술 선택이 필요한 이유를 설명할 수 있는가
- 실패와 limitation을 정직하게 표시했는가
- 다음에 확인할 가설이 구체적인가
이 기준은 구현 경험이 다른 학생 팀을 같은 결과물로 만들지 않으면서도, product reasoning을 비교할 수 있게 했습니다.
발표는 온라인과 오프라인 사이의 변화 기록이었다
발표 구조는 문제 → 온라인에서 세운 가설 → 일주일 동안 확인한 사실 → 바뀐 결정 → demo → 남은 질문 순서로 정리했습니다. 청중은 final feature뿐 아니라 팀이 어떻게 학습했는지 볼 수 있었습니다.
학생에게도 발표는 결과 포장이 아니라 자신의 판단을 설명하는 연습이 됐습니다. 어떤 기능을 구현하지 못했다는 말 대신, 어떤 evidence 때문에 우선순위를 바꿨고 다음에 무엇을 검증할지 말할 수 있었습니다.
이 사례에서 Working Backwards는 온라인 강의 자료도, 오프라인 발표 형식도 아니었습니다. 두 시점 사이의 학습을 보존해 처음의 질문이 실제 prototype과 판단 변화로 이어지게 하는 연결 장치였습니다.
댓글