Exercises

Fast-forward 12 months. Helix Robotics has failed. Working backwards from that headline, we name every reason it went wrong — the strategic misses, the cultural drift, the conversations we should have had but didn't.

It's counter-intuitive on purpose. Imagining failure first is one of the most reliable ways to surface the risks a team is quietly carrying. The exercise creates permission to say the thing nobody wants to say.

What we produce: a ranked list of failure modes that becomes the agenda for the next session ("The conversation we are avoiding").

Now the opposite move. We write the press release we'd want to publish 18 months from now — the moment that makes the team proud, the customer outcome that justifies everything.

Borrowed from Amazon's working-backwards method: you write the announcement before you build the thing, then ask whether what you're actually doing today gets you to that headline.

What we produce: a one-page release with a real headline, a customer quote, and the three things we'd point to as evidence. It's the sharper version of "vision" — concrete, dated, and pinned to outcomes.

Each leader writes their own operating manual: how they think, how they make decisions, what energizes them, what drains them, how they want to be challenged, the things their colleagues should know but might never ask.

Most teams under-share this. The POM closes that gap in one document. We read each other's, then talk about what was surprising, what's load-bearing for working well together, and where the gaps are.

The interactive POM workbook is already live — you can fill it in (and export it as PDF or Markdown) on your own schedule before the day:

Open the POM workbook

Break into small teams, pick a real Helix Robotics problem from the morning's "Leveraging AI" session, and build something — a working prototype, an automation, a dashboard, a sharper process. Whatever moves a real metric.

The constraint: ship something demoable in two hours. The point isn't the artifact, it's proving to ourselves what's actually possible with the tools we already have access to.

What we produce: 3–4 short demos at the end of the session. Best one earns bragging rights and the first slot on the post-retreat commitments tracker.

We've written a full playbook for how to use Claude Code, a knowledge base, and a small army of agents to actually ship in those two hours — with eight worked-example project ideas and copy-paste starter prompts:

Open the Two-Hour Hackathon Playbook