Beyond Rituals: Rethinking Product Discovery in the Age of AI
The Superstitious Pigeons
Xavier Rizos uses B. F. Skinner’s pigeons to argue that product teams can mistake ritual for causation. He connects the startup boom and corporate adoption of design rituals to favourable macroeconomic conditions rather than the rituals alone.
Product Rituals and a Renaissance Parallel
Journey maps, personas, sticky-note boards and service blueprints are examined as costly artefacts that may not improve outcomes. Rizos compares this to medieval scholasticism and the Renaissance shift from copying inherited texts to observing the world.
What AI Changes
AI changes the prototyping trade-off by supporting wider, faster and sharper exploration. A Singapore Airlines project illustrates how an AI-enhanced approach compressed an eleven-week forecast to five weeks.
Prompt and Context Engineering
Detailed prompts become the unit of work, while a shared repository stores meetings, research, rules, designs and code. Dynamic, project-specific context enables AI to triangulate information and narrows the divide between designers and engineers.
A Kids-Banking Project in the IDE
Rizos walks through turning research transcripts into flows, prompts, prototypes, code, personas and journey maps inside an IDE. The demonstration shows why rules and context matter more than undirected vibe coding.
Which Rituals Should Survive?
Historical examples show that practices often mutate rather than disappear. Rizos closes by asking teams to keep useful maps of the territory while using AI to reduce production cost and focus human effort on direction and judgement.
Just not to redo an intro, but why am I here why am I here and what am I going to talk about? So during the day, I work in tech. I work in tech. I work in AI. I work for an organization that actually we do deliver projects, but that's probably the the interesting bit here is that we do work very closely with an organization called GitHub, and we pilot and test things that make features that make us features on your laptops when you use Copilot when you install a new version.
So we're part of these people who actually push the boundaries of their of their tool. That's what I do during the day. And at night, I've got a hobby, which I love history, and I love history so much that I gave a talk at Ignite last year about this, and I I wrote a textbook that is used in Australian high school today.
And what I would like to do today is a mashup between tech and history, and you you could see in the in the early talk how history is pertinent for this topic of AI and where it's taking us. So let's start with a bit of history. We're in the nineteen sixties, and a US psychologist in the name of BF Skinner does an experimentation with pigeons.
He feeds them at random times, and he notices that the birds start to elaborate very bizarre rituals around the feeding, and they start to switch legs. They start to move their wings because they start to develop a superstition that by doing those little those rituals, they make the food appear, where, in fact, the food was totally random.
So I would like to put a proposition to you that when it comes to product discovery and design, we are those pigeons. I'm going a little bit hard, and I'm going to soften towards the end. So our experiment is not Skinner's. It's what we can call two decades of startup design superstition.
We are at the back of a profound transformation on the markets and in business where those entities called startups with their very peculiar culture and practices, and we're not talking just about beanbags. We're talking about design thinking, lean start up framework, agile frameworks. I've been quite successful at transforming the fabric of the ecosystem, especially if, like us, we work in digital and tech.
I would contend because I'm more of a macro guy than a individual business and equity person that the rise of those 20 founders, and don't get me wrong, some of them very, very smart and smart people at the right place at the right time, who saw a material prize, who think their own clever strategies and their culture could be explaining those startup successes, I would actually contend that that period was actually a massive macroeconomic tide lifting all boats.
We were on the back of the GFC. We were living in a zero interest rate interest rates environment, so capital was actually flowing to those startups. The tech was maturing. The tech was actually ready for the taking and to actually deliver on the expectation. But what happened, interestingly, is that on the other end of town, the big guys, the big corporate, started to actually see those school kids and were desperate to imitate them.
And they started to adopt those performative rituals. The design thinking artifacts started to make it to executive committees. The field trips to Spotify in Silicon Valley. I worked for a very well known big bank in this country where it was a ritual for the execs to go to visit Spotify and to try to transform that other side of George Street.
And if you think a little bit harsher, we can ask this question. Did mimicking those rituals fix product in corporate? So I think no, but it did train an entire generation of people. I benefited from it. I think a lot of of us in this room have benefited. So two things can be true at the same time.
Now what are those rituals? It's drafting those journey maps. It's filling those mural boards with sticky notes that are sitting somewhere in the clouds and I've never seen since the workshop. It's elaborating those personas that nobody uses. If every single time I walked into one of those workshop and I was told that Jake is a 30 year old aspirational, and he has a dog called Lily, and I would sit there and wonder why I'm spending six weeks of my time.
Hi. Okay. And this design service blueprint. Now if you think that I'm a little bit harsh, and I'm probably a little bit k? Besides whoever read that. And moreover, even even even if they are very well facilitated, they still require a ton of manual work and disconnected steps and tools that create a lot of friction.
So I would like to ask this question again. Are we creating these because they work or because they we think they make the food appear? So now I'm going to switch back from tech to history. I am absolutely fascinated by a period in history that is towards the end of the Middle Ages in Europe.
So Europe had emerged from what we call the Dark Ages. Okay? And you had a fairly sophisticated society and culture there, but the savants, the scholars, entered into a practice that is that was called scholasticism. So they kept looking for answers in ancient Latin text. So if you remember the movie, The Monty Python, the life of no. Not the life of Brian, the other one, the holy grail.
You see the monks that are banging their heads with a plank of wood? That was basically what those knowledge workers of the times were doing. They kept looking into the ancient texts for the answers of the their world. So what had started as a method, which, you know, was probably rightful, which is let's go back to the classics and see whether they can enlighten us, became a doctrine.
They fell in love with their artifacts rather than their outcomes, and they literally confused the map for the territory. And this is what the Renaissance aimed at killing. Okay? The Renaissance says, kill those rituals, get out of the building. You will not find the answers in those texts. You will find the answers in observing the world. And because we are at a web direction, we could not go without a web meme.
And one of my favorite memes, and thank you, Cheryl, for pointing it out, is that imagine after centuries of copying and pasting medieval miniatures in manuscripts where you see how, you know, little horses are being drawn, and your patron comes to you and say, okay. You're going to draw a horse now from the front, and you go, yeah. Alright. I know how to do that.
And that's what you end up with. So what happens when you move to the Renaissance thinking and you get really serious about studying anatomy and how life works? Well, you move your thinking and your mental model from copying manuscripts to producing content. And you see where I'm going there in terms of AI. You generate sketches. You build your prototype, and you end up with a product that is far much more elegant and beautiful.
So my contention today is that we are in a parallel paradigm. I don't want to insult the product and design community. But, you know, just for the sake of the challenge, I'd like us to actually challenge ourselves and actually kind of squint at this and think that all these elaborated rituals that we've built around correlation might actually be a mistake for causation.
Now there is a reason we did this. Okay? Because we come from this world. We come from this very white, stale, madman type of world where people would be imagine a workshop, and these little chucks is our customers on the map, and we are heading to our north star.
And this is literally where we've been working. I started my working in the nineties at the end towards the end of the nineties, actually, that looked like this. And it literally was looking looking like working in the matrix. So when we, as a community, came up with those new ways of working, they were rapid, they were cheap, they were flexible, they were engaging, They actually were truly okay for prototyping.
These are pictures I took from my time in the innovation lab at Westpac, but they were very problematic to deliver to production. And if I can swear on microphone, they literally were shooting the bed when it was about delivering products to the consumer because the expectation you had created with your prototype didn't match the there was too much friction, didn't match the the thing that had to be delivered. So what happens when we inject a little bit of AI and we take a step back?
So if we challenge those rituals, you've seen this diagram. I find it quite illustrative of the mindset. We've come from this world of waterfall where nothing got done until the end, and it was always over budget. With agile, I personally believe that we came up with a machination with a little bit of a trick and an invention when we spoke about MVP. It was a way to try to be cheaper but finding our way because producing code was still very expensive.
Besides, why did we give the user a skateboard to work with when we knew from the start that they wanted a car? Now with AI, sure, AI could give you a homeroomobile if you don't prompt it properly, but the work is actually precisely in guiding and refining to what you want.
So I'm going to get a little bit less abstract and more concrete, so we're going to actually now zoom in and be practical. If you consider the double diamond as a useful mental model to think of this topic, Today, you have this kind of respiration, you know, expansion, contraction between problem to concept and solution.
What does AI do very well? AI, generative AI, excels at generating. It's literally in the world, in the name. So it's going to be very, very good at generating assumption, at generating concepts. And because it's compute, it's also very, very good at analyzing. It's also very good at analyzing data, but particularly very good at analyzing unstructured data.
And 80% of the data in the enterprise is unstructured, so which means that it's going to be able to analyze concept, analyze pictures, all the things that Robert talked about in the previous talk. So what I would like to do now is to actually unpack with very precise example why injecting the robot.
So that helmet is not only the Daft Punk helmet, but it's the Copilot one where you see that the AI has allowed you to be wider, faster, sharper. And I want to actually pick from real world example from the work we've been doing. So that's not a self speech at all, but it's just to say that I didn't make this up in my bedroom.
This is not some vibe coding on the weekend. It's actually from real projects we've been doing at work, partnering with GitHub, working with people like Singapore Airlines, like Urban Surf in Sydney or HCF. Why am I saying this? Because these are very difficult environments where when you come up with a method, it's really put to the test.
And if it doesn't work, they bring you over the course because they're not very happy with you. Now one picture that we that I think explains the whole the way it's changed my life, basically, the way it's changed the life of my colleagues is this is one of the first projects we did for Singapore Airlines. Singapore Airlines in in Singapore wanted to update their mobile app, the stuff you take when when you board the plane to order meals.
They had forecasted eleven weeks to deliver the thing. By bringing AI and Copilot and not just generating code, but generating the entire product, we were able to actually do the thing in five weeks. So when they saw that, they went, okay. So we need to pay attention. What are you talking about? So I'm just going to walk you through the the the building blocks or the bricks of this method.
The first thing is the the learning is the prompt is the new unit of work. I think in prompt and by prompt, I don't mean this kind of going to Lovable or Replit and say, generate me your banking app. No. What I mean by that is a very detailed set of instruction. It sometimes needs to fit an entire file, and you actually laying out, laddering the context.
The second thing is that that point exists for a reason, is we are putting everything in a repository that stores the entire context of the project. So what I mean by that is that if I'm on a call and somebody shows a diagram, I screenshot it, I put it in the repo.
I record absolutely every single meeting. I take the transcripts. I put them in the repo. If the client has got a document, I put it in the repo. And it's not about throwing all these documents as a as a as a soup, as an anamorphous soup in the repository. It's that you have to structure your repository to represent the mental model of the project.
So usually, your design system, your documentation, of course, your code. The point I'm trying to make here is that you're using AI tools that are usually being designed by engineers for engineers to generate code. But the hack here is to use those tools to deal with absolutely every single piece of information, not just code, every single piece of information. And what it means is that by having that context, we move from prompt engineering, which to me is this kind of chain of thoughts where the equivalent of going on Google or chat GPT, and you ask a question, you get an answer, you ask another question, you get another answer, and you kind of fumble your way to somewhere.
Here, and I'm going to use a a big word, it's more a complex adaptive system. All these dimensions, these documentation, design, transcripts, architecture diagrams are all interconnected, which means that the mom and you get your design, your tech, and your product together when you do your product discovery. The moment you touch an element, the AI will actually update everything.
The moment you modify a line of code, the documentation is going to be updated, which means that that repository becomes like a living brain of that product. And you get to the point where when it's ready, you literally put a product in the hands of the customer. The other point, and I think for me it was a revelation, is two things. When we talk about dynamic context is it's very specific data, which means that it's not about asking Claude or Chad GPT to find some random generic stuff on the internet about the topic you're working on.
It's very specific to your project and your organization. And the other thing is to triangulate the data. Level one to me is you take a document, you take a transcript, and you ask the AI to summarize it. That's interesting, but that's not the point. What's interesting is to take data that never used to talk together before and to triangulate between those points to extract an insight.
With the consequences of that how am I going to for time? Okay. Good. The for that is the teams are much smaller, and I think we found a sweet spot with with one or two designers, one product, two engineers. And by virtue of being smaller, it means that they've got to talk with with each other. The thing the other thing as well is the work itself is changing. And to go back to the area the initial introduction I was making about those ritual, it does feel that in the early days of design thinking, the difficulty was the point.
The work was the sole. You know? Oh, we're going to do a service design for six weeks. We're going to create those customers on a maps. The difficulty of doing those things was the pinnacle. It was the the achievement. Now the issue is no longer to have access to the data, provided the projects we work on gives you this data.
I would even contend that the quality is not even the question. Okay? People who complain that the quality of the output is not good enough, well, just go back to your data sources. Find better data. That's not the point. The work now is to be sold to this data. And so that gives us two points. And I think, John, you mentioned this in your introduction.
For twenty years at Web Directions, we've been asking this question, should designer code? Or did we also ask whether engineers should design? And we probably landed on, no, they shouldn't. But what's what's and I'm going to try to echo your intro to this conference. We don't have the quest the answers, but we are definitely entering a gray space of asking the question.
Something is changing, and there is definitely a shrinking divide between designers and engineers. And I use this kind of illustrative picture I found, which is the Figma's and the to the sponsors. And the Copilot are actually banging into each other. The second consequence, and I'm just going to take you very quickly for a very specific project to show you how it works, is to me, the idea, as in, like, GitHub Copilot, is becoming the new front line. And this is going to be great and create problems. So if you want to bear with me, I'm just going to walk you I don't have a video, but it's more a series of screenshots to show you a real project real project, kids banking.
So the brief is the following. There is a big bank. You work for them. They as they say in their jargon, they own the family, the parents' bank account. And they notice that every time the parents wants to give a credit card or a card to their kids, they need to go to a fintech like a Spriggy.
So you're working at NAB or Westpac, and you say, why don't we have a case banking solution? Traditionally, you'd go through this whole stakeholder interview, survey design, manual analysis. Within six to twelve months, and I've gone through this at Westpac, you're still nowhere near producing any products. This is a real project that I worked on.
You use AI. So what happens? First, you set up the repository I just spoke about. So this is Versus Code. That's GitHub Copilot, Cursor, same environment. You set up your folders in the way you think your project is going to work. So you see here initial context, prototype specification, your architecture documentation, and so forth and so forth.
You spend a lot of time thinking very deeply how the thinking very deeply about your own mental model to tell the machine how to mirror it. Right? Then what happens is you do an interview with your stakeholders. And instead of writing a whiteboard with a Sharpie and then taking a picture and putting that picture somewhere on your new in your drive and nothing else happens, you use AI to actually generate the flows that are really accurate and ask the AI to triangulate to actually say, now from those initial transcripts, generate a prompt, a very detailed prompt that I will be able to put in, okay, Figma make. So Figma, you generate your prototype in Figma make.
Then you take what you started to build in the prototyping tool. You put it into GitHub Copilot. And the reason why it's not Vibe coding, because nobody wants to actually use a banking app that has been Vibe coded, is that this is the secret sauce, and I think this is the message I want to pass. The repository is one thing.
But inside this repository, you have very, very, very detailed rules that are acting as guardrails. They're very. They even specify the naming conventions of the output. They tell you how the they tell the AI how it's got to design. And then this is really what happened in a couple of weeks. In a couple in fact, it was in a couple of days. You end up with a banking app that's working.
You've got your screens, your your parents' dashboard, and so forth and so forth. Now I'm going to emerge from the depth of these very textual screens. You see the problem? The problem is designers and product people think in shapes and colors. Engineers do think in command line. When we started doing this, there was almost a revolution in my design team because they were like, well, you're really expecting me to actually have we gone backwards?
Have we gone from those beautiful screens to typing on the typewriter? So what we saw is a form of skeuomorphism. What we saw is that the engineers some engineers and some designers got together on the weekend and say, if you want me to work like this, I need you to give me the tools to work in the ID.
And what they did is that develop they developed some tools, some extension to be able to reproduce the artifacts they were used to because this is not really an option. What they ended up doing is creating these things to be able to say, with that tool that sits in the background, you see this extension tool, go to the transcript, understand this context, go to the user flow, and in the time it's taken me to read that prompt, generate those personas and those journey maps.
But what happens, the difference between those and the previous ones, is you can interact with them. If you're not pleased with the outcome, you can edit it. And then the point and I'm landing I'm feeling I'm concluding. You're sitting there, and you're going, okay. Hang on a sec. Woah. Woah. You started your intervention by saying that in the form of a renaissance, we should kill those arcane processes and rituals.
And now you're telling me that you are recreating them with AI. Why? So to me, as I'm trying to make sense, we used the word sensemaking earlier, is that on the left hand side, you have a visualization of that paradigm of repository. You have a context that keeps growing like a snowball. You prompt it and you prompt it until it reaches a point of maturity that is a fully formed product.
However, there's still people around you, and these people, you still to give you still need to give them maps to take them on a journey. Please forgive the pun. And the thing is the cost of producing those map has now fallen with AI. Right? So if you can produce those those artifacts in a couple of hours instead of twelve weeks sprint, I don't have a problem with that. And in fact, AI is now doing the work for you.
And when you're actually manipulating those artifacts, all you have to do is decide where you want to go. So it totally shifts the the focus of your work. And the other thing as well is if you don't do this, you basically ended up riding driving a Formula one in a traffic jam. Every single organ immune defense of the organization is going to actually turn against you.
So I'm going to conclude now, and I'm going to tie it by very quickly to a story. So we know that back in the Middle Ages, imagine your entire job description being this essential ritual of control c, control v. Your job is gone. During the Industrial Revolution, there were what we called no pair wrappers. They were an essential ritual.
We just had invented factories, and you had to get up in the morning and not be late as I was this morning. And their job was to knock at the windows to wake people up, and they got taken down by this extremely disruptive piece of technology that we all know. Now in the twentieth century, accountants, for them, actually, the spreadsheet didn't kill them. Their craft evolved and to do strategy rather than addition.
So the punch line here is coming is whilst I wanted to start by being an anarchist and a nihilist and kill all those process processes, as I was preparing this talk, I realized that processes actually often don't totally disappear. They mutate. You can't break the laws of thermodynamics.
You've got to feed the machine. So you put further, you put gas, or you put electricity. So now this is the conclusion. The question we need to ask ourselves as per John's introduction is, what are we deciding? What are the rituals that don't really serve us anymore and we can get rid of them? And what are those that actually it's probably good to keep them because they make our lives easier if you work on the projects where people expect to see their user personnel, their customer journey map, as I've experienced in the recent projects.
You know what? That's fine. I'll give you your customer journey map to make you happy. And conclusion, before I hand over the microphone, I'm going to make a connection with, I think, the talk that Katya is going to give, that if you're sitting there going, okay, what what's the should I adopt those things or not?
I think the answer is already written for us. I know we are asking questions, but there are certain certainties where what's next is already across the corner. We've come from this world of democratizing personal computing. We've introduced those new business model with SaaS and mobile. And we're here talking about AI and agents, and we already see the next thing emerging, which you spoke as well, Robert, in your in your talk, where agents are going to actually replace and MCPs are going to replace the traditional ways with which we interact with those experiences. So that's it.
Thank you very much.
People
- B. F. Skinner
Technologies & Tools
- VS Code
- agentic AI
Concepts & Methods
- superstitious pigeons
- design thinking
- medieval scholasticism
- Double Diamond
- context engineering
- dynamic context
- skeuomorphism
Organisations & Products
- GitHub Copilot
- Singapore Airlines
Design and product discovery have given us powerful frameworks and artifacts—journey
maps, Miro boards, Figma files—that shaped how we work. But have these tools become
rituals? Like the scholastic thinkers of the Middle Ages clinging to Latin texts before
the Renaissance, we may have fallen in love with the artifacts themselves rather than
the outcomes they serve.
With AI and large language models, we now have the ability to prototype ideas faster,
test assumptions sooner, and even rethink the very notion of the MVP. Why settle for
“minimal” when you can generate more, faster, and with less friction?
Xavier Rizos explores how rituals emerge when meaning is lost—when process replaces
purpose. By connecting ancient wisdom to modern design practice, we’ll ask: how can we
dwell in reality, let go of illusions, and move from surface-level rituals back to the
deeper fruit of discovery?
This is a provocative invitation to question our habits, confront our attachments, and
embrace a more fluid, AI-enabled way of designing and building.















