Haven't taken the check yet? Do that first — 14 questions, about four minutes. It scores you on the three areas below and tells you which one to fix first. Already have your result? Jump to your weakest area: Fit · Rollout · Governance.

01The model

Three things to get right. Fit without rollout is shelfware; rollout without governance is an ungoverned data flow at scale.

01Fit — each tool maps to a named problem and a workflow people already have — with an owner who decides what’s rolled out.
02Rollout — you can deploy to a team, onboard people, measure adoption, and keep it alive if the champion leaves.
03Governance — you know each tool’s data flow, own and scope any API keys, and the tools fit a privacy and AI-usage review.

The check scores each and gives a combined grade from Curious to Embedded. The engagement, in a sentence: find the weak one and reinforce it first.

02Fit

Fit is whether a tool maps to a named problem here, or just looks useful. The test: can you point at the outcome you'd notice if adoption worked — not an install count?

What good looks like
  • Each tool addresses a named problem here — not “this looks useful”.
  • Tooling has one owner who decides what's rolled out, configures it, and fields questions.
  • The tool slots into a workflow people already have — it isn't a new habit nobody asked for.
  • The intended users have tried the free beta and fed back before any rollout.
  • “Adopt a tool” is tied to an outcome you'd notice — not an install count.
Common failure
  • Shiny-object install — adopted because it's clever, not because it solves a named problem.
  • Nobody owns it — so nobody configures it, answers questions, or notices it died.
  • New habit nobody asked for — the tool needs a workflow that doesn't exist yet.
Your first move
If you're just starting

Start from the problem, not the tool. For each tool you're considering, name the specific pain it addresses here and the workflow it slots into — and give tooling a single owner. Then get the intended users onto the free beta and collect real feedback before any rollout.

If it's partly there

The interest is real but loosely tied to outcomes. Pin each tool to an outcome you'd actually notice — fewer weak prompts shipped, dark patterns caught in procurement, AI use made visible — and make the owner's remit explicit so decisions don't stall.

If it's already strong

Keep the owner close to the users, keep checking each tool against the outcome it's there for, and drop any tool that stops earning its place as the practice moves on.

Go deeper

  • For each candidate tool, write one sentence: the problem it solves here, and the workflow it joins.
  • Name a single tooling owner with the remit to decide what's rolled out and configure it.
  • Run a two-week beta with the intended users and collect written feedback before committing.

03Rollout

Rollout is whether a tool gets deployed and adopted, or dropped in a channel and forgotten. The test: if the champion left tomorrow, would it survive?

What good looks like
  • Browser policy allows extensions, and there's a managed way to deploy them.
  • There's real onboarding — “what it does, how we use it” — not a link in a channel.
  • Adoption is measured — who's using it, is it helping — not assumed after launch.
  • Users have a channel to report friction that reaches someone who can act.
  • If the champion leaves, tooling survives — config documented, more than one person across it.
Common failure
  • Link-and-leave — dropped in a channel, no onboarding, no follow-up.
  • Adoption assumed — nobody checks who's actually using it after launch.
  • Bus factor one — config lives with the champion; it dies when they leave.
Your first move
If you're just starting

Right now this can't scale past a champion. Confirm browser policy allows extensions and find the managed way to deploy them, write a short "what it does / how we use it" onboarding, and make sure config is documented and known to more than one person.

If it's partly there

Deployment works but adoption is assumed. Start measuring who's actually using it and whether it helps, give people a real channel to report friction that reaches the owner, and set a review point rather than a launch-and-forget.

If it's already strong

Keep onboarding part of joining the team, keep the adoption check and the feedback channel live, and keep the bus factor above one so tooling survives a departure.

Go deeper

  • Write a one-page onboarding per tool: what it does, how we use it here, where to ask for help.
  • Pick one adoption signal — weekly active users, or a usage marker — and check it a month after launch.
  • Document the config somewhere the owner isn’t the only one who can find it.

04Governance

This is the exposed one. Governance is knowing each tool's data flow rather than assuming it — and bringing any API keys and reviews up to the same bar as other software.

What good looks like
  • You know each tool's data flow — what runs locally in the browser vs what calls an API.
  • Any API key is owned, scoped and rotated — not pasted from a personal account.
  • The tools went through the same privacy and security review as other software.
  • The tools are explicitly covered by your AI-usage policy — or the policy gets written.
Common failure
  • Personal keys — a tool running on someone's private API account, unmanaged.
  • Off the governance radar — never reviewed like other software, invisible to the AI policy.
  • Assumed data flow — nobody has actually checked what leaves the browser.
Your first move
If you're just starting

For each tool, write down its data flow — what stays in the browser versus what calls an API. Bring any API keys under ownership (scoped, rotated, not personal), run the tools through the same privacy and security review as other software, and check them against your AI-usage policy — or write the policy.

If it's partly there

The basics are known for the main tool but not consistently. Extend the data-flow write-up to every tool in use, get key management to owned-scoped-rotated, and make the tools explicitly part of the AI-usage policy rather than adjacent to it.

If it's already strong

Keep the data-flow notes current as tools update, keep keys rotating, and re-run the review whenever a tool changes what it sends or a new one comes in.

Go deeper

  • Write a short data-flow note per tool: local-only vs API calls, and what data each call carries.
  • Move any API key off a personal account to an owned, scoped, regularly-rotated one.
  • Add the tools by name to the AI-usage policy — or use their arrival as the reason to write it.
🧰

The four JTC tools — Guardian AI, PromptForge, Dark Pattern Detector, Scrum Toolkit — are all free public beta and sell as rollout within an engagement, not licences. The incentive is adoption that sticks, not seats.

05Do this in the next two weeks

  • Take (or retake) the readiness check and note which of fit, rollout or governance scored lowest.
  • For fit: write the one-sentence problem-and-workflow for each candidate tool, and name a tooling owner.
  • For rollout: draft a one-page onboarding per tool, and pick one adoption signal to check a month out.
  • For governance: write a data-flow note per tool, and move any key off a personal account.
  • Add the tools by name to the AI-usage policy — or use them as the reason to write it.
  • Pick the single weakest area, put a named owner and a date on its first move, leave the other two as "next".

Still stuck?

If the weak area won't move — tools keep getting installed and abandoned, adoption never gets measured, the data flow stays unchecked — that's the point to bring Jon in. Pick one tool tied to the sharpest problem, often alongside a governance audit, roll it out properly (owner, onboarding, policy setup, adoption check), then govern and embed it with a data-flow note and key management.