Map How Work Actually Flows Before You Add AI Agents

Lightly edited for clarity. Speakers: Ysi Gonzalez (Vantelira) and Marie-Claire Asseko.

This episode is powered by Vantelira. We go inside a scaling operation, fix the process, and build the system that keeps it running.

Introduction

Ysi: Hello and welcome to The Forward Deployed Operator. I am Ysi, and I have the pleasure of being here today with Marie-Claire Asseko.

She is an operator, a strategist and a consultant focused on innovation and people enablement, with over 10 years across marketing, technology and product. Her work bridges digital transformation and change management to inspire adoption and scaling. If that sounds familiar, stay tuned — we have a lot to talk about today.

Marie-Claire is an avid learner, a relentless experimenter and a dependable collaborator. As a consultant, she helps SMBs improve their marketing systems and their data quality, converting chaos and uncertainty into operational clarity, measurable execution and sustainable growth. Marie-Claire, welcome to the show.

Marie-Claire: Thank you for having me, Ysi. I'm very excited for the conversation today.

Ysi: Thank you for making this time for us. I remember I met you at a round table in a women's community we're both part of, and you started talking about all the different AI models, how to use them and which ones you use for what. And I was like, I need to be friends with this girl. Got my heart.

Marie-Claire: It was a mutual feeling, because I was like, "Oh my god, she's also interested in this. I'm not weird. We're in this together."

Ysi: I love it. And this is one of the reasons I launched this show — to tell the world what we do as forward deployed operators. We go into the business, we learn their processes, and then we have enough knowledge to say: this is where you can automate, this is where we're going to bring value to you. Stop chasing data. Stop entering data into places. Let's automate that, and then let's make something that is valuable for you as a company.

Consultant, product manager, strategist and coach

Ysi: You sit at a rare combination: consultant, product management, business strategist and coach. How do all of these come together?

Transformations fail because they skip people

Marie-Claire: I never planned to combine those roles. I discovered that each role solved a different part of the same problem. And for me the problem is that most transformations fail because organizations invest in product, in strategy, in decisions, in the operating model — but not necessarily in people. I've been part of many, many projects where I've seen the toll those projects take on people when they haven't been involved properly.

As a product manager, I had the opportunity to really work on how strategy translates into decisions and priorities, and how we're going to execute. As a consultant, it's a different role. I'm not as close to the day-to-day execution, but I sit with leaders to redesign how we're going to operate. And the coaching is really about helping people adopt a new way of working.

I wanted to solve the problem of people being intimidated by tech, for reasons organizations can actually tackle — and there are different angles to tackle it from. That's how I moved between the roles. It's hard for people who don't have that mindset to understand: why are you moving from consultant, pre-sales, solutions engineer to coach and strategist? What's the connection? For me, it's about understanding the whole business, so I know which levers I can pull to help it improve itself.

Resistance to change, but not for the reason you think

Ysi: What's the same thing you find in every engagement, regardless of the industry or the role? There must be something that stays the same.

Marie-Claire: The thing I see the most is resistance to change — but not for the reason we think. In change management we talk about early adopters, and about people who just don't want to change their ways of working. But the resistance comes from people not understanding why they have to do it. The decision to implement something new comes from above, literally, and then people are asked to change the way they've been working for five, six, ten years — or even just two — and they don't understand why.

I find that if you take the time to onboard people properly and clearly, and position the change not just as something the organization decided for its own growth but as something that can benefit them, they become very involved contributors to expanding the change within their teams and departments.

Are you going to fire me after I build this?

Ysi: I have to agree with you. I've seen it many, many times. Just recently I had a conversation with a close friend about how you explain to a group of people who have been doing business the same way that they now have to start building their own AI agents to do the job.

The first reaction is: are you going to fire me after I build this? The second reaction is: I do a better job than they would. And we came to the conclusion that it is our role to show them the aha moment — how much time they're going to save — so they can concentrate on actually managing those agents. Or as I put it: you're no longer just an employee. You're a manager now. You're managing your team of agents doing the not-so-valuable work, and you, the human, stay in the pilot position.

