I’ve been dealing with a few clients of late, most of which have heard the ruckus around this newfangled Web 2.0 thing, and most of which want to do something Web 2.0 with their projects. Some want to implement blogs, others are interested in Wiki’s and podcasting, and surprisingly most of them want some Ajax features. The list goes on. 

That’s really good because I’m always happy to talk to people about getting more out of the web, specifically around creating better and more valuable user experiences, but the problem I have (and which I communicate) is that Web 2.0 doesn’t just stop at implementing a blog engine, podcasts, a Wiki or Ajax.

When you get down to the nitty gritty of things, the above technologies are the way in which we create a better or richer user experience, so that the user has a better affinity for our product or service but also so that we are able to better interact with them, or so that they are able to better interact with others on the site.

The technology itself is ambivalent, it doesn’t care what it’s used for or how it’s implemented. So, as a web practitioner it’s my job to remind the clients that it’s quite possible to implement said cool new feature, but what are you going to do with it afterwards?

This situation reminds me of the good old early days when clients asked you to build a web site for them, and then also expected you to write the copy for the web site, even though you didn’t know enough about their business or industry to do the job justice.

Similarly, when implementing these new Web 2.0 features, most of which are becoming easier and more mainstream by the day, clients and practitioners need to bear in mind that both the rolling out and post-implementation work need to be agile in nature, if you’re going to get the best from these new technologies promise.

Taking six weeks to write up a 200 page functional specification document isn’t going to win you much affection from your users, when they’ve already gone to the competition because they were faster, leaner and meaner, implementing the same functionality quicker than you to attract new users (including yours).

Likewise, taking 2 weeks to respond to a customer comment on your blog about why your new product doesn’t work in whatever circumstance isn’t going to win you much affection – rather it’s going to create a negative word of mouth spiral that you don’t want. 

Neither will launching a new Wiki to document your product more comprehensively than your instruction manual does (think user generated content here), then spending a week adding some initial content, then never touching it again.

The bottom line is that any strategy which plans to engage users and draw them into a positive word of mouth spiral, whatever the technology underneath, must be implemented as quickly as possible and with as much involvement from users as possible. You must also have a follow-through plan that goes beyond the short term. Assigning someone responsibility with regular update reports is probably a good idea too.


Published 11 July, 2006 by Gareth Knight

27 more posts from this author

You might be interested in

Comments (2)

Sonia Kay

Sonia Kay, Consultant at 120 Feet

I’m currently carrying out research amongst a wide range of organisations into their Web project management approaches, and it’s probably fair to say that without significant change some of them will struggle to get the most out of emerging technologies. But not from lack of will in the marketing and project teams.

The vast majority of people I’ve spoken to already recognise that their projects need to be smaller in scope and timescale, prioritise the most important changes over peripheral requirements, and be iterative in their nature in order to deliver a product that does what marketing have asked for. But a lot of them are using Prince/Waterfall adaptations, and a regular comment is that a Prince project can be a big ship to turn around if you need to change direction mid-way.

One of my interviewees is operating in a market place where the customers’ rapid adoption of new technologies is driving change at a phenomenal pace. They can’t afford to work on a 3 month cycle, they need to respond quickly to market demands and deliver the improvements to their web offering that are going to make the biggest difference to their customers (and consequently their bottom line). An environment like this demands complete collaboration and communication between the marketing team and the developers, and they have found that Agile has given them the framework to do this.

So if it’s so easy why doesn’t everyone work in this way? The answer that I’m getting so far is that working in an Agile way requires significant cultural change. If your organisation is making the transition from online to offline, if you’re integrating with legacy systems, if you outsource your development – then chances are Prince / Waterfall has always been the way to go. And your board of directors probably like the fact that all your projects are completely buttoned down before you spend any development resource on it, and that risk management and quality assurance are going to be embedded into the DNA of every undertaking. But does letting go of Prince mean you have to say goodbye to the security blanket? What I think I can safely say is that the decision to change approach needs to come from the top of the organisation. Watch this space for the full findings.

about 12 years ago



Hi Sonia,

Thanks for sharing information with us. On the same note, Did you come across any functional specification for any web application? If yes, if you can provide me that, it would be a gr8 help.

Thanks in Anticipation

almost 11 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Digital Pulse newsletter. You will receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.