The key lesson I learned building PolitiFact: Demos, not memos

So there was a little news around here lately. PolitiFact won a Pulitzer Prize. To say I'm still in shock is an understatement. A week later, it doesn't seem real.

All week long, we've been talking about how PolitiFact started, how it all came together. It's been fun remembering how it started out with Bill Adair having an idea and me having an idea on how we could pull it off. The crude mock-ups, the development environment on a box that was headed for the trash. I still can't believe we did it. But out of the many lessons I learned on PoltiFact, one stands out. It's become mantra for me.

Demos, not memos.

To be clear, my bosses thought PolitiFact was a good idea from the start. But there was a material difference between how they reacted to memos and how they reacted to seeing it working.

The sales job got easier. The abstract became concrete. The conversations changed from "what do you mean by" to "what if we did this."

Here's why I think demos, not memos works:

1. Ideas are cheap and plentiful. Execution is hard. One of the best books I've ever read is The Myths of Innovation by Scott Berkun. One of the myths he explores is that ideas are everywhere. The trick is picking which ones to execute on because you have limited resources and limited time to do that. If you're really passionate about your idea, building a demo makes yours stand out from the blizzard of ideas that are spawned every day.

2. Meetings suck. My favorite game right now? I sit in meetings, guessing what everyone around the table makes, and then I figure out how much this meeting is costing. Then I figure out how many page views at so much CPM its going to take to break even on just that meeting. I'm pretty sure I'm descending into madness, but the point is this: a demo cuts down on meetings. You don't have to spend time explaining what you want to do. You just show it. A demo is not a finished product -- there's still plenty of work to be done -- but the meetings stop being about the idea and start being about execution.

3. Requirements documents suck. If you've never participated in a software project, a requirements document is a list of everything your app has to do. They are usually written by people who aren't developers and usually come out of meetings that have very little to do with what users want or is technologically feasible. What bothers me about them is that requirements documents remove large swaths, if not all, developer creativity from the process. PolitiFact succeeded technologically because the guy with the vision and the guy who could build it worked together. We went back and forth, both with ideas, iterating through the development. Form and function were blurred together. Requirements documents say here's what we want, go build it and nothing more. Thinking that way means never being any better than your document.

Now, does building a demo mean guaranteed success? No. Not even close. I can still count the number of not-this-blog sites I've launched on one hand. I have 14 projects that I've started building out as demos that have gone nowhere. Sometimes, an idea you think is great just isn't. Sometimes seeing it up on the screen reveals that. Sometimes just trying to build it reveals what a giant hairy ball of pain your idea is going to be. But you won't learn that from a memo. In a memo, everything is easy. Which is why demos matter.

By: Matt Waite | Posted: April 27, 2009 | Tags: Journalism, Personal, Django | 10 comments