How do I benefit from doing more work?

Marie-Claire: I would even add a third angle. What people have told me is: if I use AI, I'm going to be able to do more work, and the organization will benefit from it. But how am I benefiting from doing more work? Am I just going to get even more work?

So it's also about positioning it as an opportunity. Maybe you have projects or ideas that were put on the back burner, or on ice, because there weren't the resources, the technology or the time. By outsourcing some of the work to AI, you gain time back that you can invest in those ideas.

And there's that fear: if I use AI, I'm basically training it to do my job, and then I'll be fired or replaced by the agent. I take that and present it as an opportunity to innovate in the role you have. Because you were able to outsource the repeatable tasks, you can really hone in on what truly makes the difference in your role.

AI gives you back the fun part of the job

Ysi: And also actually execute the fun part of the job. I remember one of the jobs I held, probably over 10 years ago now, where I spent the whole time gathering data from different reporting systems and putting it in an Excel sheet. It took me close to a week to gather all that information — it was a very large organization — and then I had to build a forecast based on it.

The part I liked most was after the data was gathered: looking at each of the products I needed to forecast, looking at the patterns, seeing where the spikes and drops were. With AI, if I were in that role again, the data gathering would be nothing — it's just there. And I'd get to do the fun part: understanding that this forecast aligns because it makes sense with the patterns of the market, or this one doesn't because it's actually a new product. I really enjoyed having those nuggets of knowledge, but I didn't get to do that part much, or I was always running late because I spent so much time cleaning and gathering the data.

AI doesn't know whether the result makes sense

Marie-Claire: You said something very key, and that's where I see the value of AI: summarizing information and supporting the decisions you have to make as a human, because you remain accountable for the work. Automating those analyses and generating some of the documentation so you can identify the patterns.

But at the end of the day, you said, "I can see that it makes sense." The AI does not know whether it makes sense. It's just going to present you with a result. You, from your expertise — of your team, of the market, of your years of experience in the role — know whether it makes sense. That's why, as you said, it's not here to replace. It's going to amplify what you already know how to do but didn't have time to dive into before.

What it actually takes to build an agent

Ysi: I want to ask you something I already know the answer to. You've built agents already. What does it take to build an agent? Everybody has that change-management fear — an agent is going to come and take my job. I think there's a misconception about how easy it is, and today is the day we clarify that.

Marie-Claire: I shared that misconception for a while, because I was talking to people who were more technical than me, and I thought I didn't have the skills to create an agent. Then I had a moment of: listen, apply what you tell your clients. Start with what you don't know, and use a tool that will help you define what you don't know.

Defining a co-founder persona with guardrails

Marie-Claire: The first step — the one I recommend to everyone, though there's some resistance to it — was going to the tool I use the most, which is ChatGPT. As a consultant I still have my employee habits: it's very easy for me to talk about execution, but selling my work and my expertise can be hard. And because ChatGPT is the tool I've engaged with the most, across the widest range of topics, it's also the tool that knows me the most.

So I went to it and said: I need a co-founder. As you know, I'm a consultant. I need a co-founder who compensates for the gaps I have in executing some of my ideas. I need a co-founder who will challenge me when I ideate things that are too conceptual and don't translate commercially.

I specified: you have five attempts to create that persona.

Ysi: Guardrails.

Marie-Claire: Yes, because it can go on forever. Every five steps, I'd give a correction or we'd move on to the next step. From that I got a very detailed profile of a co-founder persona that would fit me. I edited some areas and corrected some things.

Handing the persona to Claude Code

Marie-Claire: Then I went to Claude Code and said, "Hey Claude, I want you to create that agent." It was literally a Google Doc. I pointed Claude Code to that Google Doc and said: create an agent for this, and let me know when you're done.

Ysi: Just to clarify — this was your first agent. You didn't necessarily know what Claude was going to do with that information, or what was needed. You went in head on.

