Opener, bullets, story, actions, transition
A rehearsal-friendly version that keeps the existing script intact. Each slide gives you a framing line, paraphraseable bullets, a story cue, on-slide action notes, and a transition line.
How to use this version
- Opener: the first sentence or framing thought for the slide.
- Bullets: not polished prose. These are the ideas to paraphrase in your own words.
- Story: the narrative or background cue to make the point feel lived-in.
- Actions: what to click, reveal, point at, or pause on during the slide.
- Transition: the line that gets you cleanly to the next slide.
When you can build anything, where are the boundaries?
2–3 minI want to start with the tension that made me want to do this session: we can now build more than we can responsibly own.
- AI made the build cheaper, but it did not make judgment, communication, support, or handoff cheaper.
- The question is no longer only “can I build it?” It is “should I own this after I build it?”
- Frame this as practical, not philosophical: this is about real client work, real internal teams, and real tiny yeses that turn into obligations.
Tell the arc from B2B software into fractional GTM engineering: you have sat close to partnerships, product, sales, CS, and ops, so you have seen that the artifact is rarely the whole job. Now with AI, the artifact appears faster, but the operating surface still has to be owned by someone.
No reveal action. Let the title land, then point to the “Building got cheap. Boundaries got expensive.” line as the core thesis.
To understand why this feels different now, start with where the bottleneck moved.
The bottleneck moved.
2–3 minBefore AI, a lot of the visible work was production. Now production compresses, but the human work around it expands.
- Before: writing, building, wiring, and producing took most of the time.
- After: scope, review, alignment, client education, edge cases, and deciding what good looks like become the heavy part.
- If you still price and scope like production is the scarce part, your calendar will punish you.
Use a software-company story frame: the demo is never the whole implementation. Sales may love the thing, product may worry about fit, CS may inherit questions, ops may need process, and support may need documentation. The work moved into alignment.
No fragment action. Walk left-to-right across the two bars: before AI, then after AI. Emphasize that the work did not disappear, it moved.
Once production feels cheap, bad asks start to feel cheap too.
Cheap building makes bad asks more expensive.
3 minWhen building was expensive, cost forced a conversation. Now the thing looks like it can be done in an afternoon, so people skip the scoping conversation.
- Budget used to create friction. Time used to create friction.
- Cheap production can remove the exact friction that protected the project.
- Skipping scoping does not remove risk. It just moves risk later, after expectations have formed.
Use the “free shipping did not make returns free for the warehouse” analogy. The customer sees the convenience. The business still has to absorb the operational cost somewhere.
No reveal action. Point to the curve: low build cost on one side, rising scoping risk on the other. Let people feel that the risk has not gone away.
That is why the most dangerous moment in the whole engagement is the tiny yes.
YES feels free.
3 minA yes is not just a moment. A yes is a maintenance object.
- Every small yes creates surface area: scope, maintenance, stakeholders, dependency, and communication.
- The danger is that the yes feels like fifteen minutes, but the expectation can live for months.
- You are not trying to stop momentum. You are trying to make ownership visible before it becomes weird.
Tell a quick “tiny ask became real work” story: a workflow tweak or automation looked simple, but then data quality, permissions, support, training, or “can you just check this?” started showing up afterward.
This slide has reveal steps. Advance/click through each item in the right card as you name it: Scope, Maintenance, Stakeholders, Dependency, Communication. Pause after the last one and say “that is the real cost of yes.”
I group those tiny yeses into five traps. You probably have a favorite, which usually means the one that hurt you most.
Five ways the easy yes compounds.
5–6 minHere are the five patterns I see over and over. The point is not that clients are bad. Usually they are excited. Excitement just creates more surface area than the original ask.
- Scope creep sounds like “while you’re in there.”
- Maintenance tail sounds like “you built it, so can you fix it?”
- Stakeholder surprise is when IT, legal, ops, or the VP arrives after the work is basically done.
- De facto employee happens when access to you becomes the product.
- Communication ceiling is the truth that output scales faster than relationships.
Pick one anonymized client story. Good options: the Slack channel that became the engagement, the prototype that got treated like production, or the hidden approver who appeared at delivery.
This slide has five reveal actions. After naming each trap, advance/click to reveal the guardrail at the bottom of that card: Log every yes; Price or exclude; Name the decider; Set request paths; Cap by attention.
The fix is not to become rigid or anti-client. The fix is to make the yes visible.
Replace the easy yes with a boundary system.
4 minBoundaries do not have to sound like no. A good boundary often sounds like, “Great idea. Let’s put it where it belongs.”
- The sentence to steal is: “Yes, and that’s phase two.”
- It validates the idea, protects the current scope, and keeps momentum.
- The goal is not to win a scope argument. The goal is to make the work legible enough that everyone can make a clean decision.
Tell the operator-side-of-the-table story: you are not trying to be defensive with clients. You are trying to protect trust by making tradeoffs clear while everyone still has choices.
This slide has three reveal cards. Advance/click through Before, During, After. Let each card become a sentence they can borrow.
The first place to apply that is the promise you are actually making.
Scope the promise, not the task list.
4 minA prototype and a product are different promises. In GTM work, the cleanest prototype is validating their data before you build anything.
- Prototype means learn fast. Product means operate clean.
- The GTM move: get read-only access to their CRM, validate what is already there, and show the output before you build infrastructure.
- Say it out loud: is this for learning, or will someone run pipeline on it Monday morning?
- A prototype can be useful without being something the business should depend on.
Use the CRM example: a client wants to go fully agentic on pipeline and market signals, but their CRM is a rat’s nest from every RevOps team that ever touched it. Instead of building infrastructure first, ask for read-only MCP access to their HubSpot or Salesforce, validate what data already exists, generate the output, and ask “is this what good looks like?” You learn in an afternoon. The product is the clean, owned, monitored version you build only after they have seen it work.
No reveal action. Point from Prototype to Product. Say the prototype line concretely: read-only access, validate, show the output. Then contrast: product means owned, monitored, documented. For the newer builders, add the access play — lead with a productized audit that shows 50 to 60 percent of the output up front, so asking for CRM access is obviously worth it.
Once you know the promise, the next question is what happens after it ships.
Price the tail before it becomes a favor.
4 minMaintenance is either included, excluded, or priced. The problem is when it is implied.
- The invoice can end while the system keeps living.
- APIs change. Data changes. Prompts drift. People use the thing differently.
- If you never named the tail, they assume the tail is you.
Tell a post-launch story: something shipped cleanly, then a vendor changed an API, a prompt started behaving differently, a dataset got messy, or a team member asked for help because “you know how it works.”
No reveal action. Walk the timeline left-to-right: Build, Ship, API changes, Prompt drifts, They call you. Land on the footer rule: monitoring is included, excluded, or priced. Never implied.
And the tail is not just technical. A lot of the tail is people.
Map the people before you automate the work.
4 minAutomation changes someone’s job, so the org chart always enters the room eventually.
- A champion can be excited and still not be the person who approves security, supports the workflow, trains the team, or lives with the consequences.
- Ask early: who else has to say yes before this is done?
- Stakeholder mapping is not bureaucracy. It is scope protection.
Use the B2B software lens: partnerships and product roles teach you that implementation is cross-functional. The buyer, user, blocker, approver, and owner are often different people.
No reveal action. Point to each person bubble: Champion, VP, IT, Legal, Ops, User. Ask the slide question out loud.
Even if the scope and stakeholders are right, there is one more ceiling: your attention.
Treat communication as the scarce resource.
4 minAI scales output. It does not scale your attention.
- “Just add me to Slack” can become extremely expensive.
- The client thinks they asked for a communication channel. You may have accidentally sold availability.
- Use one request path, one cadence, and one owner. If they need dependency, sell dependency. Do not donate it.
Tell the Slack/DM story: the thread starts as convenience, then becomes where the real work lives. Suddenly you are checking, interpreting, reassuring, and responding all day without anyone calling it a retainer.
This slide has message reveal actions. Advance/click through each notification: “Can you check this?”, “While you’re in there…”, “Can you join our Slack?” Then point to the attention meter and say “this is what actually fills up.”
This also changes how I think about price, because the value was never just the hours.
Faster delivery does not make the outcome worth less.
4 minIf AI helps me do something in two hours instead of twenty, that does not mean the outcome became less valuable.
- The value is not the typing. The value is the judgment.
- You are paid for knowing what to build, what not to build, what risk to remove, and how to make the result useful.
- Picasso principle: the value is knowing where to draw the line.
Tie this directly to GPA: the work is not “we typed into AI for you.” The work is deciding what the team should automate first, then building and shipping something that fits the business.
No reveal action. Point to “2 hrs” first, then “Outcome Value,” then walk down the three drivers: judgment, risk removed, leverage created.
And the cleanest sign that you created value is that the client can run it without you.
Design the exit before you say yes.
4 minDone means someone else can run it.
- If only you can operate it, you did not ship a system. You shipped a dependency.
- The exit needs to be designed before the yes, not after everyone is tired.
- Handoff is part of done: docs, walkthrough, owner.
Use the “undocumented magic” cautionary story. Clever work that only you understand feels impressive in the moment, but it is not leverage for the client. It is a future support ticket.
No reveal action. Point through the handoff stack: Docs, Walkthrough, Owner. Then point to the exit door and say the slide line: “Done means someone else can run it.”
If we compress all of this into what you can use tomorrow, it comes down to three moves.
Three moves that keep AI work bounded.
2–3 minWhat did we learn today? Not that you should build less. The opportunity is real. The lesson is that ownership has to be explicit.
- Scope the promise: learning, production, or operating commitment.
- Name the tail: maintenance, support, approvals, communication, and monitoring.
- Design the exit: docs, walkthrough, owner, and handoff.
- Said as questions before any yes: what promise am I making, what tail am I owning, how do I leave?
- Tomorrow, use this before the next “quick yes.”
Tell the larger takeaway story: the people who win with AI will not just be the fastest builders. They will be the clearest operators. They will know what they are willing to own and what needs a boundary.
No reveal action in the current deck version. All takeaway cards are visible. Use this as the actual wrap-up, not as a new teaching slide.
Now I want to make this useful, so let’s take questions through the lens of tiny yeses.
Questions.
Q&AFor questions, the most useful version is: bring me a tiny yes you are considering, or one you already regret.
- Ask for the scenario in one sentence.
- Classify the trap: scope, maintenance, stakeholders, dependency, or attention.
- Name the hidden tail.
- Write one boundary sentence they can actually say.
If the room is quiet, seed the first example yourself: “A client says, can you just join our Slack so we can ask quick questions?” Then model how you would answer and show the framework working live.
No reveal action in the current deck version. The three Q&A prompts are visible. Use them as the facilitation structure.
I’ll pause there. Thank you for spending the time, and if you want to keep the conversation going, connect with me here.
Thank you.
30 secThanks for being here. Keep building. Keep the boundaries.
- Invite people to scan the QR code.
- Say the URL if needed: linkedin.com/in/scottmurtaugh.
- If someone has a client situation, internal automation question, or tiny yes they want to sanity-check, ask them to connect and send it over.
This is not a long story slide. Keep it warm and brief. The final idea: the fastest builders will not automatically win; the clearest owners will.
No reveal action. Leave the slide up so people can scan the QR code. Do not rush the final visual.
Final line if you want one: The builders who win with AI will not just be the fastest. They will be the clearest about what they are willing to own.