But why?

To make a difference.

That's my answer to why I want to build things. I know how vague that sounds. A difference to whom? What gets better for them? If I can't answer that, I probably need to spend a little longer with the problem before getting excited about my idea.

It's easy to skip that part. You see something that could be improved and start thinking about how you'd build it. Within an hour, you've got features in mind. Maybe a name. You're already explaining the idea to someone, and explaining it makes you more attached to it.

Meanwhile, the person you wanted to help is carrying on with their day. You haven't asked them much yet.

This is why first principles matters to me. I want to get back to what I know about a problem, separate that from what I'm assuming, and figure out what the person needs before deciding what the solution should look like.

Here's a fairly ordinary example. Say an online shop gets messages every morning from customers asking where their orders are. Whoever handles support is fed up with answering the same question. The owner starts looking at chatbots.

I can understand the attraction. The questions repeat, so the answers should be easy to automate. Set it up, connect the order data, and give the support person some breathing room.

But I'd want to read those messages first.

Are customers asking because the deliveries are late? Because the tracking link doesn't work? Or because the confirmation email told them almost nothing about when to expect the package?

Those would lead me to quite different decisions. If the courier hasn't moved a parcel in four days, an instant reply saying “your order is on its way” is going to piss someone off faster. If the problem is a missing delivery estimate, we might be able to fix the email this afternoon.

And perhaps the useful change is to tell customers when something goes wrong, before they have to chase us. That would mean finding a way to spot delayed orders and sending an honest update, including what we're doing about it.

The original job was “find a chatbot.” After a bit of digging, we might be working on delivery updates or replacing an unreliable courier. We could still need the chatbot. We'd have a much better idea of what to ask it to do.

That's the part of first principles I find useful. A customer needs reliable information about an order they've paid for. There are several ways to provide it. Once you understand that requirement, you can look beyond whichever solution happened to occur to you first.

There's a related idea called lateral thinking, associated with Edward de Bono. It involves changing the way you look at a problem to find other possibilities. Sending an update before anyone asks is a small example of that shift. You're changing when the conversation happens, which might reduce the need for it later.

It doesn't have to be a spectacular invention. I'd be happy with a change that saves a customer an anxious evening and a support person another unpleasant call.

The difficulty, I think, comes when you're already invested in the answer. Maybe you've spent weeks comparing tools. You've told the team automation is the priority. Someone has started building it. Now a person asks whether a better email would solve half the problem, and you have to take that suggestion seriously.

I want to be willing to do that. Even if it's annoying. Especially if the person asking wasn't involved in coming up with the original plan.

There's a limit, obviously. I don't want every small decision to require a debate about the purpose of the company. If someone has dealt with the same issue for ten years, there is probably a lot I can learn by listening to them. Asking why includes being interested in the answer.

But “we've always done it this way” leaves me with more questions. I'd want to know what happened when the process was introduced, what it was meant to prevent, and whether that problem still exists. Maybe there's a good reason. Maybe we're carrying on with something because nobody remembers who can change it.

You also have to check whether your new idea helped. In the shop example, I'd look at whether fewer customers need to chase an order, whether they're getting accurate information, and whether support has become easier. If people stop sending messages because they've given up on us, the lower number isn't much to celebrate.

That's what I mean by making a difference. I want to be able to point to something that got better for the person dealing with the problem. And before I commit to building anything, I'd like to understand their side of it well enough to explain why the work is worth doing.