I never set out to be a founder. After 30-plus years building products at companies like MYOB, Aconex, Oracle and Prospection, I understood the rhythms of product leadership well enough to know "founder" is not a role you walk into lightly. You need a problem that won't leave you alone. Mine arrived on a Sunday afternoon, with a board pack.
It's finally the weekend.
It's Friday evening. You've had a big week. You sit down, open your laptop, and find a 200+ page board pack waiting for you. Board meeting is Tuesday.
So you start reading. And somewhere around page 40, you notice it: you've seen about 80% of this before. The structure is the same, the language is similar, the sections are in the same order. But somewhere in those remaining 20% are things that matter — what's changed, what's slipped, what should be keeping the executive team up at night.
Finding those things (really finding them, with confidence) takes four to six hours if you're doing it properly. And most directors aren't doing it with four to six spare hours. They're doing it in the gaps between everything else.
Somewhere in those 200 pages is the sentence that should have kept everyone up at night. Most directors skim past it.
I was sitting on boards while also working at Prospection, a company that had been doing rigorous AI and machine learning on healthcare data for over 12 years, long before the "ChatGPT / AI hype" made it fashionable. We were building models on hundreds of millions of de-identified patient records. I understood what AI could and couldn't do.
And I kept thinking: why can't board governance work this way?
The prototype nobody asked for.
So I did what product people do. I started building something for myself.
Prospection's CTO, Ricky Chen (someone I consider a guru when it comes to AI) supported me, and I began experimenting with large language models, training a personal setup based on ACID principles and real governance practices. It wasn't perfect — especially on financials — but it helped me prepare faster and more strategically. I could spot issues more easily. I had sharper questions. And more importantly, I felt a sense of control, rather than perpetually racing to get through the material.
Then I mentioned it casually to a chair I knew well. A few days later he called me back.
'I was on the golf course and told some other directors what you'd built — they want it too!'
That was the moment. It didn't take a market sizing exercise, it was before any TAM calculation. A chair on a golf course, word of mouth, directors with their hands up before I'd even decided to turn my personal AI tool into a real product.
Validating the pull.
Before committing to building a real product, I did the coffee and lunch circuit — catching up with leaders and executives in my network who also happened to sit on boards. The answers to "what's the hardest part of your director role?" were strikingly consistent across conversations: prep takes too long, the packs are overwhelming, things flagged last time get lost, the constant feeling of missing something important.
What stood out wasn't the volume of pain. It was the kind of help they wanted. They didn't want an AI tool that gave them a faster summary. They wanted one that helped them think. And more than once I heard a version of the same warning:
"Don't build a tool that flattens everyone into asking the same generic things. What I bring to this board is unique. The tool should make that sharper, not erase it."
That last point became a design principle that ran through every feature decision. The product had to be personalised to how each director thinks, not just to what's in the pack.
The Jobs to Be Done behind the pain.
Before writing a line of code, I used a Jobs to Be Done framing to get beneath the surface. JTBD asks not what people want a product to do, but what they're trying to accomplish when they reach for it. The job, not the feature.
Five jobs came up with striking consistency in my conversations with directors and chairs:
Job 1 — Detect what's changed.
When I receive a new board pack, I want to understand immediately what's new, what's changed, and what's recurring — so I can spend my limited prep time where it actually matters.
Job 2 — Track what's still open.
When I'm preparing for a meeting, I want to see what was flagged last time, what was resolved, and what's been quietly dropped — so I'm never blindsided and never let something slip through unchecked.
Job 3 — Walk in sharp.
When I've finished my prep, I want to feel confident that I've covered everything, have my key questions ready, and won't be caught flat-footed — so I can contribute strategically rather than reactively.
Job 4 — Hold executives accountable across cycles.
When something was discussed or committed to in a previous meeting, I want to be able to find it quickly — across multiple packs, using either a specific keyword or a vague half-memory — so I can hold management accountable without spending 45 minutes trawling through old documents.
This came up in almost identical language across multiple conversations: "I'm sure this was talked about a few meetings ago." "When did they say they'd have this done by?" "Why have they stopped talking about it?" The inability to quickly verify what was promised, when, and what happened next was one of the most consistent frustrations — and one of the hardest to solve without a tool that remembered across packs.
Job 5 — See the financial signals that don't announce themselves.
When I'm reviewing the financials, I want to be alerted to governance-critical signals that are easy to miss — like whether GST obligations are being paid on time, whether annual leave liabilities are building up, whether something in the numbers signals a cashflow problem that management hasn't flagged explicitly — so I'm not blindsided by insolvency risk or a regulatory issue that was hidden in plain sight.
This job resonated particularly strongly with financially literate directors — not because they needed help reading a P&L, but because they were acutely aware of the signals that sit between the lines of standard financial reporting. The kind of thing that doesn't get a red flag in the board pack but should.
None of these jobs were being met by existing tools. Board portals like Diligent distribute documents. Generic AI tools summarise them. Neither supports better governance decisions.
That gap was where Vizory would live.
A note on the audience.
Directors are a specific kind of customer. They're time-poor but not budget-poor. They're sceptical but not resistant to good tools. They have genuine liability concerns — both about the quality of their governance and about what happens to their data.
Another important aspect: they talk to each other. The director community, particularly in Australia, is tight. Which means word-of-mouth could be powerful — but also that a bad experience could travel just as fast as a good one.
I knew from the start that this market would reward depth of use and trust over volume of signups. The question was whether I could build something that earned both.