Recognise When You're Building Without Context

A few years ago I was working on a platform for a financial services company, basically a website where customers could access their accounts. Nothing revolutionary, but it was a decent sized project with proper backing from senior leadership, and the engineering team were keen to get stuck in.

We built the thing. It took a while, as these things do, and honestly it felt pretty good throughout. We had people from around the business chipping in opinions, leadership seemed happy with the direction, and from a technical standpoint we were doing solid work.

The one thing we never did was talk to an actual user.

Which, looking back, is kind of mad. We were in a sales-led organisation, so there were people talking to customers literally every day. We could have just asked to sit in on a call, or got someone to introduce us, or even just picked up the phone. But we didn't. We figured we knew what we were doing. We were engineers and designers, this is what we do, and we just cracked on with it.

I think at the time it felt like we were being efficient. Why slow everything down with user research when we've already got a clear picture of what needs building? We had smart people making reasonable decisions. What more did we need?

Turns out, quite a lot.

The platform launched and technically it worked fine. Clean code, features all present and correct, did exactly what it was designed to do. But engagement was low, and when we started digging into why, we found all these issues we'd never anticipated. Currencies weren't displaying the way users expected. Things were rendering weirdly on different devices. The kind of stuff you'd catch immediately if you'd ever actually watched someone try to use the thing.

Pretty quickly the senior leadership who'd been so enthusiastic started asking some pointed questions about what exactly all that time and money had achieved. The blame ended up landing on engineering, as it often does in these situations. And what followed was genuinely horrible. The company made redundancies, and some of the people I'd been working with lost their jobs. The project itself got mothballed eventually and replaced with something completely different.

I've thought about this a lot since, and the thing that gets me is how avoidable it all was. We didn't fail because we were bad engineers or because the technology was wrong. We failed because we built something in a vacuum. We assumed that because it made sense to us, it would make sense to the people we were building it for, and we never bothered to check if that was actually true.

These days I do things differently. Before I get into the weeds on any project, I make myself stop and ask whether we've actually spoken to users. And I mean real users, not stakeholders or the sales team's interpretation of what customers want. The actual people who are going to use this thing.

It sounds so obvious when you say it out loud. But it's remarkable how often it gets skipped, or treated as a formality rather than something that might genuinely change what you build. I know because I used to skip it too.

I've also started asking why we're building something in the first place. What's the actual problem here? Who decided it was worth solving? What does success look like? These feel like abstract questions when you're itching to write code, but they're the foundation everything else sits on. Get them wrong and it doesn't matter how good your engineering is.

I'm not saying engineers should second-guess every decision or that you need a focus group before you write a line of code. Sometimes you have to make calls based on experience and instinct. But there's a difference between making informed decisions and just building in the dark because you never thought to ask anyone what they actually needed.

If you're working on something right now, it's worth taking a minute to ask yourself honestly whether you actually know who you're building this for. Have you spoken to them? Or are you just guessing based on what seems logical from where you're sitting?

Because building something well and building the right thing aren't the same, and the gap between them can hurt more than you'd expect.