Digital Conversations
complex maths small

Complexity vs Effectiveness, or: how I learned to stop developing and love the press release

23rd August 2012

Part 1: Complexity vs Effectiveness

First things first: the complexity of a tool is totally independent of how effective it is. Unfortunately, I often see people discuss the complexity of a new digital tool and its broad range of features or unique database structure as a proxy for how effective it is – or worse, as evidence of how effective it is.

This approach is natural, for us an agency and for project owners on the client side. Complex tools look impressive. They represent a lot of effort. And the more effort expended, the better the end result. Right? Furthermore, it also shields stakeholders from criticism – who is going to lay blame when KPIs aren’t met when ‘look at all the hard work and thought that went into this tool!’ If you’re going to fail, it looks better to fail while overdoing than underdoing.

There’s nothing wrong with putting in lots of effort. Effort is great as long as it’s applied correctly. And while over-developing can be harmless, occasionally the added complexity will actually reduce the effectiveness of the tool.

Think about Facebook and the myriad of functionality it has, some of which I still haven’t even used. Had it launched in its present form, I’m willing to bet that adoption would be a lot slower. At launch, it was a simple tool that addressed a core problem: people wanted to connect via online profiles, but MySpace and Windows Live offered terrible user experiences. It was the simplicity of Facebook initially – in both functionality and layout – that made it so ‘sticky,’ encouraging growth.

Part 2: Press Release First!

So what’s the answer? I’ve recently been drawn to the Amazon approach to product development, which is to reverse engineer the final tool from the position of the end-user. In this fantastic post on Quora, Amazon product manager (and Quora champion) Ian McAllister outlines how they do it: press release first.

Yes, that right. Write the press release for your new tool before you even start planning development (even if you won’t actually release it). Why? The press release allows you to focus on the pitch behind the tool. You can go to Quora for a full breakdown of their approach, but in summary: “describe the product and the benefit”, “describe the problem your product solves,” and “describe how elegantly your product solves the problem.” If you find yourself developing solutions to problems not outlined in the press release or coming up with extra “value-adding” feature, ,then pull back and ask why? If the answer remains compelling, then at least ask when? Does this need to be in the first release? Can it wait until later?

This ties in with the “always in beta” mind-set, which is a good way of looking at most digital projects. Don’t strive for perfection on launch. Strive to hit the minimum effective level required to address the core problem, and then iterate from there. It gets you live earlier, it eases your users into the tool, and it means that you’ll have data and feedback to inform subsequent development of those additional features on your wish-list.

This is an approach I’ve taken recently, although mostly just in my back-of-the-napkin sessions (if any client wants to give it a go on an actual project then get it touch – I’m keen to work with you on it. It will be fun!).

In Summary

The effectiveness of your website is basically how well it addresses business and user problems. If that is best achieved by a static 2-page microsite then so be it. If it’s best achieved by a bespoke crowd-sourcing and collaboration platform then that’s fine as well. It’s just important to remember at the outset that effectiveness is not how big or complex the final solution is, it’s how well it addresses the initial problem that prompted the project. Start with and stay focussed on the user and their problems and I guarantee the final result will be better than starting with a laundry list of functionality.

Leave a response

  • Your email address will not be published.
  • You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>