Read it straight through.

Thanks everyone for being here. Before I get into any of this, let me tell you why I even wanted to do this session, because it comes out of a tension I keep running into in my own work.

We can build more than ever right now. AI made the building part cheap. But here is the thing nobody hands you along with that speed: the responsibility for what you build. AI made it cheaper to produce. It did not make the judgment cheaper, or the communication, or the support, or the handoff. So the question I keep coming back to is not can I build this anymore. It is should I build this, and do I actually want to own it after I do?

Quick bit on who I am, so you know why I am up here. I have spent most of my career in B2B software, on the partnerships and product side, and these days I work as a fractional go-to-market engineer. I embed with startups and scaleups, I advise a couple of public companies on AI adoption, and across all of that I have sat close enough to sales, product, CS, and ops to see one thing clearly: the thing you build is almost never the whole job. The artifact is the easy part now. Somebody still has to own everything around it.

So today is practical, not philosophical. This is about real client work, real internal teams, and the real tiny yeses that quietly turn into obligations. [point to the line] Building got cheap. Boundaries got expensive. That is the whole talk in one line. Let me show you why it feels so different now, starting with where the bottleneck actually moved.

Here is what changed under us. Before AI, most of the visible work was production. Writing it, building it, wiring it up, actually producing the thing, that is where the hours went. There was always review and alignment, but the weight was in the build.

Now flip it. The build compresses down to almost nothing, and all the human work around it expands to fill the space. Scoping. Review. Alignment. Educating the client. Handling the edge cases. Deciding what good even looks like. That is the heavy part now.

And if you take one thing from this slide, it is this: if you still scope and price like production is the scarce resource, your calendar is going to punish you. You will say yes to more builds because they are easy, and then drown in everything that surrounds them.

I felt this as a software person first. The demo is never the whole implementation, right? Sales loves the demo, product worries about fit, CS inherits the questions, ops needs a process, support needs documentation. The work did not disappear when the demo got easy. It moved into alignment. Same thing is happening to all of us now. [walk the two bars: before, then after] The work did not go away. It moved. And once production feels cheap, here is the trap: bad asks start to feel cheap too.

When building was expensive, the cost itself protected you. It forced a conversation. Nobody casually asked for a three-week build, because three weeks was obviously three weeks. The price tag created friction, and that friction made you scope.

Now the same thing looks like an afternoon. So people skip the scoping conversation entirely, and that includes us. The friction that used to protect the project is gone, because the build got cheap.

But here is the part that matters: skipping the scope does not remove the risk. It just moves the risk downstream, to after expectations have already formed. The yes felt free. The tail is not free.

The analogy I use is free shipping. Free shipping did not make returns free for the warehouse. The customer just sees the convenience. The business still absorbs the real cost somewhere, it just moved out of sight. Cheap building is the same. [point to the curve] Low build cost on one side, rising scope risk on the other. The risk did not vanish. It moved. And that is why the single most dangerous moment in the whole engagement is the tiny yes.

So let us sit on the tiny yes, because this is the heart of it. A yes is not just a moment. A yes is a maintenance object. The second you say it, it starts taking up space, and it keeps taking up space long after the fifteen minutes it took to do.

Every small yes creates surface area in five places. [advance through each as you name it] It touches your scope. It creates maintenance. It pulls in stakeholders. It creates dependency. And it adds communication. [pause on the last] That is the real cost of a yes: not the fifteen minutes, the surface area.

Let me make that concrete with one that bit me. Years ago I said yes to a small invoicing automation for a client. Easy yes. Built it, moved on, never really thought about who owned it after me. Fast forward, and I am standing on Machu Picchu, literally on a mountain in Peru, and that thing breaks because something upstream changed in an API. Now the client has a real problem, and I am trying to fix an invoicing system from the side of a mountain. That was an easy yes I made years earlier, and it found me at the worst possible time, because I never named who owned it.

You are not trying to kill momentum here. Saying yes can be the right call. You are just trying to make the ownership visible before it gets weird later. So let me group these into the five traps I see over and over.

These are the five patterns, and I would bet you each have a favorite, which usually just means the one that hurt you the most. And to be clear, the point is not that clients are bad. Usually they are excited. It is that excitement quietly creates way more surface area than the original ask.

First, scope creep. It sounds like while you are in there, can you also. [reveal guardrail] The guardrail is simple: log every yes, even the free ones, so the scope stays visible to both sides.

