Three months in a hospital: why AI hasn’t made discovery optional

In late 2003 we had some matching software, a hunch and a conversation from a barbecue that wouldn't leave us alone.

A nurse and midwife we knew had some of her colleagues over for a weekend barbecue, and the conversation turned to how hard it was for nurse managers to find staff. When someone called in sick, the manager reached for a little black book or a handwritten list of favourite nurses and casuals and started ringing. Down the list, one call at a time, often late at night, until someone said yes. And it wasn't just their hospital. It was happening everywhere. It wasn't unusual for a manager to spend half of her shift searching for staff.

We had already developed sophisticated matching logic from our earlier work in permission-based mobile marketing, matching consumers to promotions. On paper, the jump looked obvious. How hard could it be to match casual nurses with shifts? Send a message instead of making a phone call. Done.

We didn't build it. Not then. After a serendipitous meeting with the acting Chief Nurse of NSW, we spent three months with Central Coast Health, two to three days a week, watching how rostering actually worked.

What we would have missed

The black book was the visible problem. It was slow, manual and exhausting, and anyone could see that.

What we only found by being on site was everything sitting underneath it.

The same nurses appeared on several managers' lists, so they got most of the work while others barely got a call. That frustrated the people being overloaded and the people being overlooked. The system wasn't just inefficient. It was unfair, and nobody had designed it that way. It had simply grown that way, one phone call at a time.

Then there were the rules nobody had written down in one place. Occupational health and safety requirements. Short shifts. Grades. Clinical skills that had to suit the ward. Constantly shifting personal preferences about where and when people were willing to work. Every one of those shaped who should be asked first, and experienced managers carried most of it in their heads.

If we had built the obvious version, a faster way to work through the black book, we would have automated the unfairness and skipped the rules that kept patients and staff safe. It would have been quicker. It would also have been wrong.

Cascom, the first version of what became ShiftMatch, soft-launched at Central Coast Health in April 2004. We ran it alongside the old way of working and kept refining it with the people using it. It dramatically cut the time managers spent ringing around to fill shifts, and the project went on to win the efficiency category at the 2004 Baxter Health Awards.

The questions we learned in that hospital became the foundation of the product for the next twenty-odd years. Who is available? Who is qualified? Who should be asked first? Is it fair? Is it safe? Everything that came later, from integrations to mobile apps to the agency network, was built on those answers.

Discovery didn't stop at launch

Those three months were the start, not the end. Every implementation after that was another round of discovery. Each new hospital, aged-care provider or school had its own rules, its own workarounds and its own idea of what fair looked like. Every training session taught us something too.

One of my favourite examples came from a nurse admin clerk in those early years. She would look at an unfilled shift, think of someone who should have been perfect for it, and wonder why the system hadn't asked them. She had a feeling they should match, and she wanted to know why they didn't. Staff were asking the same question from the other side: why didn't I get that shift, or why am I not getting shifts at all? Plenty of those questions landed with us as support requests, nearly all of them some version of "why not?"

So that's what we built, and that's what we called it. "Why Not?" let a manager pick a worker and a shift and see the exact reasons they didn't match. Maybe the worker had excluded that location. Maybe Do Not Disturb was on, or the shift was outside their grade or skills. Matching stopped feeling like a black box. The clerk could check her hunch in seconds, staff got a straight answer, and a whole category of support requests went away. More than fifteen years later, "Why Not?" was still in every user guide we wrote.

None of that came from a requirements document. It came from listening to the people closest to the work, and paying attention to the questions they kept asking.

Today there's a name for this: customer-led design. We didn't call it that at the time. It was simply how we worked, and it's why so many of our release notes credited a customer for the change.

But customer-led doesn't mean doing whatever customers ask. The clerk never asked for a "Why Not?" screen. She asked a question. Our job was to hear the problem inside the question, then design an answer that worked for every customer, not just one.

The learning went both ways. While we taught customers how to use ShiftMatch, they often saw their own processes clearly for the first time. Some rules turned out to be habits nobody needed. Others mattered far more than anyone had realised. At the same time, they were teaching us how their world really worked. The best implementations felt less like a handover and more like two teams working out the problem together.

AI has collapsed the cost of building

Today, a first version of that product could probably be prototyped in a weekend. Describe the workflow to an AI coding tool, connect an SMS service, and by Monday you'd have something that sends shift offers and looks convincing in a demo.

That's genuinely exciting. I use these tools every day, and the speed is real. The distance between an idea and a working thing has never been shorter.

AI is very good at giving you what you asked for. It's far less able to tell you that you asked for the wrong thing.

But speed changes where the risk sits. When building was slow and expensive, the cost of building the wrong thing was obvious, so you were forced to think first. When building is fast and cheap, the cost of misunderstanding the problem doesn't disappear. It just shows up later, after the product is in front of customers, the data model is set and people have started to rely on it.

AI is very good at giving you what you asked for. It's far less able to tell you that you asked for the wrong thing. It hasn't stood in the rostering office. It hasn't seen the workarounds, the unwritten rules and the trade-offs people make every day without thinking about them. If you hand it a shallow brief, it will build a shallow product, beautifully and at speed.

There's a lesson in "Why Not?" for AI products too. People trust a system they can question. If an AI makes a decision about someone's shift, pay or workload, the people affected will ask "why not me?" The products that last will be the ones that can answer.

The same risk applies after launch. It's tempting to let AI-generated guides and chatbots take over onboarding and training. They can help, but if they replace the conversations entirely, you lose one of the richest sources of discovery you have.

What good discovery looks like now

The principles haven't changed much since 2003. The way we can apply them has.

Go where the work happens. Documents, data and interviews all help, but watching someone do the job shows you what they've stopped noticing. That's usually where the real problem lives.

Look for the need behind the request. "Make it faster" was the request. "Make it fair, safe and trusted" was the need. Those lead to very different products.

Find the unwritten rules. Most of the complexity in any operation sits in people's heads. If you're going to let software, or AI, make a decision, you need to understand every rule that decision is quietly following today.

Use AI to speed up learning, not to skip it. This is where the opportunity is. Put a rough prototype in front of a scheduler on Tuesday instead of a polished product in six months. Use AI to synthesise interview notes, test assumptions and explore options quickly. Fast building is most valuable when it helps you ask better questions sooner.

Treat every implementation as discovery. Onboarding, training and support aren't the end of product work. They're where you find out whether your understanding holds up in someone else's world. At ShiftMatch, sales, implementation and support stayed close to product decisions for exactly that reason.

Make the learning two-way. The questions customers ask while learning your product often teach you more than the answers you give them. And when you help them see their own operation more clearly, the product gets better and so does the relationship.

The bottleneck has moved

For most of my career, the hard part was building. Increasingly, the hard part is knowing what's worth building. The teams that do well with AI won't be the ones that ship the most. They'll be the ones that understand the problem well enough to ship the right thing quickly.

Three months felt like a long time in 2003. Looking back, it was one of the best investments we ever made. It also set a habit we kept for the next twenty-odd years: every implementation, training session and support call was a chance to learn something we didn't know. That's what gave us a product that hospitals didn't just use, but trusted with their staff and their wards.

If you're working on a product where the speed of building is starting to outrun your understanding of the problem, I'd be happy to compare notes.