What Building QFlo Taught Me About Product

QFlo started as a simple premise: digitise queues. Give businesses a way to manage foot traffic, give customers a way to stop standing around.

Simple premise. Messy reality.

The Problem We Thought We Were Solving

We went in thinking the problem was organisation — businesses didn't know how many people were waiting, in what order, for what service. A dashboard and a ticketing system would fix it.

We built that. It helped. But usage data told a different story: the businesses that got the most value weren't the ones with the cleanest dashboards. They were the ones whose customers changed their behaviour.

The real problem wasn't that businesses couldn't manage queues. It was that customers hated the uncertainty of waiting. Not the waiting itself — the not knowing.

What We Actually Built

Once we reframed around the customer experience, everything shifted.

Live status updates became the core feature. Not the admin dashboard. When customers could see "you're 3rd in queue, estimated 12 minutes," they stopped hovering at the counter. They sat down. They went to grab coffee. Staff interactions became less anxious.

The dashboard was for the business. The status broadcast was for the customer. The value lived at the intersection.

The Lesson

The hardest thing in product work isn't building features. It's resisting the first framing of a problem long enough to find the real one.

We almost shipped a glorified spreadsheet because our initial brief came from operations managers, not the people standing in line. The brief was technically accurate. It just wasn't solving the right thing.

Now I start every product conversation with: who has the worst experience here, and what does their day look like? Not what do they need — what does their day look like. The need usually emerges from that.

QFlo is better software because we got this wrong first. Most good products are.