Second, the maintenance tail. You built it, so can you just keep it running? [reveal] Guardrail: price it or exclude it. Never let maintenance be implied.

Third, stakeholder surprise. You scoped it with one excited champion, and then at delivery IT, or legal, or the VP shows up with new requirements and a veto. [reveal] Guardrail: name the decider up front.

Fourth, becoming the de facto employee. This is when access to you becomes the actual product. [reveal] Guardrail: set request paths, so you are not just always on.

And fifth, the communication ceiling, which is the simple truth that your output scales but your relationships do not. [reveal] Guardrail: cap by attention, not by build capacity.

The fix for all five is not to get rigid or anti-client. The fix is just to make the yes visible. So how do you do that without becoming the person who says no to everything?

Here is the reframe that changed this for me. A boundary does not have to sound like no. A good boundary usually sounds like, great idea, let us put it where it belongs.

[reveal: Before] Before anything is scoped, you can still give momentum. Sure, we can do that. That keeps the energy, but notice you have not actually committed to anything yet. You have kept it inside the scoping conversation.

[reveal: During] The sentence I steal the most is this one. Yes, and that is a phase two thing. Say that one with me, because it does three jobs at once. It validates their idea, it protects the scope you already agreed to, and it keeps you out of the well-you-already-said-yes argument later.

[reveal: After] And then the after: here is who owns it. That is the one that turns a delivery into a handoff instead of a forever-commitment.

The goal here is not to win a scoping argument. It is to make the work legible enough that everybody, you and the client, can make a clean decision with their eyes open. And the very first place to apply that is the promise you are actually making.

This is probably the most important distinction in the whole talk: a prototype and a product are two completely different promises, and when building is this cheap, they get blurred constantly.

A prototype is for learning fast. A product is for operating clean. A prototype can be incredibly useful without ever being something the business should actually run on. And the fastest way to create a bad product is to let a prototype quietly graduate into one with no ceremony, no requirements, no docs, no owner, no support terms.

Let me make this concrete, because this is the move I would actually want you to walk out with. Say a client wants to go fully agentic on their pipeline, market signals, enrichment, the works. But their CRM is a rat's nest, because every RevOps person who ever passed through left their fingerprints on it. The instinct is to start building infrastructure. Do not. The prototype is: get read-only access to their CRM, validate what data is already in there, generate the output, and put it in front of them. Read-only MCP access into their HubSpot or Salesforce, and the question is, is this what good looks like? You learn that in an afternoon. The product, the clean, owned, monitored, documented version, you only build after they have seen it work.

One honest caveat for anyone earlier in this. Let me into your CRM is an easy ask when you have reputation behind you, and a big ask when you do not. So earn it. Lead with a productized audit that shows them fifty, sixty percent of the output up front, here is your list, here is a sample, here is what it would cost, so that asking for access is obviously worth it. That is the play. Once you know which promise you are making, the next question is what happens after the thing ships.

So you shipped it. Here is the part people forget to price: the tail. Maintenance is one of three things: included, excluded, or priced. The only wrong answer is implied.

Because the invoice ends, but the system keeps living. APIs change. Their data changes. Prompts drift as the models update underneath you. People start using the thing in ways you did not design for. [walk the timeline] You build it, you ship it, an API changes, a prompt drifts, and then they call you. And if you never named the tail, guess what they assume the tail is? You.

Picture an enrichment workflow you built that quietly breaks the day a data provider changes their API. Nobody notices until the list going out is wrong, and now it is a fire drill, and it is your fire drill, for free, because it was never scoped. [land on the rule] So the rule is the line right here: monitoring is included, excluded, or priced. Never implied. And the tail is not only technical. A lot of the tail is people.

Here is the one that is easy to miss when you are heads-down building. Automation changes somebody's job. And the second it does, the org chart walks into the room, whether you invited it or not.

Your champion can be genuinely excited and still not be the person who has to approve the security review, or support the workflow, or train the team, or live with the consequences when it changes how their day works. [point across the bubbles] Champion, VP, IT, legal, ops, the actual user. Those are often six different people with six different reactions.

So the question to ask early, before you build anything, is just: who else has to say yes before this is actually done? Mapping that is not bureaucracy. It is scope protection. I learned this on the software side, implementation is always cross-functional. The buyer, the user, the blocker, the approver, and the owner are usually not the same person. Find them before you automate someone's job, not after. And even when you get the scope and the stakeholders right, there is still one more ceiling waiting for you: your own attention.

