There’s a methodology I’ve been using for years that I only gave a name to recently. Philipp and I call it conference-driven development. The idea is exactly what it sounds like: you submit a talk about something you haven’t built yet, and then you build it before the date.
It sounds reckless. People hear it and get a little uncomfortable. Isn’t that risky? What if it doesn’t work? What if the demo fails?
Yes. And that’s the point.
The problem with building first
When I have an idea for a project, the natural instinct is to wait. Wait until it’s ready. Wait until I understand the whole shape of it. Wait until I can see how it ends before I start.
This is a very effective way to not build things.
Ideas without deadlines are ambient. They live in Notion, in voice memos, in the margins of conference notes. They feel important. They stay theoretical. I have years of evidence for this - ideas I was genuinely excited about that are still exactly where I put them, untouched, because there was never a reason to start today over tomorrow.
The conference call for proposals creates a reason to start today.
How it actually works
You submit a talk. You give it a title that commits you to a specific idea. The CFP closes, the talk gets accepted, and now there’s a room of people and a date on a calendar.
That room doesn’t care that you haven’t built the demo yet. It doesn’t care that the architecture changed three times since you submitted. It doesn’t care that a better model came out last week and now your whole approach looks different.
The deadline is fixed. You build.
Otto
The clearest example is Otto.
Philipp and I had been talking about building an AI agent system for community management for more than two years. We had conversations, diagrams, ideas about what it should do and how it should work. It lived in Notion as a very detailed set of notes.
Then we submitted four talks about it to AWS Community Days. All four got accepted.
We had to build it.
Not the theoretical version. Not the fully polished version we’d been imagining. A real version that we could put on a stage and say: this is how it works, here is what it does, here is what it got wrong.
The AI landscape shifted substantially between submission and presentation. New models appeared. Best practices changed. We rebuilt parts of Otto mid-stream because what we’d originally designed was already outdated by the time we got to it. That was fine. The deadline didn’t move. We adapted.
When you build under pressure, you also build honestly. You can’t hide behind polish or “almost done.” You stand in front of a room and show exactly where the system is. That feedback - from a real audience, in real time - is better than anything you get from building in isolation.
The juggling parallel
This is exactly how juggling works. You don’t learn to juggle three balls by practising in private until you’re ready to perform. You learn by throwing them up when you’re not ready and finding out where they land.
Every juggling pattern I’ve learned, I’ve learned by putting myself in a situation where dropping was visible and continuing was necessary. The performance creates the skill. Not the other way around.
Conference-driven development works on the same principle: the commitment creates the capability. You don’t wait until you’re capable enough to commit. You commit and then become capable.
The talk you give at the end isn’t just a presentation about what you built. It’s a record of how the building happened - including the parts that didn’t go as planned, the three pivots in the middle, the section where the demo didn’t quite work and you had to explain why.
That’s the most honest version of the story. And the most useful to the people in the room.
What this requires
Submit the talk. Build the thing. Show your work before it’s done.
That’s the pattern.
Linda Mohamed is an AWS Hero and conference speaker in Vienna. She has given talks about demos she built the week before. She recommends it.