Marie-Claire: Yes, because the advice I give people is: if you don't know where to start, that's where you should start. There's no perfect step. The people I've talked to who have created agents did what I did — went to the tool and said, I want to create an agent, help me define it. Some people don't create personas for their agents. But I needed one, because what I needed most as a consultant was a sounding board that would correct me or give me recommendations whenever I forgot the commercial side of my job. If I have a co-founder who can help me brainstorm, ideate and correct proposals, I'm good.

So I use ChatGPT for its memory and Claude Code for its ease, because I also wanted the agent on my terminal, with access to files on my computer and in the cloud. I didn't know what was going to happen. Have I looked into the agent's files since? Yes. But for the first two weeks I used that agent, I didn't open its files once. You don't need to know all the pieces to be able to work with it. If optimizing agents isn't your job, why would you go into its files and tweak them all the time? That's not the focus of what I do.

Write every correction back to the agent's files

Marie-Claire: What I have done is tell it: whenever I make a correction or give you feedback, write that feedback to your files, so next time you take it into account before giving me an answer. That's what I need. I don't need to go in and rewrite the agent's memory — because even if the agent doesn't remember everything, I do. There's a big portion of documentation behind it.

Ysi: So you're iterating with the agent. When it gives you something that isn't what you expected — because you know how things need to come out — you course correct and tell it: take this to your memory. That's the documentation-heavy part everybody needs to remember. Even I have forgotten at some point, and had to go back to a chat and realize I never put this into the Notion page or the Google Drive I keep as memory. That muscle — iterate with the agent, iterate with the tool, get it where we want it, and document the process and the corrections — is the one to build.

Knowledge management everyone needs

Marie-Claire: I strongly believe that a basic understanding of knowledge management and process management principles is something everybody needs. It doesn't have to be technical. Knowledge management is basically: where is the information stored, how often is it updated, and who updates it.

And with all the usage limits, I want to be able to compact my conversations and progress, so that if I ever hit the limit, I just go to another tool, call the same memory file and keep going.

Ysi: Yes. I posted about this recently. For some reason Claude was going to the latest model and consuming all my tokens, and it wasn't even noon and I was running out. Normally I have five different things running at the same time.

Marie-Claire: Yeah.

Ysi: It's five employees working. Then I noticed that the conversations I'd opened that day had gone back to Fable 5, and of course it ran out. But because I had all my documentation ready, I was able to jump into the next tool and just continue working.

The chief token officer agent

Marie-Claire: When I create a new agent, I definitely monitor what it's doing the first couple of times. And for the token issue — because I had the same issue — I created an AI chief token officer agent. Once a week I ask it to review how I used my tokens against the type of work I needed to get done. Sometimes it tells me: you could have used Sonnet for this, or Opus for this, but you used Fable.

Based on that, when I've created other agents, I've been able to assign each one the model it actually needs for the task and the result I want. Because these tools sometimes do things that aren't necessary. I'm not going to say it's useless, but you have to keep an eye on it. It'll call Google Drive five times to read one document — I don't have the right to download, can I download, okay, download, oh, I don't have the right. And I'm like, you know what, let me just point you to the file on my computer, so you don't have to call any tool at all.

That's a habit you pick up — but you can't pick it up if you never try, if you never engage with those tools. I'm learning so much as I use these agents.

People still need permission to try AI

Ysi: You mentioned something I really want to tap into: you don't get to understand it if you don't try it. There's a real need to go and try it. And I don't know if you feel the same, but I've found people still need permission to go and use AI tools.

Accept the discomfort of learning something new

Marie-Claire: Yes, and that's one of the frictions I've seen. Even in the comfort and privacy of their own homes, people don't want to look stupid to themselves. You're trying something new for the first time ever. It's going to feel awkward.

I remember installing Claude Code on my computer. It took me a while and a lot of back and forth, because I have an old personal computer. When I was following the steps, I first downloaded a package that was too heavy and didn't have what I needed. Then I went back. I took so many screenshots — back to Claude: this is what I see on the screen, what do I do?

Ysi: Yes. Yes.

