The Six Questions

Even if you don’t care about the answers, you still need to know what they

Capitalism, at its core, is all about supply and demand. You have a Thing, and somebody else wants the Thing. So, you arrange a trade. Doesn’t matter what you get in return – services, chickens, dollars, the giant stone coin of the Yap islanders – you each have something the other wants, so you agree on a mutually beneficial exchange.

Things get significantly more complicated from there, and software is no exception. One of the things that makes things easier is knowing what your customers want.

Nobody actually wants features

I’ve seen several developers (and companies) fall into the trap of thinking “if our software has feature X, we’ll make more money”. This is not true. Nobody actually gives a crap and a half about features. It took me far too long to really understand this.

On the other hand, everybody wants a problem solved. Features and functionality that solve a problem - that’s where fortunes are made.

Everybody wants problems solved

Take single-sign-on, for example. Adding single-sign-on to an application is, by itself, completely useless. Nobody cares. But, when combined with other useful things, it solves several problems - it simplifies user management, removes yet another password people have to remember (or forget), etc. There’s lots of benefits to single-sign-on, and that is what people want. They want their lives made better or easier. They don’t want SAML/Oauth in the software they use. They don’t even want to think about the mechanism behind how it works. They just want to be able to click a button and be signed in. They want the benefits.

Focus on the problem you’re solving

As professional software developers, we owe it to ourselves, our users, our customers, our colleagues, our clients, and our employers to focus on the problem they want solved. After all, if you don’t understand the problem, how will you know when you’ve solved it?

If these people don’t understand the problem, then things get tricky. It takes rare vision to graple with that kind of situation.

On the other hand, if these people do understand the problem, then you’re in luck. You can just ask them. In general, people love to talk about their problems. There’s an entire, multibillion dollar industry built around people paying just to have somebody listen to their problems. Take advantage of that impulse.

The six questions

In order to understand the problem you’re trying to solve, there’s six questions every software developer has a responsibility to be able to answer:

1. Who are our users?

This one should be straightforward. If you’Ve got users, who are they? Are they large enterprise employees? Are they lawyers? Plumbers? Pastry chefs? Millenials? Who wants your software so much that they’re willing to give you their time, money, and attention?

2. How do our users use the product?

Also pretty straightforward. What level of interaction do they actually have with your software? When they do use it, what do they do with it? Most developers believe this to be obvious. Most of them are wrong. Users are a chaotic, unpredictable force of nature. If your software is capable of doing anything, your users will find surprising ways to use it that you never anticipated.

3. Why do they use our product vs anyone else’s?

Maybe your users aren’t aware you have competition. And yes, you have competition. I’ve been in organizations that believed they had no competitors, but it wasn’t true. There’s always competition. The competition may not do everything your software does, but those differences are where you need to spend a lot of attention. Are your users aware of those differences? If not, would they care?

If the only thing keeping your customers from jumping ship is the fact that they don’t know they have options, you’ve got a serious problem.

4. What do they like about it?

Also pretty straightforward. If you’ve built something that solves a problem, your users will be happy to tell you. You owe it to them to understand what it is you actually do to improve their lives. You need to know where you succeeded in your efforts, even if you did it accidentally in a way you never anticipated.

5. What do they dislike about it?

You’ll notice these are all straightfoward. This one is no exception. If you’re careful, this is where you’ll get lots of great ideas for how to improve your product. You’ll get lots of garbage you probably don’t care about as well, but you still need to know.

6. How would they like to improve the product, if they had a magic wish-granting genie?

It’s true, users often have no idea what they want. Or they want things that simply don’t fit with your product. But if you have many users saying the same thing, maybe it’s time to listen, even if you don’t agree. After all, you’re not a paying customer - they are. And that’s what “the customer is always right” truly means. They’re the ones with the money, and by definition they can give that money to somebody else if you aren’t providing enough value in return. “If only they understood the brilliance of what I built” might be a good way to feel superior, but my landlady (as nice as she is) doesn’t accept feelings of superiority to cover my rent. She wants cash.

Know the answers, even if you don’t care

If you, and every developer on your team, knows the answers to those six questions. It’s best for every developer to get those answers, directly from the customer. The more layers of communication (read: people) that exist between developers and customers, the more likely it will be that important information gets lost in translation.

Even if your developers don’t care about the answers (not all feedback is useful), they should still know what the answers are. If they don’t care, it’s just as important to know why.