mattwaite.com

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.

Comments

Cynthia McCune's comment on April 27, 2009 1:44 p.m.

"Demos, not memos" fits right in with my favorite words of advice to beginning writers: "Show, don't tell."

Rich's comment on April 27, 2009 4:13 p.m.

"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."

It makes you wonder how those people got into a position of telling others what to do, doesn't it? If you don't know a craft, how can you manage the people who make it happen?

Great advice and again congratulations on a well-deserved prize.

Paul Sholar's comment on April 27, 2009 6:03 p.m.

You're being too dismissive of requirements documents, as if everything you will build exists in a historical vacuum. Maybe think of requirements rather as statements about the *context* within which the product/project is expected to operate. (What are users' expectations? What look/feel are we adopting and why? What do we know *not* to do? Etc.) It also represents how much your team already knows about where you're going. Regards.

Darren McPherson's comment on April 28, 2009 5:52 a.m.

"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."

I know first hand of this. Usually the non-technical people who make the technical decisions are sales, marketing and project managers. They should have at least 1 creative/technical for clarity.

Patrick Beeson's comment on April 29, 2009 9:27 a.m.

Great entry Matt!

Much of what I do at Scripps is project management, which means I'm the guy getting the right folks together and putting together the dreaded requirements. But because I understand what it means to do the design, development and content, I can ensure we don't over-scope things.

I think that every project manager should have these skills to do their job effectively.

It would be akin to an editor never having reported on, or written, a story.

Sam Sabey's comment on April 29, 2009 10:40 p.m.

I am so with this, and echo everything said.

Doing beats the crap out of talking, for just that. It takes the "huh" and turns it into "aha".

It provides the momentum, which without, it's just another 2cent idea.

Ken's comment on April 30, 2009 7:37 a.m.

Congratulations on a well-deserved Pulitzer. PolitiFact may be the best example of where organizational journalism should be these days.

And I think you're dead on with Demos Not Memos. I'm a product guy and agree completely with that notion and the whole documentation thing. It's true that requirements play a role, but I've seen too many projects where a product manager seems to believe if "it's a requirement", it's going to be done - without any clue as to whether it's even doable.

The best projects I have been associated with happened with a strong product manager working with a strong engineer on an idea before any requirements are written. And in most organizations I've worked in, that had to happen outside of the normal flow and in addition to your current assignments. But it resulted in projects where the requirements were actually a development guide and not a giant stack of paper handed out at a kick-off meeting and ignored by the engineers.

Lonnie's comment on May 8, 2009 3:22 p.m.

I agree with the context. But (there is always a but), how does this play out in the context of "large" or "expensive" projects, i.e. a new lunar lander. NASA lives and dies by the CMMI software development philosophy. Can "demos, not memos" work anywhere outside of the "flexible" internet world?

Fernando Diaz's comment on May 30, 2009 11:48 a.m.

Thanks Matt. Now to get to work!

Austin's comment on June 19, 2009 2:40 a.m.

Now, i dont know if at the time of my comment you will still be helping with politifact. However i have to disagree with it recieving the pulitzer. I recall checking the website at the very least once a week before and after the election and found that the updates were very inconsistent. For example, i found that most of the Obama or Biden statements that were found to be false were not reported as such until after the election. However most of McCain or Palin statements that were found to be false were immediatly posted. As a registered Libertarian, i believe this to be highly unethical and i find myself just as shocked that Politifact recieved a pulitzer.