Marie-Claire: In the end, it worked. But if, when I got stuck, I'd told myself, "You're so stupid, everybody's creating agents and you can't even install Claude Code on your computer," I would never have gotten to where I am now, running sessions with different agents.

I had to accept the discomfort of learning something new. Maybe I don't understand every line of code. Maybe there are many things I don't understand. But that's not why I'm using these tools. I want them to help me do my work. As long as the output gets me to the business outcome I'm looking for, I'm okay. You have to accept being uncomfortable. No one is going to judge you.

No one knows what they're doing

Marie-Claire: And the thing I like to say is that, truth be told, no one knows what they're doing. The businesses banking on AI are banking on vibes and faith, hoping it'll help them make money. You've probably seen the articles saying businesses are finding it hard to assess the ROI on AI. How do you measure people saving hours of work? What do they do with those hours?

No one knows. We're at an exciting time where we can all learn together, learn from other people and experiment. I really hope we don't feel intimidated because we see people with software engineering degrees doing crazy things we don't understand. We can do crazy things in our own lane as well.

Ysi: That's it. And that's what we have been doing.

Every system you fixed became someone else's win. The next one has your name on it. An eight-week live cohort. You solve a real problem inside a real company, ship a working AI system, and leave with the case study, the build and the title: Forward Deployed Operator. Join the waitlist at fdoschool.com. That is fdoschool.com.

LiliBloom makes personalized wooden and acrylic keepsakes out of Montreal. It is my choice for any keepsakes that I want to give to my friends, my family, my customers. First birthday photo boards, cake toppers, first day of school signs, anything in between and anything you need. Every piece is thoughtfully designed and crafted with love, care, and an eye for detail, making your celebrations and your gifts even more special. Find them on Etsy as LiliBloomShop. That's L-I-L-I-B-L-O-O-M-S-H-O-P. LiliBloomShop.

SMB vs. enterprise approaches to AI

Ysi: I know you work with SMBs but also with enterprise customers. Do you get to use AI with them too? I want to understand the difference between an SMB approach to AI and the enterprise level.

Marie-Claire: SMBs typically don't have an AI budget. It's more like: we have this issue. Say with the sales pipeline — we get a lot of requests, we can't process them all on time, so we lose deals. How can we improve? When you bring AI to that, they're eager. They're so overwhelmed, with so many things moving at the same time, that they don't really question it. They're just like, okay, let's go and try. It's great.

But as a consultant you have to remember that you're the one who knows about safety and the security of the data being used — and make sure whatever you implement actually leaves the business better, instead of reaching a business outcome while exposing them in another way that hurts them down the line.

Enterprises lead with risk

Marie-Claire: At the enterprise level it's more complex, because enterprises are risk first.

Ysi: Yes.

Marie-Claire: Risk first, safety, security, architecture first — because they have a lot more to lose. And it's not necessarily losing sales; it's losing reputation. I was talking to a friend who works at an AI insurance company, and he said, literally: no one wants to be the next Desjardins. That's what's driving AI and data governance. It's not making more money or getting more clients. It's: no one wants a data breach. No one wants data taken by employees and sold to third parties.

Ysi: Yeah.

Marie-Claire: So the concerns are completely different. In the enterprise, the risk is about the reputation of the business and its ability to transact and handle its customers' data. For SMBs, it's about solving problems as fast as possible.

Lead with business goals, not time savings

Ysi: And it's our job to make the recommendations and help them understand: you're going to save this much time, which is equivalent to this employee doing that work. They could go do the actual customer outreach, have that front-facing conversation, and let the agent filter out the qualified leads.

Marie-Claire: My approach is a little different, in that I try not to lead with "this employee is going to save this much time." Employees get scared when you say that. If my work takes less time, maybe it's because my work isn't important — all of those considerations.

So I lead with the business objectives. To reach this goal, you need to do more of X, or you need to start doing Y. Then, as we analyze why you're not able to do more or do new things, we find the bottleneck, the issue. That's when I bring up: maybe we could use this tool to help. Yes, they'll save time — but I'm not leading with that. I'm leading with: you're going to reach your goals, either by doing more of what's working, or by investing time in new things your market is trending toward that you don't have the capacity to go after.

