When to listen, and when to say no

19 October 2026 · Rob Schmitt

If you make an app, you’re told two things that sound as if they can’t both be true:

• Stick to your vision. Have a clear idea of what you’re making, and don’t let anyone talk you out of it.
• Listen to your users. The people using it know things you don’t.

Stick rigidly to the vision and you stop hearing anything useful. Listen to everyone and the app drifts, one reasonable request at a time, away from what it was meant to be. So the usual answer is to balance the two, and to choose, each time, which of them to follow. I don’t think that’s quite right.

Steve Jobs is usually held up as the case for sticking to your vision. “A lot of times, people don’t know what they want until you show it to them,” he told BusinessWeek in 1998. I think he was right. Ask people what they want from a notes app and you’ll get a very long list, with every item on it perfectly reasonable for the way that person takes notes. Build all of it and you get an app nobody quite wanted.

A year before that interview, Jobs made a decision that shows what sticking to your vision looks like in practice. He had just come back to Apple, which was close to running out of money, and he was closing projects down. One of them was OpenDoc, Apple’s attempt to replace big all-in-one applications with small parts you could combine in a single document, and plenty of developers had built their products on it. At Apple’s developer conference that May, one of those developers stood up and told Jobs, more or less, that he didn’t know what he was talking about.

Jobs stuck with the decision. His argument was that OpenDoc was born of a clever piece of technology rather than of anything Apple’s customers actually needed: “You’ve got to start with the customer experience and work backwards to the technology.” The developer had every reason to be angry: his work depended on OpenDoc. But Jobs was deciding for the Mac as a whole.

Ten years later, people were telling Jobs he was wrong again, this time about the iPhone.

When the iPhone went on sale in June 2007, the only apps on it were Apple’s, and developers wanted to build their own. At WWDC a few weeks before the launch, Jobs offered them web apps instead, which he called a “sweet solution”. According to Walter Isaacson’s biography, Jobs didn’t want other people’s apps on the phone, because outside software could bring viruses and mess the phone up.

Developers didn’t think web apps were enough. By the end of that summer, people were breaking into their phones to install apps Apple hadn’t approved. Art Levinson, on Apple’s board, kept phoning Jobs to argue for opening the phone up, and Phil Schiller, who ran marketing, agreed with Levinson.

In October 2007 Jobs announced that developers would get the tools to build their own apps. The App Store opened the following July.

This time, the answer was yes.

One answer was no and the other was yes, and both look right now. So what decided them?

The best description I’ve found of when to listen doesn’t come from tech at all. It’s from Neil Gaiman, in a list of rules for writers the Guardian published in 2010: “when people tell you something’s wrong or doesn’t work for them, they are almost always right. When they tell you exactly what they think is wrong and how to fix it, they are almost always wrong.”

That’s how the two fit together. Listen to people about the problem, and let your vision decide the fix. The people using the thing know where it hurts. The person making it decides what to do about it, because they’re the one looking at the whole of it.

Both of Jobs’s decisions work that way. The iPhone developers were right that web apps weren’t enough, and he accepted that. The shape of the App Store was his: Apple checked every app before it went on sale, which dealt with his worry about viruses too. The OpenDoc developer was right that the decision hurt him. But Jobs was starting from the customer experience, and keeping OpenDoc would have fixed the developer’s problem, not the customers’.

Soot, my notes app, is in beta, so I’m getting a lot of email. Most of it tells me something’s wrong: something didn’t behave the way someone expected, they say so, and they’re nearly always right. I’m grateful to everyone who’s taken the time to write. Those reports are usually bugs, and fixing a bug needs no philosophy.

Feature requests are harder. Sometimes someone asks for something I’d never use myself, and my instinct is to leave it out. But people come to Soot from other apps, and what they’re used to counts for something, so I don’t dismiss those requests. 37signals, the company behind Basecamp, advised in their 2006 book Getting Real to read feature requests and then throw them away, because “the ones that are important will keep bubbling up anyway”. I write them down, but the principle is the same: if other people keep running into the same thing, I know there’s a real problem. What to do about it is still my call, and it isn’t always what was asked for.

Every decision about Soot goes through one filter: does it fit the app I set out to make? Soot has a point of view about how a notes app should look and work, and plugins would let anyone change that, so they don’t get through it, however good the case for them. Nor does syntax that only one other app understands, because every note should stay a plain Markdown file that any app can read.

So I listen to everyone. When the fix someone asks for doesn’t fit Soot, the answer is no, and I keep looking for one that does.