The social media revolution has forced traditional journalism to rethink its most basic premise: a well researched, well developed and thoroughly checked news story. We don’t want to wait for weeks or even days for a news story. We want it within hours of it breaking, minutes would be best.  Journalists have even coined a new name for it: fast forward journalism. It’s a fast, unstructured post, and with just the facts that are available at the moment, giving its audience enough information to get them up to speed. I believe online development needs its own fast forward approach.

Not long ago I sat in a room filled with engineers working on a spec document for an online tool. We worked for a solid week. The engineers were trying to account for every potential user scenario and exception. I was fighting for simplicity and quick deployment. I had not given my process a name yet, but I’m calling fast forward development.

The reason start ups are more likely to create tools we love to use is because they often start with a simple idea and deploy it quickly, cost effectively and then allow users input to change and grow the product. Facebook is a great example of something that started small and focused (Harvard students only at first) then grew to other schools and now has over 500 million members.

Too often we take our analog reasoning into a digital project and kill it before it even has a chance to live.

Whether you’re developing a new website, an online ministry tool, or an e-commerce solution, consider the following:

What’s the absolutely minimum number of features this project  should have? The wisdom here is to create a tool that is useful but it has no more than it needs to have for a successful launch. If you don’t give your users enough, it will fail. They will not check back to see if you have finished the site. If you try to give them too much you run the risk of scope creep, timeline delays, costs overruns–and all of it before your target audience has a chance to tell you that your most resource-intensive feature was not worth the extra time and money.

How fast can we launch? Currently my team at The A Group is working on a few large and quite complex projects. But even on these projects we timeline weeks of development as opposed to months.

Digital platforms are alive and they can, and should, change often. The sooner we realize that there is no perfection when it comes to the digital domain, the sooner we’ll become effective software developers. Technology, attitudes and opportunities chance fast. In order to be relevant and even survive, so should your program.

What do you think of the “fast forward development” approach?