Can we go bigger?

In 2021, we couldn't build fast enough. So we did the sensible thing and brought our goals down to fit what we could actually build. Now it's the other way round. Building is the cheapest bit now.

Cutting those goals was the right call at the time. A goal nobody can build is just a nice slide.

This week we took a customer page from a prototype on real data to a live page in one afternoon. Not months. Not days. Hours!

So what do most of us do with all of these new tools? From where I'm sitting, we ask AI to clear the same queue a bit faster.

Visionary stuff.

I'm guilty of it too. We spent years getting very good at "what can we drop?", and nobody's stretched the "can we go bigger?" muscle in a while.

Well get ready: today we're going to work out that muscle.

And the things we never even tried deserve another look too.

Let's go!

We got very good at making do

Cutting the goal made sense. What happens afterwards is the sneaky bit.

The cut stops looking like a cut. A year later it's just how we do things, and nobody remembers there was ever a bigger version.

Years ago, when the product hit an error it couldn't sort out by itself, a developer stepped in and fixed it by hand.

Should we build something proper to handle those errors? Of course not. Fixing them by hand was the cheap option, and back then it was the right one.

Nobody was being lazy or daft. It was a sensible trade, and it became normal for the most boring reason there is: it kept working well enough.

You've almost certainly got one of these. It's the job everyone knows is a bit manual, that someone just handles, and that nobody has questioned in ages because it's never quite broken.

And a compromise that sticks around long enough gets its own furniture.

Then we organised around it

It got a channel and a weekly rota, so there was always someone on hand and it wasn't just the same one or two developers every time.

Then customer-service requests joined the pile. Move this, change that, quick edit to a record, please.

Then it spread: another rota, an urgent channel (for the requests that were more urgent than the other requests) and a service desk. Eventually, a proper board with response times on it.

Every step was an improvement. Honestly. A board with response times beats a developer quietly fixing things in a corner and hoping nobody asks.

But through every version, the same things kept happening.

"Urgent" stopped meaning urgent. So much so that I have screenshots of "URGENT" as single message sent to a colleague.

As we all know, uppercase is the right way to ask for something.

Every new tool made the queue tidier. None of them made it smaller.

The only thing that ever made a request go away for good was building the missing bit into the product.

Here's the part that I'd argue with anyone about: a manual request that keeps coming back is a bug report. The product is telling you something's broken or missing, and somebody is patching it by hand every time it comes up.

You don't need a developer rota to have one of these. In your company it might be the client who emails every Friday for the same export. The onboarding spreadsheet only one person understands. The Monday meeting that mostly decides whose turn it is.

Each of those is organised. Some of them are beautifully organised.

The question is whether they still need to exist.

Going bigger means the customer does it themselves

A customer needed a big batch of data updated to suit their needs. All in one go.

The usual answer? A request in the queue, and someone at our end doing it for them.

There are two ways to make that better. And I did both.

The faster one: I wrote a script so our staff could get through the whole batch at once. Quicker, definitely. But it's still a request, and the customer is still waiting on us. That's where most of us stop.

The bigger one is a question I'd already been asking: why don't we just let the customer do it in the product?

The script makes the queue faster. The question asks why the customer has to join the queue at all. And you can ask that about every queue you've got.

The day after the script, I had the self-serve version up for review. The customer uploads their list, checks a preview of what's going to happen, submits it, watches it run, cancels if something looks off and downloads the results at the end.

The real test is boring and simple: does that request stop landing in the queue?

This is what I mean by bigger. A better result for the customer, because nobody's waiting on anyone. More people served, without someone at our end doing each one. Or something useful that wasn't practical before. More output for its own sake doesn't count. Another report nobody opens is just more stuff.

None of this is free, by the way. Fast is great and rushed isn't. Whatever you build still needs reviewing, testing and somebody to look after it when it breaks. You're swapping a queue for a feature, and the feature needs an owner too.

Worth it for a request that keeps coming back. Probably not for one that turns up once a year.

Look past the queue

Everything so far started in a queue. Somebody asked, somebody waited, somebody handled it.

The queue only shows you what people ask for.

The bigger stuff is often what nobody asks for any more, because everyone learned the answer was no. Those requests don't sit on a board with response times. They don't sit anywhere. People just quietly stopped asking.

Here are three made-up examples to get you hunting for your own. Imagine a 40-person agency. (Entirely fictional. Any resemblance to your agency is a coincidence. Probably. Hi Mike 👋)

The service you only offer occasionally. The proper quarterly review, the one with real digging and real recommendations, only goes to the two biggest clients. Everyone else gets the standard pack. The smaller clients would love the proper one too. It just eats a senior person's week every time, so it's rationed.

The question nobody investigates. A client's numbers jumped between two reports. Everyone noticed. The account lead mentioned it on the call, somebody said "interesting", and the report went out saying what changed and never why. Nobody had a spare afternoon to dig into it.

