The fastest way to build the wrong thing

AI has made software much faster to build. We see that every day.

Our developers can prototype ideas faster, explore different approaches without burning days of development time and get something working in front of people much earlier than we could a few years ago.

That's a good thing. We use AI heavily ourselves.

But I'm slightly uncomfortable with some of the excitement around how quickly we can now "build a product".

You can vibe code your way to something impressive in a weekend. It can look polished, do the thing you asked it to do and be good enough to convince you that you're nearly there.

Then you start looking underneath it.

How has authentication been handled? What data is being stored, and where? What happens when lots of people use it at the same time? How easy is it to change six months from now? Has anyone tested all the things that can go wrong rather than the one journey that works beautifully in the demo?

We've spent long enough developing software to know how quickly a collection of individually sensible features can turn into something unwieldy if nobody is thinking about the architecture underneath them.

Security, testing, scalability and maintainability haven't disappeared because code is quicker to produce.

And there's another problem we care about even more.

You can now build the wrong product much faster too.

We probably spend half our time trying to understand what to build

Enjoy Development is a software company, but I would estimate that around 50% of the valuable work we do isn't writing software.

It's listening.

Listening to clients. Listening to users. Looking at what people currently do. Trying to understand why they do it that way. Challenging assumptions. Putting rough ideas in front of people and finding out that something we thought was obvious makes absolutely no sense to them.

Sometimes we'll spend weeks understanding a problem before we're confident about what should be built.

That's not wasted development time. It is product development.

The tools have changed dramatically over the years we've been doing this. Those habits haven't.

Research still matters. Product-market fit still matters. User testing still matters. Co-design matters when you have the opportunity to do it properly.

And listening to real people matters.

There's a temptation, especially now, to sit in a room and imagine all the things technology could do.

We try to start somewhere else: what difference are we trying to make for the person using it?

The eventual answer might involve some clever technology. Quite often it does. But we've also had plenty of ideas that became much simpler once we understood the problem properly, and features we thought people would love that turned out not to matter very much at all.

I'd much rather discover that before we've built them.

Impactful has been a lesson in this

Impactful is a product we've developed to help increase participation in volunteering and help organisations engage people they aren't currently reaching.

It would have been very easy to approach that as a technology problem.

Build an app. Put volunteering opportunities in it. Add some nice filters. Job done.

Except there are already places people can search for volunteering opportunities.

We wanted to understand why many people, particularly younger people, weren't engaging in the first place.

So a lot of the work behind Impactful has been research with young people and people working across the voluntary sector. We've looked at motivations, barriers, language, identity, how people find opportunities and what volunteering looks like from their side rather than from the organisation's side.

Young people have been involved in co-designing the product.

That changes what you build.

It changes the language you use. It changes how you introduce somebody to volunteering. It affects how opportunities are presented, how people record what they've done and what you choose to leave out.

We're still learning because the job isn't finished when the software goes live.

If Impactful helps an organisation reach a young person who would never have visited a traditional volunteering website, that's useful. If we've built a technically excellent platform that the same people use as every other platform, we haven't solved much.

Research has its own problem

Listening to people properly takes time.

A good interview gives you things a survey often doesn't. Someone says something you weren't expecting, you ask why, they explain it, and suddenly the problem looks different.

Doing that with five people is manageable.

Doing it with 50 can become a research project in its own right.

Doing it regularly with hundreds of customers, employees, volunteers or members of the public is beyond the resources of a lot of organisations.

That's why we've been building Rooms.

Rooms is an AI interview platform. You decide what you want to understand and set the agenda for the conversation. You share a link and people talk to an AI interviewer.

They can explain themselves rather than choose between five radio buttons.

An organisation could use it to understand why customers are leaving, test a new service with users, hear from staff about a change, speak to volunteers about their experience or involve young people in developing something that affects them.

For us, this is one of the more interesting things AI can do.

We're obviously interested in using AI to make development quicker. But Rooms can also make the work around development better.

Instead of five user interviews because that's all the budget allows, perhaps you can listen to 50 people.

Instead of doing research at the beginning of a two-year project and never speaking to users again, perhaps you can keep listening.

Instead of assuming you know why people aren't using something, you can ask them.

That feeds directly back into how we want to build products at Enjoy.

We want the speed AI gives our developers. We also want good architecture, proper testing and security behind anything we're asking people to rely on.

And before we get too excited about any of that, we want to know who we're building for, what problem they have and whether the thing we're proposing is likely to make any difference.

That's still where we spend a lot of our time.