Week one inside a company with fragmented processes

Ysi: It's the why behind it — the aha moment of showing them where they can go. When you walk into a company with fragmented processes, what does the first week actually look like? You walk in and find out that a process hasn't been updated and nobody told Claudia — or whoever the employee is, if it's not AI — to go update it. What do you do in week one?

Marie-Claire: It doesn't look dramatic. In a company with fragmented processes, people actually don't engage with one another that much — which means every department has its own spreadsheet, its own definitions, its own version of the reality of the business.

When every team defines "client" differently

Marie-Claire: Because you, as the consultant, go from team to team, you start to realize: this team calls a "client" anyone who has had a contract with the company at any point in time. That team calls a "client" someone with a commitment of over $50,000. And another team calls it something else again. So when people from these teams talk to each other, they use the same word to mean completely different things. It takes someone to tell them: when you all say "client," you have completely different definitions. Everyone has good intentions, and everyone is busy.

Map how work actually flows, not the documentation

Marie-Claire: That's why, in the first week, I mostly observe. I map how work actually flows — not how the process documentation says it's supposed to work. What are people actually doing to get the work done? Very detailed: when you do this action, where do you click?

I had this happen once with a SaaS company. They had Marketo, a marketing automation platform, and one employee said, "Yes, I can do automated scoring." I said, that's interesting, can you show me? As he showed me, I realized it wasn't automated scoring. He was manually updating many different parts of the workflows for the automation to work. So is it really automation? But if you heard him speak, that's how he described his reality.

Ysi: Yes.

Follow one customer request end to end

Marie-Claire: So in the first week, the fastest way to understand an organization is: observe, map how work actually flows, and — because I'm very focused on business outcomes — follow one customer request from the moment the company reaches out, say through cold calling in SaaS, to the purchase and maybe the renewal. What are the handoffs, the delays, the workarounds, and the decision points?

Then I present it to the team: this is how work is actually happening. Lots of people are shocked, because I also highlight which team is responsible for what. You can see where it's disconnected — where one team's output should feed another team, but that team goes to a third team for an output that's less up to date, and so on. That's typically when people open their eyes and say, "Oh my god, how do we even function as a business? It's so disconnected from beginning to end." And then I ask: how does the customer experience that?

Very Lean Six Sigma of you

Ysi: Very Lean Six Sigma of you.

Marie-Claire: I know. I love Six Sigma. It's the way to go. It's clear, and it removes assumptions — because I can have my own assumptions too.

The bottleneck is not where the work stops

Ysi: Yes, we all have our biases. Staying on the Lean Six Sigma thread: how often does the client say, "This is where the problem is, this is the bottleneck," and then you're like… okay?

Marie-Claire: In their defense, I still remember my operations and logistics class at university. The first thing the instructor said was: the bottleneck is not where the work stops. Because work is piling up at a station, you'll think that's the bottleneck — but it's not. She showed us a big factory floor with different stations and asked where the bottleneck was. Everybody said it's obvious, it's where the most work is. She said no. Often it's upstream. If that station is working as intended, it's processing work at the intended pace — there's just too much work coming at it.

So often what the client thinks is the bottleneck is where they feel things aren't moving fast enough, but they don't always ask why the flow stopped there, or why it's slower at that point.

Reporting, technology and communication problems

Marie-Claire: Sometimes they think, "We have a reporting problem. We can't get all the data and reports we need on time to make decisions." Then I look at the dashboards and realize: it's because you haven't defined what the data is. You haven't defined what a client is, or what an opportunity is. So whoever built the dashboard went with their own understanding, which is different from yours. That's where the bottleneck comes from.

Or they have a technology problem: we need to optimize or reconfigure the platform. Then I go in and find six or seven competing automations or workflows, and the system gets stuck in a loop, because someone created a workflow a month ago, someone else edited it, and it's documented nowhere. No governance, no oversight.

