Why the build half of a project keeps getting easier — and why the adoption half is what actually decides whether the work lands.
Start LessonAI-assisted development has dramatically lowered the cost of the build half of staff-led innovation. Staff without a traditional engineering background can now produce functional tools — given enough specification skill and time.
The adoption half — onboarding scaffolds, integration into existing workflows, the institutional context that makes a would-be user invest the activation energy to actually use the tool — costs the same as it always did. And it typically does not sit inside a single staff builder's scope.
That asymmetry shapes what staff-led innovation can and can't accomplish on its own. Recognizing it changes how a project should be planned, scoped, and resourced.
This field guide walks you through both halves: the discipline questions for the build, the structural questions for adoption, and the decision points where the two have to meet.
Ready when you are
ContinueThe two halves of a staff-led tool project are not symmetrical. They have different cost curves, different owners, and different failure modes. Switch between the tabs below to see each half on its own terms.
With AI-assisted development, a staff member who can write a clear scope document, a real use case, and outcome-shaped specifications can produce a functional tool. The leverage now lives in specification — not in writing code.
Onboarding scaffolds, workflow integration, and institutional context still cost what they've always cost. They don't get cheaper just because the tool got cheaper to build — and they rarely fit inside a single builder's scope.
Ready when you are
ContinueEach half has its own discipline questions. The build-side questions help you keep the work load-bearing. The adoption-side questions help you name what would have to be true for the work to actually land.
What is the smallest version of this tool that solves the actual problem? Anything beyond that is a choice, not a requirement.
What infrastructure am I taking on with this build — servers, accounts, hosting, stored data? Can I solve the same user problem with less? (More build means more maintenance.)
What am I building because the tech is interesting, vs. what the user actually needs?
Which quality concerns am I designing in from the start vs. bolting on at the end?
Accessibility is the canonical test — but the same question applies to data privacy, security, and performance. Each one is dramatically cheaper to design in than to retrofit.
Can I write a clear scope document, a real use case, and outcome-shaped specifications for what I want?
If yes, the build cost is lower than ever. If not, invest in the specification work first — that is where the leverage now lives, not in writing code.
First-use experiences, starter templates, walkthroughs that get a user from zero to a working artifact.
Without these, even the friendliest expert user will stall in the first session and not return.
Clarity on the existing process this tool slots into, and the friction it removes from that process.
A tool that asks users to invent a new workflow around it almost never gets traction.
A reason for the would-be user to invest activation energy now. A mandate, a strategic initiative, an integration with something they already use, a course they're already redesigning.
"Available" isn't a reason. "Aligned with what I have to do this semester" is.
Someone whose job, in part, is to help users cross the gap from aware of the tool to using the tool.
This is rarely the same person as the builder. If it isn't named, it doesn't happen by default.
If the adoption half can't be resourced, is the tool still worth building anyway? Sometimes yes — for proof of concept, capability building, scholarly contribution. Naming the question explicitly is how it gets answered well.
Ready when you are
ContinueWalk the project through both halves before adding more scope. The point isn't to slow the work down — it's to keep the work load-bearing and to surface decisions that would otherwise be made by drift.
What scope am I taking on that isn't load-bearing? Which discipline questions am I avoiding? What am I building because the tech is interesting rather than because the user needs it?
What would have to be true for this tool to be used, not just available? Which of those conditions exist now? Which don't? Who is responsible for the conditions that don't yet exist?
If the adoption conditions don't exist and can't be created within scope, say so explicitly. Then decide: keep building, pivot scope, or hand off — rather than letting the project drift into exists but isn't used by default.
Test your understanding
Knowledge CheckIt's to make sure what gets built does the work it was meant to do — and that what doesn't get the support to be adopted is at least known not to, rather than discovered later.