If a job's worth doing, it's worth doing well

These days, perhaps more than ever, velocity is king. There’s no time to waste. Only PRs to push and ideas to ship.

But at what cost?

I’ve always been aware of how much ‘hacking the system’ is romanticised; just work lean, do what you need to get stuff done, worry about the details later. Debt is a very valuable tool to getting product work done, but it isn’t sustainable, especially when it comes to our internal processes, particularly research.

While the cost of shipping has reduced dramatically in the last couple of years, the cost of knowing what to ship remains a burden. Why spend weeks on a lengthy discovery project when we can just put stuff out there and observe? Isn’t that a faster and more efficient route to customer success?

I’d argue it isn’t.

It certainly has its place, but in many organisations that follow this way of thinking, you’re only getting half the story. Analytics might show you where people are dropping out of your onboarding, but won’t tell you why. And then, because the apparatus of deeper observation isn’t in place, there’s usually a scramble to get time with customers to find out why; often involving a research brief, budget signoff, participant gathering, scheduling and so on.

Because of this reactive nature of customer research, our tools are often fragmented. Without a set process in place, participant lists get saved into local spreadsheets; outreach comes from the researcher’s individual email rather than a shared inbox; notes are saved into private spaces on Notion and themes are mapped in Miro, or Figjam, or something else depending on who’s driving. With all these disparate threads making up your research repertoire, is it any wonder that so many companies have such a poor understanding of what their customers want?

This was exactly the situation I faced in a previous role. We had a good idea of who our ideal customer would be, but very little idea of how those people operated and therefore how best to serve them. We hypothesised, we leaned towards features that would be the most lucrative, we straight up guessed sometimes. Everything except just setting up a standardised process for talking to them.

I get why teams often don’t do this. I built the process to fix it, and it was time-consuming and exhausting. An endless tennis match of emails and link-sharing between me and Compliance, then Legal, then Financial Crime, then Data Protection, then the MLRO - all very helpful and positive interactions but so much red tape to navigate.

But therein lies the value; do it once, and you never have to do it again. Establish a transparent, set process that covers participant consent, GDPR, budget, frequency, approvals and incentive payments and you’ll eventually have a well-oiled machine that you can use proactively, not reactively.

AI is undoubtedly making everything faster, but we should direct at least some of this newly-available time into wider operational efficiency and better ways of working, not just faster engineering pipelines.

If I could go back and do one thing differently in my last role it would be to start working on the operational side of things before anything else. In retrospect, it would have saved so much time and misplaced effort on building the wrong things based on a senior stakeholder’s hunch.

Try spending an hour or so this week on your non-design, non-engineering workflows; map out the problem and the potential upsides, before getting into how it’ll work.

Designers are, rightfully so, concerned about their position in this new frontier world of prompts and agents; they’d do well to remember that designing processes and systems is still designing.