Ryan Stuart and the art of changing his mind

Ryan Stuart wanted to change his home internet plan. He chose live chat, hoping to avoid the support line. Forty-five minutes and three virtual transfers later, he was told to call the support line anyway. Then came the automated survey asking him to rate the experience. The company had managed to make a simple request complicated, and now wanted a little administrative assistance with the aftermath.

Stuart recounted that episode in February 2018. By then, he was running Kapiche, a Brisbane software business concerned with what companies do with the things customers tell them. His complaint was familiar enough to require very little explanation. The interesting part was his response: he wanted businesses to find the common concerns buried in all those individual encounters, then do something useful with them.

There is a pleasing complication in his career. Before helping companies listen, Stuart had to learn to listen himself. His own descriptions of building Kapiche contain mistaken assumptions, outside advice and decisions he later reconsidered. The software keeps changing. So does the founder.

A friendship with a very long development cycle

Stuart and his co-founder, Kris Rogers, met in Grade 8. Both went on to study engineering at the University of Queensland, and both spent about seven years working as software engineers before building their own business. Their partnership predates the pitch deck by a considerable margin.

Stuart attended UQ between 2003 and 2007, studying software engineering. His professional background includes engineering and product work at Daesim Technologies and Leximancer. Those roles put him inside the practical business of making software work, rather than merely discussing what it might eventually accomplish.

The engineering identity has survived the CEO title. His public GitHub profile describes him as a software engineer interested in using data to improve decisions. His Stack Overflow biography names Python, Java and JavaScript among the languages he worked with, and describes a focus on text analytics. There is a trail of technical questions behind the business vocabulary.

Kapiche’s account of its beginnings includes a local cafe, several unsuccessful attempts and successive versions of the product. It is an appropriately ordinary setting for a company devoted to understanding ordinary language. Two old friends, some coffee and a problem that refused to become simple just because they could write code.

The garage had algorithms. The market had questions.

Stuart and Rogers initially tinkered with algorithms and built small prototypes. In his account of those early efforts, Stuart admitted that they had developed products without consulting potential customers. “We built them without talking to anyone,” he said. It is a short sentence with an expensive possible sequel.

In mid-2016, the business entered the CUA Sponsored Entrepreneur Program at River City Labs. Kapiche launched in April 2017 and soon secured a paying customer. Later that year, the founders joined the River City Labs accelerator powered by muru-D. They arrived with software and customers, while acknowledging gaps in their commercial experience.

By September 2019, Kapiche had announced an A$1.75 million funding round led by Main Sequence Ventures. Transition Level Investments, the River City Labs Accelerator Fund and Queensland’s Business Development Fund also participated. Stuart was discussing plans to sell more actively in the United States.

The money gave the enterprise a public milestone. The earlier admission gives the milestone its meaning: technical effort had needed contact with the people expected to pay for it. A working prototype can answer whether something is possible. A customer has a rather different question about whether it is worth buying.

Fifteen possibilities, one useful question

In a February 2018 reflection on the accelerator, Stuart reported that Kapiche had tripled its paying-customer count in four months. He described a narrowing of focus: the team had identified 15 possible uses for its technology, then talked to existing customers about why they were actually using it. Customer experience emerged as the immediate focus.

Advice arrived through people as well as programs. Mike Knapp pointed the team toward Crossing the Chasm. Vu Tran encouraged them to understand buyers’ problems. A workshop with Anamaria Nino-Murcia helped Stuart think about team alignment. He had assumed engineering would be the difficult part. Leading people supplied a correction.

That same year, attending SaaStr Annual prompted another review of his habits. Listening to David Skok, Stuart recalled occasions when he had talked about Kapiche’s features instead of buyers’ problems. He also identified Aaron Ross’s Predictable Revenue as a favourite book and expressed a wish to return the support he had received from other founders and investors.

These are revealing choices of detail. His recollections make room for teachers, reading and the practical mechanics of selling. The founder appears as a student of a business he was already responsible for running.

“why are you using Kapiche?”

Ryan Stuart, recalling the question put to existing customers

The score still needs a story