So the three problems I hear are technology, communication and reporting. But they're typically not about the reporting tools or the technology. It's really about who owns the project, who owns the edits and who owns the data.

Ysi: Yeah.

Don't argue with the diagnosis, gather the evidence

Marie-Claire: So I try not to argue with my client's diagnosis. I just gather the evidence.

Ysi: Yes.

Marie-Claire: Then we validate it against the evidence together. Typically, once people see the system mapped out, the real constraint — the real pain point — becomes obvious to everyone.

Ysi: And what they come in with is a symptom. They're convinced it's the bottleneck, but it's a symptom. That's where we start applying all these methodologies to find the actual root cause — root cause analysis, the five whys — to make sure we're gathering all the information. As you said, someone built an automation workflow somewhere and it's causing X, Y, Z. Having that overview of the business lets us pinpoint where the bottleneck actually is. Clear that out, and everything flows as expected.

Marie-Claire: Exactly.

The exec team wants AI agents by next quarter

Ysi: Say an operator has a messy, fragmented process — one thing is documented, another isn't. And the exec team says: no, no, we need AI agents by next quarter. Agents here, here and there, because we need these people doing another job and we need to increase output. What's the first thing that needs to be in order?

Structured work first: definitions, decision rights, guardrails

Marie-Claire: AI is excellent at accelerating structured work — and the key word is structured. I know people don't like to talk about how they work and why they do it, but to implement something like this, we have to map the processes. We have to sit down and agree on the definitions, on the decision rights and the decision points. Because if nobody agrees, AI is simply going to produce inconsistent results faster.

Ysi: Yes.

Marie-Claire: So look at the process you want to use an AI agent for, then step back and ask how that process actually contributes to business outcomes.

Ysi: Prioritize it.

Marie-Claire: Exactly. Then bring in everyone who may be impacted. If you have an AI agent in the sales team doing a lot of the work, that agent needs to interact with other teams — and those teams are impacted by the change too. So you communicate the change, and understand the impacts on the data, the technology and the people: how will people engage with the agent, and what do they need to know?

And ultimately, who is the human in the loop, who owns the decisions? If we put guardrails in place and the AI has to stop, who has the authority to decide? If the AI comes to you and says, "I'm stuck between this and that, which should I do?" — the organization or team has to have agreed on the person who owns that decision, or is at least accountable for it.

So: process definitions, decision rights and ownership, and then guardrails. We want a fail-safe workflow. There are decisions we don't want the AI to make — we want the AI to execute. Actually, we don't want AI to make any decisions. When it's time to make one, it has to be routed to a human, and we need to know who that human is.

If I can't do the job, I can't teach an AI

Ysi: There's a trick I've used myself for many years now. I get people to show me their job so that I can execute it.

Marie-Claire: Oh.

Ysi: And that's how I've uncovered everything — "you said you needed to click here and send an email to person X, but actually I have to do this other thing." So if I cannot do the job, I cannot teach an AI.

We're bad at explaining how we work

Marie-Claire: Exactly. And it's crazy how bad we are — and I include myself — at explaining how we work. That's one of the things we need to work on as professionals: taking the time to think about how we think.

Ysi: Yes.

Marie-Claire: When I go into a project, how do I get a sense of how hard or easy it's going to be? It comes from learned experience, but I have to take it out of my head and see how I can build a system that reproduces that logic externally. That's very hard for people, because those are reflexes we've acquired. There are tools I know so well that, without them in front of me, I can tell you exactly where to click: go here, click on the left side, you should see something like this, do that. I can explain it to you, but it has to be documented somehow.

Ysi: Exactly. Otherwise — if you were onboarding someone, could they take the documentation and know how to do the job? Software engineers did this exercise in their first programming classes, at least back in the day. The teacher would say: write me the instructions for task X. And the way they'd correct it was by executing the task exactly as written. That's what programming is — the developers of the world know you have to write out specifically everything that needs to be done.

The peanut butter and jelly sandwich exercise

