Acceptance un-criteria

We’re usually measured by how well we deliver what’s asked of us. But that alone does not account for doing the right thing.

A feature request is a good example of this idea. By the time a request becomes a ticket, it has lived a long life. On enterprise projects, it has sat through meetings and budget talks. It has survived a few rounds of approval and at least one heated debate. Then it reaches us, and we write the final chapter: the user story, the acceptance criteria, the test scenarios. 

But how much of that information is enough to build the right thing? Our best creation comes from being curious enough to read between the lines. 

Tracing the story back

The interesting bits are outside the brief. How does the client’s business make money? Who uses what we build, and what else are they juggling? Which teams, systems and vendors touch this feature? Who maintains it after handover? And could the team challenge some of the assumptions behind the request? 

The backstory looks different from every seat. An engineer might see the feature built for the editorial team differently from the PM who knows the client and the history behind the request. The most curious readers are often the newest who haven’t learned to accept things as they are. Their curiosity has more than once led to real fixes or a better UX we took back to the client.

Recently, an enterprise client brought us a fully formed feature request. It was signed off internally, the behaviour was mapped out, and it came with a diagram. The easy path was to estimate it and start developing. Instead, the team asked why it needed to work that way and whether there was a simpler route to the same outcome. There was. The agreed solution cost less to build and worked better for users.

Return On Curiosity

For the client, it starts with time and money. Every feature in a large organisation comes with approvals, training, documentation and years of maintenance. Building less of the wrong thing saves all of that. Users get something that fits how they actually work. And over time, the client gets a team that brings ideas instead of waiting for instructions.

For our people, it builds judgement. An engineer who knows why a feature exists makes better small decisions independently. Their estimates get sharper and they spot problems before they become tickets. That’s the difference between being handed work and being trusted with it. 

And yes, it’s good business. Less rework protects margins. When clients see that we understood what they needed, not just what was written, they come back. They bring us the next project, extend the engagement, and sometimes introduce a sister brand or another division. In service business, growth comes from noticing nearby needs and caring enough to solve them.

Asking more better questions

Curiosity has a cost, and clients pay part of it. Asking what’s already in the brief makes it look like we haven’t done our homework. On enterprise accounts, one question can pass through three inboxes before anyone answers. 

So start with what’s already there: docs, the live site and project history. The questions that reach the client should be ones no document can answer.

AI can help connect the dots across papers and months of decisions in minutes. It reads the backstory faster than any of us, as long as it’s written down. But not everything can be found on paper. What problem did nobody think to mention? What workaround does an editor use everyday? Those answers don’t come in the request and someone has to be curious enough to ask.

Next time you open a ticket

If you build things, answer one thing the ticket doesn’t say: who will use this, and what will change for them once it ships? If you can’t answer, spend ten minutes finding out.

If you commission the work, notice whether your team ever asks about the backstory. A team that reads only the last chapter delivers exactly what was written. A team that reads the whole story delivers what you need.

Knowing what to build gets the work done. 
Knowing why makes it worth doing.

There’s plenty more to share on this in later editions. For now, check out my WordCamp Asia 2026 talk, “Project Delivery: Somewhere Between Plan A and Reality.”