The idea shelved as too expensive. Letting clients see where their job's up to on their own, instead of emailing the account manager and waiting for a reply. Somebody suggested it once. It got a polite "lovely idea, not this year", and that was the end of it.

Sound familiar? That last one is the same move as the customer approving their own batch. Different company, same queue in disguise.

In every one of those, the no was real when we said it. A client portal was a proper project. Digging into every odd number was a week nobody had. So the question for each is the same:

Is the reason still true, and when did anyone last check?

Some of them will still be a no. And not always because of the building. Maybe the data you'd need doesn't exist. Maybe it's a judgement only a person can make. Maybe the client simply won't change how they work (we all have one).

That's a fine answer. Write it down, with the date, so the next person doesn't have to work it out all over again.

You don't need an offsite to find yours, or a strategy day covered in sticky notes. One job, one conversation, one test.

Something you can implement by Friday

Reassess one part of your business by Friday.

You'll finish the week with a ranked "What we can do now" document and one real test of the assumption that stopped you. Allow about an hour for the interview, then book a slot later in the week for the test. In working time, please. Nobody gives up a weekend for this (I mean it).

Start with one job and three things. Pick one department or recurring job: quotes, onboarding, client replies, the monthly report, support. Then bring:

• the most recent real example of that job
• one idea you shelved as too slow or too expensive
• the person who actually does the work

Before you start, write four lines:

1. What happens now
2. The result you actually want
3. The old constraint that stopped you
4. The evidence for that constraint, and the date somebody last checked it

Line four is usually where it gets interesting. If the honest answer is "everyone just knows", write that down too.

Let the AI do the interviewing. Get the person who does the work in the room (or on the call) and open the AI tool you already pay for. Take out any client data you aren't allowed to share first. Then paste this:

I want to reassess one recurring job in our company: [job]. Interview the person who does it, one question at a time. Start with the most recent real example: what arrived, what they did, which tools they used, who waited and for how long, and what went wrong. Then ask about one idea we shelved as too slow or too expensive, and one service we only offer occasionally. For each one, ask what stopped us and when we last checked that the reason was still true. When you have enough, sort what you've found into three groups: work we could remove, service we could improve, things we could now attempt. Bigger means a better result, more people served or something useful we couldn't do before. More output doesn't count. For every opportunity, write: current practice, old constraint, proposed outcome, evidence, unknowns, first test, owner and pass condition. Use only evidence we've given you. Label each one demonstrated, plausible but untested, or still blocked. Don't invent software features, integrations or time savings. If something depends on a tool or data you haven't seen, say so. Rank the list, best first, and say why. Finish with one experiment brief for the top item: who owns it, what they need, what they'll produce and how they'll judge it, tested on one safe, real example from the last month. If anything is unclear, ask me before you guess.

The prompt fusses about evidence and labels on purpose. Left alone, AI will happily promise features your tools don't have and savings nobody measured. "Plausible but untested" is a perfectly good answer. It's honest, and it tells you exactly what to test.

What comes out. A ranked "What we can do now" document in those three groups, every opportunity filled in with the eight fields and a status label, and one experiment brief underneath.

Here's what one entry might look like. Hypothetical example, made up for illustration: the monthly client report.

• Current practice: someone pulls the figures into last month's template and sends it.
• Old constraint: nobody had time to work out why the numbers moved, so the report says what changed and never why.
• Proposed outcome: each report explains the biggest changes since the last one, with the evidence behind them.
• Evidence: on the last few calls the client asked why, and the account lead answered from memory.
• Unknowns: whether the data explains the change, or only the account lead knows.
• First test: run last month's pair of reports through it and compare the explanation with what the account lead already knows.
• Owner: the account lead.
• Pass condition: they'd send it with light edits.
• Status: plausible but untested.

No savings, no results. It's a thing worth checking, and that's all it claims to be.

Then the check. In that booked slot, run the top item's first test on one safe, representative real example from the last month. Work on a copy, and nothing goes to a customer without a person checking it first. Then mark the item demonstrated or still blocked, and update the document.

Either result is useful. One of your old "we can't" assumptions has finally been checked, and now it's written down with a date on it.

I've made a one-page PDF with the prompt and a What we can do now kit with an editable template and a filled-in fictional example. Use the prompt on its own or take the helping hand.

By Friday, aim for one ranked document, one experiment brief and one test result.

If it worked, tell me. If it didn't, tell me too. I'd love to see what ends up back on your list.

No manual yet

In 2021 we cut the goal to fit the build. Now the build is the cheap bit, so the goal is what needs another look.

The request we learned to put up with. The customer who could do it themselves. The idea that got a polite "lovely idea, not this year".

Every one of those was a sensible no when somebody said it. Some will still be a no. You only find out which by checking, one job at a time. There is no manual yet. (OMG so meta!)

I'm still ridiculously excited about what we can build now.

I'd just like one queue to get smaller instead of better organised.

You survived another week in this strange new world AND another one of my articles. Amazing!

Over to you now: what did you cut back when building was slow, and has anyone checked whether it's still too expensive?