This is the ceiling nobody warns you about. AI scales your output. It does not scale your attention. And attention is the thing that actually runs out.

Watch how innocent this looks. [reveal] Quick question. Sure. [reveal] Can you check this? Of course. [reveal] While you are in there. Yep. [reveal] Can you join our Slack so we can ask you stuff quickly? And that last one, I have made that exact mistake, feels like you are just giving them a convenient channel. What you actually sold, without meaning to, is your availability. All day.

[point to the meter] This is what fills up. Not your build time, your attention. So the move is to give it structure: one request path, one cadence, one owner. If the client genuinely needs to depend on you, that is fine, sell them the dependency. Just do not donate it. And funny enough, this changes how I think about pricing, because the value was never really the hours in the first place.

Let me hit pricing head on, because AI creates a weird trap here. If AI helps me do in two hours what used to take twenty, it is really tempting, for me and for the client, to think the thing is now worth less. It is not. The speed changed. The value of the outcome did not.

You know the Picasso story. He is out somewhere, someone asks him to sketch something on a napkin, he does it in a couple minutes and says that will be a serious amount of money. And she says, but it only took you two minutes. And he says, no, it took me my whole life to be able to do that in two minutes. That is exactly where we are. The value was never the typing. The value is the judgment. [point down the three] Knowing what to build, what not to build, what risk to quietly remove, and how to make the result actually useful. That is what they are paying for. The outcome, not the clock.

So I price the outcome, never the hours. I even do this with my own contractors, I pay them for the value of the output and let them manage their own time against it. And the cleanest proof that you created real value is that they can run it without you. Which brings me to the exit.

Here is a rule I try to live by now. Done means someone else can run it. If I am the only person who can operate the thing, I did not ship a system. I shipped a dependency, and I made myself the single point of failure.

And the key move is that you design the exit before you say yes, not after everybody is tired and the project is limping to a close. The handoff is part of done, not a nice-to-have you get to if there is time. [point through the stack] Three pieces: docs, what it does, where it lives, how to change it. A walkthrough, a short video someone can replay without me. And a named owner, an actual person who runs it after launch.

The trap here is what I call undocumented magic. You build something clever and fast that only you understand, and in the moment it feels impressive. But it is not leverage for the client. It is a future support ticket with your name on it. [point to the door] Done means someone else can run it. So if I compress this whole hour into what you can actually use tomorrow, it comes down to three moves.

So what do you actually walk out of here with? Not build less, the opportunity is real, build away. The lesson is that ownership has to be explicit. Three moves.

One: scope the promise. Say out loud whether this is learning, production, or an ongoing operating commitment. Two: name the tail. Maintenance, support, approvals, communication, monitoring. Those are real work, so name them. Three: design the exit. Docs, a walkthrough, a named owner, a clean handoff.

And if you want it as three questions to ask yourself before any yes: what promise am I making, what tail am I owning, and how do I leave? That is it. Tomorrow, before the next quick yes, run those three questions. If you cannot answer them clearly, you are not looking at a quick task. You are looking at unscoped ownership. The people who win with AI are not going to be the fastest builders. They are going to be the clearest owners. Alright, let me make this useful for you specifically, so let us open it up.

For Q and A, here is the most useful version of it: bring me a tiny yes. Either one you are considering right now, or one you already regret. Give me the scenario in a sentence, and we will run it together. We will figure out which trap it is, name the hidden tail, and write the one boundary sentence you could actually say out loud.

I will start one to get us going, since these are always the same shape. Hey, can you just join our Slack so we can ask you quick questions? We have all heard that one. [open the floor] So, who has got a tiny yes? Throw it out and let us pressure-test it live.

That is what I have got. Thank you for spending the hour with me, really. Keep building, and keep the boundaries.

If you want to keep talking, scan the QR code or just find me on LinkedIn, it is linkedin dot com slash in slash scottmurtaugh. And genuinely, if you have a client situation, an internal automation question, or a tiny yes you want a second opinion on, send it over, that is my favorite kind of message to get. [leave QR up] Last thing I will leave you with: the builders who win with AI will not just be the fastest. They will be the clearest about what they are willing to own. Thanks, everybody.