Stuart’s customer-experience writing repeatedly returns to a problem with tidy numbers: they can leave the person interpreting them with very little idea of what to do next. A satisfaction score records an answer. It still needs context about the customer, the complaint and the consequences for the business.

In his 2022 article on assigning a dollar value to Net Promoter Score, he encouraged companies to connect responses with account-level financial information, examine customer behaviour and state their assumptions. The point was to work out where improvements might have commercial value, rather than treat the score as an instruction in itself.

He develops a related idea through the familiar progression from data to information, knowledge and wisdom. Raw responses need organisation. Organised responses need interpretation. An interpretation needs the context of the business before it can guide a decision. Each step asks more of the reader than possessing a spreadsheet.

The diagram is simple. Following it is less so. A company can have a beautifully maintained collection of customer answers and remain uncertain about which problem deserves attention first. Stuart’s argument places responsibility on the people using the information: they must connect it to an action they can take and an outcome they care about.

Taking a turn in the interviewer’s chair

Stuart has also built a public conversation around these questions. He hosted Insightful Leaders, interviewing people working in customer insights and experience. Guests included Virginia Wheway at Koala, David Gardner at Talkdesk and Colin Shaw of Beyond Philosophy. Topics ranged from bringing customer data together to understanding the reasons behind behaviour.

The choice of format matters. An interview gives another person room to describe the decisions, constraints and mistakes behind a polished result. For a founder whose early commercial progress depended on asking customers better questions, it is a fitting way to continue learning in public.

He appeared on Adrian Brady Cesana’s CXChronicles in February 2022, discussing the development of Kapiche and the relationship between numerical measures and written feedback. He has also joined discussions on behavioural science with Steven Hill of RAC WA and Jason Jacobson of Sekisui House.

There are concrete examples of what this work can produce. A 2023 account of RAC WA’s use of Kapiche reported that insights arrived 30 times faster than with its earlier manual method. For Stuart, the application of the engineering is visible in the work people can finally get through, and the decisions they can make afterwards.

A colleague records a change of mind

In November 2024, Kapiche account director Ika Albers publicly described Stuart reversing his position on a self-service free trial. She said he had long doubted the value of offering one. Changes made possible by generative AI helped alter that judgment, allowing people to explore demonstration data themselves.

Albers presented the episode as an example of a leader willing to acknowledge an error. It is a colleague’s assessment, attached to a specific decision. There is no need to inflate it into a sweeping declaration about his character. A founder had held a view. The conditions changed. The view changed with them.

The company’s own description of office life offers a lighter glimpse of the surroundings: Friday board games, coffee and arguments about why saucepans are called saucepans rather than saucepots. The cookware has apparently received the kind of linguistic scrutiny one might expect from a text-analytics business.

That little detail sits comfortably beside the serious work. People who spend their week turning language into categories are still allowed to question the categories in the kitchen cupboard.

Fast answers, with someone checking the work

Stuart has embraced generative AI while keeping an engineer’s concern for what the output actually means. In December 2024, he described using ChatGPT to accelerate coding and to think through strategy. He attached a qualification to the coding benefit: experience helps an engineer evaluate the suggestions.

A December 2025 announcement about Kapiche’s AI Themes made the concern more explicit. Stuart described combining generative AI, vector embeddings and clustering, with users retaining oversight. He framed accuracy as consequential for people presenting analysis that could influence product and revenue decisions. An answer delivered quickly still has to withstand questions.

Kapiche’s work with Google Cloud provides a view of the machinery behind that ambition. The relationship began in 2020. The company now uses Gemini through Vertex AI to summarise feedback themes, alongside tools for language processing and translation. The technical choices serve the same practical task: make large volumes of customer language usable by the people responsible for responding.

His more recent writing extends the listening program beyond surveys into calls, chats and emails. He asks teams to consider how much feedback sits in separate systems, how quickly they can respond and whether they can explain the business impact. Those questions preserve a useful impatience with collecting things merely because collection is possible.

Return to the internet-plan story and the ambition becomes easy to recognise. A customer had already explained what he needed, several times. Asking him to complete another form added one more response to the pile. Stuart has spent years working on what happens to that pile. Along the way, he has had to examine the answers he brings to it himself.