Instead of wasting time developing features based on untested hypotheses that turn out to be incorrect, ideas should be tested as early as possible so that less useful assumptions can be discarded
You're Pooh. Christoper Robin is anyone with some half-baked idea. The Heffalump is your customer.
Don't let Christopher Robin trick you.
“I saw a Heffalump today, Piglet.” He said carelessly. Piglet says he’s seen one and so does Pooh, both undoubtedly lying.
Pooh later looks round to see that nobody else is listening and says in a very solemn voice: “Piglet, I have decided something.”
Lacking any idea of what the Heffalump would do Pooh hits on the idea that he is a good model of the Heffalump’s behaviour.
“Suppose,” he said to Piglet, “you wanted to catch me, how would you do it?” What follows is the devising of plans, building of traps and the catching (or not) of a Heffalump.
"We are finding a Heffalump and I know how Heffalumps think," is what gets said to justify product ideas, and we just have to believe Christoper Robin. Later on in the project, Pooh has been indoctrinated and the hunt for Heffalump has spread.
You can recognise a Heffalump theory. They get talked about a lot more than anything which is actually known. We go around the room adding layers of convincing, but empty justification:
"I think the user would expect..."
"We think our users want..."
"If it were raining already, the Heffalump would be looking at the sky wondering if it would clear up..."
The Heffalump is the customer who has faults and strange behaviours but all of which are completely understood. I, Pooh, understand what our Heffalump wants and how they think. I can find us a customer.
We shall build this Cunning Trap - this Very Deep Pit and catch a Heffalump. We shall build this app and catch ourselves a huge load of users.
If only Pooh knew the difference between Heffalump theory and fact. If he could test his ideas before we spend months building this Heffalump trap, we could all feel better about what we're working on and the mutterings of "it'll never work" can be silenced.
Pooh thinks that changing the registration will sell more licenses? Let's test it.
He thinks that 50 per cent of users hitting our site from organic search don't know how to buy? We can test that.
Things can be tested.
A/B testing, proper User Acceptance Testing (UAT) and guerrilla testing gives product designers enough information about what will and won't work to keep the project team from building Very Deep Pits.
You can test the wording of your campaign on a small landing page. The usability can be compared in UAT sessions, and when it comes down to squabbling, just use A/B testing to arbitrate between the designer and the MD.
I've come to see this as spotting the different between a Heffalump theory and a fact. A Heffalump theory is something that fills up a meeting—everyone has an opinion on it and we can all talk about it endlessly because nothing can be proven. Everyone's opinion is as right as everyone else's.
It is opinion. A Heffalump theory is a hunch.
A fact can be acted upon. It's the knowledge that we need to change the registration or assert that the typefaces genuinely confuse users.
To get fact from Heffalump theory you ask specific questions and run small tests: What can we ask 5 per cent of our users which will answer this question? What AdWord campaign can we run as a test for the new offer? What A/B testing can we do which tells us whether people want free delivery instead of more customer service?
The Heffalump hypothesis doesn’t mean you shouldn’t take risks, but that you shouldn’t lie to yourself about what is and what isn’t a fact. A risk is a wonderful thing. An idiot is not.
There's still room for the stupid, insane and widely ridiculed ideas, but too many people spend months on small and provably pointless changes leaving no time, budget or will-power for the big ideas.
If a Heffalump idea comes up, say what it is. Turn it into proven fact before hours in meetings and days on the project are wasted.
These Heffalump ideas - new products or changes to apps - can often be tested in isolation. So much of what a product is comes down to UX and relatively simple application changes, but the heavy lifting happens when you move all your users to this new idea.
Read anything on lean or agile business models and there's the recurring theme of reacting to facts: test, refine, repeat. Everyone should do this, not just the trendy start-ups.
Use paper, UAT, Multivariate testing (MVT) and heaps of stats. You should live knee deep in analytics and mock-ups so when the project starts in earnest, you're as close to right as possible.
And when you realise you're a little wrong, do a test of what you think is more right before changing everything.
But don't go hunting Heffalumps.