Vizory
— Part 6 of 6 · Building Vizory

What I Built, What I Learned, What Comes Next

The unintended discoveries, the things I'd do differently, and why this matters for what I do next.

Every product journey teaches you things you didn't expect to learn. Here are the ones from Vizory that I think about most.

What surprised me.

Working with AI agents is fundamentally different from managing a team — in mostly good ways.

I've spent 30 years in product leadership, which means 30 years of learning how to communicate clearly to people, align teams, manage ambiguity, and translate strategy into execution. Building Vizory required all of that — but directed at AI systems rather than humans.

What I found was that the core skill transferred surprisingly well. Clarity of intent, precision of instruction, rigorous evaluation of outputs — these matter as much when working with language models as when working with engineers and designers. What you lose is the ability to have a nuanced conversation about 'what we're trying to achieve.' What you gain is speed, availability, and a collaborator that never gets tired or defensive.

The thing I loved most though is that you can cover an enormous amount of ground without the overhead of constant communication. You still need to communicate your intent clearly — but to an agent, not to a team of people with their own contexts, constraints, and competing priorities.

Two models are better than one.

One of the more unexpected technical learnings: using multiple AI models — with a third model evaluating the best response from the first two — produced significantly more resilient outputs than relying on a single model. This improved accuracy, and also provided insurance against model deprecation (when a provider retires a model, you're not scrambling) and produced better analysis on complex governance content.

This architectural decision paid dividends we hadn't fully anticipated when we made it.

The ICP advantage of niche.

One of the strategic choices I made early that I'd make again: resist the temptation to broaden the ICP to accelerate growth. Staying tightly focused on non-executive directors — rather than expanding to CEOs, board chairs, company secretaries, or investors — kept the product coherent and the messaging focused.

There could have been a version of Vizory that tried to be everything to everyone in the governance ecosystem. That product would have taken three times as long to build and been half as good for any individual user. The nicheness of Vizory was a core selling point.

What I'd do differently.

Three lessons that I'll carry forward into whatever I build next.

Go-to-market testing: start as soon as you can, stop building if you can't see a path.

The advice to "validate your channel as early as your product" is right in theory but harder to apply when your entire thesis is that you don't need one. My hypothesis was explicitly B2C — directors buying directly, no intermediary required. And early evidence supported that approach — the pricing survey showed willingness to pay, the discovery sessions showed genuine pain, the early adopters signed up. Nothing in that data told me the channel-free model was wrong.

What I couldn't know until I actually had a product in people's hands was whether the buying motion would stay simple once word spread beyond my immediate network. It didn't. As soon as directors started recommending Vizory to others on their boards, the chair got involved. Then the co-sec. Then someone's head of AI. The simple B2C purchase quietly became an enterprise conversation — and that only became visible through real usage, not research.

So the lesson isn't "test the channel earlier" — it's more specific than that. As soon as you have enough of a product to see real buying behaviour, shift attention to the go-to-market question with the same rigour you applied to the product.

Watch how the sale actually unfolds. Ask whether what you're seeing is scalable without a structural change. And if you can't see a viable channel at that point — don't keep building more product. The product won't solve a distribution problem.

Trust takes longer to build than you think — especially when you can't show the comparison.

Time to value is one thing. Time to trust is another.

With Vizory, the value became clearer across board cycles, but trust in the product, and willingness to commit to it, required directors to have something to compare it against. That comparison takes time to accumulate when your product is only used four to six times a year. You can't shortcut it the way you can with a daily-use tool where someone sees the benefit within a week and decides to keep going.

If you're building something people use frequently, trust compounds quickly. They see the product working, they build confidence in it, they tell others. The feedback loop is fast. If you're building something people use infrequently — quarterly, in high-stakes moments — the loop is slow by definition. You need to account for that in how you think about trials, conversion timelines, and how early you ask people to make a commitment.

What I'd do differently is a simulated second-cycle view that shows what the memory layer looks like once it's had time to work. Something that lets a new user see the "before and after" without having to wait three months to live it. The 'aha' moment is real — it just needs to arrive before the trial runs out or patience runs thin.

Know your anchors — and have a counter for each one.

Every market has anchors — the things that already exist in your buyer's mind that they'll use to evaluate your price, your category, and your value before you've said a word. It's critical to identify them early enough to build a positioning response.

For Vizory the anchors were obvious in hindsight. ChatGPT at $20. Claude at the same. The frame in people's heads was "AI subscription" and the reference price was consumer. No amount of explaining the difference between a general-purpose chatbot and a purpose-built governance tool fully dislodged that comparison for some buyers — because anchoring doesn't yield to logic, it yields to a better anchor.

You have to identify what your buyer is comparing you to before you go to market, and then build your positioning around replacing that anchor with a more favourable one. For Vizory the right counter-anchor wasn't ChatGPT — it was the cost of a governance failure, or the hourly rate of the time being wasted on manual pack prep, or the D&O liability a director carries into every meeting. Those framings existed and worked when I used them.

Find the anchors, build the counter, make it a central part of the pitch.

The framing work that paid off.

Three pieces of structured thinking I did before and during the build turned out to matter more than I expected at the time. Worth naming them because they're transferable to any product effort.

JTBD as a design framework.

Looking back at the JTBD Stories developed for Vizory — across document analysis, risk, questions, notes, cross-pack tracking, meeting modes — they held up well as a design framework. The discipline of asking 'what is this person trying to accomplish, and what gets in the way?' consistently produced better feature decisions than asking 'what features would be interesting to build?'

The three jobs that proved most valuable in practice — detecting what's changed, tracking what's still open, walking in ready to go — mapped almost perfectly onto the features that got the strongest reactions in user testing. That alignment strengthened my belief in the JTBD approach, something I've used in various roles over the years. It was genuinely predictive.

The business case document.

Before I moved into formal positioning work, I wrote a business case document — a structured articulation of the problem, the solution, the ICP, the moat, and the value proposition. This wasn't for investors, just to articulate my thinking.

The document forced a level of precision that the JTBD work alone hadn't required. It made me describe the competitive moat clearly: what would be genuinely hard to copy over time (Australian data residency, persistent context across meetings, the financial intelligence layer), versus what was a strong feature but replicable (role-aware coaching, promptless navigation). That distinction was important for prioritisation. You invest differently in moat compared to a differentiator.

The document also introduced a framing that stuck: the three motivations driving real adoption in this market.

These three became a filter for every feature decision: does this reduce liability, build credibility, or deliver clarity?

Sharing it with prospective early adopters was also a test in itself. How people responded to the document — which sections they lingered on, which questions it prompted — told me as much as any formal survey. The liability and clarity framings resonated immediately. The credibility framing resonated more slowly, but proved to be the stickiest: directors who cared most about their reputation in the room were ultimately the most motivated users.

The messaging house.

Once the JTBD work had shaped the product direction, I built out a formal positioning and messaging house. If you can't state precisely what you are, what you're not, and what you uniquely deliver, the product decisions that follow will be fuzzy. The messaging house kept us honest.

The promise we landed on: supporting directors to think clearly, question deeply, and lead with conviction — by revealing the signals that matter, tracking what's changed, and prompting more confident decisions. The elevator pitch: Vizory transforms heavy board packs into tailored insight. Directors don't just read the pack. They see what it means.

The "what Vizory is / is not" framing was equally important as a design guardrail. Vizory is: a private workspace for board intelligence and decision preparation; a context-aware support tool for surfacing gaps, patterns, and questions; a memory aid for long-arc governance and recurring board themes. Vizory is not: a dashboard for management; a compliance checker or legal substitute; a tool that replaces judgement with automation.

The exercise also surfaced a distinction that proved useful throughout the build: the difference between business value and persona value. Business value is rational and quantifiable — reduced prep hours, higher issue closure rates, earlier risk detection. Persona value is emotional and variable — "I feel in control again, even across multiple boards." "I want to show up sharp and contribute real value." "What if I missed something important?"

Both matter — but they need different arguments and different moments. The business value case works in a formal pitch or a chair's approval process. The persona value case is what made individual directors actually sign up. I found myself using the rational framing for gatekeepers and the emotional framing for users — which was itself a signal about the channel problem I'd encounter later.

One more positioning element worth calling out: the "shame-free" private workspace concept. Directors rarely admit what they don't know — especially in high-stakes or unfamiliar domains like AI, technology, or ESG. Nobody sees your questions, your gaps, or your growth. It's a personalised, confidential space to prepare and sharpen understanding without fear of exposure. That privacy angle meant a certain level of security, but more importantly it was a distinct piece of the value proposition that made directors willing to engage with the tool in ways they'd never engage publicly.

Where Vizory sits now — and what comes next for me.

Vizory has found its natural home.

The product will move into an established board services organisation — one that already has the client relationships, the governance expertise, and the credibility with ASX-level directors that a tool like this needs behind it to reach the market it deserves. The value chain makes sense: advisory services, then AI-assisted pack creation, then a platform that can analyse, host, and manage the pack. Vizory is the third step in that sequence. I'll continue to be involved as a product advisor as it develops within that context.

This is the outcome I was working toward once the channel problem became clear — finding a partner where the fit was genuine and the value chain was already pointing in the right direction.

As for what I'm doing now: everything I learned from Vizory — the AI-first product build, the hands-on work with directors and boards, the deep understanding of what governance technology can and can't do — is going into the work I do best. Helping execs and boards ask better questions of the technology and product leaders who report to them — so the conversation between the boardroom and the people building the future is sharper, more honest, and more useful on both sides.

Helping CEOs and executive teams understand where product sits in an AI-first world — what's truly transformative, what's hype, and how to make decisions that hold up over time. Helping product and technology leaders build better, think more clearly about what they're building and why, and make that case to the people above them who need to hear it. And helping the builders themselves — the people actually creating the products — hone their craft, ask better questions, and do the work with more rigour and more confidence.

The Vizory journey was one of the most intensive product management experiences of my career — because I was the PM, the researcher, the strategist, and the founder simultaneously, with real commercial stakes and real users.

I set out to solve a problem I'd lived, and I did. The product works. The directors who used it got what I wanted them to get. I knew most of these lessons going in — I'd seen pricing get away from products before, and I know distribution is structural, not tactical. What I'd genuinely underestimated was how much the building itself would test me. Not the technical work — the small-team work. When you're two people with limited resources solving something hard, every weakness is exposed and every dependency on the other person matters. There's nowhere to hide and nothing to coast on. It's the most honest test of how you operate that I know of.

Which brings me to Toby Vidler.

Toby and I had worked together at Prospection before founding Vizory, so I knew he was technically excellent. What I learned during this build was harder to know in advance: that under sustained pressure, with real constraints and the kind of fatigue that compounds over months, our working relationship didn't waiver. Toby brought thought and care to every architectural decision, and the security foundation he built gave us something to stand behind with absolute confidence in every demo and every conversation. That stability under pressure is not common, and I don't take it for granted.

He's smart, trustworthy, and has a way of working through hard problems that very few people have. I'd recommend him in a heartbeat.

Vizory is moving to the right home. The learning stays with me. The respect for what's possible when two people get the small-team thing right — that stays too.

— Kirsten Mann · Founder & CEO, Vizory · connect@vizory.co

— Closing

If you've got a problem this kind of thinking would help solve —
let's talk.