The Ask We All Get Eventually
A client shows genuine interest in ServiceNow Build Agent. They've seen the demos, heard the "vibe coding" pitch, maybe watched a colleague at another company rave about it. But before they'll commit budget to licenses and subscriptions, they want proof — real, hands-on evidence that it's worth paying for, not just a vendor slide deck.
That's a fair ask. It's also a much bigger project than it sounds like at first, because "just try it and tell us what you think" hides a string of harder questions: Try it where, since we don't have it internally? Try it on what, since our real backlog doesn't look complex enough to need it? And once we like it, how do we actually get a "yes" from every stakeholder who has a say?
This article walks through how we worked through that whole chain — from getting hands-on access with zero budget, to figuring out what would actually impress a skeptical management team, to building a review process for AI-generated work, to sequencing the pitch itself so it survives contact with security, finance, and engineering leadership.
Step 1: You Don't Need a Company License to Get Hands-On
The first obstacle is deceptively simple: your own organization doesn't have Build Agent to practice on. The instinct is to assume you need the client (or your own company) to buy something first — but that's backwards.
ServiceNow's Personal Developer Instances (PDIs) are free, and Build Agent is available there in trial form. Here's the practical path:
- Request or reset a PDI at developer.servicenow.com. If usage limits run out, you can release and re-request a fresh instance.
- Confirm your PDI is on a recent release — some older instances don't have Build Agent available yet.
- Install the "Build Agent (Trial)" app from the Store, or activate the underlying plugins directly if Store access is limited. This gives you a capped number of free interactions to work with — enough to build and iterate on something real.
- Watch for known friction points: Store access can be inconsistent on PDIs, some releases need a patch upgrade first, and you may need the right role assigned to even see the Build Agent option.
The bigger nuance, though, is what Build Agent is actually for on a PDI. It builds new custom applications — it doesn't configure or extend big pre-built product suites like ITSM, GRC, SPM, or BCM, which are separately licensed products with their own availability quirks on developer instances. So the fair test isn't "can I get GRC running on my PDI" — it's "can I build a custom app that models this domain's workflow the way a real client would need it." That distinction matters, because it changes what you should even attempt to build.
Step 2: Toy Apps Don't Convince Anyone
Once you have access, the temptation is to build a handful of simple example apps across different domains — an equipment request tracker, a risk register, a vulnerability log — and show them off one by one.
Don't. A basic single-table request-and-approval app is something any competent developer could build manually in a day. Showing it off as a "look what AI can do" moment invites the obvious pushback: we could have built that anyway — what did this actually save us?
What actually creates the impression of an achievement, rather than a toy:
- State the time comparison explicitly. Don't just show the output — say what a developer would normally estimate for the same scope, and what Build Agent actually took.
- Pick complexity that's genuinely hard to hand-code quickly — multiple related tables, conditional business logic, a working integration to an external system. Integrations especially tend to be the moment people stop being skeptical.
- Anchor the build to a real, unmet need the client already has — not a generic example. "This is the app your team requested months ago that's still in the backlog" is a story people remember.
- Show a live iteration, not just a finished screenshot. Watching a plain-English change request get applied instantly, live, outperforms ten static slides.
- Be honest about the misses. If something needed manual fixing, say so. A demo that looks too polished to be real erodes trust rather than building it.
Step 3: The Real Objection — "Our Backlog Isn't That Complex"
Here's where the conversation took its most useful turn. A fair challenge came up: in practice, client product managers don't always have deeply complex stories every sprint. Plenty of sprint work is smaller, sometimes even scrambled together near sprint planning just to fill capacity. Using an AI build tool for that can feel like using a sword where a needle is needed.
That reframes the whole ROI argument. A single, impressive, complex flagship demo doesn't map to how most sprints actually look — so proving value on a hard problem alone risks missing the point entirely.
The better argument isn't about complexity at all. It's about volume of small, repetitive scaffolding work — new tables, basic forms, single approval steps, notification rules — the kind of thing that isn't intellectually hard but still eats real developer hours every single sprint. That's exactly the work an AI build tool compresses, regardless of how "advanced" any individual story is.
So the strongest pitch is grounded in the client's own historical data, not a hypothetical:
- Pull 8–10 real completed stories from the last two or three sprints — including the smaller, less glamorous "filler" ones, not just the impressive ones.
- Get the original estimated effort (story points or dev-hours) for each, from actual sprint records.
- Rebuild three or four of them with Build Agent and time the real result.
- Present the delta as a capacity argument: "Of your last three sprints, X% of stories looked like this. Build Agent produced comparable results in a fraction of the estimated time."
This does something a single flagship demo can't — it's about the client's own backlog, so it can't be waved away as a staged trick, and it reframes the value from "look at this cool thing" to "here's capacity we get back every sprint, compounding," which is the number that actually moves a purchasing decision.
Step 4: AI-Generated Work Needs a Different Kind of Peer Review
Once Build Agent output is real and in front of people, the next question is inevitable: how do you review it? A standard code review checklist, built for human-written code, misses the failure modes specific to AI-generated applications.
Some of what tends to go wrong is different from the usual bugs: the model can misinterpret parts of a prompt, generate unindexed queries that only surface as timeouts under load, or default to overly broad access permissions because that's the "safe-looking" choice. Large, single-prompt attempts to build an entire interconnected app tend to be more inconsistent than the same app built through smaller, iterative prompts.
A useful review structure works in four layers:
- Correctness vs. intent — does the generated data model and logic actually match what was asked, including edge cases the prompt didn't explicitly cover?
- Platform fit — did it reuse existing tables and follow your org's conventions, or quietly duplicate what already exists? Are queries indexed properly? Are permissions least-privilege?
- Security and compliance — is any sensitive data exposed, are integration credentials handled properly, is there proper audit tracking where needed?
- Maintainability — can a human developer actually read and modify this later, or is it a functional but opaque black box?
Modern platform tooling now handles some of this automatically — deployment approvals, release management, and quality-gate testing are increasingly built into the platform layer rather than left entirely to manual review. That doesn't remove the need for human review; it changes where review effort should be spent, shifting it toward the judgment calls a quality gate can't make on its own.
Turning this into a simple pass/fail checklist, used consistently across every pilot app, becomes a second piece of evidence for management: it shows discipline around the tool, not just enthusiasm for it — often the exact thing that turns hesitation into approval.
Step 5: Naming the Concerns Before Someone Else Does
No responsible evaluation stops at "look how fast this is." A serious look at Build Agent surfaces real concerns that deserve honest treatment rather than being glossed over:
- Cost isn't flat. Usage is metered beyond free tiers, so cost scales with adoption — model a range of usage scenarios rather than quoting a single number.
- Shadow AI and app sprawl. When building is this easy, the risk isn't bad apps, it's too many half-adopted ones with no clear owner months later. Governance tooling and an internal app registry (owner, purpose, review date per app) address this directly.
- Data privacy. What exactly gets sent to the underlying model, and how, deserves a documented, verified answer from the platform vendor — not an assumption, especially since access paths differ across tools.
- Complex logic still needs a human. Productivity gains aren't uniform; simple work sees the biggest lift, complex business-critical logic still needs senior review before deployment.
- Skill erosion. If AI handles most scaffolding, junior developers get less hands-on practice with fundamentals. Keeping some manual-build work in rotation, plus mandatory peer review, keeps this in check.
- Legacy mess gets replicated, not fixed. Because the tool grounds its output in what already exists on an instance, an already-messy data model tends to get mirrored rather than corrected. A light instance health check before a serious rollout catches this early.
- Ownership after deployment. Who supports a Build Agent app when something breaks in production needs to be explicit in the agreement, not assumed.
None of these are unique to this tool — they're the standard checklist for adopting any new enterprise development capability. The point isn't that concerns exist; it's that they were surfaced deliberately, before a client's security or finance team found them first.
Step 6: The Governance Layer Nobody Asks About Until It's Too Late
Everything so far covers what shows up in the first few months — the pilot, the review process, the obvious risks. A genuinely mature pitch also accounts for what surfaces later, once the tool is embedded in real delivery work. These are the questions that don't come up in the excitement of a good demo, but will eventually come up in a contract renewal, an audit, or an incident review — and it's far better to have answers ready than to be caught improvising.
Intellectual property and code ownership. Who owns the code, workflows, and configurations Build Agent generates — your firm, the client, or does it depend on the license terms? This is easy to assume is obvious and often isn't, especially once a third-party AI coding tool is in the mix (Build Agent now works inside Claude Code, Cursor, Windsurf, and GitHub Copilot, each potentially with its own terms layered on top of ServiceNow's). Get the actual contractual language reviewed by whoever handles vendor agreements before this becomes a live issue, not after a dispute.
Data residency and industry-specific regulation. Beyond the general data privacy question already raised, regulated industries (healthcare, finance, government) often have hard requirements about where data is processed and which frameworks apply — HIPAA, SOX, GDPR, or sector-specific equivalents. This needs a specific, written answer for the client's actual industry, not a general assurance that "data is handled responsibly." If the client operates across multiple regions, this may not have one uniform answer.
Vendor lock-in and an exit strategy. The more delivery work leans on Build Agent, the more a team's velocity depends on a single vendor's roadmap, pricing, and continued support. It's worth asking upfront: if pricing changes significantly, or the tool is deprecated or restricted, how easily can the client's applications be maintained without it? Since the platform's governance layer keeps generated apps as standard ServiceNow artifacts under normal platform rules, the underlying apps themselves aren't locked in — but the team's working habits and velocity assumptions can quietly become dependent on the tool in a way that's worth naming explicitly rather than discovering later.
Model drift and reproducibility. The underlying AI model evolves over time, which means a prompt run today may not produce identical output if run again in six months. For most day-to-day app-building this doesn't matter much, but it does mean prompts shouldn't be treated as permanent documentation of how an app was built — the generated app itself, plus proper in-platform documentation, is the artifact of record, not the prompt history.
Environment promotion path. A detail that's easy to skip in a pilot but essential at scale: what does dev → test → production promotion look like for an AI-generated app? Does it go through the same change management and approval gates as manually built applications, or does it need its own defined path? The platform's governance tooling (deployment approvals, release management) should apply uniformly here — the policy just needs to say so explicitly, rather than leaving it ambiguous whether AI-generated apps get a shortcut through review.
An ongoing ownership structure, not just a pilot sponsor. A pilot needs one sponsor; sustained adoption needs a standing owner. Many organizations handle this with a small internal group — sometimes called a Center of Excellence or simply a platform governance group — responsible for maintaining the custom instructions/standards the tool follows, reviewing usage patterns, updating the app registry, and deciding when policies need to change. Without this, the good habits built during the pilot tend to quietly erode once the initial excitement fades and nobody owns keeping the discipline going.
Change management for the delivery team itself, not just leadership. Every stakeholder conversation covered so far is about getting a "yes" from people who approve budget and policy. There's a separate, quieter audience: the developers who'll actually use the tool day to day. Some will be enthusiastic; others may reasonably worry about what it means for their role or their skill development. Addressing this directly — framing the tool as removing scaffolding work so developers spend more time on the parts of the job that require real judgment, and backing that up with the skill-development safeguards already planned — matters as much for successful adoption as any executive sign-off. A pilot that leadership approves but the delivery team quietly resists rarely produces the results the business case promised.
Success metrics that outlive the pilot. The historical sprint comparison proves value once. Sustained adoption needs a lighter, ongoing version of the same measurement — usage volume, time saved per app category, defect rates on AI-assisted work versus manually built work, and adoption rate across the team — reviewed on a regular cadence rather than measured once and assumed to hold. This also gives the governance group something concrete to report back to the stakeholders who approved the pilot, closing the loop rather than letting the initiative go quiet after the initial rollout.
Step 7: You Don't Convince Everyone in One Room
With that much material — upside, evidence, risks, and mitigations — it's tempting to think the list of concerns alone makes the case too complicated to sell. It doesn't. It just means the pitch shouldn't be delivered as one document to one audience all at once.
Different stakeholders care about different slices of the same evidence:
- Internal sponsor first — lead with the capacity story and the flagship demo, and use them to map out who else needs to say yes, and in what order.
- Security and compliance — lead with the data privacy answer and the governance layer already in place. Surface objections here, privately, before they become a surprise later.
- Engineering and delivery leadership — walk through the peer review checklist with real results, the skill-erosion mitigation, and a clear ownership plan. This group has to live with the tool day to day, so their buy-in needs to be genuine, not just approved from above.
- Finance and procurement — a clean, confirmed cost model tied directly to the capacity numbers from step one. Nothing else needs to be in this meeting.
- Executive sign-off — by this point, most objections have already been resolved privately. The final pitch can stay short: the demo, the numbers, a note that security, engineering, and finance have already weighed in, and a proposal for a narrow, reversible pilot rather than full adoption.
That last point matters more than anything else in the sequence. Asking for a small, time-boxed pilot with defined success metrics is a fundamentally easier "yes" than asking for permanent adoption up front — and it turns most of the risk list from a blocker into "here's our plan for later," which is a much more comfortable place for any stakeholder to sit.
The Bigger Takeaway
None of this is really about ServiceNow Build Agent specifically. It's the same playbook for proving the value of any new capability to a skeptical organization: get real hands-on evidence cheaply, ground your proof in the client's own reality rather than a generic demo, build a review process before someone asks for one, name the risks before someone else names them for you, put a governance structure in place that outlives the initial excitement, and stage the pitch to match how organizations actually make decisions — one convinced person at a time, not one room.
Done this way, "try it and convince us" stops being an intimidating open-ended ask and becomes a structured, evidence-backed process with a clear finish line: not just a small, well-governed pilot that speaks for itself, but a foundation that's still standing — and still trusted — a year after the excitement of the first demo has worn off.
No comments:
Post a Comment