Marie-Claire: We've actually done that exercise with my oldest daughter.

Ysi: Yes.

Marie-Claire: Write the process for making a peanut butter and jelly sandwich.

Ysi: We spend hours playing this game. It's a great non-screen activity. And it's super fun to see how, even at that age, they learn: oh shoot, I didn't tell it to open the bag of bread, grab a slice and take it out before I told it to spread the peanut butter. And we don't like the peanut butter spreading out the back, either.

The question from the last guest

Ysi: We have a tradition on the show where the previous guest leaves a question for the next one. Somebody who works on the solutions-for-customers side left a question for you, and then I'll ask you to leave one for the next guest.

Marie-Claire: Okay.

Ysi: You ready? If you were describing what you do, how would you describe the quiet parts of your work — the parts people do not see?

The invisible part: people enablement

Marie-Claire: I go back to the importance of people. It doesn't really matter what the technology is. When we're in the thick of it — deploying a tool, fixing something, handling an incident — if the people aren't on board, everything is going to be hard.

I think we've given people a reputation for being resistant to change, and that's a phrase I'm even trying not to use. It's about uncertainty: do we know the actual cause of the incident, so I can work on the actual cause and not just what you think it is? I don't want to do work for nothing.

For me, the invisible part is people management — people enablement at the heart of tech projects. The more I work in tech, the more convinced I am that you can have the best tool in the world, but if the people managing or using it aren't on board with where you want the business to go, it's going to be hard.

Ysi: That's why I said you touched on it — the whole time we've talked, people have never left your speech. They're the center of it.

Marie-Claire: The more tech we have, the more people skills we need. I live that so deeply. When I'm tired at the end of the day, it's not because I got overwhelmed by the tool or the tech. It's because I got overwhelmed managing developers and trying to give sense and meaning to their work, in a context where we're pushing them forward with new tools, AI changing every day — use this, do that. It's not that they can't; they have the skills to use these tools. But if they don't see a purpose, if they don't understand why, it won't work — because processes don't change themselves. I can do all the mapping I want. At the end of the day, it's people who execute the processes.

The question for the next guest

Ysi: Exactly. The next guest is somebody on the tech side.

Marie-Claire: Okay.

Ysi: It's a solution for customers. That's all I can reveal. So what question would you leave for them?

Marie-Claire: Like pre-sales, post-sales? What type of solution are we talking about?

Ysi: It's a solution for companies. I actually use it a lot.

Marie-Claire: Okay. My question would be: how do you maintain your curiosity for the pain points and problems your customers are facing?

Ysi: Love it. They're going to love that question.

Marie-Claire: Because on the tech side, it's very easy to focus on what you can do. You know how to code, so everything is possible for you. But you can very easily — even faster today — build the wrong thing, the thing that won't make a difference for your customer. Curiosity is something all of us have to nurture, but even more so if you're engaging with customers. They want to know you understand what they're going through.

Ysi: Yeah.

Marie-Claire: I was a pre-sales solutions engineer, and it's easy to rest on your laurels: I know what the problems are, I know what they need. But you don't necessarily keep track of how those needs evolve with the market. So I'd be interested to know how they maintain that curiosity amid everything else they have to do.

Closing

Ysi: Thank you so much, Marie-Claire. It's been my pleasure, and I think you embody the definition of a forward deployed operator. Thank you for sharing all of your experience with us today.

Marie-Claire: Thank you so much for having me. I did a post on LinkedIn about that term a few days ago, didn't check it, and then saw thousands of impressions — because people were like, "That's it, it's me." So it's great that you're putting a name on it. I'm very excited to see where this goes, because it's not tied to an industry. It's really about how you position yourself.

Ysi: Let's go.

Marie-Claire: And congratulations on launching the podcast, by the way.

Ysi: Thank you so much. Thank you, Marie-Claire. Until the next one.

That's it for this one. Follow the show so the next episode finds you, and the newsletter goes out every Tuesday — the link is below. See you next time on The Forward Deployed Operator.