Solving the Wrong Problem

I’m sure I’ve talked about this before, but I’ve found myself staring at some great examples of this recently, so I thought I’d share.

Innovation is fundamentally about solving problems, except I’ve found there are two sets of cases where you innovate but solve the wrong problem, and that goes down very badly in the end.

OK, regular readers will know that I’m affiliated with a forum building system at present, for better and for worse. Well, it so happened that recently the forum software was under an attack of sorts from a collection of automated tools attempting to break into a semi-random group of accounts using common passwords.

While such attacks happen relatively often, this had a distinct feel to it, it was specific, it was methodical and reasonably organised, and was hitting an awful lot of forums.

A variety of tools and suggestions were bandied about in an attempt to stave off the bots, and the inevitable errors in the log, of failed password attempts – and unsurprisingly this met with a variable degree of success, ranging from nil to mostly complete.

During this time a variety of ‘can we have’ suggestions came out, one of which was to add the CAPTCHA to login, to defeat the bots. And so, sure enough, one got made. Meanwhile I’d developed a tool that had nailed this particular attack in the bud as soon as it could be known that it was symptomatic of this attack and not an innocent user.

The different approach is quite important – mine was a single magic bullet for this attack, the best provided alternative was a broad method that broke other functionality and exposed the CAPTCHA more readily to those who needed to study it to break it. Two vastly different approaches for the same problem, and even though so many asked for it, it didn’t solve the problem. In short, everyone who asked for such a function and to the person who developed it, they were looking at solving the wrong problem.

That’s the first example: looking at a problem, coming up with a solution that solves a different problem and trying to apply it to the original problem.

The second is more broad, and probably more interesting to follow. Again, from a forum situation, a very common question that’s asked is how to encourage participation, or how to encourage people to sign up.

I say this is more interesting because while it has elements of the above, it’s far more prone to having all kinds of interesting solutions applied to it that have two consequences: either it demonstrates that the original problem’s definition was incomplete, or that the solution solves the original problem and creates another in its stead.

I’ll start with ‘solving the original problem’ first, and probably the most odd case is an all too common question. ‘How do I get better participation?’

Well, for some reason I have yet to fully understand, that so often quickly becomes ‘How do I get it so that in order to see (my post/the files I’ve uploaded), someone has to reply to my post?’ I can only conclude that people figure ‘if folks have to reply to my post to see it, it’ll encourage posting’. On that basis it seems sensible, but when looking at it closer, it doesn’t work - how can someone reply to your post commenting on it, or commenting on your files, if they can’t even see them?

So let’s say for the sake of argument that such a modification is prepared. All it causes is people to take what their psychology directs them to do: the shortest possible path. Which means that when it happens, invariably people reply with one word or one line answers, often very generic and bland. Yes, the sub-problem has been solved: people are participating more, but the kind of participation you get is wrong.

The overall question of ‘getting participation’ is in itself an example of the ‘incomplete definition’ problem – we’ve asked for more participation, and in so doing identified a method to encourage it, with its own implementation issues. So we solve those and find a new problem in the type of participation. And yet, ultimately, we’ve innovated and solved the wrong problem on the wider stage: we’ve got more participation but it wasn’t the kind we wanted.

Or, what we should have done, is ask for ‘how to get better, high quality, participation’. Now we’re saying something more specific; we’re not only saying what we want but clarifying how we want it.

This is surprisingly common, actually, not to have enough information – another example was a paid project I did for someone a year ago, I produced a package that fulfilled every one of the criteria they set out originally, except that in every respect it was wrong. It wasn’t that I’d done anything wrong, per se, because what I’d done was what was asked, but what was asked for, solved the wrong problem…

So, when innovating, make sure you know what it is you’re trying to do before you start, that you not only figure out what you’re trying to do, but the manner in which you’re trying to do it, and I guess, to plan for unexpected side effects along the way.