The solution isn’t interesting, the problem is

“Nobody wants to use a computer,” I often find myself saying. “They want to get something done.” Open source communities are often full of technology enthusiasts. Technology enthusiasts love computers. We make them talk to each other. We make them talk to us. We do all kinds of silly, fun, and downright weird things with them. It’s easy to forget that most people don’t love computers. What they love is what computers can do.

This same perspective applies when designing processes for your community. Focus on the problem and the solution will come. Cate Huston said it great on a recent episode of “It Shipped That Way”.

But the other thing I like to foster along with that is get people to agree on the problem because the number one complaint from engineers trying to do any kind of process change is like, “I proposed this thing and people told me ‘no.’” And I’m like the solution is not interesting. You get people to agree on the problem, then the solution will be obvious or boring or someone will come up with something that you haven’t even thought of. But the point where people are at when somebody in that situation is at, it’s like they see some kind of problem on the team, they think it could be better and they propose a solution. And then an argument starts about the solution and then they come back and they’re like, “Why won’t people do this thing? It’s such a good idea.” And I’m like, “Because you had the wrong conversation. These people have not noticed this problem that you’ve noticed. So until you get them on the same page with that, your arguments are pointless.”

Cate Huston

Problems in processes

Too often we find ourselves focused on the parts that are interesting to us: the implementation of a solution. But the more valuable — and rewarding — work is solving a problem. In chapter five of Program Management for Open Source Projects, I talk about designing suitable processes. The first step is to figure out what problem the process is supposed to solve. In fact, I advise intentionally ignoring the how until the why and what are solid.

When it comes time to revisit the process, you don’t start by fixing the steps. You start by making sure the problem is still the same. It has probably changed. Understanding the new problem leads you to the new solution. Or maybe multiple solutions. It ultimately doesn’t particularly matter which solution you pick, so long as you’ve solved the problem.

Problems in messaging

So many websites — both for commercial products and community projects — tell me what the software does. (Although an alarming number of sites don’t even make that much clear!) But they don’t tell me why I care. So what if your library takes a string and alternates the case of the letters? Big deal. OH! You mean it makes writing mocking text in “SpOnGeBoB cAsE” easier? You have the Internet’s attention!

The best way to get someone’s attention is to solve a problem they have. If you don’t tell them that you solve the problem, they move on until they find something that does. And the average user won’t care how you solve the problem, so long as you solve it. They don’t want to use a computer, after all, they want to get something done.

This post’s featured photo by krakenimages on Unsplash.