
Don't ask customers for a better elephant: making the Steve Jobs leap
This is the third post in a series of five, excerpted from lessons in business by our founder, Peter Gradwell. They are taken from a YouTube interview he did in the "UK Business Forums" podcast series.
There's an old line attributed to Henry Ford: "if I'd asked people what they wanted, they'd have said faster horses." Whether or not Ford actually said it, it captures one of the trickiest balancing acts in product: customers can tell you what they don't like, but they rarely tell you what to build next.
I spent a lot of the Gradwell years butting up against this. The product managers would come back from a round of customer interviews with the top ten things customers wanted fixed, neatly prioritised. They were good lists. They were thorough. And they were almost always the wrong list.
"If you ask a thousand people what product they want, they might not have the imagination to see the next leap. They'll create a better elephant."
The phrase "better elephant" stuck with me long after I first heard it. It captures a failure mode of customer-driven development: if you only ever optimise for the thing you're already selling, you'll get very good at selling a slightly larger, slightly shinier version of it. You will not invent the iPhone, because nobody ever asked for an iPhone.
This is why I've always pushed in the other direction. When we moved Gradwell from web hosting into voice over IP in 2004, no customer had asked us for it. We had a thousand-odd hosting customers and none of them walked in and said "what I really want is for you to run my business phone system over broadband." What had happened was that I wanted a Bath phone number to route calls to two friends in Leeds and Tunbridge Wells, couldn't do it without tying up two lines on a PBX, and thought: there has to be a better way. We built it for ourselves, then realised our existing hosting customers had the exact same latent problem — they just hadn't articulated it yet.
The balance that keeps you honest
Leaning too far into the Steve Jobs model is dangerous. You end up shipping products for an imaginary customer while the real ones churn quietly out the back door. The counterweight is the diligent product-manager work — the surveys, the analytics, the top ten fixes. You need both.
The truce I landed on with my team looked like this:
- The product team owned most of the backlog. They'd done the research, they had the evidence, they were usually right about what to fix.
- A fixed slice of engineering time was mine to spend on the leaps. Things I couldn't justify with survey data but had conviction on. Some worked. Some didn't.
- We measured everything afterwards. If my leaps didn't move the numbers, they got dropped. No sacred cows.
That last bit matters. It's easy to confuse "I have a vision" with "I am right." I wasn't always right — we once spent about £300,000 trying to reboot the web-hosting business after the voice business had outgrown it, and it never took off. Failing fast is part of the deal.
How to tell which you're doing
Ask yourself: is the next feature I'm about to build something a customer would describe, or something I'd have to show them before they recognised they needed it?
A better elephant is described. A new animal has to be shown.
Both are legitimate, but they feed different parts of a business. If you only ever build what customers describe, you'll survive — but you'll never surprise anyone. If you only ever build leaps, you'll surprise yourself straight into insolvency. The founders who compound over decades can do both, and — more importantly — can tell which one they're doing on any given morning.