Software · Product · Building

Software should solve a problem, not create another one.

A product can be technically impressive and still be a terrible piece of software if using it creates more work than the problem it was supposed to fix.

I build software, so I obviously believe technology can make things better. But I also think we give software far too much credit simply for existing.

A new platform is not automatically an improvement. A dashboard is not automatically clarity. Automation is not automatically efficiency. And adding another login to somebody's day is definitely not innovation.

If the solution creates more friction than the original problem, it is not a solution yet.

Start with the actual problem

It is very easy to begin with features. People ask for portals, dashboards, workflows, AI, integrations and notifications before anyone has properly defined what is going wrong.

I prefer to start further back. What are people trying to do? Where does it become slow, confusing, repetitive or unnecessarily difficult? What information do they need? What decision are they trying to make?

Once that is clear, the software usually becomes simpler.

Good software removes decisions that never needed to exist

Some of the worst digital experiences are not broken in the technical sense. They load. The buttons work. The database saves the record. But the person using the system has to stop every thirty seconds and work out what the designer meant.

That is still friction.

Good software makes the next step obvious. It carries context forward. It does not ask the same question three times. It does not make people learn the organisation chart just to complete a basic task.

More features are not the same as more value

Feature lists are seductive because they are easy to count. But users do not experience software as a list of capabilities. They experience a sequence of moments.

Can I understand this? Can I get where I need to go? Does it remember what I already told it? Does it help me finish the job?

Sometimes the best product decision is removing something. Sometimes it is combining five steps into one. Sometimes it is deciding that a process should not be digitised exactly as it exists because the process itself is the problem.

Build around the person doing the work

I care about the systems behind software, but the person using the product should not have to.

They should not need to understand the database, the integration, the permissions model or the clever architecture underneath it. That complexity is the builder's problem.

The user's job is to do what they came to do.

The technology can be complicated underneath. The experience should not feel complicated because of it.

The test is simple

Did the software make the original problem smaller?

Did it save time? Remove uncertainty? Reduce repetition? Make the next action clearer? Help somebody get an outcome with less unnecessary effort?

If yes, keep going.

If not, another feature probably is not the answer.